Subject: [sfc] Loop prevention via TTL

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Apr 2017 14:57:27 -0400

This was brought up on the list, and there was useful discussion.
The chairs neglected to close off the discussion.
While Jim is collecting all the action items for the NSH draft, this 
email serves to report our conclusion about the discussion of adding a 
TTL field to the NSH header.

While not everyone likes the answer, there is rough consensus in support 
of changing the NSH header to include a TTL.

The specific change is to take 6 bits from the flags, and use them as a 
TTL.  And take 4 bits from the MD-Type and use them as reserved flag 
bits.  The backwards compatibility for migration of existing 
implementations was discussed, and seems workable.

The resulting packet format is, as diagrammed by Adrian Farrel:

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Ver|O|R|    TTL    |   Length  |R|R|R|R|MD Type|     Proto     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I have marked what was the C bit as R for reserved (must be zero on 
transmission, ignored on reception), as we have a separate rough 
consensus to deprecate that bit.

There was some discussion of exactly how the TTL field should be tested. 
  The agreement observed on the list is to decrement before testing for 
0, thus allowing an NSH packet initiated with 0 to be processed without 
any special case coding.  The default for originating an NSH header will 
be a TTL of 255.

Please speak up promptly if folks see a problem with this, as we are 
trying to get the document completed.  Also speak up if there are 
additional clarifications that we should have, to make sure the authors 
reflect Working Group agreement.

Thank you,
Joel (and Jim)

---

From: Dave Dolson <[email-masked]>
Date: Wed, 12 Apr 2017 19:20:47 +0000

Joel,
One thing: we need to make it clear which functions should decrement and test the TTL. Only SFFs ?

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, April 12, 2017 2:57 PM
To: [email-masked]
Subject: [sfc] Loop prevention via TTL

This was brought up on the list, and there was useful discussion.
The chairs neglected to close off the discussion.
While Jim is collecting all the action items for the NSH draft, this email serves to report our conclusion about the discussion of adding a TTL field to the NSH header.

While not everyone likes the answer, there is rough consensus in support of changing the NSH header to include a TTL.

The specific change is to take 6 bits from the flags, and use them as a TTL.  And take 4 bits from the MD-Type and use them as reserved flag bits.  The backwards compatibility for migration of existing implementations was discussed, and seems workable.

I have marked what was the C bit as R for reserved (must be zero on transmission, ignored on reception), as we have a separate rough consensus to deprecate that bit.

There was some discussion of exactly how the TTL field should be tested. 
  The agreement observed on the list is to decrement before testing for 0, thus allowing an NSH packet initiated with 0 to be processed without any special case coding.  The default for originating an NSH header will be a TTL of 255.

Please speak up promptly if folks see a problem with this, as we are trying to get the document completed.  Also speak up if there are additional clarifications that we should have, to make sure the authors reflect Working Group agreement.

Thank you,
Joel (and Jim)

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Apr 2017 15:30:59 -0400

Good question.  My understanding was that the agreement was for SFF and 
SF to decrement the TTL.

Opinions?
Joel

---

From: Kyle Larose <[email-masked]>
Date: Wed, 12 Apr 2017 19:46:53 +0000

Should we make it a little abstract? "Any component that understands the NSH header MUST decrement then test the TTL prior to forwarding it (or prior to processing it?). If the TTL is zero when tested, the packet MUST be discarded?"

That would then also cover SFC Proxies, for example. 

That said, do we need a special discussion about proxies? I.e. do they maintain the TTL for the same "packet" when it returns from the SFC unaware service function?

> Sent: Wednesday, April 12, 2017 3:31 PM
> To: Dave Dolson; [email-masked]
> Subject: Re: [sfc] Loop prevention via TTL
> 
> Good question.  My understanding was that the agreement was for SFF and SF
> to decrement the TTL.
> 
> Opinions?
> Joel
> 
> > While Jim is collecting all the action items for the NSH draft, this email
> serves to report our conclusion about the discussion of adding a TTL field
> to the NSH header.
> >
> TTL.  And take 4 bits from the MD-Type and use them as reserved flag bits.
> The backwards compatibility for migration of existing implementations was
> discussed, and seems workable.
> >
> transmission, ignored on reception), as we have a separate rough consensus
> to deprecate that bit.
> >
> >   The agreement observed on the list is to decrement before testing for 0,
> thus allowing an NSH packet initiated with 0 to be processed without any
> special case coding.  The default for originating an NSH header will be a
> TTL of 255.
> >
> trying to get the document completed.  Also speak up if there are additional
> clarifications that we should have, to make sure the authors reflect Working
> Group agreement.
> >
> > Thank you,
> > Joel (and Jim)
> >

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 12 Apr 2017 12:59:33 -0700

Hi Joel,
since we're introducing TTL, should we define behavior of a component that
realizes that TTL had expired? In some scenario, e.g. OAM, TTL expiration
may be desired, engineered event.

Regards,
Greg

On Wed, Apr 12, 2017 at 12:30 PM, Joel M. Halpern <[email-masked]>
wrote:

>> email serves to report our conclusion about the discussion of adding a TTL
>> field to the NSH header.
>>
>> 0, thus allowing an NSH packet initiated with 0 to be processed without any

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Apr 2017 16:28:06 -0400

I am not sure what you are asking for.
I did not write it, but I think we all assumed, and the proposed text 
showed, that when the decrement results in 0, the packet is dropped.

I suspect what youa re really asking is whether we should add some sort 
of ICMP behavior.  The working group did not ask for that.  And more 
importantly, it would be very dificult, since SFPs are not 
bi-directional.  If adding the TTL would result in the working group 
spending two years delaying publication of NSH, I would personally 
prefer to skip the TTL.

Yours,
Joel

On 4/12/17 3:59 PM, Greg Mirsky wrote:
> Hi Joel,
> since we're introducing TTL, should we define behavior of a component
> that realizes that TTL had expired? In some scenario, e.g. OAM, TTL
> expiration may be desired, engineered event.
>
> Regards,
> Greg
>
> On Wed, Apr 12, 2017 at 12:30 PM, Joel M. Halpern <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Good question.  My understanding was that the agreement was for SFF
>     and SF to decrement the TTL.
>
>     Opinions?
>     Joel
>
>
>         From: sfc [mailto:[email-masked]
>         <mailto:[email-masked]>] On Behalf Of Joel M. Halpern
>         To: [email-masked] <mailto:[email-masked]>
>         While Jim is collecting all the action items for the NSH draft,
>         this email serves to report our conclusion about the discussion
>         of adding a TTL field to the NSH header.
>
>         While not everyone likes the answer, there is rough consensus in
>         support of changing the NSH header to include a TTL.
>
>         The specific change is to take 6 bits from the flags, and use
>         them as a TTL.  And take 4 bits from the MD-Type and use them as
>         reserved flag bits.  The backwards compatibility for migration
>         of existing implementations was discussed, and seems workable.
>
>         I have marked what was the C bit as R for reserved (must be zero
>         on transmission, ignored on reception), as we have a separate
>         rough consensus to deprecate that bit.
>
>           The agreement observed on the list is to decrement before
>         testing for 0, thus allowing an NSH packet initiated with 0 to
>         be processed without any special case coding.  The default for
>         originating an NSH header will be a TTL of 255.
>
>         Please speak up promptly if folks see a problem with this, as we
>         are trying to get the document completed.  Also speak up if
>         there are additional clarifications that we should have, to make
>         sure the authors reflect Working Group agreement.
>
>         Thank you,
>         Joel (and Jim)
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/sfc>
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/sfc>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/sfc>
>
>

---

From: Kyle Larose <[email-masked]>
Date: Wed, 12 Apr 2017 20:33:00 +0000

Does the method by which we handle a TTL expiry, aside from drop, really need to be defined in the NSH spec? Later protocols or standards could always extend the functionality, unless we phrase it to exclude future extensions. Can we just avoid doing that?

For example, imagine a traceroute like OAM message specification. Couldn't we just say that in order to support it, any devices which drop the message because of NSH ttl expiry must send a message back to the originator (contained within the OAM payload)? No change to the NSH spec -- it simply extends the existing functionality.

> Sent: Wednesday, April 12, 2017 4:28 PM
> To: Greg Mirsky
> Cc: [email-masked]; Dave Dolson
> I suspect what youa re really asking is whether we should add some sort of
> ICMP behavior.  The working group did not ask for that.  And more
> importantly, it would be very dificult, since SFPs are not bi-directional.
> If adding the TTL would result in the working group spending two years
> delaying publication of NSH, I would personally prefer to skip the TTL.
> 
> Yours,
> Joel
>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 12 Apr 2017 13:46:39 -0700

Hi Kyle,
I very much agree with your suggestion. I think that details of TTL Expiry
handling  could be deferred to another document. If the NSH document states
that the packet with TTL of 0 MUST not be forwarded, that may be all we
need. More details might be added "a packet MAY be discarded or it MAY be
passed for processing to the appropriate network layer".

Regards,
Greg

On Wed, Apr 12, 2017 at 1:33 PM, Kyle Larose <[email-masked]> wrote:

> Does the method by which we handle a TTL expiry, aside from drop, really
> need to be defined in the NSH spec? Later protocols or standards could
> always extend the functionality, unless we phrase it to exclude future
> extensions. Can we just avoid doing that?
>
> For example, imagine a traceroute like OAM message specification. Couldn't
> we just say that in order to support it, any devices which drop the message
> because of NSH ttl expiry must send a message back to the originator
> (contained within the OAM payload)? No change to the NSH spec -- it simply
> extends the existing functionality.
>
> of
> bi-directional.
> > >            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> > +-+
> > >         There was some discussion of exactly how the TTL field should
> be
> > >         tested.

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 12 Apr 2017 13:57:45 -0700

Hi Joel,
perhaps the following explanation of TTL handling will be sufficient for
NSH document and still leave room for detailed analysis elsewhere:

Outgoing packet with TTL value of 0 MUST NOT be forwarded. The packet MAY
be discarded or it MAY be passed to the appropriate network layer for error
processing.

Regards,
Greg

---

From: Dave Dolson <[email-masked]>
Date: Wed, 12 Apr 2017 21:05:37 +0000

To make it more precise, as Joel mentioned, the value of zero must only be checked after decrementing.

    Outgoing packet with TTL value of 0 after decrementing by 1 MUST NOT be forwarded.

From: Greg Mirsky [mailto:[email-masked]]
Sent: Wednesday, April 12, 2017 4:58 PM
To: Joel M. Halpern
Cc: Dave Dolson; [email-masked]
Subject: Re: [sfc] Loop prevention via TTL

Hi Joel,
perhaps the following explanation of TTL handling will be sufficient for NSH document and still leave room for detailed analysis elsewhere:
Outgoing packet with TTL value of 0 MUST NOT be forwarded. The packet MAY be discarded or it MAY be passed to the appropriate network layer for error processing.

Regards,
Greg

On Wed, Apr 12, 2017 at 1:28 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:
I am not sure what you are asking for.
I did not write it, but I think we all assumed, and the proposed text showed, that when the decrement results in 0, the packet is dropped.

I suspect what youa re really asking is whether we should add some sort of ICMP behavior.  The working group did not ask for that.  And more importantly, it would be very dificult, since SFPs are not bi-directional.  If adding the TTL would result in the working group spending two years delaying publication of NSH, I would personally prefer to skip the TTL.

Yours,
Joel

Regards,
Greg

On Wed, Apr 12, 2017 at 12:30 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    Opinions?
    Joel

        Joel,
        One thing: we need to make it clear which functions should
        decrement and test the TTL. Only SFFs ?

        -Dave

        -----Original Message-----
        From: sfc [mailto:[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>] On Behalf Of Joel M. Halpern
        Sent: Wednesday, April 12, 2017 2:57 PM
        To: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
        Subject: [sfc] Loop prevention via TTL

        There was some discussion of exactly how the TTL field should be
        tested.

        Thank you,
        Joel (and Jim)

        _______________________________________________
        sfc mailing list
        [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
        https://www.ietf.org/mailman/listinfo/sfc
        <https://www.ietf.org/mailman/listinfo/sfc>

        _______________________________________________
        sfc mailing list
        [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
        https://www.ietf.org/mailman/listinfo/sfc
        <https://www.ietf.org/mailman/listinfo/sfc>

    _______________________________________________
    sfc mailing list
    [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
    https://www.ietf.org/mailman/listinfo/sfc
    <https://www.ietf.org/mailman/listinfo/sfc>

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Thu, 13 Apr 2017 01:24:32 +0000

I like Dave’s text better. MUST not forward is clear and to the point and does not preclude any extra processing that may take place to the packet as it does mandates immediate drop.

Andrew

From: sfc <[email-masked]> on behalf of Dave Dolson <[email-masked]>
Date: Thursday, April 13, 2017 at 5:05 AM
To: Greg Mirsky <[email-masked]>, "Joel M. Halpern" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [sfc] Loop prevention via TTL

Hi Joel,

Regards,
Greg

Yours,
Joel

Regards,
Greg

    Opinions?
    Joel

        Joel,

        -Dave

        -----Original Message-----
        From: sfc [mailto:[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>] On Behalf Of Joel M. Halpern
        Sent: Wednesday, April 12, 2017 2:57 PM
        To: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
        Subject: [sfc] Loop prevention via TTL

        Thank you,
        Joel (and Jim)

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 12 Apr 2017 20:47:43 -0700

Hi Andrew,
as long as it doesn't say MUST do X, but instead uses MUST NOT do Y, I'm OK.

Regards,
Greg

On Wed, Apr 12, 2017 at 6:24 PM, Dolganow, Andrew (Nokia - SG/Singapore) <
[email-masked]> wrote:

> I like Dave’s text better. MUST not forward is clear and to the point and
> does not preclude any extra processing that may take place to the packet as
> it does mandates immediate drop.
>
>
>
> Andrew
>
>
>
> *From: *sfc <[email-masked]> on behalf of Dave Dolson <
> [email-masked]>
> *Date: *Thursday, April 13, 2017 at 5:05 AM
> *To: *Greg Mirsky <[email-masked]>, "Joel M. Halpern" <
> [email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
>
> *Subject: *Re: [sfc] Loop prevention via TTL
>
>
>
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Wednesday, April 12, 2017 4:58 PM
> *To:* Joel M. Halpern
> *Cc:* Dave Dolson; [email-masked]
> *Subject:* Re: [sfc] Loop prevention via TTL
>
>
>
> Hi Joel,
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 14 Apr 2017 22:00:41 +0100

Hello.
 
Three things to add to this discussion.
 
With the removal of the C-bit, should we increase the size of the TTL by 1 bit?
If, as has been suggested, anything that is processing the NSH should decrement the TTL, we can expect three decrements per SF (SFF in, SF, SFF out), so we might welcome an extra bit.
 
Joel wrote
>  originating an NSH header will be a TTL of 255.
 
I don't understand this. If a packet is initiated with TTL of 0, and then processed, the TTL will be decremented. But decrementing 0 is ambiguous.
Actually, I don't understand initiating with TTL 0. What's that about?
 
Joel also wrote...
> If adding the TTL would result in the working group spending two years delaying
> publication of NSH, I would personally prefer to skip the TTL
I choose neither of these options!
If there was a call to draft text, then I missed it.
 
Thanks,
Adrian

From: sfc [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: 13 April 2017 04:48
To: Dolganow, Andrew (Nokia - SG/Singapore)
Cc: Joel M. Halpern; [email-masked]; Dave Dolson
Subject: Re: [sfc] Loop prevention via TTL
 
Hi Andrew,
 
Regards,
Greg
 
On Wed, Apr 12, 2017 at 6:24 PM, Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]> wrote:
I like Dave’s text better. MUST not forward is clear and to the point and does not preclude any extra processing that may take place to the packet as it does mandates immediate drop.
 
Andrew

 

 
Hi Joel,
 
Regards,
Greg
 
On Wed, Apr 12, 2017 at 1:28 PM, Joel M. Halpern <[email-masked]> wrote:
I am not sure what you are asking for.
I did not write it, but I think we all assumed, and the proposed text showed, that when the decrement results in 0, the packet is dropped.

Yours,
Joel

Regards,
Greg

    Opinions?
    Joel

        Joel,

        -Dave

        -----Original Message-----
        From: sfc [mailto:[email-masked]
        <mailto:[email-masked]>] On Behalf Of Joel M. Halpern
        Sent: Wednesday, April 12, 2017 2:57 PM
        To: [email-masked] <mailto:[email-masked]>
        Subject: [sfc] Loop prevention via TTL

        Thank you,
        Joel (and Jim)

---

From: James N Guichard <[email-masked]>
Date: Fri, 14 Apr 2017 21:44:48 +0000

Is there any good technical reason to decrement the TTL at an SF given that the SFF will catch the loop anyway?. Also, note that an SF does not forward packets based upon the NSH encapsulation and I would think that decrementing the TTL is part of the forwarding operation.

Jim

From: sfc [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Friday, April 14, 2017 5:01 PM
To: 'Greg Mirsky' <[email-masked]>; 'Dolganow, Andrew (Nokia - SG/Singapore)' <[email-masked]>
Cc: 'Joel M. Halpern' <[email-masked]>; 'Dave Dolson' <[email-masked]>; [email-masked]
Subject: Re: [sfc] Loop prevention via TTL

Hello.

Joel wrote

Joel also wrote...

Thanks,
Adrian

Cc: Joel M. Halpern; [email-masked]<mailto:[email-masked]>; Dave Dolson

Hi Andrew,

Regards,
Greg

On Wed, Apr 12, 2017 at 6:24 PM, Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]<mailto:[email-masked]>> wrote:
I like Dave’s text better. MUST not forward is clear and to the point and does not preclude any extra processing that may take place to the packet as it does mandates immediate drop.

Andrew

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of Dave Dolson <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 13, 2017 at 5:05 AM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>, "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

From: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, April 12, 2017 4:58 PM
To: Joel M. Halpern
Cc: Dave Dolson; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Loop prevention via TTL

Hi Joel,

Regards,
Greg

Yours,
Joel

Regards,
Greg

    Opinions?
    Joel

        Joel,

        -Dave

        -----Original Message-----
        From: sfc [mailto:[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>] On Behalf Of Joel M. Halpern
        Sent: Wednesday, April 12, 2017 2:57 PM
        To: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
        Subject: [sfc] Loop prevention via TTL

        Thank you,
        Joel (and Jim)

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 14 Apr 2017 17:47:39 -0400

Adrian.  Comments in -line.
Yours,
Joel

On 4/14/17 5:00 PM, Adrian Farrel wrote:
> If, as has been suggested, anything that is processing the NSH should
> decrement the TTL, we can expect three decrements per SF (SFF in, SF,
> SFF out), so we might welcome an extra bit.

As chair, I can live with either.  As a participant, I tend to prefer 6 
bits, but it is very small preference.

> I don't understand this. If a packet is initiated with TTL of 0, and
> then processed, the TTL will be decremented. But decrementing 0 is
> ambiguous.
>

This was a discussion on the list.  First, as was pointed out to me 
privately, as it is a 6 bit field, the starting value is 63.
The question is what happens if the initial classifier has not yet been 
upgraded to compliance with the RFC.  If the logic is taht suggested by 
Dave Dolson:

Decrement TTL;
Compare with 0 -> Do not forward if 0;

Then things work even if the initial classifier (or a reclassifier which 
is not complaint and over-writes all the flag bits) sets the TTL to 0. 
This helps us with migration.

> If there was a call to draft text, then I missed it.

Greg had suggested that we needed to spell out the full OAM implications 
of the TTL handling.  My experience as a participant and leader is that 
trying to work out all the implications would produce an unacceptable 
delay.  Greg has since stated that as long as we define the TTL 
expiration behavior as "do not forward", he can live with it for this 
document.

>
>
>
> Thanks,
>
> Adrian
>
>
>
>
>
>
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Greg Mirsky
> *Sent:* 13 April 2017 04:48
> *To:* Dolganow, Andrew (Nokia - SG/Singapore)
> *Cc:* Joel M. Halpern; [email-masked]; Dave Dolson
> On Wed, Apr 12, 2017 at 6:24 PM, Dolganow, Andrew (Nokia - SG/Singapore)
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> I like Dave’s text better. MUST not forward is clear and to the point
> and does not preclude any extra processing that may take place to the
> packet as it does mandates immediate drop.
>
>
>
> Andrew
>
>
>
> *From: *sfc <[email-masked] <mailto:[email-masked]>> on
> behalf of Dave Dolson <[email-masked] <mailto:[email-masked]>>
> *To: *Greg Mirsky <[email-masked]
> <mailto:[email-masked]>>, "Joel M. Halpern" <[email-masked]
> <mailto:[email-masked]>>
> *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
>
>
> *From:*Greg Mirsky [mailto:[email-masked]
> <mailto:[email-masked]>]
> *Cc:* Dave Dolson; [email-masked] <mailto:[email-masked]>
>     Outgoing packet with TTL value of 0 MUST NOT be forwarded. The
>     packet MAY be discarded or it MAY be passed to the appropriate
>     network layer for error processing.
>
>
>
> Regards,
>
> Greg
>
>
>
> <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>         From: sfc [mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>] On
> Behalf Of Joel M. Halpern
>         To: [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 14 Apr 2017 15:30:53 -0700

Dear All,
I've mentioned the Alternate Marking method that can be used as truly
passive method to measure packet loss and delay. The method requires
allocation of Marking field so that the value of the field does not affect
the processing of the packet by the network. Ideally, it could be two bits
long, but one bit will do too.
I don't think it has to be defined in the NSH document at this time. I just
would like us to consider how limited number of reserved bits we have in
the fixed header.

Regards,
Greg

On Fri, Apr 14, 2017 at 2:47 PM, Joel M. Halpern <[email-masked]>
wrote:

> is not complaint and over-writes all the flag bits) sets the TTL to 0. This
> helps us with migration.
>
>
>>
>>
>> Joel also wrote...
>>
>>> delaying
> delay.  Greg has since stated that as long as we define the TTL expiration
> behavior as "do not forward", he can live with it for this document.
>
>
>>
>>
>> Thanks,
>>
>> Adrian
>>
>>
>>
>>
>>
>>
>>
>> behalf of Dave Dolson <[email-masked] <mailto:[email-masked]
>> >>

---

From: Sumandra Majee <[email-masked]>
Date: Mon, 17 Apr 2017 18:34:16 +0000

Support.

Quite a bit has already been discussed. My  $0.2
1) Only SFF decrement TTL
2) If TTL = 0 AFTER decrement, then SFF must drop this packet. 

On 4/12/17, 11:57 AM, "sfc on behalf of Joel M. Halpern" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    
    Thank you,
    Joel (and Jim)

---

From: Dave Dolson <[email-masked]>
Date: Mon, 17 Apr 2017 18:56:19 +0000

This makes sense to me, to only decrement TTL at the SFF.

From: James N Guichard [mailto:[email-masked]]
Sent: Friday, April 14, 2017 5:45 PM
To: [email-masked]; 'Greg Mirsky'; 'Dolganow, Andrew (Nokia - SG/Singapore)'
Cc: 'Joel M. Halpern'; Dave Dolson; [email-masked]
Subject: RE: [sfc] Loop prevention via TTL

Jim

From: sfc [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Friday, April 14, 2017 5:01 PM
To: 'Greg Mirsky' <[email-masked]<mailto:[email-masked]>>; 'Dolganow, Andrew (Nokia - SG/Singapore)' <[email-masked]<mailto:[email-masked]>>
Cc: 'Joel M. Halpern' <[email-masked]<mailto:[email-masked]>>; 'Dave Dolson' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Loop prevention via TTL

Hello.

Joel wrote

Joel also wrote...

Thanks,
Adrian

Hi Andrew,

Regards,
Greg

Andrew

Hi Joel,

Regards,
Greg

Yours,
Joel

Regards,
Greg

    Opinions?
    Joel

        Joel,

        -Dave

        -----Original Message-----
        From: sfc [mailto:[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>] On Behalf Of Joel M. Halpern
        Sent: Wednesday, April 12, 2017 2:57 PM
        To: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
        Subject: [sfc] Loop prevention via TTL

        Thank you,
        Joel (and Jim)

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 17 Apr 2017 14:38:54 -0700

Hi Joel,
I've got some concern about the behavior we expect from the SFC entities
that do not support TTL. The current draft requires that Reserved fields be
set to zero on transmit and ignored on receipt. If we have such entities in
the SFC, wouldn't these reset the TTL field on each NSH that traverses
them? and thus we still may have undetectable infinite loop (it is not
worse than without TTL). Not sure we can really fix it but perhaps mention
such scenario in the document would be helpful.

Regards,
Greg

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 17 Apr 2017 18:27:39 -0400

Greg, SFF (and SF, and proxy SF) do not create the NSH header.  They do 
modify it.  Hence, an NSH should preserve the reserved bits unmodified. 
This is common practice in protocols across the IETF.

We can change the wording if you like, but it will not chane the 
behavior of existing devices.  If they gratuitously modified flags, then 
they will break things.  As far as I can tell, the WG agreed that was 
unlikely.

Also, that is not our primary concern.  We want to make it easy to work 
with existing implementations, but not at the cost of being crazy.

Yours,
Joel

On 4/17/17 5:38 PM, Greg Mirsky wrote:
> that do not support TTL. The current draft requires that Reserved fields
> be set to zero on transmit and ignored on receipt. If we have such
> entities in the SFC, wouldn't these reset the TTL field on each NSH that
> traverses them? and thus we still may have undetectable infinite loop
> (it is not worse than without TTL). Not sure we can really fix it but
> perhaps mention such scenario in the document would be helpful.
>
> Regards,
> Greg
>
> On Wed, Apr 12, 2017 at 11:57 AM, Joel M. Halpern <[email-masked]
>     email serves to report our conclusion about the discussion of adding
>     a TTL field to the NSH header.
>
>     The specific change is to take 6 bits from the flags, and use them
>     as a TTL.  And take 4 bits from the MD-Type and use them as reserved
>     flag bits.  The backwards compatibility for migration of existing
>     tested.  The agreement observed on the list is to decrement before
>     testing for 0, thus allowing an NSH packet initiated with 0 to be
>     processed without any special case coding.  The default for
>     additional clarifications that we should have, to make sure the
>     authors reflect Working Group agreement.
>
>     Thank you,
>     Joel (and Jim)
>

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Mon, 17 Apr 2017 23:49:30 +0000

Agreed, both seems reasonable to me.

> On Apr 17, 2017, at 2:34 PM, Sumandra Majee <[email-masked]> wrote:
> 
> Support.
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 17 Apr 2017 16:53:41 -0700

Hi Sumandra,
I prefer the wording that states "MUST NOT forward" rather than "MUST drop"
as the latter is too restrictive.

Regards,
Greg

On Mon, Apr 17, 2017 at 4:49 PM, Paul Quinn (paulq) <[email-masked]> wrote:

> > On 4/12/17, 11:57 AM, "sfc on behalf of Joel M. Halpern" <
> [email-masked] on behalf of [email-masked]> wrote:
> >
> support

---

From: Sumandra Majee <[email-masked]>
Date: Tue, 18 Apr 2017 00:23:52 +0000

Agree

Sent from my iPhone

On Apr 17, 2017, at 4:53 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Sumandra,
I prefer the wording that states "MUST NOT forward" rather than "MUST drop" as the latter is too restrictive.

Regards,
Greg

On Mon, Apr 17, 2017 at 4:49 PM, Paul Quinn (paulq) <[email-masked]<mailto:[email-masked]>> wrote:
Agreed, both seems reasonable to me.

> On Apr 17, 2017, at 2:34 PM, Sumandra Majee <[email-masked]<mailto:[email-masked]>> wrote:
>
> Support.
>
> On 4/12/17, 11:57 AM, "sfc on behalf of Joel M. Halpern" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
>
>    [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: Eric Gray <[email-masked]>
Date: Tue, 18 Apr 2017 07:53:42 +0000

Joel, et al,

It has become difficult to figure out who said what, or what the latest word is in this discussion.

Summarizing, it looks as if the current case is that the actual number of bits may be 7, instead of 6 - where the maximum value corresponds to the number of bits (i.e. - 63 for 6 bits and 127 for 7 bits).

It also seems that the default starting value must be 0 (zero - to allow for some degree of backwards compatibility) and that decrementing this value is assumed to produce the maximum value (I interpreted Adrian's comment about ambiguity of decrementing a value of zero to possibly mean that - if an implementation  assumes the TTL value is unsigned - then decrementing that value might simply produce zero again).

Also, since we are redefining fields in a header format, we will also need to modify instructions to IANA about allocating reserved bits.

Is my interpretation/summary of this discussion correct?

--
Eric

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: den 14 april 2017 23:48
To: [email-masked]; 'Greg Mirsky' <[email-masked]>; 'Dolganow, Andrew (Nokia - SG/Singapore)' <[email-masked]>
Cc: 'Dave Dolson' <[email-masked]>; [email-masked]
Subject: Re: [sfc] Loop prevention via TTL

On 4/14/17 5:00 PM, Adrian Farrel wrote:
> With the removal of the C-bit, should we increase the size of the TTL 
> by
> 1 bit?
>

As chair, I can live with either.  As a participant, I tend to prefer 6 bits, but it is very small preference.

> Actually, I don't understand initiating with TTL 0. What's that about?

This was a discussion on the list.  First, as was pointed out to me privately, as it is a 6 bit field, the starting value is 63.
The question is what happens if the initial classifier has not yet been upgraded to compliance with the RFC.  If the logic is taht suggested by Dave Dolson:

Decrement TTL;

Then things work even if the initial classifier (or a reclassifier which is not complaint and over-writes all the flag bits) sets the TTL to 0. 
This helps us with migration.

> If there was a call to draft text, then I missed it.

Greg had suggested that we needed to spell out the full OAM implications of the TTL handling.  My experience as a participant and leader is that trying to work out all the implications would produce an unacceptable delay.  Greg has since stated that as long as we define the TTL expiration behavior as "do not forward", he can live with it for this document.

> On Wed, Apr 12, 2017 at 6:24 PM, Dolganow, Andrew (Nokia - 
> SG/Singapore) <[email-masked] <mailto:[email-masked]>> wrote:
>
> <mailto:[email-masked]>>, "Joel M. Halpern" 
> <[email-masked] <mailto:[email-masked]>>
> perhaps the following explanation of TTL handling will be sufficient 
> for NSH document and still leave room for detailed analysis elsewhere:
>
> I suspect what youa re really asking is whether we should add some 
> sort of ICMP behavior.  The working group did not ask for that.  And 
> more importantly, it would be very dificult, since SFPs are not 
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>> wrote:
>
>         <mailto:[email-masked] <mailto:[email-masked]>>] 
> On Behalf Of Joel M. Halpern