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

Hi Med, et. al,
I'm somewhat lost at the need to discuss egress SFF as special case in
regard to TTL handling. I believe that we've agreed that:

   - receiving TTL==0 is valid;
   - TTL is to be decremented by 1 before being forwarded to the next SFF.
   Special case - TTL of value 0. This case is handled as TTL equals 64 and
   thus packet is expected to be transmitted with TTL of 63;
   - egress SFF that terminates SFC, as I understand, removes NSH and the
   TTL altogether. SFC TTL does not play any part after SFC has been
   terminated.

What have I missed? Appreciate your comments.

Regards,
Greg

On Mon, May 1, 2017 at 10:39 PM, <mohamed.boucadair@orange.com> wrote:

> Hi Jim,
>
>
>
> Yes, your wording is better: “SFFs that terminate a service chain MUST
> forward the packet even if SHL is decremented to 0”
>
>
>
> Thank you.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* James N Guichard [mailto:james.n.guichard@huawei.com]
> *Envoyé :* lundi 1 mai 2017 16:22
> *À :* BOUCADAIR Mohamed IMT/OLN; Dave Dolson; sfc@ietf.org
>
> *Objet :* RE: 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:* mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com
> <mohamed.boucadair@orange.com>]
> *Sent:* Friday, April 28, 2017 10:38 AM
> *To:* Dave Dolson <ddolson@sandvine.com>; James N Guichard <
> james.n.guichard@huawei.com>; sfc@ietf.org
> *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:ddolson@sandvine.com <ddolson@sandvine.com>]
> *Envoyé :* vendredi 28 avril 2017 16:29
> *À :* BOUCADAIR Mohamed IMT/OLN; James N Guichard; sfc@ietf.org
> *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:sfc-bounces@ietf.org <sfc-bounces@ietf.org>] *On
> Behalf Of *mohamed.boucadair@orange.com
> *Sent:* Friday, April 28, 2017 9:36 AM
> *To:* James N Guichard; sfc@ietf.org
> *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:sfc-bounces@ietf.org <sfc-bounces@ietf.org>] *De la
> part de* James N Guichard
> *Envoyé :* jeudi 27 avril 2017 20:54
> *À :* sfc@ietf.org
> *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
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>
>