Subject: Re: [sfc] TTL field within the NSH base header

From: James N Guichard <[email-masked]>
Date: Mon, 1 May 2017 14:22:18 +0000

I don't understand this sentence as if an SFF is terminating a service chain then it *wont* be forwarding the packets to attached SFs; Shouldn't this sentence read "SFFs that terminate a service chain MUST forward the packet even if SHL is decremented to 0" ?

Jim

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, April 28, 2017 10:38 AM
To: Dave Dolson <[email-masked]>; James N Guichard <[email-masked]>; [email-masked]
Subject: RE: TTL field within the NSH base header

Re-,

I see SHL as a means to prevent SFF loops. There is no value in deleting a packet after an SFF decrement the SHL to 0, but that packet is to be passed to SFs that are attached to this SFF. The packet will be forwarded after stripping the NSH header; no risk for SFF loops out there. No?

Cheers,
Med

De : Dave Dolson [mailto:[email-masked]]
Envoyé : vendredi 28 avril 2017 16:29
À : BOUCADAIR Mohamed IMT/OLN; James N Guichard; [email-masked]<mailto:[email-masked]>
Objet : RE: TTL field within the NSH base header

Med,

"SFFs that terminate a service chain MUST forward the packet to attached SFs even if SHL is decremented to 0."
I don't think this is right.
If TTL/SHL is decremented to 0, this must not be forwarded as NSH.
I see that *receiving* a packet with SHL=1 can result in chain termination, i.e., NSH decapsulation. But not forwarding as NSH with SHL=0.

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, April 28, 2017 9:36 AM
To: James N Guichard; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] TTL field within the NSH base header

Hi Jim, all,

I have the following comments :

·         Change "TTL" to "SFF Hop Limit (SHL)" because this field is not about a time to live but about a limit of SFF hops to be crossed.

·         I don't understand what is meant by "testing".

·         I suggest to make this change to cover the following points:

o   SHL should be configurable by the control plane.

o   Packets can be forwarded to SFs even if SHL is decremented to 0 for the terminating SFF.

o   I don't think it is a good idea to include "Decrementing by a value of 1 from 0 shall result in a TTL value of 63" because this will lead to a broken mechanism.

OLD:
TTL: Service plane time-to-live. An SFF MUST decrement the TTL by a value of 1 for all NSH packets it receives. Decrementing by a value of 1 from 0 shall result in a TTL value of 63. The default for originating an NSH packet is a TTL value of 63. The decrement SHALL occur before testing for 0. After decrement, if the TTL is 0, the NSH packet MUST NOT be forwarded.

NEW:
SHL (SFF Hop Limit): Indicates the maximum SFF hops for a service chain. The initial SHL value SHOULD be configurable via the control plane; the configured initial value can be specific to a chain or all chains. If no initial value is explicitly provided, the default initial SHL value 63 MUST be used. Each SFF involved in forwarding an NSH packet MUST decrement SHL value by 1. The packet MUST NOT be forwarded to a next hop SFF if SHL is decremented to zero. SFFs that terminate a service chain MUST forward the packet to attached SFs even if SHL is decremented to 0.

Thank you.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de James N Guichard
Envoyé : jeudi 27 avril 2017 20:54
À : [email-masked]<mailto:[email-masked]>
Objet : [sfc] TTL field within the NSH base header

Dear WG:

Having reviewed all of the email discussion on the mailing list it appears to the chairs that we have consensus to add a TTL field to the NSH base header. We would like to propose the following changes:

Section 3.2:
Update figure 2 as follows:

     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| Next Protocol |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Add the following text after figure 2:

TTL: Service plane time-to-live. An SFF MUST decrement the TTL by a value of 1 for all NSH packets it receives. Decrementing by a value of 1 from 0 shall result in a TTL value of 63. The default for originating an NSH packet is a TTL value of 63. The decrement SHALL occur before testing for 0. After decrement, if the TTL is 0, the NSH packet MUST NOT be forwarded.

Section 3.4:
Update figure 4 to reflect the new base header format as per section 3.2 base header.

Section 3.5:
Update figure 5 to reflect the new base header format as per section 3.2 base header.

Section 12.2.1:
Current text is as follows:

   There are ten bits at the beginning of the NSH Base Header.  New bits
   are assigned via Standards Action [RFC5226].

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Critical TLV (C bit)
   Bits 4-9 - Reserved

Replace entire text as follows:

   There are eight reserved bits in the NSH Base Header. New bits
   are assigned via Standards Action [RFC5226].

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:
Current text has the MD-type as 8-bit values.

Update text for this section and table 1 to reflect 4-bit values *not* 8-bit values.

Please review carefully and indicate support for these changes (or any changes to the suggested text).

Thanks,

Jim & Joel

---

From: Ron Parker <[email-masked]>
Date: Mon, 1 May 2017 14:28:24 +0000

I'd like to disambiguate the word "forwarding".   From SFF perspective, there is forwarding to attached SF instances and there is forwarding to other SFFs.

"SFFs that terminate a service chain MUST forward the packet to attached service functions, even if SHL is decremented to 0"

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of James N Guichard
Sent: Monday, May 1, 2017 10:22 AM
To: [email-masked]; Dave Dolson <[email-masked]>; [email-masked]
Subject: Re: [sfc] TTL field within the NSH base header

Jim

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, April 28, 2017 10:38 AM
To: Dave Dolson <[email-masked]<mailto:[email-masked]>>; James N Guichard <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: TTL field within the NSH base header

Re-,

Cheers,
Med

Med,

-Dave

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: Kyle Larose <[email-masked]>
Date: Mon, 1 May 2017 14:42:11 +0000

Do we really need to complicate SFFs by having them understand whether they are forwarding to an SF or an SFF? Has that distinction been made previously? If not, I question whether it's worth forcing it to be made now just to add one more hop to the path.

From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, May 01, 2017 10:28 AM
To: James N Guichard; [email-masked]; Dave Dolson; [email-masked]
Subject: Re: [sfc] TTL field within the NSH base header

   Ron

Jim

Re-,

Cheers,
Med

Med,

-Dave

Hi Jim, all,

*        Change "TTL" to "SFF Hop Limit (SHL)" because this field is not about a time to live but about a limit of SFF hops to be crossed.

*        I don't understand what is meant by "testing".

*        I suggest to make this change to cover the following points:

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: James N Guichard <[email-masked]>
Date: Mon, 1 May 2017 14:45:12 +0000

Yes but my point was if the SFF is *terminating* the service chain there are no service functions left to be forwarded to so the sentence does not make any sense. If however the SFF is terminating the service chain and at termination the SHL reaches 0 then it should still forward the packet (after removal of NSH).

Jim

From: Ron Parker [mailto:[email-masked]]
Sent: Monday, May 01, 2017 10:28 AM
To: James N Guichard <[email-masked]>; [email-masked]; Dave Dolson <[email-masked]>; [email-masked]
Subject: RE: TTL field within the NSH base header

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of James N Guichard
Sent: Monday, May 1, 2017 10:22 AM
To: [email-masked]<mailto:[email-masked]>; Dave Dolson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] TTL field within the NSH base header

Jim

Re-,

Cheers,
Med

Med,

-Dave

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: Ron Parker <[email-masked]>
Date: Mon, 1 May 2017 14:50:17 +0000

We could simplify this by saying that an SFF that receives an NSH packet with TTL=1 shall drop the packet.   That doesn't require any distinction of the type of forwarding.    You could argue that perhaps 1 means take care of local SF's, only, but then we are back to having to make that distinction.    Given that we are starting at 63 by default, finessing what happens when receiving 1 doesn't seem worthwhile to me.

From: James N Guichard [mailto:[email-masked]]
Sent: Monday, May 1, 2017 10:45 AM
To: Ron Parker <[email-masked]>; [email-masked]; Dave Dolson <[email-masked]>; [email-masked]
Subject: RE: TTL field within the NSH base header

Jim

From: Ron Parker [mailto:[email-masked]]
Sent: Monday, May 01, 2017 10:28 AM
To: James N Guichard <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Dave Dolson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: TTL field within the NSH base header

   Ron

Jim

Re-,

Cheers,
Med

Med,

-Dave

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 1 May 2017 10:53:59 -0400

The distinction has been made frequently.
For example, section 7.1 of the NSH document has separate tables 
describing the information needed by an SFF to forward to the next SFF. 
That table includes indication of the transport and next hop address to 
be used.
In contrast, the summary of information about forwarding toi service 
functions only includes an identification of the SF, as the forwarding 
mechanism for that communication is outside of our scope.

Yours,
Joel

