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

[Loa Andersson <[e-mail]>]

Working Group,

I read the draft and tried to pin down the comments, as far as I can
see there is nothing in the current comments that bloack working group
adoption, everything could during normal working group process. I
actually prefer that it is done this way, rather that in the individual
document to better capture wg consensus. To this end the wg chairs may
want to include a note in the mail that close the adoption poll to say
what the outstanding issues to be solved by the wg are.

/Loa

On 2019-01-26 13:35, Donald Eastlake wrote:
> Hi Med,
> 
> See below.
> 
> On Thu, Jan 24, 2019 at 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.
> 
> So, I've read RFC 2983 and consulted with its author David Black. RFC
> 2983 is not a standards track or BCP RFP. It's just Informational. It
> focuses on two models, the "uniform" model you describe below and the
> "pipe model".
> 
>> 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.
> 
> RFC 2983 doesn't say anything about which model should be used by SFC
> nor does it say which model should necessarily be used by an
> "encap/decap function". I continue to believe that the pipe model,
> which does not require any modification to the inner IP DSCP based on
> an outer IP DSCP, is more appropriate for SFC.
> 
> The situation is quite different for ECN, as compared with DSCP. For
> example, standards track RFC 6040 requires examination of both the
> outer and inner ECN marking at egress and their combination (or
> dropping the packet).
> 
> Thanks,
> Donald
> ===============================
>   Donald E. Eastlake 3rd   [phone] (cell)
>   1424 Pro Shop Court, Davenport, FL 33896 USA
>   [e-mail]
> 
>> 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
> 

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert
Bronze Dragon Consulting             phone: [phone]