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>
Apparently I am having trouble typing this morning.

Do others understand the DiffServ RFCs to place this requirement on SFC?
I am also checking with some other folks who work regularly with DSCPs 
and the relevant RFCs.

Thank you,
Joel

On 1/24/19 8:39 AM, Joel M. Halpern wrote:
> <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
>>>>>>>>
> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc