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

Hi Med,

On Tue, Apr 19, 2022 at 8:40 AM <mohamed.boucadair@orange.com> 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. 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,

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

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.

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.

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.

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.

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

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