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

[[e-mail]]

Hi Donald,

Please see inline.

Cheers,
Med

De : Donald Eastlake <[e-mail]>
Envoyé : mercredi 20 avril 2022 01:02
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : [e-mail]
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-nsh-ecn-support-09.txt

Hi Med,

On Tue, Apr 19, 2022 at 8:40 AM <[e-mail]<mailto:[e-mail]>> wrote:
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:

I don't think the draft imposes a requirement on every SFF to be an IPFIX collector/exporter, just on the ingress and egress nodes for the flows of interest.
[Med] I think it does. The reasoning is as follows:
* The SFC architecture does not make any assumption on the chains that can be instantiated in a domain. So, every SFF can potentially terminate a service chain.
* An SFF that terminates a service chain is the egress for that chain. A terminating SFF is responsible for striping the NSH.

On the other hand, it is helpful for every SFF and, indeed, every node containing a queue that could  be congested, to be ECN-aware.

But it is not fatal if some are not. It is just the congestion at non-ECN-aware nodes will be unmanaged,
[Med] I think you have already a note in the draft that covers this part.

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.

I agree that the above "MUST" statement, which was just added in the last revision, needs further elaboration. There needs to be some way to get IPFIX messages from ingress to egress. I can think of three general ways:
[Med] Thank you for sharing this fair summary.

1. IPFIX over the SFC domain's transport layer protocol such as sending the messages via SCTP over IP if IP is supported throughout the domain, which is the recommended method if it is available. This requires the ingress to be configured with additional information.

[Med] Indeed. Please note that the configured egress for a chain may not be the actual one that will be used for a given flow when reclassification happens on-path (rfc7665#section-4.8). An approach to avoid the configuration of the egress nodes is to use an NSH OAM trace message to discover the egress for a chain and then use whatever discovered egress to send the ecn data.

2. IPFIX over NSH. This would require assigning a new Next Protocol value for the NSH Next Protocol field for IPFIX. (Alternatively, you could use something more complex like IPFIX over UDP over IP over NSH but it is not clear what would be gained by the additional complexity and packet length.) This would normally use a different SPI, which would have to be configured, from the SPI used for data, to convey the IPFIX message more directly from ingress to egress.

[Med] I guess this one requires also knowing the egress nodes.

3. IPFIX via NSH TLV. This could be done but it would probably require using MD Type 2 and subject IPFIX messages to the same path and data delays / loss as user data. On the other hand, it might get the IPFIX message to the egress with minimal additional configuration at the ingress.
[Med] A variant would be to make use of rfc8393.html#section-6.4 to interleave these packets with data packets.

The draft suggests using NSH steering for IPFIX messages if direct transport protocol connectivity between ingress and egress is problematic but is not clear whether this means 2 or 3 above and whichever of these it is suggesting, the draft does not provide sufficient detail so that needs to be added. The draft recommends using a higher priority for IPFIX messages than for user data. Methods 1 and 2 above facilitate while this might be impractical for Method 3, causing re-ordering.

I think details for Method 2 should be added to the draft.

[Med] I agree that the current mention of IPFIX over NSH in the draft is underspecified.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]<mailto:[e-mail]>

Cheers,
Med

De : sfc <[e-mail]<mailto:[e-mail]>> De la part de Andrew G. Malis
Envoyé : mardi 19 avril 2022 13:54
À : Donald Eastlake <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]<mailto:[e-mail]>


On Mon, Apr 18, 2022 at 6:02 PM <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sfc
_______________________________________________
sfc mailing list
[e-mail]<mailto:[e-mail]>
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.

_________________________________________________________________________________________________________________________

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.