Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption"

["Joel M. Halpern" <[e-mail]>]

<chair hat on>
Thank you for the citation Med.

I would like to hear from others in the working group as to whether they it.

Yours,
Joel


On 1/24/19 1:39 AM, [e-mail] wrote:
> Joel,
> 
> DSCP preservation is a trivial requirement for intra-domain SFC. Please refer to https://tools.ietf.org/html/rfc2983:
> 
>     When a tunnel is not end-to-end, there are
>     circumstances in which it may be desirable to propagate the DSCP
>     and/or some of the information that it contains to the outer IP
>     header on ingress and/or back to inner IP header on egress.
> 
> One of the models discussed in 2983 assumes the following.
> 
>     In this model, any packet has exactly one DS Field
>     that is used for traffic conditioning at any point, namely the DS
>     Field in the outermost IP header; any others are ignored.
>     Implementations of this model copy the DSCP value to the outer IP
>     header at encapsulation and copy the outer header's DSCP value to the
>     inner IP header at decapsulation.
> 
> Because SFF is an encap/decpa function, it falls under the above implementations.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Joel M. Halpern [mailto:[e-mail]]
>> Envoyé : mercredi 23 janvier 2019 17:10
>> À : BOUCADAIR Mohamed TGI/OLN
>> Cc : [e-mail]; [e-mail]
>> Objet : Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in
>> state "Candidate for WG Adoption"
>>
>> <no hat>
>> Maybe I am missing something important, but I would not expect SFF to
>> exhibit the behavior you describe relative to DSCPs.
>>
>> I do not know of any place where this is required for intra-domain
>> tunnels.  It is an interesting issue for inter-domain usage of SFC.  But
>> our scope is explicitly intra-domain.
>>
>> As far as I know, DSCPs are not re-marked within a domain.  They are
>> modified at entry / exit from a domain, but that is not an issue for an SFF.
>>
>> Is there someplace where the behavior you are asking about is required
>> by existing documents?
>>
>> Yours,
>> Joel
>>
>> On 1/23/19 8:37 AM, [e-mail] wrote:
>>> Hi Joel,
>>>
>>> The point Joel is SFFs has to preserve whatever DSCP marking when
>> encapsulating/encapsulation (including cases where transport encap changes).
>>>
>>> If you will, we can describe the scenario using your words:
>>>
>>> =======
>>> Consider an SFF that receives a packet with a transport DSCP marking
>>> and an NSH header.  That SFF removes the transport header.  It then
>>> (usually) sends the packet via some other means to an SF, and gets the
>>> packet back.  After which it sends it on to the next SFF with a new
>>> transport header carrying the NSH.
>>> Let us take as given that we want to support DSCP marking preservation.
>>> Then we need to somehow preserve the DSCP information that the SFF
>>> receives.
>>> ==========
>>>
>>> Cheers,
>>> Med
>>>
>>>> -----Message d'origine-----
>>>> De : Joel M. Halpern [mailto:[e-mail]]
>>>> Envoyé : mardi 22 janvier 2019 13:31
>>>> À : BOUCADAIR Mohamed TGI/OLN; Andrew G. Malis
>>>> Cc : [e-mail]; [e-mail]
>>>> Objet : Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support
>> in
>>>> state "Candidate for WG Adoption"
>>>>
>>>> (again: speaking personally)
>>>> DSCP behavior is VERY different from ECN behavior in terms of
>>>> intermediate router modification.  DSCPs may get rewritten at certain
>>>> specific places, but not generally at interior routers.  So mapping from
>>>> the interior packet DSCP to the exterior packet DSCP and IEEE marking is
>>>> normal and safe.  there is no need to reverse the process.  ECN marking
>>>> needs to reverse the process due to the fact that individual routers are
>>>> expected to change the marking based on local conditions.
>>>>
>>>> At least thaat is how I understand it,
>>>> Joel
>>>>
>>>> On 1/22/19 1:25 AM, [e-mail] wrote:
>>>>> Hi Joel,
>>>>>
>>>>> What makes ECN specific in this regards compared to DSCP marking
>>>> preservation?
>>>>>
>>>>> Cheers,
>>>>> Med
>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Joel M. Halpern [mailto:[e-mail]]
>>>>>> Envoyé : vendredi 18 janvier 2019 15:55
>>>>>> À : BOUCADAIR Mohamed TGI/OLN; Andrew G. Malis
>>>>>> Cc : [e-mail]; [e-mail]
>>>>>> Objet : Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-
>> support
>>>> in
>>>>>> state "Candidate for WG Adoption"
>>>>>>
>>>>>> <chair hat off>
>>>>>> Let me try as an individual to paraphrase what I understand the document
>>>>>> to be offering.  That authors should feel free to comment further
>>>>>> including if necessary telling me that I am confused.
>>>>>>
>>>>>> Consider an SFF that receives a packet with a transport ECN indication
>>>>>> and an NSH header.  That SFF removes the transport header.  It then
>>>>>> (usually) sends the packet via some other means to an SF, and gets the
>>>>>> packet back.  After which it sends it on to the next SFF with a new
>>>>>> transport header carrying the NSH.
>>>>>> Let us take as given that we want to support effective ECN.
>>>>>> Then we need to somehow preserve the ECN information that the SFF
>>>> receives.
>>>>>>
>>>>>> One way would be to insist that the SFF, when it receives the ECN
>>>>>> information, has to rummage through to find the internal IP packet, and
>>>>>> must update the internal ECN information therein.  Ugg.  IThat would be
>>>>>> a pretty onerous requirement.
>>>>>>
>>>>>> Instead, the document suggests that the SFF transfer the marking to the
>>>>>> NSH header, and then use that NSH marking when it generates the new
>>>>>> transport header.  This can then be used when the packet exits the NSH
>>>>>> domain to propagate the information to the header (which is by
>>>>>> definition exposed when the NSH header is removed.)
>>>>>>
>>>>>> Med, if I understand you properly you are suggesting that the SFF should
>>>>>> somehow keep the information from the transport header associated with
>>>>>> the packet, but not in the NSH header.  In some SFF implementations, and
>>>>>> with some ways of working with SFs, that is doable.  Requiring that
>>>>>> would limit the implementation and deployment choices.
>>>>>>
>>>>>> <chair hat somewhere>
>>>>>> Yours,
>>>>>> Joel
>>>>>>
>>>>>> On 1/18/19 4:15 AM, [e-mail] wrote:
>>>>>>> Hi Andy,
>>>>>>>
>>>>>>> Please see inline.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Med
>>>>>>>
>>>>>>> *De :*sfc [mailto:[e-mail]] *De la part de* Andrew G. Malis
>>>>>>> *Envoyé :* jeudi 17 janvier 2019 16:33
>>>>>>> *À :* BOUCADAIR Mohamed TGI/OLN
>>>>>>> *Cc :* [e-mail]; IETF Secretariat;
>>>>>>> [e-mail]; [e-mail]
>>>>>>> *Objet :* Re: [sfc] The SFC WG has placed
>>>>>>> draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption"
>>>>>>>
>>>>>>> Med,
>>>>>>>
>>>>>>> Your point about RFC 5129 is correct, but I'm not personally aware of
>>>>>>> any implementations. And I was just using MPLS as an example, there may
>>>>>>> be others in the future as well.
>>>>>>>
>>>>>>> [Med] I understood this was an example, but still this is IMHO supposed
>>>>>>> to be handled among the spirit of the effort led by Bob in 6040 and its
>>>>>>> current & futures updates.
>>>>>>>
>>>>>>> Your point about the SFF preserving ECN is implementation dependent,
>> for
>>>>>>> example the SFF could have separate input and output interfaces without
>>>>>>> shared memory, or the transport encapsulation could change in different
>>>>>>> regions of the SFC domain.
>>>>>>>
>>>>>>> [Med] I don’t understand your point about separate inputs/output
>>>>>>> interfaces and the change of encap schemes. Let’s put aside SFC for a
>>>>>>> moment and consider the example of a LISP XTR which is supporting ECN
>>>>>>> dissemination/handling. That xTR may not use the same in/out
>> interfaces,
>>>>>>> but still need to achieve some processing when doing its encap/decap.
>>>>>>>
>>>>>>> It's difficult to depend on SFFs being able to preserve
>>>>>>> transport-header-dependent information without that becoming a
>>>>>>> requirement in the SFC architecture.
>>>>>>>
>>>>>>> [Med] I don’t think that we can tag congestion notification as
>>>>>>> “transport-header-dependent”. There are ways to pass that info even
>> when
>>>>>>> the transport encap changes.
>>>>>>>
>>>>>>> This is IMHO among things that the WG is supposed to cover under this
>>>>>>> item in the charter (please note that those are clearing taged as
>>>>>>> transport issues):
>>>>>>>
>>>>>>> ==
>>>>>>>
>>>>>>> 4) Transport Considerations - This will capture the expectations SFC
>>>>>>> places on transport behavior, including dealing with issues such as
>>>>>>> congestion indications and responses.
>>>>>>>
>>>>>>> ==
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Andy
>>>>>>>
>>>>>>> On Thu, Jan 17, 2019 at 10:02 AM <[e-mail]
>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>
>>>>>>>        Hi Andy,
>>>>>>>
>>>>>>>        Please see inline.
>>>>>>>
>>>>>>>        Cheers,
>>>>>>>
>>>>>>>        Med
>>>>>>>
>>>>>>>        *De :*Andrew G. Malis [mailto:[e-mail]
>>>>>>>        <mailto:[e-mail]>]
>>>>>>>        *Envoyé :* jeudi 17 janvier 2019 15:50
>>>>>>>        *À :* BOUCADAIR Mohamed TGI/OLN
>>>>>>>        *Cc :* IETF Secretariat; [e-mail]
>>>>>>>        <mailto:[e-mail]>;
>>>>>>>        [e-mail]
>>>>>>>        <mailto:[e-mail]>;
>> [e-mail]
>>>>>>>        <mailto:[e-mail]>
>>>>>>>        *Objet :* Re: [sfc] The SFC WG has placed
>>>>>>>        draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG
>>>> Adoption"
>>>>>>>
>>>>>>>        Med,
>>>>>>>
>>>>>>>        Not all transports support ECN marking, for example NSH over
>> MPLS.
>>>>>>>
>>>>>>>        [Med] Isn’t this covered by RFC5129?
>>>>>>>
>>>>>>>        And even where the transport supports ECN marking, note the
>> example
>>>>>>>        in Figure 1 in the draft where the outer encapsulation can be
>>>>>>>        stripped during SFF processing. In that case, the scope of the
>> ECN
>>>>>>>        marking is limited to individual SFF-SFF links. rather than end-
>> to-
>>>> end.
>>>>>>>
>>>>>>>        [Med] Why couldn’t SFF preserve ECN when doing its transport
>>>>>>>        decap/encap?
>>>>>>>
>>>>>>>        Cheers,
>>>>>>>
>>>>>>>        Andy
>>>>>>>
>>>>>>>        On Thu, Jan 17, 2019 at 9:12 AM <[e-mail]
>>>>>>>        <mailto:[e-mail]>> wrote:
>>>>>>>
>>>>>>>            Hi all,
>>>>>>>
>>>>>>>            I do think that ECN is naturally better handled at the
>> transport
>>>>>>>            encapsulation instead of the NSH itself.
>>>>>>>
>>>>>>>            Requiring the functionality to be handled at the transport
>> encap
>>>>>>>            (draft-ietf-tsvwg-rfc6040update-shim) and NSH is redundant,
>> IMO.
>>>>>>>
>>>>>>>            I like the approach we set in the SFC architecture in which
>> we
>>>>>>>            separated service matters from transport ones. I'd vote for
>>>>>>>            maintaining that separation cleaner as it was set in the arch
>>>> RFC.
>>>>>>>
>>>>>>>            Thank you.
>>>>>>>
>>>>>>>            Cheers,
>>>>>>>            Med
>>>>>>>
>>>>>>>             > -----Message d'origine-----
>>>>>>>             > De : sfc [mailto:[e-mail]
>>>>>>>            <mailto:[e-mail]>] De la part de IETF Secretariat
>>>>>>>             > Envoyé : jeudi 3 janvier 2019 06:11
>>>>>>>             > À : [e-mail] <mailto:[e-mail]>;
>>>>>>>            [e-mail]
>>>>>>>            <mailto:[e-mail]>;
>>>>>>>             > [e-mail] <mailto:[e-mail]>
>>>>>>>             > Objet : [sfc] The SFC WG has placed
>>>>>>>            draft-eastlake-sfc-nsh-ecn-support in
>>>>>>>             > state "Candidate for WG Adoption"
>>>>>>>             >
>>>>>>>             >
>>>>>>>             > The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support
>> in
>>>>>> state
>>>>>>>             > Candidate for WG Adoption (entered by Joel Halpern)
>>>>>>>             >
>>>>>>>             > The document is available at
>>>>>>>             >
>>>>>>>            https://datatracker.ietf.org/doc/draft-eastlake-sfc-nsh-ecn-
>>>>>> support/
>>>>>>>             >
>>>>>>>             > Comment:
>>>>>>>             > This starts the WG call for adoption of this draft.
>>>>>>>             > Please respond to the list, indicating support for this as
>> a
>>>>>>>            work item of the
>>>>>>>             > working group with this document as the basis for the
>> work,
>>>>>>>            or objection to
>>>>>>>             > the working group adopting this item as a working group
>>>> draft.
>>>>>>>             >
>>>>>>>             > The authors should confirm to the chairs and WG secretary
>>>>>>>            that all IPR known
>>>>>>>             > to them relevant to this draft has been disclosed.
>>>>>>>             >
>>>>>>>             > The working group adoption call will last 2 weeks, ending
>> at
>>>>>>>            the end of the
>>>>>>>             > day on Thursday, January 17 2019 COB somewhere.
>>>>>>>             >
>>>>>>>             > Thank you,
>>>>>>>             > Joel
>>>>>>>             >
>>>>>>>             > _______________________________________________
>>>>>>>             > sfc mailing list
>>>>>>>             > [e-mail] <mailto:[e-mail]>
>>>>>>>             > https://www.ietf.org/mailman/listinfo/sfc
>>>>>>>