Re: [mpls] Opsdir last call review of draft-ietf-mpls-sfc-encapsulation-02

["Joel M. Halpern" <[e-mail]>]

My comment on this may not have made it to everyone.  If you receive a 
duplicate, I apologize  (I received DMARC errors from something about 
translations from the draft.all address to gmail addresses.)

Speaking as a co-author...

It is not at all clear to me that GTSM applies or how it would apply. 
There is no requirement that successive SFF be one MPLS hop apart.

Yours,
Joel

On 2/22/19 9:27 AM, Andrew G. Malis wrote:
> Carlos,
> 
> Looks good on all but one point - I think I see why you're referencing 
> GTSM, since packets at the SFC layer would generally be one hop away 
> from each other at that layer. Is that correct? However, I really don't 
> have sufficient experience with GTSM to craft specific text. If you 
> think it's important enough to include, could you propose some text for 
> me to include?
> 
> Thanks again,
> Andy
> 
> 
> On Thu, Feb 21, 2019 at 8:41 PM Carlos Pignataro (cpignata) 
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     Hi, Andy,
> 
>>     On Feb 21, 2019, at 1:06 PM, Andrew G. Malis <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>     Carlos,
>>
>>     Many thanks for your review! I'm also including the SFC WG on my
>>     reply.
> 
>     Thanks for the quick response, and for considering the comments!
> 
>     I enjoyed reading this document — please see below.
> 
>>
>>     Comments inline.
>>
>>     On Wed, Feb 20, 2019 at 10:58 PM Carlos Pignataro
>>     <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>         Reviewer: Carlos Pignataro
>>         Review result: Has Issues
>>
>>         Reviewer: Carlos Pignataro
>>         Review Result: Has Issues
>>
>>         I have reviewed this document as part of the Operational
>>         directorate's
>>         ongoing effort to review all IETF documents being processed by
>>         the IESG.  These
>>         comments were written with the intent of improving the
>>         operational aspects of
>>         the IETF drafts. Comments that are not addressed in last call
>>         may be included
>>         in AD reviews during the IESG review.  Document editors and WG
>>         chairs should
>>         treat these comments just like any other last call comments.
>>
>>         This document is highly readable, includes very clear textual
>>         descriptions, and
>>         is very well organized. Easy to read in its simplicity.
>>         However, it would
>>         benefit from a more explicit connection to the transport encap
>>         mechanics from
>>         RFC 8300 (e.g., S4, S6.1). Specifically, I'd recommend adding
>>         a Figure or an
>>         SFF NSH Mapping Table example, to depict and/or exemplify the
>>         SFF function.
>>
>>
>>     I'm trying to envision what would make a good figure here. We
>>     could add an additional line to Table 1 of RFC 8300 and reference
>>     that table:
>>
>>            +------+------+---------------------+-------------------------+
>>            | SPI  | SI   | Next Hop(s)         | Transport Encapsulation |
>>            +------+------+---------------------+-------------------------+
>>            | 25   | 220  | Label 5467          | MPLS                    |
>>            +------+------+---------------------+-------------------------+
>>
>>     Is that what you had in mind? If not, I'm open to other suggestions.
> 
>     If you think it helps, this would be a good addition.
> 
>>
>>         >From an Operational standpoint, the document seems largely
>>         appropriate in terms
>>         of dataplane considerations. Some key considerations are
>>         explicitly out of
>>         scope:
>>            The method used by the downstream receiving node to
>>         advertise SFF
>>            Labels to the upstream sending node is out of scope of this
>>         document.
>>
>>         This really seems to mean that, with the simple definition in this
>>         Informational document, interoperable implementations cannot
>>         yet exist. If
>>         there is no mechanism to advertise the SFF Label or to manage
>>         the semantics of
>>         this particular label, how will it know? Static configuration,
>>         which is not
>>         covered anyway, is not in my humble opinion a manageable
>>         scalable approach.
>>
>>
>>     Actually, while it is outside the scope of this document, it is
>>     within the scope of draft-ietf-bess-nsh-bgp-control-plane, and
>>     text is being added to the next revision of that draft to show how
>>     it can be used to signal the encapsulation defined here. This was
>>     worked out after this draft was forwarded to the IESG, but we can
>>     now add a reference to that draft seeing as we'll be doing a
>>     post-last-call update.
> 
>     I think that will help, as an Informative “one embodiment” type of link.
> 
>>
>>         Title: MPLS Encapsulation For The SFC NSH
>>
>>         RFC 8300 makes an explicit distinction between the terms
>>         'encapsulation' and
>>         'transport encapsulation' (see e.g., Figure 1, Section 1.5 5.,
>>         and Section 4 of
>>         RFC 8300).
>>
>>         It seems to me that this is the "MPLS Transport Encapsulation
>>         for the SFC NSH"
>>
>>
>>     Thanks, we'll fix that.
>>
>>
>>         2.  MPLS Encapsulation Using an SFF Label
>>
>>         Similarly, "2. MPLS Transport Encapsulation Using an SFF Label"
>>
>>            The encapsulation is a standard MPLS label stack [RFC3032]
>>         with an
>>            SFF Label at the bottom of the stack, followed by a NSH as
>>         defined by
>>            [RFC8300] and the NSH payload.
>>
>>         Insteadf of "NSH payload" I think "orignal packet" is meant.
>>
>>
>>     RFC 8300 uses both "payload" and "original packet/frame", but the
>>     latter more than the former. So we can change "payload" to
>>     "original packet/frame".
>>
>>
>>         Also, this encapsulation is Underdefined: What is the value of
>>         TTL? TC?
>>
>>
>>     I've been looking back at other related RFCs (such as PW and IP
>>     VPN label definitions) and they're also mostly silent on these
>>     values. I did find the following in RFC 6073:
>>
>>         The setting of the TTL of the PW MPLS
>>         label is a matter of local policy on the originating PE, but SHOULD
>>         be set to 255.
>>
>>     Regarding the TC, we can follow the example of RFC 6391:
>>
>>         This document does not define a use for the Traffic Class (TC) field
>>         [RFC5462  <https://tools.ietf.org/html/rfc5462>] (formerly known as the Experimental Use (EXP) bits
>>         [RFC3032  <https://tools.ietf.org/html/rfc3032>]) in the flow label.  Future documents may define a use for
>>         these bits; therefore, implementations conforming to this
>>         specification MUST set the TC field to zero at the ingress and MUST
>>         ignore them at the egress.
>>
>>     Do you have any alternative suggestions?
> 
>     These two approaches sounds good to me. And Ack to the other
>     previous responses.
> 
>>
>>            Much like a pseudowire label, an SFF Label is allocated by the
>>            downstream receiver of the NSH from its per-platform label
>>         space.
>>
>>         A PW Label is more restrictive. RFC 8077 says it MUST be
>>         allocated as
>>         per-platform:
>>
>>            egress LSR only.  Note that the PW label must always be at
>>         the bottom
>>            of the packet's label stack, and labels MUST be allocated
>>         from the
>>            per-platform label space.
>>
>>         Is this the case for the SFF Label as well? If so, what is the
>>         implication of
>>         the MUST? If not, why is it different than other equivalent
>>         similar labels?
>>
>>
>>     We can change the text to:
>>
>>      Much like a pseudowire label, an SFF Label MUST be allocated by
>>     the downstream receiver of the NSH from its per-platform label
>>     space, since the meaning of the label is identical independent of
>>     which incoming interface it is received [RFC3031].
>>
> 
>     That’s a great improvement.
> 
>>
>>            2.  Push the SFF Label to identify the desired SFF in the
>>         receiving
>>                MPLS node.
>>
>>         TTL value? 1? 2? 255 for GTSM? GTSM RFC 5082 could be used here.
>>
>>
>>     As I noted above, 255, although I used RFC 6073 as my source
>>     rather than 5082. We'll add that here as well.
>>
> 
>     Sounds good.
>     These protocols use 5082 in one form or another:
>     https://datatracker.ietf.org/doc/rfc5082/referencedby/
> 
>>
>>         4.  Operations, Administration, and Maintenance (OAM)
>>         Considerations
>>
>>            OAM at the SFC Layer is handled by SFC-defined mechanisms
>>         [RFC8300].
>>            However, OAM may be required at the MPLS transport layer. 
>>         If so,
>>            then standard MPLS-layer OAM mechanisms such as the Generic
>>            Associated Channel [RFC5586] label may be used.
>>
>>         RFC 5586 is _not_ an OAM mechanism. It is an associated
>>         channel creation
>>         mechanism, over which OAM could be carried.
>>
>>         Thus, what traditional MPLS OAM can be carried here? Things
>>         like RFC 4379 / RFC
>>         8029 would need the definition of an SFF Label FEC (which does
>>         not exist).
>>         Which other one? IP/ICMP seems of very limited value.
>>
>>
>>     That's a good point about RFC 5586. The intention is that the MPLS
>>     OAM would be at the transport label layer above the SFF label, so
>>     most any MPLS-layer OAM would be applicable. So how about
>>     rewording to make that more clear:
>>
>>     OAM at the SFC Layer is handled by SFC-defined mechanisms
>>     [RFC8300]. However, OAM may be required at the MPLS transport
>>     layer.  If so, then standard MPLS-layer OAM mechanisms may be used
>>     at the transport label layer (the labels above the SFF label).
> 
>     Looks good to me, thank you.
> 
>>
>>
>>         6.  Security Considerations
>>
>>         Have you considered the use of GTSM?
>>
>>
>>     No, we hadn't. Can you point me to any examples of GTSM being used
>>     in an MPLS or PW context?
> 
>     Yes, see above.
> 
>>
>>         8.  References
>>
>>            [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service
>>         Function
>>                       Chaining (SFC) Architecture", RFC 7665,
>>                       DOI 10.17487/RFC7665, October 2015,
>>                       <https://www.rfc-editor.org/info/rfc7665
>>         <https://www..rfc-editor.org/info/rfc7665>>.
>>
>>         SHould RFC 7665 be Normative? It defines the "SFF" which is
>>         quite central to
>>         understanding this document.
>>
>>
>>     Good point. It was there because 7665 is an Informational RFC, but
>>     RFC 8067 does allow normative references to informational RFCs, so
>>     I'll move it.
> 
>     Thank you.
> 
>>
>>         Other Nits and Editorials:
>>
>>            SFF Labels are similar to other service labels at the
>>         bottom of an
>>            MPLS label stack that denote the contents of the MPLS
>>         payload being
>>            other than IP, such as a layer 2 pseudowire, an IP packet
>>         that is
>>            routed in a VPN context with a private address, or an Ethernet
>>            virtual private wire service.
>>
>>         This says "being other than IP, such as IP", which seems to be
>>         self-contradictory :-)
>>
>>     :-)
>>
>>     How about we change "other than IP," to "other than a normally
>>     routed IP packet”,
> 
>     That would disambiguate it.
> 
>     Thanks again.
> 
>     To me, the control plane / advertisement was the most important
>     operationally-relevant comment.
> 
>     Thanks,
> 
>     Carlos.
> 
>>
>>     Thanks again,
>>     Andy
>