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

From: IETF Secretariat <[email-masked]>
Date: Wed, 02 Jan 2019 21:10:55 -0800

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 3 Jan 2019 09:15:08 -0500

As a co-author, I feel that this draft is ready for WG adoption.

Thanks,
Andy

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 7 Jan 2019 09:57:01 +0200

Hi,

I reviewed the draft, and I believe it is worth pursuing in the working
group.

Comments:

- Section 1.3 / Section 4: these sections discuss how the ingress node
(classifier) may react to the congestion. However, it seems that there may
be a conflict if the egress node both propagates the ECN to the destination
AND sends a congestion feedback to the ingress node. In this case traffic
may be throttled by two nodes (traffic source and NSH classifier). It would
be helpful if the draft clarifies whether these two behaviors are mutually
exclusive, or how they coexist.

- The draft implies that in a network that uses ECN-in-NSH the Ingress and
Egress nodes must be ECN aware, while the SFFs and SFs may be ECN unaware,
allowing interoperability with older SFF/SF nodes. I would suggest to state
this explicitly in the introduction.

- "It MAY instead be set to ECT(1) if the NSH domain supports the
experimental L4S capability [RFC8311], [ecnL4S]."
  This sentence is confusing from an implementer's perspective. Does the
"MAY" here allow interoperability between the two approaches (RFC3168/
RFC8311)? Please clarify in the draft whether ECN-in-NSH-aware nodes are
expected to be implemented as defined in [RFC3168] or as in [RFC8311], or a
combination of both.

Cheers,
Tal.

---

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 7 Jan 2019 21:55:47 +0000

Hi,

I support the adoption of this draft. Congestion management is an essential feature in the NSH framework.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: [email-masked]
Tel:         +34 913 129 041
Mobile:  +34 682 051 091
----------------------------------

On 03/01/2019, 06:11, "sfc on behalf of IETF Secretariat" <[email-masked] on behalf of [email-masked]> wrote:

    Comment:

    Thank you,
    Joel

    _______________________________________________
    sfc mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/sfc

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 8 Jan 2019 16:43:37 -0500

Hi Tal,

On Mon, Jan 7, 2019 at 2:57 AM Tal Mizrahi <[email-masked]> wrote:
>
> Hi,
>
> I reviewed the draft, and I believe it is worth pursuing in the working group.

Thanks for the support.

> Comments:
>
> - Section 1.3 / Section 4: these sections discuss how the ingress node (classifier) may react to the congestion. However, it seems that there may be a conflict if the egress node both propagates the ECN to the destination AND sends a congestion feedback to the ingress node. In this case traffic may be throttled by two nodes (traffic source and NSH classifier). It would be helpful if the draft clarifies whether these two behaviors are mutually exclusive, or how they coexist.

That is a reasonable consideration and the draft should probably talk
about it. I think some actions by the NSH classifier could cause
problems but there are other NSH classifier actions that would be OK.

> - The draft implies that in a network that uses ECN-in-NSH the Ingress and Egress nodes must be ECN aware, while the SFFs and SFs may be ECN unaware, allowing interoperability with older SFF/SF nodes. I would suggest to state this explicitly in the introduction.

OK.

> - "It MAY instead be set to ECT(1) if the NSH domain supports the experimental L4S capability [RFC8311], [ecnL4S]."
>   This sentence is confusing from an implementer's perspective. Does the "MAY" here allow interoperability between the two approaches (RFC3168/ RFC8311)? Please clarify in the draft whether ECN-in-NSH-aware nodes are expected to be implemented as defined in [RFC3168] or as in [RFC8311], or a combination of both.

I agree we need to clarify that.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [email-masked]

> Cheers,
> Tal.
>
> On Thu, Jan 3, 2019 at 7:11 AM IETF Secretariat <[email-masked]> wrote:
>>
>>

---

From: Mach Chen <[email-masked]>
Date: Mon, 14 Jan 2019 08:09:19 +0000

Yes/support.

Best regards,
Mach

> -----Original Message-----
> From: sfc [mailto:[email-masked]] On Behalf Of IETF Secretariat
> Sent: Thursday, January 03, 2019 1:11 PM
> To: [email-masked]; [email-masked];
> [email-masked]
> Subject: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in
> state "Candidate for WG Adoption"
> 
>

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 15 Jan 2019 22:53:22 +0000

