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

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

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