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

[Greg Mirsky <[e-mail]>]

"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" <[e-mail]> 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:[e-mail]]
*Sent:* Monday, May 1, 2017 11:41 AM

*To:* Dave Dolson; James N Guichard; [e-mail];
[e-mail]
*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

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:[e-mail] <[e-mail]>]
*Sent:* Monday, May 1, 2017 11:25 AM
*To:* Ron Parker <[e-mail]>; James N Guichard <
[e-mail]>; [e-mail]; [e-mail]
*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.

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:[e-mail]
<[e-mail]>]
*Sent:* Monday, May 1, 2017 11:14 AM
*To:* Dave Dolson; James N Guichard; [e-mail];
[e-mail]
*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:[e-mail] <[e-mail]>]
*Sent:* Monday, May 1, 2017 11:11 AM
*To:* Ron Parker <[e-mail]>; James N Guichard <
[e-mail]>; [e-mail]; [e-mail]
*Subject:* RE: TTL field within the NSH base header



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:[e-mail]
<[e-mail]>]
*Sent:* Monday, May 1, 2017 10:50 AM
*To:* James N Guichard; [e-mail]; Dave Dolson;
[e-mail]
*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:[e-mail]
<[e-mail]>]
*Sent:* Monday, May 1, 2017 10:45 AM
*To:* Ron Parker <[e-mail]>;
[e-mail]; Dave Dolson <[e-mail]>;
[e-mail]
*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:[e-mail]
<[e-mail]>]
*Sent:* Monday, May 01, 2017 10:28 AM
*To:* James N Guichard <[e-mail]>;
[e-mail]; Dave Dolson <[e-mail]>;
[e-mail]
*Subject:* RE: 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:[e-mail] <[e-mail]>] *On Behalf
Of *James N Guichard
*Sent:* Monday, May 1, 2017 10:22 AM
*To:* [e-mail]; Dave Dolson <[e-mail]>;
[e-mail]
*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:* [e-mail] [mailto:[e-mail]
<[e-mail]>]
*Sent:* Friday, April 28, 2017 10:38 AM
*To:* Dave Dolson <[e-mail]>; James N Guichard <
[e-mail]>; [e-mail]
*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:[e-mail] <[e-mail]>]
*Envoyé :* vendredi 28 avril 2017 16:29
*À :* BOUCADAIR Mohamed IMT/OLN; James N Guichard; [e-mail]
*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:[e-mail] <[e-mail]>] *On Behalf
Of *[e-mail]
*Sent:* Friday, April 28, 2017 9:36 AM
*To:* James N Guichard; [e-mail]
*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:[e-mail] <[e-mail]>] *De la part
de* James N Guichard
*Envoyé :* jeudi 27 avril 2017 20:54
*À :* [e-mail]
*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











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