Tal,

Following up on Donald's responses as a co-author,...

> problems but there are other NSH classifier actions that would be OK.
[BB] We've started covered to cover this in Section 1.3 
<https://tools.ietf.org/html/draft-eastlake-sfc-nsh-ecn-support-02#section-1.3>, 
where we list and discuss the three types of action at the domain 
ingress that would be reasonable in response to congestion. However, I 
agree this isn't sufficient to address your concern, so it would also be 
useful to say what type of ingress action would /not/ be appropriate. 
Perhaps adding the following text to the note after the 3 bullets 
(subject to agreement by co-authors):

    "Any action by the ingress to reduce congestion needs to allow
    sufficient time for the end-to-end congestion control loop to
    respond first, for instance by the ingress taking a smoothed average
    of the level of congestion signalled by feedback from the tunnel
    egress."

I can also reassure you for each specific case that we suggest:

 1. Policing: Policing based on congestion feedback is intended to take
    over if the load is unresponsive to congestion signalling forwarded
    towards the receiver. Therefore, if the end-to-end congestion
    control is doing its job, policing-based on congestion feedback
    should do nothing. So the two ought not to conflict.
    Congestion-based policing should only intervene if congestion
    becomes excessive.

    [Note that this is not the same as a rate policer (which doesn't
    need congestion feedback - it can see the rate locally, so it can
    police to a rate without feedback about congestion from other
    nodes). Typically, rate policing conservatively limits everyone's
    rates to limit the possibility of congestion downstream. The idea of
    congestion policing is that you don't need to police rates - you
    only police if the sum of all the traffic at any node exceeds
    capacity (and if the end-systems don't respond to the congestion
    themselves).]

 2. Upstream congestion feedback: I believe this is a sub-case of
    congestion-based-policing (1), where the ingress passes its signals
    to some other node that does the policing on its behalf.

 3. Re-direction: Traffic engineering is definitely a case where it has
    to move slowly, which gives time for the end-system congestion
    controls to respond. We already have a point about taking care to
    avoid flap, etc. But I think being more specific with the extra
    words above can only help.

> I agree we need to clarify that.
Let me get back to you on this one. I have to admit that I can't 
remember why we catered for L4S in the way written around table 2. I've 
checked back, and I actually wrote this part myself, but it looks wrong 
to me, which would be embarrassing. However, I need to check with my 
co-authors to confirm that.

Whatever, thanks for picking this up.

Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: <[email-masked]>
Date: Thu, 17 Jan 2019 14:12:38 +0000

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:[email-masked]] De la part de IETF Secretariat
> Envoyé : jeudi 3 janvier 2019 06:11
> À : [email-masked]; [email-masked];
> [email-masked]
> Objet : [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 17 Jan 2019 09:49:33 -0500

Med,

Not all transports support ECN marking, for example NSH over MPLS.

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.

Cheers,
Andy

On Thu, Jan 17, 2019 at 9:12 AM <[email-masked]> wrote:

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

---

From: <[email-masked]>
Date: Thu, 17 Jan 2019 15:02:01 +0000

Hi Andy,

Please see inline.

Cheers,
Med

De : Andrew G. Malis [mailto:[email-masked]]
Envoyé : jeudi 17 janvier 2019 15:50
À : BOUCADAIR Mohamed TGI/OLN
Cc : IETF Secretariat; [email-masked]; [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Thank you.

Cheers,
Med

> De : sfc [mailto:[email-masked]<mailto:[email-masked]>] De la part de IETF Secretariat
> À : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 17 Jan 2019 10:33:28 -0500

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.

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. It's difficult to depend on SFFs being able to
preserve transport-header-dependent information without that becoming a
requirement in the SFC architecture.

Cheers,
Andy

On Thu, Jan 17, 2019 at 10:02 AM <[email-masked]> wrote:

> Hi Andy,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Andrew G. Malis [mailto:[email-masked]]
> *Envoyé :* jeudi 17 janvier 2019 15:50
> *À :* BOUCADAIR Mohamed TGI/OLN
> *Cc :* IETF Secretariat; [email-masked];
> [email-masked]; [email-masked]
> *Objet :* Re: [sfc] The SFC WG has placed
> draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption"
>
>
>
> Med,
>
>
>

---

From: <[email-masked]>
Date: Fri, 18 Jan 2019 09:15:34 +0000

Hi Andy,

Please see inline.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Andrew G. Malis
Envoyé : jeudi 17 janvier 2019 16:33
À : BOUCADAIR Mohamed TGI/OLN
Cc : [email-masked]; IETF Secretariat; [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy,

Please see inline.

Cheers,
Med

De : Andrew G. Malis [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : jeudi 17 janvier 2019 15:50
À : BOUCADAIR Mohamed TGI/OLN
Cc : IETF Secretariat; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption"

Med,

Cheers,
Andy

Thank you.

Cheers,
Med

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 18 Jan 2019 09:54:53 -0500

<chair hat off>
Let me try as an individual to paraphrase what I understand the document 
to be offering.  That authors should feel free to comment further 
including if necessary telling me that I am confused.

Consider an SFF that receives a packet with a transport ECN indication 
and an NSH header.  That SFF removes the transport header.  It then 
(usually) sends the packet via some other means to an SF, and gets the 
packet back.  After which it sends it on to the next SFF with a new 
transport header carrying the NSH.
Let us take as given that we want to support effective ECN.
Then we need to somehow preserve the ECN information that the SFF receives.

One way would be to insist that the SFF, when it receives the ECN 
information, has to rummage through to find the internal IP packet, and 
must update the internal ECN information therein.  Ugg.  IThat would be 
a pretty onerous requirement.

Instead, the document suggests that the SFF transfer the marking to the 
NSH header, and then use that NSH marking when it generates the new 
transport header.  This can then be used when the packet exits the NSH 
domain to propagate the information to the header (which is by 
definition exposed when the NSH header is removed.)

Med, if I understand you properly you are suggesting that the SFF should 
somehow keep the information from the transport header associated with 
the packet, but not in the NSH header.  In some SFF implementations, and 
with some ways of working with SFs, that is doable.  Requiring that 
would limit the implementation and deployment choices.

<chair hat somewhere>
Yours,
Joel

On 1/18/19 4:15 AM, [email-masked] wrote:
> Hi Andy,
> 
> Please see inline.
> 
> Cheers,
> 
> Med
> 
> *De :*sfc [mailto:[email-masked]] *De la part de* Andrew G. Malis
> *Envoyé :* jeudi 17 janvier 2019 16:33
> *Cc :* [email-masked]; IETF Secretariat; 
> 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.
> 
> 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 
> [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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Andy,
> 
>     Please see inline.
> 
>     Cheers,
> 
>     Med
> 
>     *De :*Andrew G. Malis [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Cc :* IETF Secretariat; [email-masked]
>     <mailto:[email-masked]>;
>     [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     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.
> 
>     On Thu, Jan 17, 2019 at 9:12 AM <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Hi all,
> 
>         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
> 
>          > De : sfc [mailto:[email-masked]
>         <mailto:[email-masked]>] De la part de IETF Secretariat
>          > À : [email-masked] <mailto:[email-masked]>;
>         [email-masked]
>         <mailto:[email-masked]>;
>          > [email-masked] <mailto:[email-masked]>
>          > [email-masked] <mailto:[email-masked]>

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 18 Jan 2019 14:19:40 -0500

Hi Joel,

I think your message correctly describes what the draft is doing.

To me, carrying ECN in the NSH within the SFC domain is simpler and
more robust than trying to use the outer or the inner transport
headers. For example, should an SF or SF Proxy clear the outer
transport ECN bits, with ECN being carried in the NSH, you just lose
congestion management on the round trip from the SFF to that SF or SF
Proxy. On the other hand, if you are depending on ECN in the outer
transport header rather than the NSH (or in metadata where there is no
outer transport header), then you lose congestion management across
the entire SFC domain. Or if there is an SF or SF Proxy reached by a
transport protocol that has no ECN support, you don't have to muck
around finding the inner transport header to update.

Thanks,
Donald

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 22 Jan 2019 00:05:46 +0000

Tal,

I've conferred with my co-authors, and I can confirm that there is no 
need for a separate L4S mode, as incorrectly described around Table 2 in 
draft-02. It was actually me who wrote the incorrect text and table in 
the first place - my co-authors are wholly innocent, cos I'm the one 
developing the L4S experiment (L4S = Low Latency Low Loss Scalable 
throughput)! So thanks for asking how the two approaches interoperate, 
which made me notice this.

The answer to your question is that L4S doesn't need any change to how 
congestion signals are propagated. L4S is purely a different AQM 
algorithm at network nodes and a different response algorithm at the 
source. As far as encap and decap are concerned, the tunnelling 
behaviours specified in RFC6040 and followed in the sfc-nsh-ecn draft 
inherently work for L4S just as well as for standard RFC3168 ECN. That's 
all the SFC WG needs to know.

However, if you want to know a little more about how L4S works, the 
source distinguishes its packets by setting them to ECT(1), which an L4S 
node classifies into a distinct L4S queue. Any network node that doesn't 
support L4S will just handle these packets as if ECT(0) and ECT(1) mean 
the same (as required by the original ECN spec [RFC3168]). And the 
source has to detect such behaviour and respond accordingly 
[draft-ietf-tsvwg-ecn-l4s-id].

We will be correcting the text as follows:

CURRENT:

    Then, if the resulting NSH ECN field is Not-ECT, the ingress SHOULD
    set it to ECT(0), in order to indicate that the NSH encapsulation is
    an ECN-Capable Transport.It MAY instead be set to ECT(1) if the NSH domain supports the experimental L4S capability [RFC8311  <https://tools.ietf.org/html/rfc8311>], [ecnL4S  <https://tools.ietf.org/html/draft-eastlake-sfc-nsh-ecn-support-02#ref-ecnL4S>].
...

             +-----------------+-------------------------------+
             | Incoming Header |Departing NSH and Outer Headers|
             | (also equal to  +---------------+---------------+
             | departing Inner |  Classic ECN  |    L4S ECN    |
             |     Header)     |     Mode      |     Mode      |
             +-----------------+---------------+---------------+
             |    Not-ECT      |   ECT(0)      |    ECT(1)     |
             |     ECT(0)      |   ECT(0)      |    ECT(0)     |
             |     ECT(1)      |   ECT(1)      |    ECT(1)     |
             |       CE        |     CE        |      CE       |
             +-----------------+---------------+---------------+

PROPOSED:

    Then, if the resulting NSH ECN field is Not-ECT, the ingress SHOULD
    set it to ECT(0).This indicates that, even though the end-to-end transport is not 
ECN-capable, the egress and ingress of the SFC domain are acting as an 
ECN-capable transport. This approach will inherently support all known 
variants of ECN, including the
    experimental L4S capability [RFC8311  <https://tools.ietf.org/html/rfc8311>], [ecnL4S  <https://tools.ietf.org/html/draft-eastlake-sfc-nsh-ecn-support-02#ref-ecnL4S>].
...

             +-----------------+---------------+
             | Incoming Header |Departing NSH  |
             | (also equal to  |& Outer Headers|
             | departing Inner |               |
             |     Header)     |               |
             +-----------------+---------------+
             |    Not-ECT      |   ECT(0)      |
             |     ECT(0)      |   ECT(0)      |
             |     ECT(1)      |   ECT(1)      |
             |       CE        |     CE        |
             +-----------------+---------------+

On 15/01/2019 22:53, Bob Briscoe wrote:
> remember why we catered for L4S in the way written around table 2. 
> I've checked back, and I actually wrote this part myself, but it looks 
> wrong to me, which would be embarrassing. However, I need to check 
> with my co-authors to confirm that.
>

---

From: <[email-masked]>
Date: Tue, 22 Jan 2019 06:25:33 +0000

Hi Joel, 

What makes ECN specific in this regards compared to DSCP marking preservation? 

Cheers,
Med

> De : Joel M. Halpern [mailto:[email-masked]]
> Envoyé : vendredi 18 janvier 2019 15:55
> À : BOUCADAIR Mohamed TGI/OLN; Andrew G. Malis
> Cc : [email-masked]; [email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Jan 2019 07:30:44 -0500

(again: speaking personally)
DSCP behavior is VERY different from ECN behavior in terms of 
intermediate router modification.  DSCPs may get rewritten at certain 
specific places, but not generally at interior routers.  So mapping from 
the interior packet DSCP to the exterior packet DSCP and IEEE marking is 
normal and safe.  there is no need to reverse the process.  ECN marking 
needs to reverse the process due to the fact that individual routers are 
expected to change the marking based on local conditions.

At least thaat is how I understand it,
Joel

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 22 Jan 2019 16:57:57 +0200

Hi Bob,

Many thanks for the clarification.

Cheers,
Tal.

On Tue, Jan 22, 2019 at 2:05 AM Bob Briscoe <[email-masked]> wrote:

> Tal,
>
> I've conferred with my co-authors, and I can confirm that there is no need
> for a separate L4S mode, as incorrectly described around Table 2 in
> draft-02. It was actually me who wrote the incorrect text and table in the
> first place - my co-authors are wholly innocent, cos I'm the one developing
> the L4S experiment (L4S = Low Latency Low Loss Scalable throughput)! So
> thanks for asking how the two approaches interoperate, which made me notice
> this.
>
> congestion signals are propagated. L4S is purely a different AQM algorithm
> at network nodes and a different response algorithm at the source. As far
> as encap and decap are concerned, the tunnelling behaviours specified in
> RFC6040 and followed in the sfc-nsh-ecn draft inherently work for L4S just
> as well as for standard RFC3168 ECN. That's all the SFC WG needs to know.
>
> However, if you want to know a little more about how L4S works, the source
> distinguishes its packets by setting them to ECT(1), which an L4S node
> classifies into a distinct L4S queue. Any network node that doesn't support
> L4S will just handle these packets as if ECT(0) and ECT(1) mean the same
> (as required by the original ECN spec [RFC3168]). And the source has to
> detect such behaviour and respond accordingly
>    an ECN-Capable Transport. It MAY instead be set to ECT(1) if the NSH
>    domain supports the experimental L4S capability [RFC8311 <https://tools.ietf.org/html/rfc8311>], [ecnL4S <https://tools.ietf.org/html/draft-eastlake-sfc-nsh-ecn-support-02#ref-ecnL4S>].
> ...
>
>    set it to ECT(0). This indicates that, even though the end-to-end
>    transport is not ECN-capable, the egress and ingress of the SFC
>    domain are acting as an ECN-capable transport. This approach will
>    inherently support all known variants of ECN, including the
> Let me get back to you on this one. I have to admit that I can't remember
> why we catered for L4S in the way written around table 2. I've checked
> back, and I actually wrote this part myself, but it looks wrong to me,
> which would be embarrassing. However, I need to check with my co-authors to
> confirm that.
>

---

From: <[email-masked]>
Date: Wed, 23 Jan 2019 13:37:37 +0000

Hi Joel,

The point Joel is SFFs has to preserve whatever DSCP marking when encapsulating/encapsulation (including cases where transport encap changes).

If you will, we can describe the scenario using your words:  

=======
Consider an SFF that receives a packet with a transport DSCP marking
and an NSH header.  That SFF removes the transport header.  It then
(usually) sends the packet via some other means to an SF, and gets the
packet back.  After which it sends it on to the next SFF with a new
transport header carrying the NSH.
Let us take as given that we want to support DSCP marking preservation.
Then we need to somehow preserve the DSCP information that the SFF
receives.
==========

Cheers,
Med

> Envoyé : mardi 22 janvier 2019 13:31
> >> Objet : Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support
> in

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 23 Jan 2019 11:10:21 -0500

<no hat>
Maybe I am missing something important, but I would not expect SFF to 
exhibit the behavior you describe relative to DSCPs.

I do not know of any place where this is required for intra-domain 
tunnels.  It is an interesting issue for inter-domain usage of SFC.  But 
our scope is explicitly intra-domain.

As far as I know, DSCPs are not re-marked within a domain.  They are 
modified at entry / exit from a domain, but that is not an issue for an SFF.

Is there someplace where the behavior you are asking about is required 
by existing documents?

Yours,
Joel

---

From: <[email-masked]>
Date: Thu, 24 Jan 2019 06:39:12 +0000

Joel, 

DSCP preservation is a trivial requirement for intra-domain SFC. Please refer to https://tools.ietf.org/html/rfc2983: 

   When a tunnel is not end-to-end, there are
   circumstances in which it may be desirable to propagate the DSCP
   and/or some of the information that it contains to the outer IP
   header on ingress and/or back to inner IP header on egress.

One of the models discussed in 2983 assumes the following. 

   In this model, any packet has exactly one DS Field
   that is used for traffic conditioning at any point, namely the DS
   Field in the outermost IP header; any others are ignored.
   Implementations of this model copy the DSCP value to the outer IP
   header at encapsulation and copy the outer header's DSCP value to the
   inner IP header at decapsulation.

Because SFF is an encap/decpa function, it falls under the above implementations. 

Cheers,
Med

> Envoyé : mercredi 23 janvier 2019 17:10
> > The point Joel is SFFs has to preserve whatever DSCP marking when
> encapsulating/encapsulation (including cases where transport encap changes).
> >
> >>>>>       marking is limited to individual SFF-SFF links. rather than end-
> to-
> >> end.
> >>>>>
> >>>>>           I do think that ECN is naturally better handled at the
> transport
> >>>>>           encapsulation instead of the NSH itself.
> >>>>>
> >>>>>            > The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support
> in
> >>>> state
> >>>>>            > 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 adoption call will last 2 weeks, ending
> at
> >>>>>           the end of the

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 24 Jan 2019 08:39:51 -0500

<chair hat on>
Thank you for the citation Med.

I would like to hear from others in the working group as to whether they it.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 24 Jan 2019 09:02:34 -0500

<chair hat on>
Apparently I am having trouble typing this morning.

Do others understand the DiffServ RFCs to place this requirement on SFC?
I am also checking with some other folks who work regularly with DSCPs 
and the relevant RFCs.

Thank you,
Joel

On 1/24/19 8:39 AM, Joel M. Halpern wrote:
>> DSCP preservation is a trivial requirement for intra-domain SFC. 
>> Please refer to https://tools.ietf.org/html/rfc2983:
>>
>>> Objet : Re: [sfc] The SFC WG has placed 
>>>>>>>> Your point about the SFF preserving ECN is implementation 
>>>>>>>> dependent,
>>> for
>>>>>>>>        draft-eastlake-sfc-nsh-ecn-support in state "Candidate 
>>>>>>>> for WG
>>>>> Adoption"
>>>>>>>>
>>>>>>>>        Med,
>>>>>>>>
>>>>>>>>        stripped during SFF processing. In that case, the scope 
>>>>>>>> of the
>>> ECN
>>>>>>>>            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
>>>>>>>>            maintaining that separation cleaner as it was set in 
>>>>>>>> the arch
>>>>> RFC.
>>>>>>>>
>>>>>>>>            Thank you.
>>>>>>>>
>>>>>>>>            Cheers,
>>>>>>>>            Med
>>>>>>>>
>>>>>>>>             > -----Message d'origine-----
>>>>>>>>             > De : sfc [mailto:[email-masked]
>>>>>>>>             > Envoyé : jeudi 3 janvier 2019 06:11
>>>>>>>>             > À : [email-masked] <mailto:[email-masked]>;
>>>>>>>>             > [email-masked] <mailto:[email-masked]>
>>>>>>>>             > 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
>>>>>>>>             >
>>>>>>>>            
>>>>>>>>             >
>>>>>>>>             > 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
>>>>>>>>             > [email-masked] <mailto:[email-masked]>
>>>>>>>>             > https://www.ietf.org/mailman/listinfo/sfc
>>>>>>>>
>

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 26 Jan 2019 00:35:33 -0500

Hi Med,

See below.

>    header on ingress and/or back to inner IP header on egress.

So, I've read RFC 2983 and consulted with its author David Black. RFC
2983 is not a standards track or BCP RFP. It's just Informational. It
focuses on two models, the "uniform" model you describe below and the
"pipe model".

> Because SFF is an encap/decpa function, it falls under the above implementations.

RFC 2983 doesn't say anything about which model should be used by SFC
nor does it say which model should necessarily be used by an
"encap/decap function". I continue to believe that the pipe model,
which does not require any modification to the inner IP DSCP based on
an outer IP DSCP, is more appropriate for SFC.

The situation is quite different for ECN, as compared with DSCP. For
example, standards track RFC 6040 requires examination of both the
outer and inner ECN marking at egress and their combination (or
dropping the packet).

Thanks,
Donald

---

From: Loa Andersson <[email-masked]>
Date: Mon, 28 Jan 2019 10:08:14 +0800

Working Group,

I read the draft and tried to pin down the comments, as far as I can
see there is nothing in the current comments that bloack working group
adoption, everything could during normal working group process. I
actually prefer that it is done this way, rather that in the individual
document to better capture wg consensus. To this end the wg chairs may
want to include a note in the mail that close the adoption poll to say
what the outstanding issues to be solved by the wg are.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: <[email-masked]>
Date: Mon, 28 Jan 2019 08:39:26 +0000

Hi Donald, 

Please see inline. 

Cheers,
Med

> De : Donald Eastlake [mailto:[email-masked]]
> Envoyé : samedi 26 janvier 2019 06:36
> Cc : Joel M. Halpern; [email-masked];
> [email-masked]
> > DSCP preservation is a trivial requirement for intra-domain SFC. Please
> refer to https://tools.ietf.org/html/rfc2983:
> >
> 2983 is not a standards track or BCP RFP. It's just Informational.

[Med] Yes, but an interesting RFC as revealed by the wording used in some documents, e.g., 

draft-ietf-intarea-gue:
   "For instance, if an IP packet is being
   encapsualated in GUE then diffserv interaction [RFC2983] and ECN
   propagation for tunnels [RFC6040] SHOULD be followed."

or RFC8085:
   "Designing a tunneling mechanism requires significantly more expertise
   than needed for many other UDP applications, because tunnels are
   usually intended to be transparent to the endpoints transmitting over
   them, so they need to correctly emulate the behavior of an IP link
   [INT-TUNNELS], for example:

   o  Requirements for tunnels that carry or encapsulate using ECN code
      points [RFC6040].

   o  Usage of the IP DSCP field by tunnel endpoints [RFC2983]."

 It
> "encap/decap function".

[Med] Agree. I cited the uniform model because this is what is recommended in some networks to preserve QoS policies, see for example RFC6908.

 I continue to believe that the pipe model,
> an outer IP DSCP, is more appropriate for SFC.

[Med] This should be deployment-specific, IMO: the architecture should allow for both. 

If we focus on the pipe model, an SFF has to look into the inner header for diffserv matters. Then, if an SFF does that for DSCP, it can do it for ECN too without requiring duplicated functionality at the NSH level.

> > > Objet : Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-
> support in
> > > >>>>>       stripped during SFF processing. In that case, the scope of
> the
> > > ECN
> > > >>>>>           maintaining that separation cleaner as it was set in the
> arch
> > > >> RFC.
> > > >>>>>
> > > >>>>>           Thank you.
> > > >>>>>
> > > >>>>>           Cheers,
> > > >>>>>           Med
> > > >>>>>
> > > >>>>>           https://datatracker.ietf.org/doc/draft-eastlake-sfc-nsh-
> ecn-
> > > >>>> support/
> > > >>>>>            >
> > > >>>>>            > Comment:
> > > >>>>>            > 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

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 30 Jan 2019 21:14:35 -0500

I guess that at this point it depends mostly on how often you think
the different circumstances will occur.

I don't think people will use outer DSCP marking that much in SFC
domains. While it is plausible for the egress SFF to change the DSCP,
I think it would only rarely depend on how an outer DSCP was
manipulated across the SFC domain. If I am correct then it is
significantly more effort to handle ECN between the outer and inner
IP.

Maybe we need to make competing presentations and see which way the
room hums in Prague...

Thanks,
Donald

On Mon, Jan 28, 2019 at 3:39 AM <[email-masked]> wrote:
> > support
> > > > support