Subject: [sfc] draft-eastlake-sfc-nsh-ecn-support

From: <[email-masked]>
Date: Tue, 17 Jul 2018 18:57:40 +0000

Dear authors,

I read this draft but it is unclear to me why ECN-related bits have to be mirrored in the NSH. IMO, if any congestion handling is needed, this should be left to the transport encapsulation rather than creating a cascading model like the one proposed in the draft.

Is there any value in disseminating the congestion notification in NSH while this can be by the transport encapsulation scheme?

Thank you.

Cheers,
Med

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 17 Jul 2018 15:11:23 -0400

Med,

We can go into this more during the presentation, but not all transports
have native ECN markings.

Cheers,
Andy

On Tue, Jul 17, 2018 at 2:57 PM, <[email-masked]> wrote:

> Dear authors,
>
>
>
> I read this draft but it is unclear to me why ECN-related bits have to be
> mirrored in the NSH. IMO, if any congestion handling is needed, this should
> be left to the transport encapsulation rather than creating a cascading
> model like the one proposed in the draft.
>
>
>
> Is there any value in disseminating the congestion notification in NSH
> while this can be by the transport encapsulation scheme?
>
>
>
> Thank you.
>
>
>
> Cheers,
>
> Med
>

---

From: <[email-masked]>
Date: Tue, 17 Jul 2018 19:21:05 +0000

Re-,

Thank you, Andy.

Shouldn’t this be fixed for each of these encap schemes (e.g., draft-ietf-tsvwg-rfc6040update-shim)?

Cheers,
Med

De : Andrew G. Malis [mailto:[email-masked]]
Envoyé : mardi 17 juillet 2018 15:11
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]; [email-masked]
Objet : Re: draft-eastlake-sfc-nsh-ecn-support

Med,

We can go into this more during the presentation, but not all transports have native ECN markings.

Cheers,
Andy

On Tue, Jul 17, 2018 at 2:57 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Dear authors,

Thank you.

Cheers,
Med

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 17 Jul 2018 16:15:35 -0400

Hi Med,

I feel that carrying ECN in the NSH is the most robust.

- If you try to just carry it in the outer transport header, that requires
that ECN be preserved through all boxes, even say an SFF that receives with
one transport and sends with a different transport. Since all boxes inside
the SFC domain have to preserve ECN, it is kind of delicate and you really
can't do incremental deployment in the interior.

- If you try to not have it in the NSH but preserve it in the inner payload
transport header, copying to the outer transport and combining back into
the inner transport, then if the ultimate source to final destination path
does not support ECN, you can't do ECN to manage congestion within the SFC
domain without further mechanisms.

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

On Tue, Jul 17, 2018 at 3:21 PM, <[email-masked]> wrote:

> *De :* Andrew G. Malis [mailto:[email-masked]]
> *Envoyé :* mardi 17 juillet 2018 15:11
> *À :* BOUCADAIR Mohamed IMT/OLN
> *Cc :* [email-masked]; [email-masked]
> *Objet :* Re: draft-eastlake-sfc-nsh-ecn-support
>
>
>
> Med,
>
>
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 17 Jul 2018 17:04:19 -0400

Med,

In section 5, that draft supports the use of our draft for the NSH (see the
bottom of page 8).

Cheers,
Andy