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

[Donald Eastlake <[e-mail]>]

Hi Med,

Thanks for your response and various pointers in it to things that may be
included in the next revision.

However, there is one point on which I disagree with you:
Say you have a network of N nodes and are adding a feature. Furthermore,
there are ways of using that network that need that feature and that make
use of the feature at different subsets of those N nodes. While it might be
desirable to implement the feature on all nodes, it is also possible to
simply choose to make use of the network such that you only use the nodes
at which the feature is implemented. So, I completely disagree
that specification of such a feature must mandate implementation at every
node in such a network.

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


On Wed, Apr 20, 2022 at 2:08 AM <[e-mail]> wrote:

> 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]> 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]
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* sfc <[e-mail]> *De la part de* Andrew G. Malis
> *Envoyé :* mardi 19 avril 2022 13:54
> *À :* Donald Eastlake <[e-mail]>
> *Cc :* [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]> 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]
>
>
>
>
>
> On Mon, Apr 18, 2022 at 6:02 PM <[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]
> https://www.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________
> sfc mailing list
> [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.
>
>