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
From: BESS <[email protected]> on behalf of "[email protected]"
<[email protected]>
Date: Monday, November 9, 2020 at 12:20 AM
To: "[email protected]" <[email protected]>,
"[email protected]"
<[email protected]>
Subject: [bess] 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.
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/
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
