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

[<[e-mail]>]

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