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

Hi Andy,

Please see inline.

Cheers,
Med

De : sfc [mailto:sfc-bounces@ietf.org] De la part de Andrew G. Malis
Envoyé : jeudi 17 janvier 2019 16:33
À : BOUCADAIR Mohamed TGI/OLN
Cc : sfc-chairs@ietf.org; IETF Secretariat; draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org
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 <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote:
Hi Andy,

Please see inline.

Cheers,
Med

De : Andrew G. Malis [mailto:agmalis@gmail.com<mailto:agmalis@gmail.com>]
Envoyé : jeudi 17 janvier 2019 15:50
À : BOUCADAIR Mohamed TGI/OLN
Cc : IETF Secretariat; sfc-chairs@ietf.org<mailto:sfc-chairs@ietf.org>; draft-eastlake-sfc-nsh-ecn-support@ietf.org<mailto:draft-eastlake-sfc-nsh-ecn-support@ietf.org>; sfc@ietf.org<mailto:sfc@ietf.org>
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 <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> 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:sfc-bounces@ietf.org<mailto:sfc-bounces@ietf.org>] De la part de IETF Secretariat
> Envoyé : jeudi 3 janvier 2019 06:11
> À : sfc-chairs@ietf.org<mailto:sfc-chairs@ietf.org>; draft-eastlake-sfc-nsh-ecn-support@ietf.org<mailto:draft-eastlake-sfc-nsh-ecn-support@ietf.org>;
> sfc@ietf.org<mailto:sfc@ietf.org>
> 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
> sfc@ietf.org<mailto:sfc@ietf.org>
> https://www.ietf.org/mailman/listinfo/sfc