[Pals] Last call review of draft-ietf-pals-p2mp-pw-01.txt

[Stewart Bryant <[e-mail]>]

   
Here are some last call comments on draft-ietf-pals-p2mp-pw-01.txt
written from the perspective of the document shepherd and Chair.

I think the process from here on needs to be for you to produce a new
version, discussing any of these comments with the list as appropriate.
Then, given the number of comments and the fact that I have seen
no discussion on the list, for me to try to persuade some others
to thoroughly review the text.
  
Firstly there are too many front page authors. I suggest that the two
editors Sami and Siva as editors remain on the front page and all other's are
moved to a "Contributing Authors" section at the end of the document.
If you can agree amongst yourselves that some others of you should remain
on the front then I am fine, but remember that any more than five needs
a very strong case to be made to the IESG, and I need text supporting
that case for inclusion in the shepherd's writeup.

ID-Nits makes the following complaint about references

   == Missing Reference: 'P2MP-PW-REQ' is mentioned on line 143, but not
      defined

   == Missing Reference: 'L3VPN-MCAST' is mentioned on line 352, but not
      defined

   == Missing Reference: 'PW-TWC-FEC' is mentioned on line 466, but not defined

   == Missing Reference: 'P2MP-LSP-PING' is mentioned on line 575, but not
      defined

   == Unused Reference: 'RFC6514' is defined on line 669, but no explicit
      reference was found in the text

   == Unused Reference: 'RFC 6667' is defined on line 679, but no explicit
      reference was found in the text

   == Unused Reference: 'RFC7338' is defined on line 690, but no explicit
      reference was found in the text

   == Unused Reference: 'RFC6425' is defined on line 693, but no explicit
      reference was found in the text

I think that this is because you have symbolic references in the text but
only RFCs in the reference section. Please correct this.

====================


1  Introduction

    A reference model for P2MP PW is
    depicted in Figure 1 below. A transport LSP associated with a P2MP
    SS-PW SHOULD be a P2MP MPLS LSP (i.e., P2MP TE tunnel established via
    RSVP-TE [RFC4875] or P2MP LSP established via mLDP [RFC6388])
  
SB> nit "or a P2MP"

===================
  
    spanning from the Root-PE to the Leaf-PE(s) of the P2MP SS-PW tree.
    For example, in Figure 1, PW1 can be associated with a P2MP TE tunnel
    or P2MP LSP setup using mLDP originating from PE1 and terminating at
    PE2 and PE3.


SB> True, but a little confusing since PW1 also goes to PE4. I think
SB> you need to say something about that.

                  |<--------------P2MP PW---------------->|
           Native |                                       |  Native
          Service |     |<--PSN1->|      |<--PSN2->|      |  Service
           (AC)   V     V         V      V         V      V   (AC)
             |    +-----+         +------+         +------+    |
             |    |     |         |   P1 |=========|T-PE2 |AC3 |    +---+
             |    |     |         |   .......PW1.........>|-------->|CE3|
             |    |T-PE1|=========|   .  |=========|      |    |    +---+
             |    |  .......PW1........  |         +------+    |
             |    |  .  |=========|   .  |         +------+    |
             |    |  .  |         |   .  |=========|T-PE3 |AC4 |    +---+
     +---+   |AC1 |  .  |         |   .......PW1.........>|-------->|CE4|
     |CE1|------->|...  |         |      |=========|      |    |    +---+
     +---+   |    |  .  |         +------+         +------+    |
             |    |  .  |         +------+         +------+    |
             |    |  .  |=========|   P2 |=========|T-PE4 |AC5 |    +---+
             |    |  .......PW1..............PW1.........>|-------->|CE5|
             |    |     |=========|      |=========|      |    |    +---+
             |    +-----+         +------+         +------+    |

                                  Figure 1: P2MP PW

    Mechanisms for establishing P2P SS-PW using LDP are described in
    [RFC4447]. In this document, we specify a method to signal P2MP PW

SB> nit "a method of signalling" (I think)

    using LDP. In particular, we define new FEC, TLVs, parameters, and
    status codes to facilitate LDP to signal and maintain P2MP PWs.

    As outlined in [P2MP-PW-REQ], even though the traffic flow from a
    Root-PE (R-PE) to Leaf-PE(s) (L-PEs) is P2MP in nature, it may be
    desirable for any L-PE to send unidirectional P2P traffic destined
    only to the R-PE. The proposed mechanism takes such option into
    consideration.

    The P2MP PW requires an MPLS LSP to carry the PW traffic, and the
    MPLS packets carried over the PW will be encapsulated according to
    the methods described in [RFC5332].

