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

[Joe Clarke <[e-mail]>]

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]>; James N Guichard
>> <[e-mail]>; [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]>
>> *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]>
>> *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]
>> https://www.ietf.org/mailman/listinfo/sfc
>>
> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc