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

[<[e-mail]>]

Hi Joel, 

Works for me. Thanks.

Cheers,
Med

> -----Message d'origine-----
> De : Joel M. Halpern [mailto:[e-mail]]
> Envoyé : vendredi 28 avril 2017 17:17
> À : BOUCADAIR Mohamed IMT/OLN; Dave Dolson; Ron Parker; Joe Clarke; James
> N Guichard; [e-mail]
> Objet : Re: [sfc] TTL field within the NSH base header
> 
> One of the minor clarifications for the document, not related directly
> to TTL, that I gathered from the list discussion was that some people
> were understanding the 0 on transmission requirement the way you say.
> 
> That was never the intent.  That would have made the behavior
> counter-productive for forward compatibility.
> So we will direct the authors to clarify that the MBZ is on origination,
> and that other devices must preserve the reserved bits unmodified.
> (When the bits have meaning, and the meaning is understood, then the
> intermediate behavior will depend upon the specific bit obviously.)
> 
> Yours,
> Joel
> 
> On 4/28/17 10:33 AM, [e-mail] wrote:
> > Re-,
> >
> >
> >
> > The current spec says :
> >
> >
> >
> >    All other flag fields are reserved for future use.  Reserved bits
> >
> >    MUST be set to zero when sent and MUST be ignored upon receipt.
> >
> >
> >
> > Which means that these bits are zeroed, not forwarded as received.
> >
> >
> >
> > Changing that behavior would avoid that the SFF hop limit bits are
> > zeroed by an non-compatible SFF, but still doing so would lead to
> > processing a hop limit field that is not reflecting the exact SFF hops
> > (SFF loops will be still possible, then). Is it worth to enable the
> > feature in such SFC domain given the unreliability of the mechanism?
> > Wouldn’t be simple to require to enable it only if all SFFs/Classifier
> > if a domain comply with it?
> >
> >
> >
> > Cheers,
> >
> > Med
> >
> >
> >
> > *De :*Dave Dolson [mailto:[e-mail]]
> > *Envoyé :* vendredi 28 avril 2017 16:23
> > *À :* BOUCADAIR Mohamed IMT/OLN; Ron Parker; jmh.direct; Joel M.
> > Halpern; Joe Clarke; James N Guichard; [e-mail]
> > *Objet :* RE: [sfc] TTL field within the NSH base header
> >
> >
> >
> > This is the debate about whether the flags must be set to zero when the
> > packet is created or each time it is sent from a device.
> >
> > I think most of us hoped that SFFs and SFs only “forward” packets, not
> > “write” packets.
> >
> >
> >
> > Should we change the language to indicate the difference between a
> > classifier creating a packet and zeroing the reserved flags vs. SFFs and
> > SFs forwarding whatever is received?
> >
> >
> >
> >
> >
> > *From:*[e-mail]
> > <mailto:[e-mail]>
> [mailto:[e-mail]]
> > *Sent:* Friday, April 28, 2017 10:17 AM
> > *To:* Ron Parker; Dave Dolson; jmh.direct; Joel M. Halpern; Joe Clarke;
> > James N Guichard; [e-mail] <mailto:[e-mail]>
> > *Subject:* RE: [sfc] TTL field within the NSH base header
> >
> >
> >
> > Ron, all,
> >
> >
> >
> > About the decrement of 0 to 63, isn’t that behavior broken anyway given
> > that a non-compliant SFF in the path will set these bits to zero because
> > reserved bits “MUST be set to zero when sent”?
> >
> >
> >
> > Cheers,
> >
> > Med
> >
> >
> >
> > *De :*sfc [mailto:[e-mail]] *De la part de* Ron Parker
> > *Envoyé :* vendredi 28 avril 2017 16:07
> > *À :* Dave Dolson; jmh.direct; Joel M. Halpern; Joe Clarke; James N
> > Guichard; [e-mail] <mailto:[e-mail]>
> > *Objet :* Re: [sfc] TTL field within the NSH base header
> >
> >
> >
> > Thanks all for the discussion, and I now appreciate the backward
> > compatibility aspect.   But, if we take a more direct approach to
> > describing the behavior, we simply need to state what happens when SFF
> > receives NSH with TTL=0, TTL=1, TTL >1.   I might offer the following…
> >
> >
> >
> > TTL: Service plane time-to-live. Treatment of certain received TTL
> > values by an SFF is dependent on the SFF’s position within the sequence
> > of SFF’s for the given Service Function Path.   A received TTL value of
> > 0 received by the first SFF in an SFP shall be treated as if it had a
> > value of 64, for backward compatibility with classifiers that don’t set
> > TTL.    A received TTL value of 0 at a non-first SFF shall result in
> > discard of the packet.   A received TTL value of 1 received by the last
> > SFF in an SFP is valid and shall result in appropriate forwarding to
> > attached service functions.   A received TTL value of 1 received by a
> > non-last SFF in an SFP shall result in discard of the packet.   For all
> > scenarios where propagation to a subsequent SFF are valid, the
> > transmitted TTL shall be a decrement of 1 from the received TTL, except
> > in the special case of first-SFF receiving TTL 0 which shall result in a
> > transmitted TTL of 63.   Classifiers that support TTL shall adopt 63 as
> > the default initial TTL.
> >
> >
> >
> >
> >
> >
> >
> > *From:*Dave Dolson [mailto:[e-mail]]
> > *Sent:* Friday, April 28, 2017 8:39 AM
> > *To:* jmh.direct <[e-mail]
> > <mailto:[e-mail]>>; Joel M. Halpern
> > <[e-mail] <mailto:[e-mail]>>; Joe Clarke
> > <[e-mail] <mailto:[e-mail]>>; Ron Parker
> > <[e-mail]
> > <mailto:[e-mail]>>; James N Guichard
> > <[e-mail] <mailto:[e-mail]>>;
> > [e-mail] <mailto:[e-mail]>
> > *Subject:* Re: [sfc] TTL field within the NSH base header
> >
> >
> >
> > Sorry, yes, I think the proposed text is OK.
> >
> > If it would help others, we could be more explicit about the reason.
> >
> >
> >
> > David Dolson
> > ‎
> >
> > *From: *jmh.direct
> >
> > *Sent: *Friday, April 28, 2017 8:31 AM
> >
> > *To: *Dave Dolson; Joel M. Halpern; Joe Clarke; Ron Parker; James N
> > Guichard; [e-mail] <mailto:[e-mail]>
> >
> > *Subject: *Re: [sfc] TTL field within the NSH base header
> >
> >
> >
> > It seems you are saying you agree with the described behavior.
> >
> >
> >
> > Can you live with the text as it is?
> >
> >
> >
> > Yours,
> >
> > Joel
> >
> >
> >
> >
> >
> >
> >
> > Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone
> >
> >
> >
> > -------- Original message --------
> >
> > From: Dave Dolson <[e-mail] <mailto:[e-mail]>>
> >
> > Date: 4/28/17 13:49 (GMT+01:00)
> >
> > To: "Joel M. Halpern" <[e-mail]
> > <mailto:[e-mail]>>, Joe Clarke <[e-mail]
> > <mailto:[e-mail]>>, Ron Parker <[e-mail]
> > <mailto:[e-mail]>>, James N Guichard
> > <[e-mail] <mailto:[e-mail]>>,
> > [e-mail] <mailto:[e-mail]>
> >
> > Subject: Re: [sfc] TTL field within the NSH base header
> >
> >
> >
> > For the record, I want backwards compatibility.
> > And also, I think it is wasteful to have a code-point that is prohibited
> > on the wire. I've always felt IP.TTL was bad for this reason.
> >
> > As for the wording, we could be explicit that TTL=0 is valid on the
> > wire, meaning 64.
> >
> > David Dolson
> > ‎
> >   Original Message
> > From: Joel M. Halpern
> > Sent: Friday, April 28, 2017 4:28 AM
> > To: Joe Clarke; Ron Parker; Dave Dolson; James N Guichard; [e-mail]
> > <mailto:[e-mail]>
> > Subject: Re: [sfc] TTL field within the NSH base header
> >
> >
> > There are really two separate issues.
> > First, and most important, what behavior does the working group want?
> >      The discussion started with a proposal along the lines Ron
> > suggests, and moved to what is in the summary Jim provided.  We are
> > trying as chairs to reflect the WG agreement, and to bring this to a
> > close.  Yes, we are incurring technical debt (of different forms and
> > degrees) in any solution that allows backwards compatibility.  So, yes,
> > we can still change this if the WG wants, but this was the rough
> > consensus Jim and I saw.
> >
> > Second, there is the question of whether the text is clear.  It is
> > always a balancing act between explaining the motivation for everything
> > at great length 9and losing the reader), vs just giving the behavior
> > with no explanation (and tending to get incorrect implementations.)  We
> > need to be somewhere in between.  We may not be in the right place.
> >
> > Yours,
> > Joel
> >
> > On 4/27/17 5:55 PM, Joe Clarke wrote:
> >> On 4/27/17 16:37, Joel M. Halpern wrote:
> >>> That alternative was discussed.  It also works.
> >>> However, with that alternative, if the Initial classifier is an old
> >>> system (not RFC compliant), we will not get any protection from the
> TTL.
> >>> If we take this (admittedly slightly odd) approach to decrementing the
> >>> TTL, then even though we do not recommend it, things still work with
> an
> >>> initial classifier that generates a TTL of 0.
> >>>
> >>> It is thus more robust, so the WG selected it in discussion atht
> >>> einterim adn on the list.
> >>
> >> Thanks, Joel.  I know it was discussed, but reading the final text, I
> >> wonder if this is just building technical debt into the protocol from
> >> the beginning.
> >>
> >> While this makes sense today, will it be as obvious (or as needed) in a
> >> year?  In two?
> >>
> >> Ron's text does seem clearer at the expense of the backward compat
> >> explicitness.
> >>
> >> Joe
> >>
> >>>
> >>> Yours,
> >>> Joel
> >>>
> >>> On 4/27/17 4:05 PM, Ron Parker wrote:
> >>>> Thanks, Dave.    Do you think it is possible to combine that backward
> >>>> compatibility with the simpler (to me) concept of testing for a
> packet
> >>>> that arrives with TTL=1 and conditioning behavior on whether the SFF
> is
> >>>> the terminating SFF of the path?
> >>>>
> >>>>
> >>>>
> >>>>    Ron
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> *From:* Dave Dolson [mailto:[e-mail]]
> >>>> *Sent:* Thursday, April 27, 2017 4:03 PM
> >>>> *To:* Ron Parker <[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
> >>>>
> >>>>
> >>>>
> >>>> Ron,
> >>>>
> >>>> Decrementing from zero to reach 63, and checking for zero after
> >>>> decrementing provides a degree of backwards compatibility with the
> prior
> >>>> header format.
> >>>>
> >>>> This permits packets on the wire to have 0 in the bits that were
> >>>> previously “reserved”.
> >>>>
> >>>>
> >>>>
> >>>> -Dave
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> *From:*sfc [mailto:[e-mail]] *On Behalf Of *Ron Parker
> >>>> *Sent:* Thursday, April 27, 2017 3:21 PM
> >>>> *To:* James N Guichard; [e-mail] <mailto:[e-mail]>
> <mailto:[e-mail]>
> >>>> *Subject:* Re: [sfc] TTL field within the NSH base header
> >>>>
> >>>>
> >>>>
> >>>> I had to really think about the language around decrementing by 1
> from 0
> >>>> and reaching 63.   This would only occur in an error scenario where a
> >>>> preceding SFF misbehaved, wouldn’t it?   Why are we insistent that
> the
> >>>> test for 0 happen after decrement, thereby creating this problem.
> I
> >>>> suspect that this has been already discussed and I apologize if I
> missed
> >>>> it, but if the language were simplified to say an SFF that receives
> an
> >>>> NSH with TTL=1 shall not forward it to another SFF (e.g., allowing it
> to
> >>>> engage its local SF instances, still).   Otherwise, it must decrement
> by
> >>>> 1 before forwarding to another SFF.
> >>>>
> >>>>
> >>>>
> >>>> An exact wording along these lines might be something like:
> >>>>
> >>>>
> >>>>
> >>>> TTL: Service plane time-to-live. An SFF MUST test the TTL before
> >>>> forwarding to another SFF for a given Service Function Chain.  If the
> >>>> received TTL value is 1, the SFF MUST drop packets that would
> otherwise
> >>>> have been forwarded to another SFF, but SHALL send such packets to
> >>>> attached service functions if the SFF terminates the Service Function
> >>>> Chain.   If the TTL value is greater than 1, the SFF must decrement
> the
> >>>> TTL by 1 before forwarding to another SFF.   The default for
> originating
> >>>> an NSH packet is a TTL value of 63.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> *From:* sfc [mailto:[e-mail]] *On Behalf Of *James N
> Guichard
> >>>> *Sent:* Thursday, April 27, 2017 2:54 PM
> >>>> *To:* [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
> >>>> *Subject:* [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] <mailto:[e-mail]>
> >>> https://www.ietf.org/mailman/listinfo/sfc
> >>
> >