Subject: Opsdir last call review of draft-ietf-mpls-sfc-encapsulation-02

From: Carlos Pignataro <[email-masked]>
Date: Wed, 20 Feb 2019 19:57:57 -0800

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.

>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.

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"

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.

Also, this encapsulation is Underdefined: What is the value of TTL? TC?

   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?

   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.

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.

6.  Security Considerations

Have you considered the use of GTSM?

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>.

SHould RFC 7665 be Normative? It defines the "SFF" which is quite central to
understanding this document.

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 :-)

Best,

Carlos Pignataro.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 21 Feb 2019 13:06:23 -0500

Carlos,

Many thanks for your review! I'm also including the SFC WG on my reply.

Comments inline.

> 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.

> 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.

> It seems to me that this is the "MPLS Transport Encapsulation for the SFC

Thanks, we'll fix that.

> 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?

> 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].

> 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.

> 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).

> 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?

> 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.

> :-)

How about we change "other than IP," to "other than a normally routed IP
packet",

Thanks again,
Andy

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 22 Feb 2019 01:41:52 +0000

Hi, Andy,

On Feb 21, 2019, at 1:06 PM, Andrew G. Malis <[email-masked]<mailto:[email-masked]>> wrote:

Carlos,

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 <[email-masked]<mailto:[email-masked]>> wrote:
Reviewer: Carlos Pignataro
Review result: Has Issues

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:

If you think it helps, this would be a good addition.

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.

Thanks, we'll fix that.

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".

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:

   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.

These two approaches sounds good to me. And Ack to the other previous responses.

 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.

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/

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.

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

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.

:-)

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 22 Feb 2019 09:27:41 -0500

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) <
[email-masked]> wrote:

> Hi, Andy,
>
> On Feb 21, 2019, at 1:06 PM, Andrew G. Malis <[email-masked]> wrote:
>
> Carlos,
>
>    [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 protocols use 5082 in one form or another:
> https://datatracker.ietf.org/doc/rfc5082/referencedby/
>
>
> 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.
>
>
> packet”,

---

From: Joel Halpern <[email-masked]>
Date: Fri, 22 Feb 2019 15:39:44 +0000

More generally, I do not think there is a requirement that SFF be only one MPLS-hop apart.  So I tend to doubt whether a reference to GTSM will be helpful.   Maybe I am missing the applicability?

Yours,

Joel

From: Andrew G. Malis <[email-masked]> 
Sent: Friday, February 22, 2019 9:28 AM
To: Carlos Pignataro (cpignata) <[email-masked]>
Cc: [email-masked]; mpls <[email-masked]>; [email-masked]; IETF Discussion <[email-masked]>; [email-masked]
Subject: Re: [mpls] Opsdir last call review of draft-ietf-mpls-sfc-encapsulation-02

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) <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Andy, 

On Feb 21, 2019, at 1:06 PM, Andrew G. Malis <[email-masked] <mailto:[email-masked]> > wrote:

Carlos,

 

Comments inline.

On Wed, Feb 20, 2019 at 10:58 PM Carlos Pignataro <[email-masked] <mailto:[email-masked]> > wrote:

 

 

Thanks, we'll fix that.

   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.

 

 

 

Sounds good.

 

Yes, see above.

8.  References

 

Thank you.

:-)

Thanks again.

Thanks,

Carlos.

Thanks again,

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 22 Feb 2019 11:43:36 -0500

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:
> 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) 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi, Andy,
> 
>>     On Wed, Feb 20, 2019 at 10:58 PM Carlos Pignataro
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     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:
>>
>>     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.
> 
>>     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".
>>
>>
>>     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:
>>
>>      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].
>>
> 
>>     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.
>>     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).
> 
>>                       <https://www.rfc-editor.org/info/rfc7665
>>         <https://www..rfc-editor.org/info/rfc7665>>.
>>
>>     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.
> 
>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 25 Feb 2019 04:49:41 +0000

Thanks Andy!

You can find some protocols using GTSM at https://datatracker.ietf.org/doc/rfc5082/referencedby/, including rfc6720, rfc7325, rfc7885, and others.

To me, specifying the TTL behavior early on is critical to make use of it before various implementations use incompatible values. For example, either using 255 for GTSM, or using 1 or similar to ensure there’s no mis-forwarding, are appropriate positions. But I would like to have this explicitly stated whichever way.

Thanks,

— Carlos Pignataro

On Feb 22, 2019, at 11:27 PM, Andrew G. Malis <[email-masked]<mailto:[email-masked]>> wrote:

Carlos,

Thanks again,
Andy

On Thu, Feb 21, 2019 at 8:41 PM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Andy,

Carlos,

Comments inline.

Thanks, we'll fix that.

Sounds good.

Yes, see above.

8.  References

Thank you.

:-)

Thanks again.

Thanks,

Carlos.

Thanks again,
Andy

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 25 Feb 2019 04:54:13 +0000

Hi, Joel,

Maybe I am misunderstanding something. Is the SFF Label, in the context of MPLS transport encapsulation for the SFC NSH, ever expected to be used for Forwarding? Is its TTL ever expected to be decremented and the packet sent? If so, I did not understand that from the existing text, since it is equivalent to a PW Label. If not, we can take advantage of TTL.

Either way is good, I’m just asking to make this explicit.

Thanks,

— Carlos Pignataro

On Feb 23, 2019, at 1:43 AM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:

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.)

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) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:
   Hi, Andy,
   On Feb 21, 2019, at 1:06 PM, Andrew G. Malis <[email-masked]<mailto:[email-masked]>
   <mailto:[email-masked]>> 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
   <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:

       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.

       >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.

       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.

          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.

       Also, this encapsulation is Underdefined: What is the value of
       TTL? TC?

   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?

          2.  Push the SFF Label to identify the desired SFF in the
       receiving
              MPLS node.

   Sounds good.

       4.  Operations, Administration, and Maintenance (OAM)
       Considerations

       [RFC8300].

       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.

   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

       SHould RFC 7665 be Normative? It defines the "SFF" which is
       quite central to
       understanding this document.

          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.

   :-)

   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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 25 Feb 2019 07:32:48 -0500

First, you have a good point that the expected behavior of the MPLS TTL 
shoudl be specified.  Given that we managed to confuse you, it needs to 
be fixed.

<speaking as co-author, not as WG chair>

As I understand it, the MPLS TTL used for transport between SFF and the 
NSH TTL used for the SFC SFP are unrelated.  The NSH TTL has a value 
that exceeds the number of expected SFF (with a default of 63.)  It is 
derement at each SFF.

The MPLS TTL needs to be set to a value sufficient to get the NSH packet 
from one SFF to the next.  That might be one MPLS hop.  It might be 
several.  Presumably therefore the default is whatever the default is 
for the MPLS network in which it is being used.

the important point is that there is no relationship between decrements 
to the MPLS TTL and decrements to the NSH TTL.  As in tunnel mode for IP 
in IP tunnels, the NSH TTL is only decrement by one for each SFF-SFF hop.

Yours,
Joel

On 2/24/19 11:54 PM, Carlos Pignataro (cpignata) wrote:
> Hi, Joel,
> 
> Maybe I am misunderstanding something. Is the SFF Label, in the context 
> of MPLS transport encapsulation for the SFC NSH, ever expected to be 
> used for Forwarding? Is its TTL ever expected to be decremented and the 
> packet sent? If so, I did not understand that from the existing text, 
> since it is equivalent to a PW Label. If not, we can take advantage of TTL.
> 
>>> 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
>>> <[email-masked] <mailto:[email-masked]> 
>>> <mailto:[email-masked]>> wrote:
>>>    Hi, Andy,
>>>>    <[email-masked] <mailto:[email-masked]> 
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>>        >From an Operational standpoint, the document seems largely
>>>>        appropriate in terms
>>>>        [RFC3032  <https://tools.ietf.org/html/rfc3032>]) in the flow 
>>>> label.  Future documents may define a use for