Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths
draft-ietf-pce-pcep-p2mp-extensions-11

[Ballot discuss]
1) the new text in 3.10 paragraph 4 is a bit difficult to read. It has an incomplete sentence - 2d sentence in paragraph 4. In addition, sentence 3 seems to be an addendum "also requested" to sentence 4 "The IANA request". please also correct "The The"

[Ballot comment]
I support Tim's DISCUSS position too.

Some new comments based on Russ Mundy's SECDIR review:

1) RFC4875 Security Considerations requires that the ingress LSR of a
  P2MP TE LSP the leaves for the P2MP LSP for use in multi-vendor
  deployments.  Although it's not clear that this document needs to
  provide this requirement, I wanted to flag the requirement in case
  that it had been overlooked.

[Ballot discuss]
I updated my DISCUSS to remove the DISCUSS-DISCUSS.  Everything else remains the same.

PCEP requires use of TCP-MD5 with recognition of its failings, specifically mentioning that TCP-AO was not yet complete.  But as TCP-AO has now passed the IESG, should there be some recognition of that change?

[Ballot comment]
I support Tim's DISCUSS position too.

Some new comments based on Russ Mundy's SECDIR review:

1) RFC4875 Security Considerations requires that the ingress LSR of a
  P2MP TE LSP the leaves for the P2MP LSP for use in multi-vendor
  deployments.  Although it's not clear that this document needs to
  provide this requirement, I wanted to flag the requirement in case
  that it had been overlooked.

[Ballot discuss]
PCEP requires use of TCP-MD5 with recognition of its failings, specifically mentioning that TCP-AO was not yet complete.  But as TCP-AO has now passed the IESG, should there be some recognition of that change?

This is DISCUSS-DISCUSS (i.e, nothing for the authors to do at this time):

This doc does not seem the proper place to change the PCEP recommendation, but a change in the MUST requirement in PCEP (RFC5440) seems to be something to consider somehow.

[Ballot comment]
> 4.6. Impact on Network Operation

>  It is expected that use of PCEP extensions specified in this document
>  does not have significant impact on network operations.

While the addition of PCEP-P2MP extensions may have minimal impact on the level of traffic and operations, the applications that are enabled by activating these extensions may result in increased traffic and operational complexity.

[Ballot discuss]
The DISCUSS is partially based on issues raised initially by Fred Baker in the OPS-DIR review.

> 4.2. Information and Data Models

>    As described in [PCE-P2MP-REQ], MIB objects MUST be supported for
>    PCEP extensions specified in this document.

As the existing PCEP MIB document
(http://tools.ietf.org/html/draft-ietf-pce-pcep-mib-01) does not support P2PM, it was agreed by the WG at IETF77, to create a new PCEP MIB module specifically to support PCEP P2MP. If such a MIB document already existed it would be good to be included as an Informative Reference. Otherwise some text should be added to 4.2 on this respect.

[Ballot comment]
I found the document difficult to read and review.

The requirements section 2 doesn't use sentences, so it is difficult to understand what the requirements actually are without going to the REQS document; if you need to do that anyway, why bother summarizing here?

I expected that the summary was provided because the following text would refer to speciifc requirements that were being met, but it doesn't. So I am not sure of the value of having the summary here.

The document contains quite a lot of redundancy (some from cut-and-paste operations). For example, the first sentences of 3.4 and 3.5 say the same thing in different words:
"The PCReq message is encoded as follows ..."
"Below is the message format for the request message:"

The document uses inconsistent terminology. I was looking to verify the IANA requests, and the text in 3.1.2 describes "The TLV Type number (TBA by IANA) ...". In the IANA section, "TLV Type numbers" are not discussed. You need to look in the "P2MP Capability TLV" section, where the "PCEP TLV Type Indicators" registry is discussed. This type of inconsistency just makes it hardedr to read and understand the document.

3.1.2 discusses a TLV, and then decribes the type and value; where's the label?

/Note that/ is almost never needed.

Purely a style issue, but in 3.3.1, I would have put the description of the F-bit ("The F bit is added") with the description fo the enumarted values of the F bit. Ditto, the N and E bits.

F bit enumeration (1) "... the receiver needs to wait until it receives an RF with the same RP-ID and with the F bit is set to 0." Should it also wait for possible additional fragments until is does receive one with an f bit of 0?

in 3.4, the last sentence says "must be present in this definition." In the definition or in messages?

in 3.5, where is  defined? I see  and , but not .

in 3.7 (and elsewhere), "... computation request must then be cancelled." How does one cancel a P2MP request? Is there a reference?

in 3.8, "if a PCC inadvertently sends a P2MP request ..." - what happens if a PCC maliciously and deliebrately sends a P2MP request? I think it would be better to reword this so it is not about the PCC, but just about the PCE. "If a PCE receives a P2MP request, and the PCE does not support P2MP ... extensions, then it should reject the request." But even better yet, shouldn't it already reject requests it doesn't understand? So this section shouldn't even be needed, right?

section 3.9 discusses a reoptimization request expressing a cost-benefit reoptimzation threshold. But that functionality is not defined here and "may be addressed in a future document." Is there soemthing specific about such a function that MUST be discussed here to ensure that implementations do not preclude such a future functions? If not, then why bring it up in this document? Let the future document discuss this possible new function.

in 3.10, there is no case 4.
I recommend you use case#s OR figure #s, but not both. Having both is redundant and potentially confusing to readers.

in 3.12, pleae provide a reference for SVEC.

in 3.12, consistency would be nice: Diversity bit, or Diverse bit?

in 3.13, s/thousands of leaves. Then/thousands of leaves, then/

in multiple places s/indentify/identify/

some of the text in 3.13, 3.13.1, and 3.13.2 is redundant. It might be best to just have it in 3.13. If you want it in 3.13.1 and 3.13.2, then you don't need it in 3.13.

in 3.13.3 "The assumption is that ..." - would that be better as "The assumption used for this example is that ...". I assume that is the reason for the assumption; otherwise please explain why this assumption is made.

in 6.1, I recommend s/P2MP Capability TLV/PCEP TLV Type Indicators/

in 6.5, for some reason, the HTML bold formatting is lost.
In the document text, this is sometimes called Objects and Values rather than PCEP objects. I would be helpful to be consistent.

[Ballot discuss]
1) section 3.1.1 discusses advertising P2MP by setting bit 10 (TBA by IANA), but this request is not made in the IANA section. Later text

2) cut and paste error in section 3.5
s/PCReq/PCResp/

3) in 3.7, if a PCE ... understands the P2MP flag, but the PCE is not capable ..., it must send a PCErr ...". The P2MP flag can be set to mean "this is not a PCReq/PCRep for P2MP" (section 3.3.1). So if the PCE understands this is not a request for P2MP and the PCE cannot do P2MP, why is that an error?

4) in 3.7, if teh PCE does not understand the P2MP flah, it is required to send a new error type. If, say, an existing implementation doesn't understand the P2MP flah because it doesn't support P2MP, why do we think it supports the new error type defined in the P2MP spec?

5) in 3.8, is the current behavior (in implementations that have not implemented the P2MP spec) to reject the request?

6) in 3.10, "it SHOULD be possible", does this mean "implementations SHOULD support the optimization functionality defined in this document"? or is implementation of the optimization functionality defined in this document REQUIRED for compliance? Can you make sure the document is clear on that point?

7) throughout 3.10, the word "must" is used; shoudl this be MUST in an RFC2119 sense?

8) "To remove old leaves the user must ..." - is it possible to get an error because there are no leaves that can be removed? I note that error 17 value=1 is for "no END-POINTS with leaf type 2". I am not quite sure when that error occurs.

9) in 3.10, "The PCC must also provide the list of old leaves and indicate if they should be reoptimized or not ..." What if the PCC knows that the PCE does not support reoptimization? Is it still required? What if the PCC doesn't care whether it gets reoptimized or not? Why is it required that the PCC provide this?

10) In 3.10, what error code is returned if the PCC does NOT provide any type 3 or type 4? Should it return an error 17 value=2, or error 17 value=3?

11) in a pruning operation, what error is returned if a leaf is specified in both the END-POINTS type 2 and END-POINTS type 4?
(or type 2 and type 3)?

12) in an add operation, what error is returned if a leaf specified in type 1 already exists?

13) in 3.12, "This specification also defines two new flags to the SVEC object". Where? I didn't find any mention of SVEC or P and D flags in the IANA section. The sections says it is in 6.2, but 6.2 defines the F,N,E flags in the RP Object.

14) in 3.13.2 Response Fragmentation, a couple cut and paste errors:
"If the response is too large ... the PCE will split the request ..."
"Each message sent to the PCE ... to signify the response has been fragmented ..."

15) in 3.13.3, I think the example text is ambiguous
"RP2 with Req-ID1 and P2MP flag and F bit cleared."
Does this mean the P2MP flag is cleared as well as the F bit?
You might be clearer if you used something like:
RP2 with ReqID=1, P2MP=1, Fbit=0.

16) in 3.13.3, "To handle the scenario ... it should send an error message to the sender ..." What error message should it send?

17) in 3.14, why is the list of unreachable destinations optional?

18) in 3.14, it is not obvious to me where this body goes inside the PCRep message format. This might be my lack of understanding of other standard PCEP objects, but PCRep is defined in 3.5. Where does the class and type associated with the body get specified in PCRep?

19) "This object can be present in PCRep messages. There can be up to one such object per RP." Maybe I just haven't found this yet. Can I have more than 1 RP in a PCRep?

20) in 4.1 "MAY be required" - I don't know what that means in terms of RFC2119 compliance.
Could the requirements list be made of sentences? I don't know how to interpret these non-sentences - both, although the first I think I can figure out. The second I definitely do not understand:

21) "Advertisement of P2MP path computation capability enabled or disabled" - does this mean I must be able to enable/disable the advertisement of the information, or that I must advertise whether the capability is enabled/disabled?


22) in 4.2, "MIB objects MUST be supported" - what MIB objects? Are these standardized? Where are they specified? Is there a reason to not include the relevant MIB objects in this document?

23) in 4.4, how does on everify correct operation of P2MP calculation?

24) in 4.5, "A new flag (value=10) could be defined ..." But this document does not do so, and I think this is the same flag mentioned in 3.1.1 (TBA by IANA) that isn't defined here.

25) in 5, "... and the implementer utilize ..." - is this the operator that needs to utilize, or the implementer?

[Ballot comment]
The following text
====

Four values are possible for the leaf type field:

  1.  New leaves to add;
  2.  Old leaves to remove;
  3.  Old leaves whose path can be modified/reoptimized;
  4.  Old leaves whose path must be left unchanged.

====

Is almost identical to the text two lines above, and the list entry numbers are I think the values, but this is not a clear way to show it.

If the authors think there will ever be more than 4 operations, they should consider using a registry.

[Ballot discuss]
The text under figure 2 looks to be incorrect, the length in the IPv6 case is surely n*16 + 4, and not n*16 bytes.

[Ballot discuss]
The security considerations state:

  As described in [PCE-P2MP-REQ], P2MP path computation requests are
  more CPU-intensive and also use more link bandwidth.  Therefore, it
  may be more vulnerable to denial of service attacks. Therefore it is
  more important that implementations conform to security requirements
  of [RFC5440], and the implementer utilize those security features.

I agree with this summary entirely, with one exception: my reading of the
security considerations in 5440 indicates that these mechanisms are all
optional with the sole exception of TCP-MD5, so "conform[ing] to the
security requirements of [RFC5440]" isn't as productive as it sounds.

I think that this section should call out the mechanisms in 5440 that are
most important for addressing the attacks noted in the current text.  I would
expect the new text to be brief since 5440 already provides a nice overview
of the mechanisms.

IANA questions/comments:

QUESTIONS:

- Section 6.5 claims that six PCE Objects have been defined, but only
four object class values are present. Did you mean that six "object
type" values were defined, inside four object-classes?

- In Section 3.3.2 you refer to a new P2MP END-POINTS Object and
mention object types 3 and 4, but nowhere are these objects
registered. Shouldn't you register these object types?

- In Section 3.12 you define P and D flags for the SVEC object body.
Should these flags be registered? There's a reference to the IANA
Considerations section 6.2 but that section defines RP Object Flag
Field registrations, not SVEC Object Flag Field registrations.

- Section 3.16 claims the NO-PATH object bit is 0x24, whereas it
should be "bit 24". These do not match and should be corrected.

- Secion 3.1 contains multiple references to a "PCE-CAP-FLAGS sub-TLV of
the PCED TLV," but we have no such registry or registration. Do we
need to register the PCED TLV? If so, where? Do we need to create a
registry for its sub-TLVs?


Notes to Authors:

- Note that PCEP Objects 25, 26, and 27 have already been allocated
to another document.
- Note that some of the PCEP-ERROR Object Error Types and Values have
also been allocted to another document.


Action 1 (section 6.1):

Upon approval of this document, IANA will make the following assignment
in the "PCEP TLV Type Indicators" registry at
http://www.iana.org/assignments/pcep/pcep.xhtml

Value Description Reference
----- ----------- ---------
TBD(6) P2MP capability [RFC-pce-pcep-p2mp-extensions-09]


Action 2 (Section 6.2):

Upon approval of this document, IANA will make the following assignments
in the "RP Object Flag Field" registry at
http://www.iana.org/assignments/pcep/pcep.xhtml

Bit Description Reference
--- ----------- ---------
TBD(18) Fragmentation(F-bit) [RFC-pce-pcep-p2mp-extensions-09]
TBD(19) P2MP (N-bit) [RFC-pce-pcep-p2mp-extensions-09]
TBD(20) ERO-compression (E-bit) [RFC-pce-pcep-p2mp-extensions-09]


Action 3 (Section 6.3):

Upon approval of this document, IANA will make the following assignments
in the "Objective Function" registry at
http://www.iana.org/assignments/pcep/pcep.xhtml

Code Point Name Reference
---------- ---- ---------
TBD(7) SPT [RFC-pce-pcep-p2mp-extensions-09]
TBD(8) MCT [RFC-pce-pcep-p2mp-extensions-09]


Action 4 (Section 6.4):

Upon approval of this document, IANA will make the following assignments
in the "METRIC Object T Field" registry at
http://www.iana.org/assignments/pcep/pcep.xhtml

Value Description Reference
----- ----------- ---------
TBD(8) P2MP IGP metric [RFC-pce-pcep-p2mp-extensions-09]
TBD(9) P2MP TE metric [RFC-pce-pcep-p2mp-extensions-09]
TBD(10) P2MP hop count metric [RFC-pce-pcep-p2mp-extensions-09]


Action 5 (Section 6.5):

Upon approval of this document, IANA will make the following assignments
in the "PCEP Objects" registry at
http://www.iana.org/assignments/pcep/pcep.xhtml

Object-Class Value TBD
Name UNREACH-DESTINATION
Object-Type 1: IPv4
2: IPv6
3-15: Unassigned
Reference [RFC-pce-pcep-p2mp-extensions-09]

Object-Class Value TBD
Name SERO
Object-Type 1: SERO
2-15: Unassigned
Reference [RFC-pce-pcep-p2mp-extensions-09]

Object-Class Value TBD
Name SRRO
Object-Type 1: SRRO
2-15: Unassigned
Reference [RFC-pce-pcep-p2mp-extensions-09]

Object-Class Value TBD
Name Branch Node Capability Object
Object-Type 1: Branch node list
2: Non-branch node list
3-15: Unassigned
Reference [RFC-pce-pcep-p2mp-extensions-09]


Action 6 (Section 6.6):

Upon approval of this document, IANA will make the following assignments
in the "PCEP-ERROR Object Error Types and Values" registry at
http://www.iana.org/assignments/pcep/pcep.xhtml

Error
Type Meaning Reference

5 Policy violation
Error-value=[TBD]:
[RFC-pce-pcep-p2mp-extensions-09]
P2MP Path computation is not allowed

TBD(16) P2MP Error
[RFC-pce-pcep-p2mp-extensions-09]
Error-Value=0: Unassigned
Error-Value=1:
[RFC-pce-pcep-p2mp-extensions-09]
The PCE is not capable to satisfy the request
due to insufficient memory
Error-Value=2:
[RFC-pce-pcep-p2mp-extensions-09]
The PCE is not capable of P2MP computation

TBD(17) P2MP Error
[RFC-pce-pcep-p2mp-extensions-09]
Error-Value=0: Unassigned
Error-Value=1:
[RFC-pce-pcep-p2mp-extensions-09]
The PCE is not capable to satisfy the request
due to no END-POINTS with leaf type 2
Error-Value=2:
[RFC-pce-pcep-p2mp-extensions-09]
The PCE is not capable to satisfy the request
due to no END-POINTS with leaf type 3
Error-Value=3:
[RFC-pce-pcep-p2mp-extensions-09]
The PCE is not capable to satisfy the request
due to no END-POINTS with leaf type 4


Action 7 (Section 6.7):

Upon approval of this document, IANA will make the following assignment
in the "NO-PATH-VECTOR TLV Flag Field" registry at
http://www.iana.org/assignments/pcep/pcep.xhtml

Bit Description Reference
----- ---------- ---------
(TBD)24 P2MP Reachability Problem [RFC-pce-pcep-p2mp-extensions-09]

AD review

idnits v2.12.02 says
  -- Couldn't find a document date in the document -- date freshness
    check skipped.

The page headers seem to have the expiry date not the creation date.

You can remove the Appendix and all (three) references as the new TLP covers this.

Seem to be missing a final footer and page break.

Proto-write-up for draft-ietf-pce-pcep-p2mp-extensions-08
Intended status : Standard Track

> (1.a)  Who is the Document Shepherd for this document?  Has the
>        Document Shepherd personally reviewed this version of the
>        document and, in particular, does he or she believe this
>        version is ready for forwarding to the IESG for publication?

JP Vasseur is the document shepherd.
He has personally reviewed the document and believes it is ready for
forwarding to the IESG for publication.

> (1.b)  Has the document had adequate review both from key WG members
>        and from key non-WG members?  Does the Document Shepherd have
>        any concerns about the depth or breadth of the reviews that
>        have been performed?

The I-D has been discussed and reviewed by the Working group.

> (1.c)  Does the Document Shepherd have concerns that the document
>        needs more review from a particular or broader perspective,
>        e.g., security, operational complexity, someone familiar with
>        AAA, internationalization or XML?

No concerns.

> (1.d)  Does the Document Shepherd have any specific concerns or
>        issues with this document that the Responsible Area Director
>        and/or the IESG should be aware of?  For example, perhaps he
>        or she is uncomfortable with certain parts of the document, or
>        has concerns whether there really is a need for it.  In any
>        event, if the WG has discussed those issues and has indicated
>        that it still wishes to advance the document, detail those
>        concerns here.  Has an IPR disclosure related to this document
>        been filed?  If so, please include a reference to the
>        disclosure and summarize the WG discussion and conclusion on
>        this issue.

The document is sound.

> (1.e)  How solid is the WG consensus behind this document?  Does it
>        represent the strong concurrence of a few individuals, with
>        others being silent, or does the WG as a whole understand and
>        agree with it?

Good consensus.

> (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
>        discontent?  If so, please summarise the areas of conflict in
>        separate email messages to the Responsible Area Director.  (It
>        should be in a separate email because this questionnaire is
>        entered into the ID Tracker.)

No threats. No discontent.

> (1.g)  Has the Document Shepherd personally verified that the
>        document satisfies all ID nits?  (See
>        http://www.ietf.org/ID-Checklist.html and
>        http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
>        not enough; this check needs to be thorough.  Has the document
>        met all formal review criteria it needs to, such as the MIB
>        Doctor, media type and URI type reviews?

Checks have been made. No Errors.

> (1.h)  Has the document split its references into normative and
>        informative?  Are there normative references to documents that
>        are not ready for advancement or are otherwise in an unclear
>        state?  If such normative references exist, what is the
>        strategy for their completion?  Are there normative references
>        that are downward references, as described in [RFC3967]?  If
>        so, list these downward references to support the Area
>        Director in the Last Call procedure for them [RFC3967].

References split.
No downrefs.

> (1.i)  Has the Document Shepherd verified that the document IANA
>        consideration section exists and is consistent with the body
>        of the document?  If the document specifies protocol
>        extensions, are reservations requested in appropriate IANA
>        registries?  Are the IANA registries clearly identified?  If
>        the document creates a new registry, does it define the
>        proposed initial contents of the registry and an allocation
>        procedure for future registrations?  Does it suggest a
>        reasonable name for the new registry?  See [RFC2434].  If the
>        document describes an Expert Review process has Shepherd
>        conferred with the Responsible Area Director so that the IESG
>        can appoint the needed Expert during the IESG Evaluation?

The document defines protocol enhancements to PCEP in support
of path computation for P2MP TE LSP.

The IANA section of this I-D uses the same language as the PCEP
specification and, in particular, uses the same sub-registry names.


> (1.j)  Has the Document Shepherd verified that sections of the
>        document that are written in a formal language, such as XML
>        code, BNF rules, MIB definitions, etc., validate correctly in
>        an automated checker?

No such formal language is used.

> (1.k)  The IESG approval announcement includes a Document
>        Announcement Write-Up.  Please provide such a Document
>        Announcement Write-Up.  Recent examples can be found in the
>        "Action" announcements for approved documents.  The approval
>        announcement contains the following sections:
>
>        Technical Summary
>          Relevant content can frequently be found in the abstract
>          and/or introduction of the document.  If not, this may be
>          an indication that there are deficiencies in the abstract
>          or introduction.
    The Path Computation Element (PCE) defined in [RFC4655] is an entity
    that is capable of computing a network path or route based on a
    network graph, and applying computational constraints.  A Path
    Computation Client (PCC) may make requests to a PCE for paths to be
    computed.

    [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic
    Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol
    Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.

    The PCE has been identified as a suitable application for the
    computation of paths for P2MP TE LSPs [RFC5671].

    The PCE communication protocol (PCEP) is designed as a communication
    protocol between PCCs and PCEs for point-to-point (P2P) path
    computations and is defined in [RFC5440].  However, that
    specification does not provide a mechanism to request path
    computation of P2MP TE LSPs.

    A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs.
    These S2L sub-LSPs are set up between ingress and egress LSRs and 
are
    appropriately overlaid to construct a P2MP TE LSP. During path
    computation, the P2MP TE LSP may be determined as a set of S2L sub-
    LSPs that are computed separately and combined to give the path of
    the P2MP LSP, or the entire P2MP TE LSP may be determined as a P2MP
    tree in a single computation.

    This document relies on the mechanisms of PCEP to request path
    computation for P2MP TE LSPs.  One path computation request message
    from a PCC may request the computation of the whole P2MP TE LSP, or
    the request may be limited to a sub-set of the S2L sub-LSPs. In the
    extreme case, the PCC may request the S2L sub-LSPs to be computed
    individually with it being the PCC's responsibility to decide 
whether
    to signal individual S2L sub-LSPs or combine the computation results
    to signal the entire P2MP TE LSP.  Hence the PCC may use one path
    computation request message or may split the request across multiple
    path computation messages.

>        Working Group Summary
>          Was there anything in WG process that is worth noting?  For
>          example, was there controversy about particular points or
>          were there decisions where the consensus was particularly
>          rough?

No controversy.

>        Document Quality
>          Are there existing implementations of the protocol?  Have a
>          significant number of vendors indicated their plan to
>          implement the specification?  Are there any reviewers that
>          merit special mention as having done a thorough review,
>          e.g., one that resulted in important changes or a
>          conclusion that the document had no substantive issues?  If
>          there was a MIB Doctor, Media Type or other expert review,
>          what was its course (briefly)?  In the case of a Media Type
>          review, on what date was the request posted?

Good.

There is one known implementations of the protocol extensions described
in this document.