Subject: [bess] WGLC and IPR poll on draft-ietf-bess-evpn-ipvpn-interworking-03

From: <[email-masked]>
Date: Mon, 9 Nov 2020 09:19:53 +0100

Hello WG,

This email starts a three weeks Working Group Last Call on
draft-ietf-bess-evpn-ipvpn-interworking-03 [1]. We add an additional week
due to the upcoming IETF meeting.

This poll runs until * the 30th Of  November *.

We are also polling for knowledge of any undisclosed IPR that applies to
this Document, to ensure that IPR has been disclosed in compliance with IETF
IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this Document please
respond to this email and indicate whether or not you are aware of any
relevant undisclosed IPR. The Document won't progress without answers from
all the Authors and Contributors. 

There is currently no IPR disclosed.

If you are not listed as an Author or a Contributor, then please explicitly
respond only if you are aware of any IPR that has not yet been disclosed in
conformance with IETF rules.

We are also polling for any existing implementation as per [2]. 

Thank you,

Stephane & Matthew

[1]
<https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-ipvpn-interworking/>
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-ipvpn-interworking/

[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Tue, 10 Nov 2020 14:10:15 +0000

Hi,

The document is ready to progress.
I’m not aware of any related IPR.

Thank you.
Jorge

From: [email-masked] <[email-masked]>
Date: Monday, November 9, 2020 at 9:20 AM
To: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: WGLC and IPR poll on draft-ietf-bess-evpn-ipvpn-interworking-03
Hello WG,

This email starts a three weeks Working Group Last Call on draft-ietf-bess-evpn-ipvpn-interworking-03 [1]. We add an additional week due to the upcoming IETF meeting.

We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this Document please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR. The Document won't progress without answers from all the Authors and Contributors.

If you are not listed as an Author or a Contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

Thank you,

Stephane & Matthew

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-ipvpn-interworking/
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Tue, 10 Nov 2020 15:18:03 +0000

Support progressing this document.

From: BESS <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Monday, November 9, 2020 at 12:20 AM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [bess] WGLC and IPR poll on draft-ietf-bess-evpn-ipvpn-interworking-03

Hello WG,

Thank you,

Stephane & Matthew

---

From: John E Drake <[email-masked]>
Date: Tue, 10 Nov 2020 16:14:21 +0000

Support and I'm not aware of any IPR

Yours Irrespectively,

John

Juniper Business Use Only
From: [email-masked] <[email-masked]>
Sent: Monday, November 9, 2020 3:20 AM
To: [email-masked]; [email-masked]
Subject: WGLC and IPR poll on draft-ietf-bess-evpn-ipvpn-interworking-03

[External Email. Be cautious of content]

Hello WG,

Thank you,

Stephane & Matthew

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-ipvpn-interworking/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-evpn-ipvpn-interworking/__;!!NEt6yMaO-gk!Udv1wWTrY2Bgrrn0X26A27BpuOpWNk_oCga90EDbojQIcSToUq32-XvDIG8Isnk$>
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw__;!!NEt6yMaO-gk!Udv1wWTrY2Bgrrn0X26A27BpuOpWNk_oCga90EDbojQIcSToUq32-XvD2wiLS7c$>

---

From: Neeraj Malhotra <[email-masked]>
Date: Tue, 10 Nov 2020 11:05:59 -0800

Hi,

Support.

Thanks,
Neeraj

On Mon, Nov 9, 2020 at 12:20 AM <[email-masked]> wrote:

> this Document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> If you are not listed as an Author or a Contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>

---

From: "Dhananjaya Rao (dhrao)" <[email-masked]>
Date: Mon, 30 Nov 2020 05:08:47 +0000

I support the publication of this draft.

I do have a few proposed updates to the draft that would help clarify aspects of usage of the Domain-Path. I’ve noted them below for the co-authors to consider.

Section 3.

1.      About the BGP D-PATH attribute:
a)      ….
Old: This attribute list may contain zero, one or more segments.

New: This attribute list may contain one or more segments.

2.      c)
Old: The gateway PE MUST NOT add the D-PATH attribute to ISF routes generated for IP-VRF prefixes that are not learned via any ISF SAFI, for instance, local prefixes.

New: A gateway PE can generate ISF routes for IP-VRF prefixes that are not learned via any ISF SAFI, for instance, local prefixes (such as OSPF or static). It may distribute the routes to other GW-PEs via an ISF SAFI in one domain, considered to be the originating domain. Hence, it MAY add the D-PATH attribute to ISF routes advertised in an ISF SAFI to other domains, in order to prevent the route from looping back into the originating domain via the other GW-PEs.

3.      d)
Old: An ISF route received by a gateway PE with a D-PATH attribute that contains one or more of its locally configured domains for the IP-VRF is considered to be a looped ISF route and MUST be dropped.

New: An ISF route received by a gateway PE with a D-PATH attribute that contains one or more of its locally configured domains for the IP-VRF is considered to be a looped ISF route and not installed in that IP-VRF nor re-advertised from it.

4.      e)
Old: The number of domains in the D-PATH attribute indicates the number of gateway PEs that the ISF route update has transited.

New: The number of domains in the D-PATH attribute indicates the number of tenant IP-VRFs on gateway PEs that the ISF route update has transited.

5.      f)
Old: None

New: For ease of configuration, a Domain-ID value on a GW-PE may be assigned globally for a peering domain in which case it applies to all tenant networks for that domain. However, a Domain-ID may be scoped granularly for an individual tenant IP-VRF. One example where a per-IP-VRF domain-ID assignment is necessary is when routes received from one domain are leaked from one IP-VRF to another and re-advertised back to the same domain, where it must be accepted and not treated as a looped route in the new tenant IP-VRF.

Example :
                  VPN [Domain1] ----  GWPE1  ----  EVPN [Domain2] ----- GWPE2
                              ID-6500:1        VRF11             ID-6500:2                    VRF21  ----
                                                                                                                                        | (route-leak)
                              ID-6500:4        VRF12             ID-6500:3                   VRF22  -----

[Note for authors : This point is to remove ambiguity about the scope of the Domain-ID.
f) could be swapped in order with e) ]

Section 3.1

6.      Old: Gateway GW1 flags the SAFI 128 route as a loop, and does not re-advertise it …
New: Gateway GW1 flags the SAFI 128 route as a loop in the tenant IP-VRF, and does not re-advertise it…

Regards,
-Dhananjaya

Hello WG,

Thank you,

Stephane & Matthew