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

[<[e-mail]>]

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
>