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

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

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