On 5/1/17 10:42 AM, Kyle Larose wrote:
> Do we really need to complicate SFFs by having them understand whether
> they are forwarding to an SF or an SFF? Has that distinction been made
> previously? If not, I question whether it’s worth forcing it to be made
> now just to add one more hop to the path.
>
>
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Ron Parker
> *Sent:* Monday, May 01, 2017 10:28 AM
> *To:* James N Guichard; [email-masked]; Dave Dolson;
> [email-masked]
> *Subject:* Re: [sfc] TTL field within the NSH base header
>
>
>
> I’d like to disambiguate the word “forwarding”.   From SFF perspective,
> there is forwarding to attached SF instances and there is forwarding to
> other SFFs.
>
>
>
> “SFFs that terminate a service chain MUST forward the packet to attached
> service functions, even if SHL is decremented to 0”
>
>
>
>    Ron
>
>
>
>
>
>
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *James N Guichard
> *Sent:* Monday, May 1, 2017 10:22 AM
> *To:* [email-masked]; Dave Dolson <[email-masked]>;
> [email-masked]
> *Subject:* Re: [sfc] TTL field within the NSH base header
>
>
>
> I don’t understand this sentence as if an SFF is terminating a service
> chain then it **wont** be forwarding the packets to attached SFs;
> Shouldn’t this sentence read “SFFs that terminate a service chain MUST
> forward the packet even if SHL is decremented to 0” ?
>
>
>
> Jim
>
>
>
> *From:[email-masked]
> <mailto:[email-masked]> [mailto:[email-masked]]
> *Sent:* Friday, April 28, 2017 10:38 AM
> *To:* Dave Dolson <[email-masked] <mailto:[email-masked]>>;
> James N Guichard <[email-masked]
> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> *Subject:* RE: TTL field within the NSH base header
>
>
>
> Re-,
>
>
>
> I see SHL as a means to prevent SFF loops. There is no value in deleting
> a packet after an SFF decrement the SHL to 0, but that packet is to be
> passed to SFs that are attached to this SFF. The packet will be
> forwarded after stripping the NSH header; no risk for SFF loops out
> there. No?
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :*Dave Dolson [mailto:[email-masked]]
> *Envoyé :* vendredi 28 avril 2017 16:29
> *À :* BOUCADAIR Mohamed IMT/OLN; James N Guichard; [email-masked]
> <mailto:[email-masked]>
> *Objet :* RE: TTL field within the NSH base header
>
>
>
> Med,
>
>
>
> “SFFs that terminate a service chain MUST forward the packet to attached
> SFs even if SHL is decremented to 0.”
>
> I don’t think this is right.
>
> I see that **receiving** a packet with SHL=1 can result in chain
> termination, i.e., NSH decapsulation. But not forwarding as NSH with SHL=0.
>
>
>
> -Dave
>
>
>
>
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of
> [email-masked] <mailto:[email-masked]>
> *Sent:* Friday, April 28, 2017 9:36 AM
> *To:* James N Guichard; [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [sfc] TTL field within the NSH base header
>
>
>
> Hi Jim, all,
>
>
>
> ·        Change “TTL” to “SFF Hop Limit (SHL)” because this field is not
> about a time to live but about a limit of SFF hops to be crossed.
>
> ·        I don’t understand what is meant by “testing”.
>
> o   I don’t think it is a good idea to include “Decrementing by a value
> of 1 from 0 shall result in a TTL value of 63” because this will lead to
> a broken mechanism.
>
>
>
> OLD:
>
> TTL: Service plane time-to-live. An SFF MUST decrement the TTL by a
> value of 1 for all NSH packets it receives. Decrementing by a value of 1
> from 0 shall result in a TTL value of 63. The default for originating an
> NSH packet is a TTL value of 63. The decrement SHALL occur before
> testing for 0. After decrement, if the TTL is 0, the NSH packet MUST NOT
> be forwarded.
>
>
>
> NEW:
>
> SHL (SFF Hop Limit): Indicates the maximum SFF hops for a service chain.
> The initial SHL value SHOULD be configurable via the control plane; the
> configured initial value can be specific to a chain or all chains. If no
> initial value is explicitly provided, the default initial SHL value 63
> MUST be used. Each SFF involved in forwarding an NSH packet MUST
> decrement SHL value by 1. The packet MUST NOT be forwarded to a next hop
> SFF if SHL is decremented to zero. SFFs that terminate a service chain
> MUST forward the packet to attached SFs even if SHL is decremented to 0.
>
>
>
> Thank you.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :*sfc [mailto:[email-masked]] *De la part de* James N Guichard
> *Envoyé :* jeudi 27 avril 2017 20:54
> *À :* [email-masked] <mailto:[email-masked]>
> *Objet :* [sfc] TTL field within the NSH base header
>
>
>
> Dear WG:
>
>
>
> Having reviewed all of the email discussion on the mailing list it
> appears to the chairs that we have consensus to add a TTL field to the
> NSH base header. We would like to propose the following changes:
>
>
>
> Section 3.2:
>
> TTL: Service plane time-to-live. An SFF MUST decrement the TTL by a
> value of 1 for all NSH packets it receives. Decrementing by a value of 1
> from 0 shall result in a TTL value of 63. The default for originating an
> NSH packet is a TTL value of 63. The decrement SHALL occur before
> testing for 0. After decrement, if the TTL is 0, the NSH packet MUST NOT
> be forwarded.
>
>
>
> Section 3.4:
>
> *Please review carefully and indicate support for these changes (or any
> changes to the suggested text).*
>
> * *
>
> Thanks,
>
>
>
> Jim & Joel
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Dave Dolson <[email-masked]>
Date: Mon, 1 May 2017 15:11:12 +0000

There is a difference between dropping the packet at receive vs. transmit.
A *terminating* SFF may accept a packet with TTL=1.  I.e., where the NSH header is removed.
What matters is that it is not decremented to zero and forwarded as NSH.

Otherwise we'd say, "huh, no point in sending a packet if TTL=1. And huh, if received with TTL=2 then we might as well drop it..." Recurse ad absurdum.

Hence, the correct language needs to convey that a device decrementing TTL (in order to forward NSH) must check if it would result in zero.

This conveys that, I think:
The packet MUST NOT be forwarded to a next hop if SHL is decremented to zero.

-Dave

From: Ron Parker [mailto:[email-masked]]
Sent: Monday, May 1, 2017 10:50 AM
To: James N Guichard; [email-masked]; Dave Dolson; [email-masked]
Subject: RE: TTL field within the NSH base header

From: James N Guichard [mailto:[email-masked]]
Sent: Monday, May 1, 2017 10:45 AM
To: Ron Parker <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Dave Dolson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: TTL field within the NSH base header

Jim

   Ron

Jim

Re-,

Cheers,
Med

Med,

-Dave

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: Ron Parker <[email-masked]>
Date: Mon, 1 May 2017 15:14:26 +0000

Agree that differentiating "forwarding" to attached SF instances vs subsequent SFF's is logical and intuitive (to me) and I prefer to acknowledge that there is a difference.   But, I was addressing a suggestion to simplify.     In practice, 61 or 62 or 63 decrements of TTL all probably mean the same thing :).

   Ron

From: Dave Dolson [mailto:[email-masked]]
Sent: Monday, May 1, 2017 11:11 AM
To: Ron Parker <[email-masked]>; James N Guichard <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: TTL field within the NSH base header

-Dave

From: Ron Parker [mailto:[email-masked]]
Sent: Monday, May 1, 2017 10:50 AM
To: James N Guichard; [email-masked]<mailto:[email-masked]>; Dave Dolson; [email-masked]<mailto:[email-masked]>
Subject: RE: TTL field within the NSH base header

Jim

   Ron

Jim

Re-,

Cheers,
Med

Med,

-Dave

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: Dave Dolson <[email-masked]>
Date: Mon, 1 May 2017 15:24:37 +0000

I think precision in the definition is important for when expects certain behavior for small values of TTL. E.g., by using trace-route type of tools.
We can't just wave our hands and say drop packets with TTL near 0 or 1 or 2.

If one has a chain of 3 items, a TTL of 6 should work. (SFFs receive packets 6 times in the system diagram that is usually drawn).

(Simplified: I realize in some systems more SFF interactions are required.)

From: Ron Parker [mailto:[email-masked]]
Sent: Monday, May 1, 2017 11:14 AM
To: Dave Dolson; James N Guichard; [email-masked]; [email-masked]
Subject: RE: TTL field within the NSH base header

   Ron

From: Dave Dolson [mailto:[email-masked]]
Sent: Monday, May 1, 2017 11:11 AM
To: Ron Parker <[email-masked]<mailto:[email-masked]>>; James N Guichard <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: TTL field within the NSH base header

-Dave

Jim

   Ron

Jim

Re-,

Cheers,
Med

Med,

-Dave

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: Ron Parker <[email-masked]>
Date: Mon, 1 May 2017 15:40:46 +0000

Agree that I'd opt for precision over simplicity.   Which is what I tried to convey a ways back on this thread regarding differentiated behavior at the last SFF in the SFP vs. the non-last SFF in the SFP.    Subsequent comments didn't seem to embrace that way of describing things.    Also, if there were consensus to supporting that approach, backward compatibility for classifiers that emit TTL=0 could be addressed by also describing behavior at the first SFF vs. non-first.

TTL=1

TTL=0

Only SFF (First and last)

Valid - service local SF's

Valid for backward compatibility - service local SF's

First SFF and not Last

Invalid - drop (since propagation to subsequent SFF with TTL=0 is illegal)

Valid for backward compatibility - service local SF's and propagate to subsequent SFF with TTL=63

Last SFF when >1 SFF's for SFP

Valid - service local SF's

Invalid -drop (due to bad behavior of previous SFF)

From: Dave Dolson [mailto:[email-masked]]
Sent: Monday, May 1, 2017 11:25 AM
To: Ron Parker <[email-masked]>; James N Guichard <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: TTL field within the NSH base header

From: Ron Parker [mailto:[email-masked]]
Sent: Monday, May 1, 2017 11:14 AM
To: Dave Dolson; James N Guichard; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: TTL field within the NSH base header

   Ron

-Dave

Jim

   Ron

Jim

Re-,

Cheers,
Med

Med,

-Dave

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: Dave Dolson <[email-masked]>
Date: Mon, 1 May 2017 15:56:05 +0000

Ron,
I too would like simple, but your table looks pretty complicated. And I think it adds configuration for an SFF to know whether there are others before it.
My version of simple:
  TTL field of 0 means 64.
  Every SFF decrements TTL each time it forwards the NSH packet. If decrementing from 1 would result in under-flow to 64, discard.

From: Ron Parker [mailto:[email-masked]]
Sent: Monday, May 1, 2017 11:41 AM
To: Dave Dolson; James N Guichard; [email-masked]; [email-masked]
Subject: RE: TTL field within the NSH base header

TTL=1

TTL=0

First SFF and not Last

   Ron

-Dave

Jim

   Ron

Jim

Re-,

Cheers,
Med

Med,

-Dave

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: Ron Parker <[email-masked]>
Date: Mon, 1 May 2017 16:50:32 +0000

Is there a decrement for each SF, too.?   In the past we've talked about decrement only between SFFs.

On May 1, 2017, at 11:56 AM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:

Ron,

Agree that I’d opt for precision over simplicity.   Which is what I tried to convey a ways back on this thread regarding differentiated behavior at the last SFF in the SFP vs. the non-last SFF in the SFP.    Subsequent comments didn’t seem to embrace that way of describing things.    Also, if there were consensus to supporting that approach, backward compatibility for classifiers that emit TTL=0 could be addressed by also describing behavior at the first SFF vs. non-first.

TTL=1

TTL=0

Valid – service local SF’s

Valid for backward compatibility – service local SF’s

First SFF and not Last

Invalid – drop (since propagation to subsequent SFF with TTL=0 is illegal)

Valid for backward compatibility – service local SF’s and propagate to subsequent SFF with TTL=63

Last SFF when >1 SFF’s for SFP

Valid – service local SF’s

Invalid –drop (due to bad behavior of previous SFF)

I think precision in the definition is important for when expects certain behavior for small values of TTL. E.g., by using trace-route type of tools.
We can’t just wave our hands and say drop packets with TTL near 0 or 1 or 2.

Agree that differentiating “forwarding” to attached SF instances vs subsequent SFF’s is logical and intuitive (to me) and I prefer to acknowledge that there is a difference.   But, I was addressing a suggestion to simplify.     In practice, 61 or 62 or 63 decrements of TTL all probably mean the same thing :).

   Ron

Otherwise we’d say, “huh, no point in sending a packet if TTL=1. And huh, if received with TTL=2 then we might as well drop it…” Recurse ad absurdum.

-Dave

We could simplify this by saying that an SFF that receives an NSH packet with TTL=1 shall drop the packet.   That doesn’t require any distinction of the type of forwarding.    You could argue that perhaps 1 means take care of local SF’s, only, but then we are back to having to make that distinction.    Given that we are starting at 63 by default, finessing what happens when receiving 1 doesn’t seem worthwhile to me.

Jim

I’d like to disambiguate the word “forwarding”.   From SFF perspective, there is forwarding to attached SF instances and there is forwarding to other SFFs.

“SFFs that terminate a service chain MUST forward the packet to attached service functions, even if SHL is decremented to 0”

   Ron

I don’t understand this sentence as if an SFF is terminating a service chain then it *wont* be forwarding the packets to attached SFs; Shouldn’t this sentence read “SFFs that terminate a service chain MUST forward the packet even if SHL is decremented to 0” ?

Jim

Re-,

Cheers,
Med

Med,

“SFFs that terminate a service chain MUST forward the packet to attached SFs even if SHL is decremented to 0.”
I don’t think this is right.
If TTL/SHL is decremented to 0, this must not be forwarded as NSH.
I see that *receiving* a packet with SHL=1 can result in chain termination, i.e., NSH decapsulation. But not forwarding as NSH with SHL=0.

-Dave

Hi Jim, all,

•        Change “TTL” to “SFF Hop Limit (SHL)” because this field is not about a time to live but about a limit of SFF hops to be crossed.

•        I don’t understand what is meant by “testing”.

•        I suggest to make this change to cover the following points:

o   I don’t think it is a good idea to include “Decrementing by a value of 1 from 0 shall result in a TTL value of 63” because this will lead to a broken mechanism.

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 1 May 2017 12:55:05 -0400

The summary I sent to the list, based on what little I could tell of 
rough consensus, was to only decrement TTL at SFF.  If you want to argue 
for decrementing at all NSH-aware devices, state your case.

Yours,
Joel

On 5/1/17 12:50 PM, Ron Parker wrote:
>> I too would like simple, but your table looks pretty complicated. And
>> I think it adds configuration for an SFF to know whether there are
>> others before it.
>>
>> My version of simple:
>>
>>   TTL field of 0 means 64.
>>
>>   Every SFF decrements TTL each time it forwards the NSH packet. If
>> decrementing from 1 would result in under-flow to 64, discard.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:*Ron Parker [mailto:[email-masked]]
>> *Sent:* Monday, May 1, 2017 11:41 AM
>> *To:* Dave Dolson; James N Guichard; [email-masked]
>> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>> Agree that I’d opt for precision over simplicity.   Which is what I
>> tried to convey a ways back on this thread regarding differentiated
>> behavior at the last SFF in the SFP vs. the non-last SFF in the
>> SFP.    Subsequent comments didn’t seem to embrace that way of
>> describing things.    Also, if there were consensus to supporting that
>> approach, backward compatibility for classifiers that emit TTL=0 could
>> be addressed by also describing behavior at the first SFF vs. non-first.
>>
>>
>>
>>
>>
>> 	
>>
>> TTL=1
>>
>> 	
>>
>> TTL=0
>>
>> *From:* Dave Dolson [mailto:[email-masked]]
>> *Sent:* Monday, May 1, 2017 11:25 AM
>> *To:* Ron Parker <[email-masked]
>> <mailto:[email-masked]>>; James N Guichard
>> <[email-masked] <mailto:[email-masked]>>;
>> [email-masked] <mailto:[email-masked]>;
>> [email-masked] <mailto:[email-masked]>
>> I think precision in the definition is important for when expects
>> certain behavior for small values of TTL. E.g., by using trace-route
>> type of tools.
>>
>> If one has a chain of 3 items, a TTL of 6 should work. (SFFs receive
>> packets 6 times in the system diagram that is usually drawn).
>>
>>
>>
>> *From:*Ron Parker [mailto:[email-masked]]
>> *Sent:* Monday, May 1, 2017 11:14 AM
>> *To:* Dave Dolson; James N Guichard; [email-masked]
>> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>> Agree that differentiating “forwarding” to attached SF instances vs
>> subsequent SFF’s is logical and intuitive (to me) and I prefer to
>> acknowledge that there is a difference.   But, I was addressing a
>> suggestion to simplify.     In practice, 61 or 62 or 63 decrements of
>> TTL all probably mean the same thing J.
>>
>>
>>
>>    Ron
>>
>>
>>
>>
>>
>> *From:* Dave Dolson [mailto:[email-masked]]
>> *Sent:* Monday, May 1, 2017 11:11 AM
>> *To:* Ron Parker <[email-masked]
>> <mailto:[email-masked]>>; James N Guichard
>> <[email-masked] <mailto:[email-masked]>>;
>> [email-masked] <mailto:[email-masked]>;
>> [email-masked] <mailto:[email-masked]>
>> A **terminating** SFF may accept a packet with TTL=1.  I.e., where the
>> NSH header is removed.
>>
>> Otherwise we’d say, “huh, no point in sending a packet if TTL=1. And
>> huh, if received with TTL=2 then we might as well drop it…” Recurse ad
>> absurdum.
>>
>>
>>
>> Hence, the correct language needs to convey that a device decrementing
>> TTL (in order to forward NSH) must check if it would result in zero.
>>
>>
>>
>> *From:*Ron Parker [mailto:[email-masked]]
>> *Sent:* Monday, May 1, 2017 10:50 AM
>> *To:* James N Guichard; [email-masked]
>> <mailto:[email-masked]>; Dave Dolson; [email-masked]
>> <mailto:[email-masked]>
>> We could simplify this by saying that an SFF that receives an NSH
>> packet with TTL=1 shall drop the packet.   That doesn’t require any
>> distinction of the type of forwarding.    You could argue that perhaps
>> 1 means take care of local SF’s, only, but then we are back to having
>> to make that distinction.    Given that we are starting at 63 by
>> default, finessing what happens when receiving 1 doesn’t seem
>> worthwhile to me.
>>
>>
>>
>> *From:* James N Guichard [mailto:[email-masked]]
>> *Sent:* Monday, May 1, 2017 10:45 AM
>> *To:* Ron Parker <[email-masked]
>> <mailto:[email-masked]>>;
>> [email-masked] <mailto:[email-masked]>;
>> Dave Dolson <[email-masked] <mailto:[email-masked]>>;
>> [email-masked] <mailto:[email-masked]>
>> Yes but my point was if the SFF is **terminating** the service chain
>> there are no service functions left to be forwarded to so the sentence
>> does not make any sense. If however the SFF is terminating the service
>> chain and at termination the SHL reaches 0 then it should still
>> forward the packet (after removal of NSH).
>>
>>
>>
>> Jim
>>
>>
>>
>> *From:* Ron Parker [mailto:[email-masked]]
>> *To:* James N Guichard <[email-masked]
>> <mailto:[email-masked]>>; [email-masked]
>> <mailto:[email-masked]>; Dave Dolson
>> <[email-masked] <mailto:[email-masked]>>; [email-masked]
>> <mailto:[email-masked]>
>> I’d like to disambiguate the word “forwarding”.   From SFF
>> perspective, there is forwarding to attached SF instances and there is
>> forwarding to other SFFs.
>>
>>
>>
>> “SFFs that terminate a service chain MUST forward the packet to
>> attached service functions, even if SHL is decremented to 0”
>>
>>
>>
>>    Ron
>>
>>
>>
>>
>>
>>
>>
>> *From:* sfc [mailto:[email-masked]] *On Behalf Of *James N Guichard
>> *To:* [email-masked]
>> <mailto:[email-masked]>; Dave Dolson
>> <[email-masked] <mailto:[email-masked]>>; [email-masked]
>> <mailto:[email-masked]>
>> *From:* [email-masked]
>> *To:* Dave Dolson <[email-masked]
>> <mailto:[email-masked]>>; James N Guichard
>> <[email-masked] <mailto:[email-masked]>>;
>> [email-masked] <mailto:[email-masked]>
>> I see SHL as a means to prevent SFF loops. There is no value in
>> deleting a packet after an SFF decrement the SHL to 0, but that packet
>> is to be passed to SFs that are attached to this SFF. The packet will
>> be forwarded after stripping the NSH header; no risk for SFF loops out
>> there. No?
>>
>>
>>
>> Cheers,
>>
>> Med
>>
>>
>>
>> “SFFs that terminate a service chain MUST forward the packet to
>> attached SFs even if SHL is decremented to 0.”
>>
>> ·        Change “TTL” to “SFF Hop Limit (SHL)” because this field is
>> not about a time to live but about a limit of SFF hops to be crossed.
>>
>> o   I don’t think it is a good idea to include “Decrementing by a
>> value of 1 from 0 shall result in a TTL value of 63” because this will
>> lead to a broken mechanism.
>>
>>
>>
>> OLD:
>>
>> value of 1 for all NSH packets it receives. Decrementing by a value of
>> 1 from 0 shall result in a TTL value of 63. The default for
>> originating an NSH packet is a TTL value of 63. The decrement SHALL
>> occur before testing for 0. After decrement, if the TTL is 0, the NSH
>> packet MUST NOT be forwarded.
>>
>>
>>
>> NEW:
>>
>> SHL (SFF Hop Limit): Indicates the maximum SFF hops for a service
>> chain. The initial SHL value SHOULD be configurable via the control
>> plane; the configured initial value can be specific to a chain or all
>> chains. If no initial value is explicitly provided, the default
>> initial SHL value 63 MUST be used. Each SFF involved in forwarding an
>> NSH packet MUST decrement SHL value by 1. The packet MUST NOT be
>> forwarded to a next hop SFF if SHL is decremented to zero. SFFs that
>> terminate a service chain MUST forward the packet to attached SFs even
>> if SHL is decremented to 0.
>>
>>
>>
>> Thank you.
>>
>>
>>
>> Cheers,
>>
>> Med
>>
>>
>>
>> value of 1 for all NSH packets it receives. Decrementing by a value of
>> 1 from 0 shall result in a TTL value of 63. The default for
>> originating an NSH packet is a TTL value of 63. The decrement SHALL
>> occur before testing for 0. After decrement, if the TTL is 0, the NSH
>> packet MUST NOT be forwarded.
>>
>>
>>
>> Section 3.4:
>>
>> *Please review carefully and indicate support for these changes (or
>> any changes to the suggested text).*
>>
>> * *
>>
>> Thanks,
>>
>>
>>
>> Jim & Joel
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 1 May 2017 10:02:01 -0700

