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

[<[e-mail]>]

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