SB> I do not understand. I looked in RFC5332, and could find nothing
SB> about PWs. I think you need to expand on how PW is layered over
SB> MPLS if it is other than as described in the PW encapsulation
SB> RFCs.
SB>
SB> My assumption is that the PW is encapulated as normal and the
SB> resultant MPLS labeled payload (the PW identifier + PW payload)
SB> is carried over the P2MP LSP in the same way as any other
SB> MPLS payload.

===================


2. Signaling P2MP PW
  

    A P2MP PW signaling is initiated by the R-PE simply by sending a

SB> nit no need for "A"

    P2MP-PW LDP label mapping message to the L-PE(s) belonging to that
    P2MP PW.

SB> This needs to be unicast sent one at a time doesn't it?
SB> That should be made clear to avoid anyone thinking they can
SB> send it over the P2MP LSP

      This label mapping message will contain the following:
          1. A FEC TLV containing P2MP PW Upstream FEC element that
             includes Transport LSP sub TLV.
          2. An Interface Parameters TLV, as described in [RFC4447].
          3. A PW Grouping TLV, as described in [RFC4447].
          4. A label TLV for the upstream-assigned label used by R-PE
             for the traffic going from R-PE to L-PE(s).

    The R-PE imposes the upstream-assigned label on the outbound packets

SB> That should be upstream-assigned PW label

==================

    When an L-PE receives a PW Label Mapping Message, it MUST verify the
    associated P2MP PSN LSP is in place. If the associated P2MP PSN LSP
    is not in place, and its type is LDP P2MP LSP, the L-PE SHOULD

SB> Why is that not MUST?

    attempt to join the P2MP LSP associated with the P2MP PW. If the
    associated P2MP PSN LSP is not in place, and its type is RSVP-TE P2MP
    LSP, the L-PE SHOULD wait till the P2MP transport LSP is signaled.

SB> So what happens if there is a failure to set up the P2MP transport
SB> LSP?

============================


2.2 P2MP PW FEC

    [RFC4447] specifies two types of LDP FEC elements called "PWid FEC
    Element" and "Generalized PWid FEC Element" used to signal P2P PWs.
    We define two new types of FEC elements called "P2MP PW Upstream FEC
    Element" and "P2P PW Downstream FEC Element". These FEC elements are
    associated with a mandatory upstream assigned label and an optional
    downstream assigned label respectively.

    FEC type of the P2MP PW Upstream FEC Element is 0x82 (pending IANA
    allocation) and is encoded as follows:


SB> This is bad practise since it amounts to code point squatting.
SB> It needs to be symbolic here and in the IANA section although
SB> you may request a particular value in the IANA section.

  Sivabalan & Boutros      Expires April 24, 2017                 [Page 7]

INTERNET DRAFT                  P2MP PW                 October 21, 2016


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | P2MP PW Up    |C|           PW Type           | PW Info Length|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    AGI Type   |     Length    |         AGI Value             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                       AGI Value (contd.)                      ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    AII Type   |     Length    |         SAII Value            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                       SAII Value (contd.)                     ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |PMSI Tunnel typ|     Length    |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       +                                                               +
       ~                   Transport LSP ID                            ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                       Optional Parameters                     |
       ~                                                               ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                    Figure 2: P2MP PW Upstream FEC Element

SB> Where is P2MP PW Up defined?

         * PW Type:

          15-bit representation of PW type, and the assigned values are
          assigned by IANA.

         * C bit:

          A value of 1 or 0 indicates whether control word is present or
          absent for the P2MP PW.

         * PW Info Length:

    Sum of the lengths of AGI, SAII, PMSI Tunnel info, and Optional
    Parameters field in octets. If this value is 0, then it references
    all PWs using the specified grouping ID. In this case, there are
    neither other FEC element fields (AGI, SAII, etc.) present, nor any
    interface parameters TLVs. Alternatively, we can use typed WC FEC

SB> WC? Presumably wildcard?


=============


    * Transport LSP ID: This is the Tunnel Identifier which is defined in
    [L3VPN-MCAST].

    An R-PE sends Label Mapping Message as soon as the transport LSP ID
    associated with the P2MP PW is known (e.g., via configuration)
    regardless of the operational state of that transport LSP. Similarly,
    an R-PE does not withdraw the labels when the corresponding transport
    LSP goes down. Furthermore, an L-PE retains the P2MP PW labels
    regardless of the operational status of the transport LSP.

    Note that a given transport LSP can be associated with more than one
    P2MP PWs and all P2MP PWs will be sharing the same R-PE and L-PE(s).