"Be liberal what you accept. Be conservative what you send."
I think this sums what we have discussed - accept TTL 0, don't forward TTL
0.

Regards, Greg

On May 1, 2017 8:58 AM, "Dave Dolson" <[email-masked]> wrote:

Ron,

I too would like simple, but your table looks pretty complicated. And I
think it adds configuration for an SFF to know whether there are others
before it.

My version of simple:

  TTL field of 0 means 64.

*To:* Dave Dolson; James N Guichard; [email-masked];
[email-masked]
*Subject:* RE: TTL field within the NSH base header

Agree that I’d opt for precision over simplicity.   Which is what I tried
to convey a ways back on this thread regarding differentiated behavior at
the last SFF in the SFP vs. the non-last SFF in the SFP.    Subsequent
comments didn’t seem to embrace that way of describing things.    Also, if
there were consensus to supporting that approach, backward compatibility
for classifiers that emit TTL=0 could be addressed by also describing
behavior at the first SFF vs. non-first.

TTL=1

TTL=0

First SFF and not Last

Valid for backward compatibility – service local SF’s and propagate to
subsequent SFF with TTL=63

*From:* Dave Dolson [mailto:[email-masked] <[email-masked]>]
*Sent:* Monday, May 1, 2017 11:25 AM
*To:* Ron Parker <[email-masked]>; James N Guichard <
[email-masked]>; [email-masked]; [email-masked]
*Subject:* RE: TTL field within the NSH base header

I think precision in the definition is important for when expects certain
behavior for small values of TTL. E.g., by using trace-route type of tools.

*From:* Ron Parker [mailto:[email-masked]
<[email-masked]>]
*Sent:* Monday, May 1, 2017 11:14 AM
*To:* Dave Dolson; James N Guichard; [email-masked];
[email-masked]
*Subject:* RE: TTL field within the NSH base header

Agree that differentiating “forwarding” to attached SF instances vs
subsequent SFF’s is logical and intuitive (to me) and I prefer to
acknowledge that there is a difference.   But, I was addressing a
suggestion to simplify.     In practice, 61 or 62 or 63 decrements of TTL
all probably mean the same thing J.

   Ron

*From:* Dave Dolson [mailto:[email-masked] <[email-masked]>]
*Sent:* Monday, May 1, 2017 11:11 AM
*To:* Ron Parker <[email-masked]>; James N Guichard <
[email-masked]>; [email-masked]; [email-masked]
*Subject:* RE: TTL field within the NSH base header

A **terminating** SFF may accept a packet with TTL=1.  I.e., where the NSH
header is removed.

Otherwise we’d say, “huh, no point in sending a packet if TTL=1. And huh,
if received with TTL=2 then we might as well drop it…” Recurse ad absurdum.

Hence, the correct language needs to convey that a device decrementing TTL
(in order to forward NSH) must check if it would result in zero.

The packet MUST NOT be forwarded to a next hop if SHL is decremented to
zero.

-Dave

*From:* Ron Parker [mailto:[email-masked]
<[email-masked]>]
*Sent:* Monday, May 1, 2017 10:50 AM
*To:* James N Guichard; [email-masked]; Dave Dolson;
[email-masked]
*Subject:* RE: TTL field within the NSH base header

We could simplify this by saying that an SFF that receives an NSH packet
with TTL=1 shall drop the packet.   That doesn’t require any distinction of
the type of forwarding.    You could argue that perhaps 1 means take care
of local SF’s, only, but then we are back to having to make that
distinction.    Given that we are starting at 63 by default, finessing what
happens when receiving 1 doesn’t seem worthwhile to me.

*From:* James N Guichard [mailto:[email-masked]
<[email-masked]>]
*Sent:* Monday, May 1, 2017 10:45 AM
*To:* Ron Parker <[email-masked]>;
[email-masked]; Dave Dolson <[email-masked]>;
[email-masked]
*Subject:* RE: TTL field within the NSH base header

Yes but my point was if the SFF is **terminating** the service chain there
are no service functions left to be forwarded to so the sentence does not
make any sense. If however the SFF is terminating the service chain and at
termination the SHL reaches 0 then it should still forward the packet
(after removal of NSH).

Jim

*From:* Ron Parker [mailto:[email-masked]
<[email-masked]>]
*Sent:* Monday, May 01, 2017 10:28 AM
*To:* James N Guichard <[email-masked]>;
[email-masked]; Dave Dolson <[email-masked]>;
[email-masked]
*Subject:* RE: TTL field within the NSH base header

   Ron

*From:* sfc [mailto:[email-masked] <[email-masked]>] *On Behalf
Of *James N Guichard
*Sent:* Monday, May 1, 2017 10:22 AM
*To:* [email-masked]; Dave Dolson <[email-masked]>;
[email-masked]
*Subject:* Re: [sfc] TTL field within the NSH base header

I don’t understand this sentence as if an SFF is terminating a service
chain then it **wont** be forwarding the packets to attached SFs; Shouldn’t
this sentence read “SFFs that terminate a service chain MUST forward the
packet even if SHL is decremented to 0” ?

Jim

*From:* [email-masked] [mailto:[email-masked]
<[email-masked]>]
*Sent:* Friday, April 28, 2017 10:38 AM
*To:* Dave Dolson <[email-masked]>; James N Guichard <
[email-masked]>; [email-masked]
*Subject:* RE: TTL field within the NSH base header

Re-,

I see SHL as a means to prevent SFF loops. There is no value in deleting a
packet after an SFF decrement the SHL to 0, but that packet is to be passed
to SFs that are attached to this SFF. The packet will be forwarded after
stripping the NSH header; no risk for SFF loops out there. No?

Cheers,

Med

*De :* Dave Dolson [mailto:[email-masked] <[email-masked]>]
*Envoyé :* vendredi 28 avril 2017 16:29
*À :* BOUCADAIR Mohamed IMT/OLN; James N Guichard; [email-masked]
*Objet :* RE: TTL field within the NSH base header

Med,

-Dave

*From:* sfc [mailto:[email-masked] <[email-masked]>] *On Behalf
Of [email-masked]
*Sent:* Friday, April 28, 2017 9:36 AM
*To:* James N Guichard; [email-masked]
*Subject:* Re: [sfc] TTL field within the NSH base header

Hi Jim, all,

o   Packets can be forwarded to SFs even if SHL is decremented to 0 for the
terminating SFF.

o   I don’t think it is a good idea to include “Decrementing by a value of
1 from 0 shall result in a TTL value of 63” because this will lead to a
broken mechanism.

OLD:

TTL: Service plane time-to-live. An SFF MUST decrement the TTL by a value
of 1 for all NSH packets it receives. Decrementing by a value of 1 from 0
shall result in a TTL value of 63. The default for originating an NSH
packet is a TTL value of 63. The decrement SHALL occur before testing for
0. After decrement, if the TTL is 0, the NSH packet MUST NOT be forwarded.

NEW:

SHL (SFF Hop Limit): Indicates the maximum SFF hops for a service chain.
The initial SHL value SHOULD be configurable via the control plane; the
configured initial value can be specific to a chain or all chains. If no
initial value is explicitly provided, the default initial SHL value 63 MUST
be used. Each SFF involved in forwarding an NSH packet MUST decrement SHL
value by 1. The packet MUST NOT be forwarded to a next hop SFF if SHL is
decremented to zero. SFFs that terminate a service chain MUST forward the
packet to attached SFs even if SHL is decremented to 0.

Thank you.

Cheers,

Med

*De :* sfc [mailto:[email-masked] <[email-masked]>] *De la part
de* James N Guichard
*Envoyé :* jeudi 27 avril 2017 20:54
*À :* [email-masked]
*Objet :* [sfc] TTL field within the NSH base header

Dear WG:

Having reviewed all of the email discussion on the mailing list it appears
to the chairs that we have consensus to add a TTL field to the NSH base
header. We would like to propose the following changes:

Section 3.2:

TTL: Service plane time-to-live. An SFF MUST decrement the TTL by a value
of 1 for all NSH packets it receives. Decrementing by a value of 1 from 0
shall result in a TTL value of 63. The default for originating an NSH
packet is a TTL value of 63. The decrement SHALL occur before testing for
0. After decrement, if the TTL is 0, the NSH packet MUST NOT be forwarded.

Section 3.4:

Update figure 4 to reflect the new base header format as per section 3.2
base header.

Section 3.5:

Update figure 5 to reflect the new base header format as per section 3.2
base header.

Section 12.2.1:

   Bits 0-1 - Version

   Bit 2 - OAM (O bit)

   Bits 4-9 - Reserved

   Bits 0-1 - Version

   Bit 2 - OAM (O bit)

   Bit 3 - Reserved

   Bits 16-19 - Reserved

Section 12.2.3:

Update text for this section and table 1 to reflect 4-bit values *not*
8-bit values.

Thanks,

Jim & Joel

---

From: James N Guichard <[email-masked]>
Date: Mon, 1 May 2017 17:38:59 +0000

Okay lots of conversation but let me offer a revised version of Med’s text that hopefully captures most of the discussion (changes highlighted):

SHL (SFF Hop Limit): Indicates the maximum SFF hops for an SFP. The initial SHL value SHOULD be configurable via the control plane; the configured initial value can be specific to one or more SFPs. If no initial value is explicitly provided, the default initial SHL value 63 MUST be used. Each SFF involved in forwarding an NSH packet MUST decrement the SHL value by 1 prior to NSH forwarding lookup. Decrementing by 1 from an incoming value of 0 shall result in a SHL value of 63. The packet MUST NOT be forwarded if SHL is, after decrement, 0 e.g. decrement SHALL occur before testing SHL for 0.

Jim

From: Greg Mirsky [mailto:[email-masked]]
Sent: Monday, May 01, 2017 1:02 PM
To: Dave Dolson <[email-masked]>
Cc: [email-masked]; [email-masked]; James N Guichard <[email-masked]>; Ron Parker <[email-masked]>
Subject: Re: [sfc] TTL field within the NSH base header

"Be liberal what you accept. Be conservative what you send."
I think this sums what we have discussed - accept TTL 0, don't forward TTL 0.

Regards, Greg

On May 1, 2017 8:58 AM, "Dave Dolson" <[email-masked]<mailto:[email-masked]>> wrote:
Ron,
I too would like simple, but your table looks pretty complicated. And I think it adds configuration for an SFF to know whether there are others before it.
My version of simple:
  TTL field of 0 means 64.
  Every SFF decrements TTL each time it forwards the NSH packet. If decrementing from 1 would result in under-flow to 64, discard.

From: Ron Parker [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, May 1, 2017 11:41 AM

TTL=1

TTL=0

First SFF and not Last

Agree that differentiating “forwarding” to attached SF instances vs subsequent SFF’s is logical and intuitive (to me) and I prefer to acknowledge that there is a difference.   But, I was addressing a suggestion to simplify.     In practice, 61 or 62 or 63 decrements of TTL all probably mean the same thing ☺.

   Ron

-Dave

Jim

   Ron

Jim

Re-,

Cheers,
Med

Med,

-Dave

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

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

---

From: Ron Parker <[email-masked]>
Date: Mon, 1 May 2017 17:57:58 +0000

No, I like decrement at only SFF.   But, it does introduce the question of whether behavior should exploit knowledge of position within the chain or not, including the added complexity of carrying this technical debt of the "old" classifier (e.g., should all SFF's blindly accept 0 as legal?).

   Ron

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Monday, May 1, 2017 12:55 PM
To: Ron Parker <[email-masked]>; Dave Dolson <[email-masked]>
Cc: [email-masked]; [email-masked]; James N Guichard <[email-masked]>
Subject: Re: [sfc] TTL field within the NSH base header

The summary I sent to the list, based on what little I could tell of rough consensus, was to only decrement TTL at SFF.  If you want to argue for decrementing at all NSH-aware devices, state your case.

Yours,
Joel

On 5/1/17 12:50 PM, Ron Parker wrote:
>> Agree that I'd opt for precision over simplicity.   Which is what I
>> SFP.    Subsequent comments didn't seem to embrace that way of
>> approach, backward compatibility for classifiers that emit TTL=0 
>> could be addressed by also describing behavior at the first SFF vs. non-first.
>>
>>
>>
>>
>>
>> 	
>>
>> TTL=1
>>
>> 	
>>
>> TTL=0
>>
>> Agree that differentiating "forwarding" to attached SF instances vs 
>> subsequent SFF's is logical and intuitive (to me) and I prefer to
>> A **terminating** SFF may accept a packet with TTL=1.  I.e., where 
>> the NSH header is removed.
>>
>> Otherwise we'd say, "huh, no point in sending a packet if TTL=1. And 
>> huh, if received with TTL=2 then we might as well drop it." Recurse 
>> ad absurdum.
>>
>>
>>
>> Hence, the correct language needs to convey that a device 
>> decrementing TTL (in order to forward NSH) must check if it would result in zero.
>>
>>
>>
>> packet with TTL=1 shall drop the packet.   That doesn't require any
>> 1 means take care of local SF's, only, but then we are back to having
>> default, finessing what happens when receiving 1 doesn't seem 
>> worthwhile to me.
>>
>>
>>
>> there are no service functions left to be forwarded to so the 
>> sentence does not make any sense. If however the SFF is terminating 
>> the service chain and at termination the SHL reaches 0 then it should 
>> still forward the packet (after removal of NSH).
>>
>>
>>
>> Jim
>>
>>
>>
>> I'd like to disambiguate the word "forwarding".   From SFF
>> perspective, there is forwarding to attached SF instances and there 
>> is forwarding to other SFFs.
>>
>>
>>
>> "SFFs that terminate a service chain MUST forward the packet to 
>> attached service functions, even if SHL is decremented to 0"
>>
>>
>>
>>    Ron
>>
>>
>>
>>
>>
>>
>>
>> I don't understand this sentence as if an SFF is terminating a 
>> service chain then it **wont** be forwarding the packets to attached 
>> SFs; Shouldn't this sentence read "SFFs that terminate a service 
>> chain MUST forward the packet even if SHL is decremented to 0" ?
>>
>>
>>
>> Jim
>>
>>
>>
>> deleting a packet after an SFF decrement the SHL to 0, but that 
>> packet is to be passed to SFs that are attached to this SFF. The 
>> packet will be forwarded after stripping the NSH header; no risk for 
>> SFF loops out there. No?
>>
>>
>>
>> Cheers,
>>
>> Med
>>
>>
>>
>> *De :*Dave Dolson [mailto:[email-masked]] *Envoyé :* vendredi 
>> 28 avril 2017 16:29 *À :* BOUCADAIR Mohamed IMT/OLN; James N 
>> Guichard; [email-masked] <mailto:[email-masked]> *Objet :* RE: TTL field 
>> within the NSH base header
>>
>>
>>
>> Med,
>>
>>
>>
>> "SFFs that terminate a service chain MUST forward the packet to 
>> attached SFs even if SHL is decremented to 0."
>>
>> ·        Change "TTL" to "SFF Hop Limit (SHL)" because this field is
>> o   I don't think it is a good idea to include "Decrementing by a
>> value of 1 from 0 shall result in a TTL value of 63" because this 
>> will lead to a broken mechanism.
>>
>>
>>
>> OLD:
>>
>> terminate a service chain MUST forward the packet to attached SFs 
>> even if SHL is decremented to 0.
>>
>>
>>
>> Thank you.
>>
>>
>>
>> Cheers,
>>
>> Med
>>
>>
>>
>> *De :*sfc [mailto:[email-masked]] *De la part de* James N 
>> Guichard *Envoyé :* jeudi 27 avril 2017 20:54 *À :* [email-masked] 
>> <mailto:[email-masked]> *Objet :* [sfc] TTL field within the NSH base 
>> header
>>
>>
>>
>> Dear WG:
>>
>>
>>
>> appears to the chairs that we have consensus to add a TTL field to 
>> the NSH base header. We would like to propose the following changes:
>>
>>
>>
>> Section 3.2:
>>

---

From: Ron Parker <[email-masked]>
Date: Mon, 1 May 2017 17:59:31 +0000

As was pointed out to me, that would limit a “legacy” classifier to SFPs that use exactly 1 SFF.   And, I think that is a really good compromise wrt carrying baggage for those legacy classifiers.

   Ron

Sent: Monday, May 1, 2017 1:02 PM

Regards, Greg

TTL=1

TTL=0

First SFF and not Last

   Ron

-Dave

Jim

   Ron

Jim

Re-,

Cheers,
Med

Med,

-Dave

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 1 May 2017 14:29:16 -0400

On 5/1/2017 1:38 PM, James N Guichard wrote:
> SHL (SFF Hop Limit)

I hate to interrupt the discussion of modular arithmetic with a 
terminology issue, but I'd recommend against this terminology change.  
"TTL" is a pretty well known term with a well known use. Inventing a new 
acronym here can only cause confusion.  I don't think anyone's suggested 
modifying the IP specs to change "TTL" to "IP Hop Limit".

(Once upon a time, there was some thinking that it might take a packet 
more than a second to transit a router, and the original IP TTL 
requirement was to decrement the TTL by at least 1 per hop, but by more 
than 1 if the packet spent more than a second in a given router.  But 
for most of the last 40 years, everyone has known that "TTL" means "hop 
count".)

---

From: Joel Halpern Direct <[email-masked]>
Date: Mon, 1 May 2017 14:57:57 -0400

Speaking persobnally, it seems to me simplest to allow all SFF to accept 
a TTL  SHL of 0 and decrement it by 1 to 63.  It provides simple, 
consistent behavior.  And it seems as robust as anything we have discussed.

Yours,
Joel

---

From: James N Guichard <[email-masked]>
Date: Mon, 1 May 2017 21:31:23 +0000

Hi Eric,

My personal opinion is that I agree with you.

What do others in the WG think?

Jim

From: Eric C Rosen [mailto:[email-masked]]
Sent: Monday, May 01, 2017 2:29 PM
To: James N Guichard <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] TTL field within the NSH base header

SHL (SFF Hop Limit)

I hate to interrupt the discussion of modular arithmetic with a terminology issue, but I'd recommend against this terminology change.  "TTL" is a pretty well known term with a well known use.   Inventing a new acronym here can only cause confusion.  I don't think anyone's suggested modifying the IP specs to change "TTL" to "IP Hop Limit".

(Once upon a time, there was some thinking that it might take a packet more than a second to transit a router, and the original IP TTL requirement was to decrement the TTL by at least 1 per hop, but by more than 1 if the packet spent more than a second in a given router.  But for most of the last 40 years, everyone has known that "TTL" means "hop count".)

---

From: Joe Clarke <[email-masked]>
Date: Mon, 1 May 2017 18:14:54 -0400

On 5/1/17 13:38, James N Guichard wrote:
> Okay lots of conversation but let me offer a revised version of Med’s
> text that hopefully captures most of the discussion (changes highlighted):
> 
>  
> 
> SHL (SFF Hop Limit): Indicates the maximum SFF hops for an *SFP*. The
> initial SHL value SHOULD be configurable via the control plane; the
> configured initial value can be specific to *one or more SFPs*. If no
> decrement *the *SHL value by 1 *prior to NSH forwarding lookup*.
> *Decrementing by 1 from an incoming value of 0 shall result in a SHL
> value of 63. The packet MUST NOT be forwarded if SHL is, after
> decrement, 0 e.g. decrement SHALL occur before testing SHL for 0. *

I think this text is clearer, and I agree (on the other thread) TTL
makes more sense vs. a new piece of terminology.

I still wonder if it's worth explicitly stating that this underrun
methodology is there to support backwards compat?

Joe

> 
>  
> 
> Jim
> 
>  
> 
>  
> 
> *From:*Greg Mirsky [mailto:[email-masked]]
> *Sent:* Monday, May 01, 2017 1:02 PM
> *To:* Dave Dolson <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; James N Guichard
> <[email-masked]>; Ron Parker <[email-masked]>
>     I too would like simple, but your table looks pretty complicated.
>     And I think it adds configuration for an SFF to know whether there
>     are others before it.
> 
>     My version of simple:
> 
>       TTL field of 0 means 64.
> 
>     *From:*Ron Parker [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     describing things.    Also, if there were consensus to supporting
>     that approach, backward compatibility for classifiers that emit
>     TTL=0 could be addressed by also describing behavior at the first
>     SFF vs. non-first.
> 
>      
> 
>                   
> 
>     	
> 
>     TTL=1
> 
>     	
> 
>     TTL=0
> 
>     suggestion to simplify.     In practice, 61 or 62 or 63 decrements
>     of TTL all probably mean the same thing J.
> 
>      
> 
>        Ron
> 
>      
> 
>      
> 
>     huh, if received with TTL=2 then we might as well drop it…” Recurse
>     ad absurdum.
> 
>      
> 
>     distinction of the type of forwarding.    You could argue that
>     perhaps 1 means take care of local SF’s, only, but then we are back
>     to having to make that distinction.    Given that we are starting at
>     63 by default, finessing what happens when receiving 1 doesn’t seem
>     worthwhile to me.
> 
>      
> 
>     the service chain and at termination the SHL reaches 0 then it
>     should still forward the packet (after removal of NSH).
> 
>      
> 
>     Jim
> 
>      
> 
>     I don’t understand this sentence as if an SFF is terminating a
>     SFs; Shouldn’t this sentence read “SFFs that terminate a service
>     chain MUST forward the packet even if SHL is decremented to 0” ?
> 
>      
> 
>     Jim
> 
>      
> 
>     value of 1 from 0 shall result in a TTL value of 63” because this
>     value of 1 for all NSH packets it receives. Decrementing by a value
>     of 1 from 0 shall result in a TTL value of 63. The default for
>     occur before testing for 0. After decrement, if the TTL is 0, the
>     NSH packet MUST NOT be forwarded.
> 
>      
> 
>     NEW:
> 
>     plane; the configured initial value can be specific to a chain or
>     all chains. If no initial value is explicitly provided, the default
>     initial SHL value 63 MUST be used. Each SFF involved in forwarding
>     an NSH packet MUST decrement SHL value by 1. The packet MUST NOT be
>     value of 1 for all NSH packets it receives. Decrementing by a value
>     of 1 from 0 shall result in a TTL value of 63. The default for
>     occur before testing for 0. After decrement, if the TTL is 0, the
>     NSH packet MUST NOT be forwarded.
> 
>      
> 
>     Section 3.4:
>

---

From: <[email-masked]>
Date: Tue, 2 May 2017 05:39:13 +0000

Hi Jim,

Yes, your wording is better: "SFFs that terminate a service chain MUST forward the packet even if SHL is decremented to 0"

Thank you.

Cheers,
Med

De : James N Guichard [mailto:[email-masked]]
Envoyé : lundi 1 mai 2017 16:22
À : BOUCADAIR Mohamed IMT/OLN; Dave Dolson; [email-masked]
Objet : RE: TTL field within the NSH base header

Jim

Re-,

Cheers,
Med

Med,

-Dave

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 1 May 2017 22:52:43 -0700

Hi Med, et. al,
I'm somewhat lost at the need to discuss egress SFF as special case in
regard to TTL handling. I believe that we've agreed that:

   - receiving TTL==0 is valid;
   - TTL is to be decremented by 1 before being forwarded to the next SFF.
   Special case - TTL of value 0. This case is handled as TTL equals 64 and
   thus packet is expected to be transmitted with TTL of 63;
   - egress SFF that terminates SFC, as I understand, removes NSH and the
   TTL altogether. SFC TTL does not play any part after SFC has been
   terminated.

What have I missed? Appreciate your comments.

Regards,
Greg

On Mon, May 1, 2017 at 10:39 PM, <[email-masked]> wrote:

> Hi Jim,
>
>
>
> Yes, your wording is better: “SFFs that terminate a service chain MUST
> forward the packet even if SHL is decremented to 0”
>
>
>
> Thank you.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* James N Guichard [mailto:[email-masked]]
> *Envoyé :* lundi 1 mai 2017 16:22
> *À :* BOUCADAIR Mohamed IMT/OLN; Dave Dolson; [email-masked]
>
> *From:* sfc [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of [email-masked]
> of 1 from 0 shall result in a TTL value of 63” because this will lead to a
> broken mechanism.
>
>
>
> OLD:
>
> *De :* sfc [mailto:[email-masked] <[email-masked]>] *De la
> part de* James N Guichard

---

From: <[email-masked]>
Date: Tue, 2 May 2017 05:55:46 +0000

Hi Eric,

Please see inline.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Eric C Rosen
Envoyé : lundi 1 mai 2017 20:29
À : James N Guichard
Cc : [email-masked]
Objet : Re: [sfc] TTL field within the NSH base header

SHL (SFF Hop Limit)

I hate to interrupt the discussion of modular arithmetic with a terminology issue, but I'd recommend against this terminology change.  "TTL" is a pretty well known term with a well known use.
[Med] I'm sure you know that TTL was also expected to be decremented each second.
   Inventing a new acronym here can only cause confusion.  I don't think anyone's suggested modifying the IP specs to change "TTL" to "IP Hop Limit".
[Med] This was already happened when specifying a new version of IP. There is no TTL in IPv6, but a Hop Limit.

---

From: <[email-masked]>
Date: Tue, 2 May 2017 06:17:06 +0000

Hi Jim,

Thank you for this updated proposal. This is much more better.

Giving the clarification discussed with Joel (i.e., do not reset reserved bits by intermediate devices), I wonder whether it makes sense to add a sentence saying that “an incoming value of 0” is only acceptable from a classifier.

Cheers,
Med

De : James N Guichard [mailto:[email-masked]]
Envoyé : lundi 1 mai 2017 19:39
À : Greg Mirsky; Dave Dolson
Cc : [email-masked]; BOUCADAIR Mohamed IMT/OLN; Ron Parker
Objet : RE: [sfc] TTL field within the NSH base header

Jim

From: Greg Mirsky [mailto:[email-masked]]
Sent: Monday, May 01, 2017 1:02 PM
To: Dave Dolson <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; James N Guichard <[email-masked]<mailto:[email-masked]>>; Ron Parker <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] TTL field within the NSH base header

Regards, Greg

TTL=1

TTL=0

First SFF and not Last

   Ron

-Dave

Jim

   Ron

Jim

Re-,

Cheers,
Med

Med,

-Dave

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: <[email-masked]>
Date: Tue, 2 May 2017 06:26:28 +0000

Hi Greg,

Please see inline.

Cheers,
Med

De : Greg Mirsky [mailto:[email-masked]]
Envoyé : mardi 2 mai 2017 07:53
À : BOUCADAIR Mohamed IMT/OLN
Cc : James N Guichard; Dave Dolson; [email-masked]
Objet : Re: [sfc] TTL field within the NSH base header

Hi Med, et. al,
I'm somewhat lost at the need to discuss egress SFF as special case in regard to TTL handling. I believe that we've agreed that:

  *   receiving TTL==0 is valid;
[Med] IMHO, this is only valid when received from a classifier.

  *   TTL is to be decremented by 1 before being forwarded to the next SFF.
[Med] Yes.
Special case - TTL of value 0. This case is handled as TTL equals 64 and thus packet is expected to be transmitted with TTL of 63;
[Med] Yes.

  *   egress SFF that terminates SFC, as I understand, removes NSH and the TTL altogether. SFC TTL does not play any part after SFC has been terminated.
[Med] The case I was concerned with is an NSH packet received with SHL=1. I wanted that packet is be presented to SFs attached to that SFF (and, once those SFs are consumed, strip nsh + forward to next-hop), not deleting it.
What have I missed? Appreciate your comments.

Regards,
Greg

On Mon, May 1, 2017 at 10:39 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jim,

Yes, your wording is better: “SFFs that terminate a service chain MUST forward the packet even if SHL is decremented to 0”

Thank you.

Cheers,
Med

De : James N Guichard [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : lundi 1 mai 2017 16:22
À : BOUCADAIR Mohamed IMT/OLN; Dave Dolson; [email-masked]<mailto:[email-masked]>

Jim

Re-,

Cheers,
Med

Med,

-Dave

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: Dave Dolson <[email-masked]>
Date: Tue, 2 May 2017 10:18:43 +0000

Med,
For the backwards compatibility case, we also support ‎SFFs that do not decrement TTL/Hop Limit. Saying a value of zero can only come from classifiers defeats that, as well as adding unnecessary complexity.

David Dolson
‎
From: [email-masked]
Sent: Tuesday, May 2, 2017 2:17 AM
To: James N Guichard; Greg Mirsky; Dave Dolson
Cc: [email-masked]; Ron Parker
Subject: RE: [sfc] TTL field within the NSH base header

Hi Jim,

Cheers,
Med

Jim

Regards, Greg

TTL=1

TTL=0

First SFF and not Last

   Ron

-Dave

Jim

   Ron

Jim

Re-,

Cheers,
Med

Med,

-Dave

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: <[email-masked]>
Date: Tue, 2 May 2017 11:57:31 +0000

Hi Dave,

SFFs that do not support SHL will preserve these bits as received. In other words, these SFFs won’t reset these bits to zeros.

Cheers,
Med

De : Dave Dolson [mailto:[email-masked]]
Envoyé : mardi 2 mai 2017 12:19
À : BOUCADAIR Mohamed IMT/OLN; James N Guichard; Greg Mirsky
Cc : [email-masked]; Ron Parker
Objet : Re: [sfc] TTL field within the NSH base header

Med,

David Dolson
‎
From: [email-masked]<mailto:[email-masked]>
Sent: Tuesday, May 2, 2017 2:17 AM
To: James N Guichard; Greg Mirsky; Dave Dolson
Cc: [email-masked]<mailto:[email-masked]>; Ron Parker
Subject: RE: [sfc] TTL field within the NSH base header

Hi Jim,

Cheers,
Med

Cc : [email-masked]<mailto:[email-masked]>; BOUCADAIR Mohamed IMT/OLN; Ron Parker

Jim

Regards, Greg

TTL=1

TTL=0

First SFF and not Last

   Ron

-Dave

Jim

   Ron

Jim

Re-,

Cheers,
Med

Med,

-Dave

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: Dave Dolson <[email-masked]>
Date: Tue, 2 May 2017 12:41:23 +0000

Med,
I agree.
Consider the case when a “new” SFF is added to an existing system:
For all NSH packets, the Hop Limit/TTL field is zero, not just those from the classifier.

I object to this statement of yours:
> add a sentence saying that “an incoming value of 0” is only acceptable from a classifier.

As I see it, an incoming value of 0 is acceptable from any source.

-Dave

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, May 2, 2017 7:58 AM
To: Dave Dolson; James N Guichard; Greg Mirsky
Cc: [email-masked]; Ron Parker
Subject: RE: [sfc] TTL field within the NSH base header

Hi Dave,

Cheers,
Med

Cc : [email-masked]<mailto:[email-masked]>; Ron Parker

Med,

David Dolson
‎

Hi Jim,

Cheers,
Med

Jim

Regards, Greg

TTL=1

TTL=0

First SFF and not Last

   Ron

-Dave

Jim

   Ron

Jim

Re-,

Cheers,
Med

Med,

-Dave

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: <[email-masked]>
Date: Tue, 2 May 2017 12:52:30 +0000

Re-,

You have a point. Acked.

My concern was how to avoid misbehaving SFFs that would forward packets with SHL==0 to a next-hop SFF even if that SFF parses the SHL field.

What about having a configuration knob to indicate the behavior to follow when receiving SHL=0? A domain that involves classifiers/SFFs that understand SHL must not forward or accept receiving packets with SHL=0.

Cheers,
Med

Envoyé : mardi 2 mai 2017 14:41

Med,
I agree.

-Dave

Hi Dave,

Cheers,
Med

Med,

David Dolson
‎

Hi Jim,

Cheers,
Med

Jim

Regards, Greg

TTL=1

TTL=0

First SFF and not Last

   Ron

-Dave

Jim

   Ron

Jim

Re-,

Cheers,
Med

Med,

-Dave

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: James N Guichard <[email-masked]>
Date: Tue, 2 May 2017 13:18:42 +0000

I think the text that I sent out yesterday covers this without adding additional complexity of  yet another configuration knob. As Dave pointed out it is possible to receive TTL 0 from a non-classifier; the current text allows for this and the TTL is set to 63 at the first compliant device.

Jim

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, May 02, 2017 8:53 AM
To: Dave Dolson <[email-masked]>; James N Guichard <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: [email-masked]; Ron Parker <[email-masked]>
Subject: RE: [sfc] TTL field within the NSH base header

Re-,

You have a point. Acked.

Cheers,
Med

Med,
I agree.

-Dave

Hi Dave,

Cheers,
Med

Med,

David Dolson
‎

Hi Jim,

Cheers,
Med

Jim

Regards, Greg

TTL=1

TTL=0

First SFF and not Last

   Ron

-Dave

Jim

   Ron

Jim

Re-,

Cheers,
Med

Med,

-Dave

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: Dave Dolson <[email-masked]>
Date: Tue, 2 May 2017 13:19:45 +0000

I still think the conceptual difficulty goes away if we say that the 6 bits 000000 represents the value 64.

Sent: Tuesday, May 2, 2017 8:53 AM

Re-,

You have a point. Acked.

Cheers,
Med

Med,
I agree.

-Dave

Hi Dave,

Cheers,
Med

Med,

David Dolson
‎

Hi Jim,

Cheers,
Med

Jim

Regards, Greg

TTL=1

TTL=0

First SFF and not Last

   Ron

-Dave

Jim

   Ron

Jim

Re-,

Cheers,
Med

Med,

-Dave

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: Ron Parker <[email-masked]>
Date: Tue, 2 May 2017 13:31:34 +0000

I’m ducking for cover, but…    If we really want to keep backward compatibility, might this inclusion of TTL/SHL be Version=1 of the NSH base header?

     Ron

From: Dave Dolson [mailto:[email-masked]]
Sent: Tuesday, May 2, 2017 9:20 AM
To: [email-masked]; James N Guichard <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: [email-masked]; Ron Parker <[email-masked]>
Subject: RE: [sfc] TTL field within the NSH base header

Re-,

You have a point. Acked.

Cheers,
Med

Med,
I agree.

-Dave

Hi Dave,

Cheers,
Med

Med,

David Dolson
‎

Hi Jim,

Cheers,
Med

Jim

Regards, Greg

TTL=1

TTL=0

First SFF and not Last

   Ron

-Dave

Jim

   Ron

Jim

Re-,

Cheers,
Med

Med,

-Dave

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: <[email-masked]>
Date: Tue, 2 May 2017 13:38:33 +0000

Re-,

I don’t get your point, Dave.

My concern is how to detect a misbehaving node vs a node that is not supporting SHL.

If all nodes in a domain support SHL, then packets with SHL==0 MUST NOT be received by any SFF of that domain. Do you agree with that?

Cheers,
Med

Envoyé : mardi 2 mai 2017 15:20

Re-,

You have a point. Acked.

Cheers,
Med

Med,
I agree.

-Dave

Hi Dave,

Cheers,
Med

Med,

David Dolson
‎

Hi Jim,

Cheers,
Med

Jim

Regards, Greg

TTL=1

TTL=0

First SFF and not Last

   Ron

-Dave

Jim

   Ron

Jim

Re-,

Cheers,
Med

Med,

-Dave

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 2 May 2017 10:07:27 -0400

Speaking personally in the following:
If we have an SFF that manages to decrement the TTL field, but then 
fails to test it against 0, yes, the loop will not break there.  Unless 
the loop is exactly 64 so that the detection comes back to the very 
oddly broken device, it will still get broken later.  Which is all we 
really ask.

Ther eis a limit to how many mis-behaviors we can allow for.  If a 
Router were to reset the IP TTL field to max, that would destroy loop 
prevention too.  So what?

I would like to keep this very simple, and avoid knobs that we do not 
need.  Allowing 0 incoming everywhere, and decrementing it to 63, seems 
simple and consistent.  It avoids needing configuration.  It allows the 
front of an SFP to be existing devices withotu needing any configuration.
And the overall behavior allows existing devices at other places in the 
path.

Yours,
Joel

On 5/2/17 8:52 AM, [email-masked] wrote:
> Re-,
>
>
>
> You have a point. Acked.
>
>
>
> My concern was how to avoid misbehaving SFFs that would forward packets
> with SHL==0 to a next-hop SFF even if that SFF parses the SHL field.
>
>
>
> What about having a configuration knob to indicate the behavior to
> follow when receiving SHL=0? A domain that involves classifiers/SFFs
> that understand SHL must not forward or accept receiving packets with SHL=0.
>
>
>
> Cheers,
>
> Med
>
>
>
> *Envoyé :* mardi 2 mai 2017 14:41
> *À :* BOUCADAIR Mohamed IMT/OLN; James N Guichard; Greg Mirsky
> *Cc :* [email-masked]; Ron Parker
> *Objet :* RE: [sfc] TTL field within the NSH base header
>
>
>
> Med,
>
> I agree.
>
> *Sent:* Tuesday, May 2, 2017 7:58 AM
> *To:* Dave Dolson; James N Guichard; Greg Mirsky
> *Cc:* [email-masked] <mailto:[email-masked]>; Ron Parker
> *Subject:* RE: [sfc] TTL field within the NSH base header
>
>
>
> Hi Dave,
>
>
>
> SFFs that do not support SHL will preserve these bits as received. In
> other words, these SFFs won’t reset these bits to zeros.
>
>
>
> Cheers,
>
> Med
>
>
>
> *Envoyé :* mardi 2 mai 2017 12:19
> *À :* BOUCADAIR Mohamed IMT/OLN; James N Guichard; Greg Mirsky
> *Cc :* [email-masked] <mailto:[email-masked]>; Ron Parker
> *Objet :* Re: [sfc] TTL field within the NSH base header
>
>
>
> Med,
>
> For the backwards compatibility case, we also support ‎SFFs that do not
> decrement TTL/Hop Limit. Saying a value of zero can only come from
> classifiers defeats that, as well as adding unnecessary complexity.
>
>
>
> David Dolson
> ‎
>
> *From: [email-masked] <mailto:[email-masked]>
>
> *Sent: *Tuesday, May 2, 2017 2:17 AM
>
> *To: *James N Guichard; Greg Mirsky; Dave Dolson
>
> *Cc: [email-masked] <mailto:[email-masked]>; Ron Parker
>
> *Subject: *RE: [sfc] TTL field within the NSH base header
>
>
>
> Hi Jim,
>
>
>
> Giving the clarification discussed with Joel (i.e., do not reset
> reserved bits by intermediate devices), I wonder whether it makes sense
> to add a sentence saying that “an incoming value of 0” is only
> acceptable from a classifier.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :*James N Guichard [mailto:[email-masked]]
> *Envoyé :* lundi 1 mai 2017 19:39
> *À :* Greg Mirsky; Dave Dolson
> *Cc :* [email-masked] <mailto:[email-masked]>; BOUCADAIR Mohamed IMT/OLN;
> Ron Parker
> *Objet :* RE: [sfc] TTL field within the NSH base header
>
>
>
> *To:* Dave Dolson <[email-masked] <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; James N Guichard
> <[email-masked] <mailto:[email-masked]>>; Ron
> Parker <[email-masked]
> <mailto:[email-masked]>>
>     *From:*Dave Dolson [mailto:[email-masked]]
>     *From:*Dave Dolson [mailto:[email-masked]]
>     *From:*James N Guichard [mailto:[email-masked]]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 2 May 2017 10:11:37 -0400

Personally, I would not say "MUST NOT".  It is a statement of effect 
that if all devices in the environment support the RFC, with TTL (SHL) 
defined as proposed, then

no NSH processing device will ever receive a packet with the TTL (SHL) 
field set to 0.

That is a statement of fact.  As I see it, it is not an interoperability 
requirement.  If such a packet is received, the right thing will happen.

Yours,
Joel

On 5/2/17 9:38 AM, [email-masked] wrote:
> If all nodes in a domain support SHL, then packets with SHL==0 MUST NOT
> be received by any SFF of that domain. Do you agree with that?
>
>
>
> Cheers,
>
> Med
>
>
>
> *Envoyé :* mardi 2 mai 2017 15:20
> *Sent:* Tuesday, May 2, 2017 8:53 AM

---

From: Dave Dolson <[email-masked]>
Date: Tue, 2 May 2017 14:34:16 +0000

Misbehaving? I hope we don’t have to account for that.
I expect we are doing this to find packet loops, not find misbehaving nodes.

E.g., regarding TTL in routing IP packets, we don’t aim to find routers that decrement TTL incorrectly; we aim to find routing loops.

In NSH, I think there are two valid behaviors: either decrement the TTL (and check) or pass it unmodified.

-Dave

Sent: Tuesday, May 2, 2017 9:39 AM

Re-,

Cheers,
Med

Re-,

You have a point. Acked.

Cheers,
Med

Med,
I agree.

-Dave

Hi Dave,

Cheers,
Med

Med,

David Dolson
‎

Hi Jim,

Cheers,
Med

Jim

Regards, Greg

TTL=1

TTL=0

First SFF and not Last

   Ron

-Dave

Jim

   Ron

Jim

Re-,

Cheers,
Med

Med,

-Dave

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: Dave Dolson <[email-masked]>
Date: Tue, 2 May 2017 14:37:26 +0000

I agree with Joel: no configuration knobs; don't try to account for misbehaviors of forwarders.

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Tuesday, May 2, 2017 10:07 AM
To: [email-masked]; Dave Dolson; James N Guichard; Greg Mirsky
Cc: Ron Parker; [email-masked]
Subject: Re: [sfc] TTL field within the NSH base header

Speaking personally in the following:
If we have an SFF that manages to decrement the TTL field, but then fails to test it against 0, yes, the loop will not break there.  Unless the loop is exactly 64 so that the detection comes back to the very oddly broken device, it will still get broken later.  Which is all we really ask.

Ther eis a limit to how many mis-behaviors we can allow for.  If a Router were to reset the IP TTL field to max, that would destroy loop prevention too.  So what?

I would like to keep this very simple, and avoid knobs that we do not need.  Allowing 0 incoming everywhere, and decrementing it to 63, seems simple and consistent.  It avoids needing configuration.  It allows the front of an SFP to be existing devices withotu needing any configuration.
And the overall behavior allows existing devices at other places in the path.

Yours,
Joel

On 5/2/17 8:52 AM, [email-masked] wrote:
> Re-,
>
>
>
> You have a point. Acked.
>
>
>
> My concern was how to avoid misbehaving SFFs that would forward 
> packets with SHL==0 to a next-hop SFF even if that SFF parses the SHL field.
>
>
>
> *De :*Dave Dolson [mailto:[email-masked]] *Envoyé :* mardi 2 mai 
> 2017 14:41 *À :* BOUCADAIR Mohamed IMT/OLN; James N Guichard; Greg 
> Mirsky *Cc :* [email-masked]; Ron Parker *Objet :* RE: [sfc] TTL field 
> *De :*Dave Dolson [mailto:[email-masked]] *Envoyé :* mardi 2 mai 
> 2017 12:19 *À :* BOUCADAIR Mohamed IMT/OLN; James N Guichard; Greg 
> Mirsky *Cc :* [email-masked] <mailto:[email-masked]>; Ron Parker *Objet :* 
> Re: [sfc] TTL field within the NSH base header
>
>
>
> Med,
>
> For the backwards compatibility case, we also support ‎SFFs that do 
> not decrement TTL/Hop Limit. Saying a value of zero can only come from 
> reserved bits by intermediate devices), I wonder whether it makes 
> sense to add a sentence saying that “an incoming value of 0” is only 
> Ron Parker *Objet :* RE: [sfc] TTL field within the NSH base header
>
>
>
> Ron Parker <[email-masked]

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 2 May 2017 07:41:52 -0700

+1

Regards,
Greg

On Tue, May 2, 2017 at 7:37 AM, Dave Dolson <[email-masked]> wrote:

> If we have an SFF that manages to decrement the TTL field, but then fails
> to test it against 0, yes, the loop will not break there.  Unless the loop
> is exactly 64 so that the detection comes back to the very oddly broken
> device, it will still get broken later.  Which is all we really ask.
>
> Ther eis a limit to how many mis-behaviors we can allow for.  If a Router
> were to reset the IP TTL field to max, that would destroy loop prevention
> too.  So what?
>
> Guichard

---

From: James N Guichard <[email-masked]>
Date: Thu, 4 May 2017 14:53:29 +0000

Dear WG:

Here is the latest text that I have captured from the email thread. Please review carefully and indicate support for these changes:

Section 3.2:

TTL: Indicates the maximum SFF hops for an SFP. The initial TTL value SHOULD be configurable via the control plane; the configured initial value can be specific to one or more SFPs. If no initial value is explicitly provided, the default initial TTL value 63 MUST be used. Each SFF involved in forwarding an NSH packet MUST decrement the TTL value by 1 prior to NSH forwarding lookup. Decrementing by 1 from an incoming value of 0 shall result in a TTL value of 63. The packet MUST NOT be forwarded if TTL is, after decrement, 0 e.g. decrement SHALL occur before testing TTL for 0.

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   There are five reserved bits in the NSH Base Header. New bits
   are assigned via Standards Action [RFC5226].

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:
Current text has the MD-type as 8-bit values. Update text for this section and table 1 to reflect 4-bit values *not* 8-bit values.

Thanks!

Jim

From: sfc [mailto:[email-masked]] On Behalf Of James N Guichard
Sent: Thursday, April 27, 2017 2:54 PM
To: [email-masked]
Subject: [sfc] TTL field within the NSH base header

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: <[email-masked]>
Date: Fri, 5 May 2017 06:00:57 +0000

Hi Jim,

Please note that the proposed wording includes a normative language in an example "e.g. decrement SHALL occur before testing TTL for 0". This is odd in an example. I would delete that example.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de James N Guichard
Envoyé : jeudi 4 mai 2017 16:53
À : James N Guichard; [email-masked]
Objet : Re: [sfc] TTL field within the NSH base header

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks!

Jim

From: sfc [mailto:[email-masked]] On Behalf Of James N Guichard
Sent: Thursday, April 27, 2017 2:54 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] TTL field within the NSH base header

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel