Re: [sfc] I-D Action: draft-ietf-sfc-nsh-ecn-support-09.txt

Hi Andy, all,

One of the reasons why I suggested to consider Experimental is that I’m not sure that it is justified to require classifiers and **every** SFFs to behave as **both** IPFIX collectors/exporters while other approaches can be considered: e.g., the cumulative data from ingress to last SFF can be passed using a dedicated NSH TLV and, as such, we can get rid of this reco:

The ingress MUST be configured to know the
   relevant egress for a flow.

Cheers,
Med

De : sfc <sfc-bounces@ietf.org> De la part de Andrew G. Malis
Envoyé : mardi 19 avril 2022 13:54
À : Donald Eastlake <d3e3e3@gmail.com>
Cc : sfc@ietf.org
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-nsh-ecn-support-09.txt

Donald,

Regarding Experimental status, take a look at the guidelines at https://www.ietf.org/standards/process/informational-vs-experimental/ , in particular guidelines 3.4 and 3.5. This draft doesn't fit either of those.

Also, in my experience, the SFC WG has not required implementations for RFC publication, rather publication has been used to encourage implementation.

Cheers,
Andy

On Mon, Apr 18, 2022 at 6:13 PM Donald Eastlake <d3e3e3@gmail.com<mailto:d3e3e3@gmail.com>> wrote:
Hi,

I have done a significant pass over this draft in light of the reviews and I believe the draft is substantially improved; however, this revision does not, in my opinion, resolve all of the review comments and another pass will be needed before a WG Last Call.

Also, one person has suggested changing the target status of this draft from Proposed Standard to Experimental. I do not have much objection to such a change. What do others think?

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com<mailto:d3e3e3@gmail.com>

On Mon, Apr 18, 2022 at 6:02 PM <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Service Function Chaining WG of the IETF.

        Title           : Explicit Congestion Notification (ECN) and Congestion Feedback Using the Network Service Header (NSH) and IPFIX
        Authors         : Donald E. Eastlake
                          Bob Briscoe
                          Yizhou Li
                          Andrew G. Malis
                          Xinpeng Wei
        Filename        : draft-ietf-sfc-nsh-ecn-support-09.txt
        Pages           : 34
        Date            : 2022-04-18

Abstract:
   Explicit congestion notification (ECN) allows a forwarding element to
   notify downstream devices of the onset of congestion without having
   to drop packets. Coupled with a means to feed information about
   congestion back to upstream nodes, this can improve network
   efficiency through better congestion control, frequently without
   packet drops. This document specifies ECN and congestion feedback
   support within a Service Function Chaining (SFC) enabled domain
   through use of the Network Service Header (NSH, RFC 8300) and IP Flow
   Information Export (IPFIX, RFC 7011).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-ecn-support/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-ecn-support-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-ecn-support-09

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc
_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.