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

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

<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
>>>>>