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

[Greg Mirsky <[e-mail]>]

+1

Regards,
Greg

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

> I agree with Joel: no configuration knobs; don't try to account for
> misbehaviors of forwarders.
>
> -----Original Message-----
> From: Joel M. Halpern [mailto:[e-mail]]
> Sent: Tuesday, May 2, 2017 10:07 AM
> To: [e-mail]; Dave Dolson; James N Guichard; Greg
> Mirsky
> Cc: Ron Parker; [e-mail]
> 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, [e-mail] 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
> >
> >
> >
> > *De :*Dave Dolson [mailto:[e-mail]] *Envoyé :* mardi 2 mai
> > 2017 14:41 *À :* BOUCADAIR Mohamed IMT/OLN; James N Guichard; Greg
> > Mirsky *Cc :* [e-mail]; Ron Parker *Objet :* RE: [sfc] TTL field
> > within the NSH base header
> >
> >
> >
> > 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:*[e-mail]
> > <mailto:[e-mail]>
> > [mailto:[e-mail]]
> > *Sent:* Tuesday, May 2, 2017 7:58 AM
> > *To:* Dave Dolson; James N Guichard; Greg Mirsky
> > *Cc:* [e-mail] <mailto:[e-mail]>; 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
> >
> >
> >
> > *De :*Dave Dolson [mailto:[e-mail]] *Envoyé :* mardi 2 mai
> > 2017 12:19 *À :* BOUCADAIR Mohamed IMT/OLN; James N Guichard; Greg
> > Mirsky *Cc :* [e-mail] <mailto:[e-mail]>; 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: *[e-mail]
> > <mailto:[e-mail]>
> >
> > *Sent: *Tuesday, May 2, 2017 2:17 AM
> >
> > *To: *James N Guichard; Greg Mirsky; Dave Dolson
> >
> > *Cc: *[e-mail] <mailto:[e-mail]>; Ron Parker
> >
> > *Subject: *RE: [sfc] TTL field within the NSH base header
> >
> >
> >
> > 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:[e-mail]]
> > *Envoyé :* lundi 1 mai 2017 19:39
> > *À :* Greg Mirsky; Dave Dolson
> > *Cc :* [e-mail] <mailto:[e-mail]>; BOUCADAIR Mohamed IMT/OLN;
> > Ron Parker *Objet :* RE: [sfc] TTL field within the NSH base header
> >
> >
> >
> > 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:[e-mail]]
> > *Sent:* Monday, May 01, 2017 1:02 PM
> > *To:* Dave Dolson <[e-mail] <mailto:[e-mail]>>
> > *Cc:* [e-mail] <mailto:[e-mail]>; [e-mail]
> > <mailto:[e-mail]>; James N Guichard
> > <[e-mail] <mailto:[e-mail]>>;
> > Ron Parker <[e-mail]
> > <mailto:[e-mail]>>
> > *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" <[e-mail]
> > <mailto:[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]
> >     <mailto:[e-mail]>]
> >     *Sent:* Monday, May 1, 2017 11:41 AM
> >
> >
> >     *To:* Dave Dolson; James N Guichard; [e-mail]
> >     <mailto:[e-mail]>; [e-mail]
> >     <mailto:[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]]
> >     *Sent:* Monday, May 1, 2017 11:25 AM
> >     *To:* Ron Parker <[e-mail]
> >     <mailto:[e-mail]>>; James N Guichard
> >     <[e-mail] <mailto:[e-mail]>>;
> >     [e-mail] <mailto:[e-mail]>;
> >     [e-mail] <mailto:[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]]
> >     *Sent:* Monday, May 1, 2017 11:14 AM
> >     *To:* Dave Dolson; James N Guichard; [e-mail]
> >     <mailto:[e-mail]>; [e-mail]
> >     <mailto:[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]]
> >     *Sent:* Monday, May 1, 2017 11:11 AM
> >     *To:* Ron Parker <[e-mail]
> >     <mailto:[e-mail]>>; James N Guichard
> >     <[e-mail] <mailto:[e-mail]>>;
> >     [e-mail] <mailto:[e-mail]>;
> >     [e-mail] <mailto:[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]]
> >     *Sent:* Monday, May 1, 2017 10:50 AM
> >     *To:* James N Guichard; [e-mail]
> >     <mailto:[e-mail]>; Dave Dolson; [e-mail]
> >     <mailto:[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]]
> >     *Sent:* Monday, May 1, 2017 10:45 AM
> >     *To:* Ron Parker <[e-mail]
> >     <mailto:[e-mail]>>;
> >     [e-mail] <mailto:[e-mail]>;
> >     Dave Dolson <[e-mail] <mailto:[e-mail]>>;
> >     [e-mail] <mailto:[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]]
> >     *Sent:* Monday, May 01, 2017 10:28 AM
> >     *To:* James N Guichard <[e-mail]
> >     <mailto:[e-mail]>>; [e-mail]
> >     <mailto:[e-mail]>; Dave Dolson
> >     <[e-mail] <mailto:[e-mail]>>; [e-mail]
> >     <mailto:[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]] *On Behalf Of *James N
> Guichard
> >     *Sent:* Monday, May 1, 2017 10:22 AM
> >     *To:* [e-mail]
> >     <mailto:[e-mail]>; Dave Dolson
> >     <[e-mail] <mailto:[e-mail]>>; [e-mail]
> >     <mailto:[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]>
> >     [mailto:[e-mail]]
> >     *Sent:* Friday, April 28, 2017 10:38 AM
> >     *To:* Dave Dolson <[e-mail]
> >     <mailto:[e-mail]>>; James N Guichard
> >     <[e-mail] <mailto:[e-mail]>>;
> >     [e-mail] <mailto:[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]]
> >     *Envoyé :* vendredi 28 avril 2017 16:29
> >     *À :* BOUCADAIR Mohamed IMT/OLN; James N Guichard; [e-mail]
> >     <mailto:[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]] *On Behalf Of
> >     *[e-mail] <mailto:[e-mail]>
> >     *Sent:* Friday, April 28, 2017 9:36 AM
> >     *To:* James N Guichard; [e-mail] <mailto:[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]] *De la part de* James N
> Guichard
> >     *Envoyé :* jeudi 27 avril 2017 20:54
> >     *À :* [e-mail] <mailto:[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] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/sfc
> >
> >
> >
> >
> >
> > _______________________________________________
> > sfc mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sfc
> >
>