SB> s/and all/in which case/

SB> Do you want to clarify that an R-PE may have many P2MP PWs with
SB> disjoint L-P sets.

    In the case of LDP P2MP LSP, when an L-PE receives the Label Mapping
    Message, it can initiate the process of joining the P2MP LSP tree
    associated with the P2MP PW.

    In the case of RSVP-TE P2MP LSP, only the R-PE initiates the
    signaling of P2MP LSP.

    * Optional Parameters:

    The Optional Parameter field can contain some TLVs that are not part
    of the FEC, but are necessary for the operation of the PW. This
    proposed mechanism uses two such TLVs: Interface Parameters TLV, and
    Group ID TLV.

    The Interface Parameters TLV and Group ID TLV specified in [RFC4447]
    can also be used in conjunction with P2MP PW FEC in alabel message.
SB> nit s/alable/a label/


SB> Throughout the text you should call up rfc4447bis




    The
    value of the sub-TLV contains the source and the group for a given
    multicast tree as shown in Figure 3.

SB> It is conventional to show the T, L and V in a TLV

    Also, if a P2MP PW is associated
    with multiple selective trees, the corresponding label mapping
    message will carry more than one instance of this Sub-TLV.
    Furthermore, in the absence of this sub-TLV, the P2MP PW is
    associated with all multicast traffic stream originating from the
    root.

                       +----------------------------------------- +
                       | Multicast Source Length (1 Octet)        |
                       +----------------------------------------- +
                       | Multicast Source (variable length)       |
                       +----------------------------------------- +
                       | Multicast Group Length (1 Octet)         |
                       +----------------------------------------- +
                       | Multicast Group (variable length)        |
                       +----------------------------------------- +


               Figure 3: Selective Tree Interface Parameter Sub-TLV Value

    Note that since the LDP label mapping message is only sent by the R-
    PE to all the L-PEs, it is not possible to negotiate any interface
    parameters.

    The type of optional P2P PW Downstream FEC Element is 0x83 (pending
    IANA allocation), and is encoded as follows:

SB> Again bad practise to but the value in the body of the text.
]
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | P2P PW Down   |C|           PW Type           | PW Info Length|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    AGI Type   |     Length    |         AGI Value             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                       AGI Value (contd.)                      ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    AII Type   |     Length    |         SAII Value            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                       SAII Value (contd.)                     ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 4: P2P PW Downstream FEC Element

    The definition of the fields in the P2P PW Downstream FEC Element is
    the same as those of P2MP PW Upstream FEC Element.

SB> ... shown in Figure 3.

  2.3 Typed Wildcard FEC Format for new FEC

    [RFC5918] defines the general notion of a "Typed Wildcard" FEC
    Element, and requires FEC designer to specify a typed wildcard FEC
    element for newly defined FEC element types. This document defines
    two new FEC elements, "P2MP PW Upstream" and "P2P PW Downstream" FEC
    element, and hence requires us to define their Typed Wildcard format.


    [PW-TWC-FEC] defines Typed Wildcard FEC element format for other PW
    FEC Element types (PWid and Gen. PWid FEC Element) in section 2 as
    follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Typed Wcard=0x5|Type=PW FEC|   Len = 3    |R|   PW type   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    . . .      | PMSI Tun Type |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
SB> It might be my cut and paste, it may be a layout error in the original.


  Sivabalan & Boutros      Expires April 24, 2017                [Page 11]

INTERNET DRAFT                  P2MP PW                 October 21, 2016


             Figure 5: Typed Wildcard Format for P2MP PW FEC Elements

    [PW-TWC-FEC] specifies that "Type" field can be either "PWid" (0x80)


  or "Generalized PWid" (0x81) FEC element type. This document reuses
    the existing typed wildcard format as specified in [PW-TWC-FEC] and
    illustrated in Figure 5. We extend the definition of "Type" field to
    also include "P2MP PW Upstream" and "P2P PW Downstream" FEC element
    types, as well as add an additional field "PMSI Tun Type". We reserve
    PMSI tunnel Type 0xFF to mean "wildcard" transport tunnel type. This
    "wildcard" transport tunnel type can be used in a typed wildcard p2mp
    FEC for further filtering. This field only applies to Typed wildcard
    P2MP PW Upstream FEC and MUST be set to "wildcard" for "P2P PW
    Downstream FEC" typed wildcard element.


SB> These are changes to an MPLS data structure, so I think that we need to
SB> ask the MPLS WG to review.

==================


3. LDP Capability Negotiation


    In line with requirements listed in [RFC5561], the following TLV is
    defined to indicate the P2MP PW capability:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |U|F| P2MP PW Capability (0x703)|            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |S| Reserved    |    Reserved   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                      Figure 7: LDP P2MP PW Capability TLV

SB> Same comment about draft text including assumed codepoint values. 703 might
SB> have gone before you get published!

=================

4. P2MP PW Status

    In order to support the proposed mechanism, a node MUST be capable of
    handling PW status. As such, PW status negotiation procedure
    described in [RFC4447] is not applicable to P2MP PW.

SB> So is there a protocol action on discovering that a peer does not
SB> support this?

    Once an L-PE successfully processes a Label Mapping Message for a
    P2MP PW, it MUST send appropriate PW status according to the
    procedure specified [RFC4447] to notify the PW status. If there is no
    PW status notification required, then no PW status notification is
    sent (for example if the P2MP PW is established and operational with
    a status code of Success (0x00000000), pw status message is not
    necessary). PW status message sent from any L-PE to R-PE contains P2P
    PW Downstream FEC to identify the PW.

SB> I could not parse the sentence above.

    An R-PE also sends PW status to L-PE(s) to reflect its view of a P2MP
    PW state. Such PW status message contains P2MP PW Upstream FEC to
    identify the PW.

    Connectivity status of the underlying P2MP LSP that P2MP PW is
    associated with, can be verified using LSP Ping and Traceroute
    procedures described in [P2MP-LSP-PING].

5 Security Considerations

    The security measures described in [RFC4447] is adequate for the
    proposed mechanism.

SB> You really need to point at the security section in draft-ietf-pals-rfc4447bis
SB> This has had a more recent security review and will replace RFC4447
SB> by the time this draft becomes an RFC.

==============

  7  IANA Considerations

7.1. FEC Type Name Space

    This document uses two new FEC element types, number 0x82 and 0x83
    will be requested as an allocation from the registry "FEC Type Name
    Space" for the Label Distribution Protocol (LDP RFC5036):

       Value    Hex    Name                               Reference
       -------  -----  -----------------------------      ---------
        130     0x82   P2MP PW Upstream FEC Element       RFCxxxx
        131     0x83   P2P PW Downstream FEC Element      RFCxxxx

SB> The text is not correct. You have requested an early allocation of these
SB> values, and you need to ask that although the early allocation has technically
SB> expired they be allocated to this RFC.

7.2. LDP TLV Type

    This document uses a new LDP TLV types, IANA already maintains a
    registry of name "TLV TYPE NAME SPACE" defined by RFC5036. The
  


Sivabalan & Boutros      Expires April 24, 2017                [Page 14]

INTERNET DRAFT                  P2MP PW                 October 21, 2016


    following values are suggested for assignment:

          TLV type  Description:

          0x0703   P2MP PW Capability TLV

7.3. mLDP Opaque Value Element TLV Type

    This document requires allocation of a new mLDP Opaque Value Element
    Type from the LDP MP Opaque Value Element type name space defined in
    [mLDP].

SB> You should give the name of the namespace directly rather than through a reference
SB> Because IANA are such nice people, I prefer to request that they do things.

    The following value is suggested for assignment:

          TLV type  Description
          0x3       L2VPN-MCAST application TLV

7.4. Selective Tree Interface Parameter sub-TLV Type

    This document requires allocation of a sub-TLV from the registry
    "Pseudowire Interface Parameters Sub-TLV Type".


    The following value is suggested for assignment:

          TLV type  Description
          0x0D      Selective Tree Interface Parameter.

SB> 0x0d is already taken!
SB.

0x0D 	up to 256 	bytes ROHC over MPLS configuration [RFC3241 
<http://www.iana.org/go/rfc3241>] 	[RFC4901 
<http://www.iana.org/go/rfc4901>]

SB> How much of this is deployed? Because if you have deployed
SB> we have a problem.


  7.5. WildCard PMSI tunnel type.

       This document requires the allocation of PMSI tunnel Type 0xFF to
     mean wildcard transport tunnel type


SB> You need to ask IANA to allocate a specific code point in a specific
SB> registry. Please use the the format of the registry.
SB>
SB> Taking the FF value can be a big deal, and needs to be
SB> co-ordinated with the registry "owner", who I think is MPLS. Has
SB> this been discussed by the MPLS WG?

  8  References

8.1. Normative References

======================

    [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L., et
    al., RFC 4447, April 2006.
SB> This needs to point to RFC4447bis which will be an RFC in the next few weeks.



- Stewart