Hi Med,
Thank you very much for the great review!
Revision 17 addresses these two comments (in addition to Ketan’s remarks):
---
# Logging
CURRENT:
If multiple instances of the D-PATH attribute are present, all
instances other than the first MUST be discarded, and the
UPDATE message MUST continue to be processed, as per
[RFC7606].
Can we mention that this event is logged at least once?
[jorge] we want to be consistent with RFC7606 when multiple instances of an
attribute exist, and that includes the logging considerations in RFC7606. Let
us know if that is not ok.
[Med] Can we remind that in the text?
[jorge] NEW:
"The D-PATH Path Attribute MUST NOT appear more than once in the Path
Attributes of a given BGP UPDATE message. If multiple instances of the D-PATH
attribute are present, all instances other than the first MUST be discarded,
and the UPDATE message MUST continue to be processed. This behavior follows
[RFC7606], including the associated logging considerations."
---
## Section 3
I’m curious which logic is used for the ordering of the terms in this section.
[jorge] we kept adding terms based on what was needed, the terms were normally
added together in groups. But we can sort them better if the editor prefers
that.
[Med] I would sort them for reader’s convenience.
[jorge] Done.
---
Thanks.
Jorge
From: [email protected] <[email protected]>
Date: Monday, March 2, 2026 at 4:19 AM
To: Jorge Rabadan (Nokia) <[email protected]>, The IESG <[email protected]>
Cc: [email protected] <[email protected]>, [email protected] <[email protected]>,
[email protected]
<[email protected]>, [email protected]
<[email protected]>
Subject: RE: Mohamed Boucadair's Discuss on
draft-ietf-bess-evpn-ipvpn-interworking-15: (with DISCUSS and COMMENT)
Hi Jorge, all,
Thank you for the follow-up and for taking care of the review. I also checked
-15/16 diff. I like the changes.
I will update my ballot and let you decide whether to implement changes per the
comments below.
Please see inline.
Cheers,
Med
De : Jorge Rabadan (Nokia) <[email protected]>
Envoyé : samedi 28 février 2026 22:36
À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; The IESG
<[email protected]>
Cc : [email protected]; [email protected];
[email protected]; [email protected]
Objet : Re: Mohamed Boucadair's Discuss on
draft-ietf-bess-evpn-ipvpn-interworking-15: (with DISCUSS and COMMENT)
Hi Mohamed,
Thanks for your through review!
Revision 16 addresses your comments. Please let us know if that clears your
DISCUSS.
Please see some comments in-line with [jorge].
Thx
Jorge
From: Mohamed Boucadair via Datatracker
<[email protected]<mailto:[email protected]>>
Date: Tuesday, January 20, 2026 at 2:02 AM
To: The IESG <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Subject: Mohamed Boucadair's Discuss on
draft-ietf-bess-evpn-ipvpn-interworking-15: (with DISCUSS and COMMENT)
CAUTION: This is an external email. Please be very careful when clicking links
or opening attachments. See the URL nok.it/ext for additional information.
Mohamed Boucadair has entered the following ballot position for
draft-ietf-bess-evpn-ipvpn-interworking-15: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-ipvpn-interworking/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Hi Jorge, Ali, Eric, John, Wen ,Jim, and Adam,
Thank you for the effort put into this specification.
Thanks to Qin Wu for the OPSDIR review. See a related point below.
The specification is dense but reads well, overall. The document also includes
several examples for illustration, which is really helpful.
However, I found it a bit unfortunate that protocol machinery aspects are mixed
with operational considerations. Separating those would be an enhancement
(e.g., such as the approach followed in RFC 9135). I’m not insisting to make a
change, but would be happy if you decide to do so :-)
Please find below points for DISCUSSion, some of them are process-related.
# Process Items
## IETF Last Call Comments
Unless I’m mistaken, I don’t see a follow-up or replies to comments received
during the IETF LC. I see at least the comments from Qin are unanswered. I’m
not echoing some of the points raised there (e.g., update or not of the base
BGP spec) as I think that discussion belong to the IETF LC comments.
[jorge] Revision 16 addresses all the comments. We have responded to all
reviewers, providing our resolutions and expressing our appreciation for their
valuable comments.
[Med] Thank you
## Use of documentation values
The document includes several examples that with ASN (e.g., Section 6.2). These
examples should be updated to make use of the range defined in RFC5398 per the
following from an IESG statement on the matter [1]:
“Authors must use reserved values for documentation in the usage examples
whenever such a range is available for a type covered by the documentation.”
[jorge] changed the ASNs to values reserved for documentation.
[Med] ACK
# D-PATH Internal structure
CURRENT:
Octets v
0 1 2 3 4 5 6
+-----------------------+-----------+
| Global | Local |
| Admin | Admin |
+-----------------------+-----------+
Figure 6: D-PATH Domain Segment
Why providing the internal structure of domain-ids is needed? Which problems
are we solving by requiring this split? Of course, Operators can adopt an
internal structure if they which so, but I’m not sure that is something that
needs to be signaled in the protocol itself.
Implementations (especially at the receiver side) should not associate any
meaning with these bits.
Also, note that getting rid of the split would also help soften issues related
to leak of local information that can be inferred from the domain-ID.
[jorge] you are right that there is no especial meaning for the receiver, other
than comparing the domain-id value with the local ones. However, the authors
agreed that defining a structured format, as described above, provides
operational benefits. In particular, it allows operators to encode geographic
or administrative information if desired, facilitates troubleshooting when
inspecting routes in the RIB-In, and helps ensure DOMAIN-ID uniqueness across
domains. Furthermore, all current field deployments and implementations use
this structured format when configuring the DOMAIN-ID. We believe that adopting
a common convention improves operational consistency and simplifies
configuration for operators.
[Med] ACK. Note that all these benefits can still be provided without having
this split, but I understand that this is already implemented and as such.
# Complexity
CURRENT:
If the act of prepending
a new domain causes an overflow in the domain segment (i.e.,
more than 255 domains), the local gateway PE MUST prepend a
new segment and prepend its own domain to this new segment.
The specification includes a provision for multiple segment, each segment with
up to 255 domains. This adds a complexity to implementations and also can
trigger misbehaviors of intermediate nodes that may present a very lengthy list
of segments.
Do we have or envisage cases where a communication may include 255 interworking
PEs?
[jorge] D-PATH is defined for use with two specific SAFIs and, as described in
this document, is intended for “walled garden” inter-domain scenarios. Also,
the mechanism has been deployed for several years, and operational experience
indicates that the number of domains carried in a given ISF route is typically
limited to a small number.
[Med] Thanks for confirming.
In the initial design discussions, only a single domain segment was permitted.
However, early WG feedback indicated the need for a future-proof encoding that
avoided a 255-domain limitation.
[Med] Not sure this will be needed in the future, but let’s see.
# Consistency
CURRENT:
2. The gateway PE MAY advertise that ISF route with a D-PATH
attribute into one or more of its configured domains,
or
* In the above example, if the EVPN route is received without
D-PATH, the gateway PE will add the D-PATH attribute with one
segment {length=1, <6500:1:EVPN>} when re-advertising to
domain 6500:2.
These parts (and other similar constructs in the draft) assume that D-PATH will
automatically be added, while this is subject to explicit configuration per:
CURRENT:
By default, the BGP D-PATH attribute is not
advertised and MUST be explicitly enabled by configuration on the
Gateway PEs.
Such text (and similar) should state that ,”assuming this is explicitly
configured per Section X”.
[jorge] ok, added this in all the cases in section 4.
[Med] ACK
# Behavior Ambiguity
There are several parts of the spec which leaves it unspecified when a given
behavior is safe to ignore. An example is provided below:
CURRENT:
The Gateway PE SHOULD NOT copy the above Extended Community types
from the original ISF route into the re-advertised ISF route.
I’m not listing all of those, but I trust the authors will check through the
doc.
[jorge] ok. For this one, we clarified the text:
NEW:
The Gateway PE SHOULD NOT copy the above Extended Community types in "a", "b"
and “c" from the original ISF route into the re-advertised ISF route. Certain
Extended Communities may influence how the receiving PE processes the route.
Propagating such attributes into another domain could therefore lead to
unintended behavior. For example, if the BGP Encapsulation Extended Community
is propagated into a destination domain that uses a different encapsulation, a
receiving PE in that domain might interpret the label field of the EVPN ISF
route according to an encapsulation context that does not apply locally
[RFC8365]. This could result in the route being discarded or programmed with
incorrect encapsulation parameters.
[Med] This is great, thanks.
# Behavior conflict
CURRENT:
However,
the following Extended Community types SHOULD NOT be propagated::
a. BGP Encapsulation Extended Communities, as defined in
[RFC9012].
b. Route Target Extended Communities. Route Targets MUST NOT be
propagated and MUST be re-initialized when re-advertising the
ISF route into a different domain. The re-initialized Route
Target value MAY or MAY NOT match the value used in the
original route.
There is a conflict between the normative language in the preamble and the one
specific in the second bullet. Please fix that.
[jorge] good catch, fixed now.
[Med] ACK
# DOMAIN-ID unicity
CURRENT:
That is, a route is considered looped if it contains
at least one DOMAIN-ID that matches any local DOMAIN-ID
configured on the Gateway PE, regardless of the ISF_SAFI_TYPE
value.
How unicity of domain-ids of involved domains is supposed to be ensured?
[jorge] The uniqueness of the domain-ids should be guaranteed by the operator’s
proper configuration. The structure given to the domain-id may help them to
that end. We added this text:
NEW
The IP-VRF of a Gateway PE that interconnects two domains is associated with
two distinct DOMAIN-IDs, one per domain. These DOMAIN-IDs MUST be different
(e.g., 6500:1 for EVPN and 6500:2 for IPVPN). Each domain MUST be identified by
a unique DOMAIN-ID. All Gateway PEs attached to the same domain MUST use the
same DOMAIN-ID value to represent that domain.
[Med] This is indeed better. Thanks.
# RFC4659 is normative
This is actually needed for VPN-IPv6 AF. Specifically, this is needed for this
SHOULD:
CURRENT:
Implementations SHOULD apply the
relevant error-handling rules specified for each supported route
type. Applicable references include::
BGP IP routes: [RFC4760], [RFC8950].
IPVPN routes: [RFC4364], [RFC4659].
[jorge] fixed
[Med] ACK
# draft-ietf-idr-wide-bgp-communities
This I-D is normative as it is needed, for example, in the following:
CURRENT:
When advertising the route into a different domain,
the gateway PE SHOULD propagate only the following set of
attributes. All other Path Attributes SHOULD NOT be propagated:
* AS_PATH
* D-PATH (only when advertising IPVPN [SAFI 128] or EVPN routes)
* IBGP-only attributes (when advertising to IBGP peers):
LOCAL_PREF, ORIGINATOR_ID, CLUSTER_ID
* MULTI_EXIT_DISC (MED)
* AIGP
* COMMUNITY, EXTENDED_COMMUNITY, LARGE_COMMUNITY, and
WIDE_COMMUNITY (as defined in
[I-D.ietf-idr-wide-bgp-communities]), except where explicitly
excluded in Item 4 below.
[jorge] fixed
[Med] ACK
## Also, please add a normative reference for AIGP (RFC 7311).
[jorge] fixed
[Med] ACK
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
# Interconnection mapping
Clarify early in the document whether an interco PE can be multi-homed or is
1:1 assumed?
[jorge] We added text in section 3 to clarify that a composite, gateway or
composite/gateway PE can interconnect more than two domains.
[Med] Thanks
# Inter-connection & bidirectionality
You may consider whether symmetric or asymmetric interco PEs are supported by
the model.
[jorge] PEs that follow these procedures advertise and process ISF routes in
accordance with the existing specifications. The best-path selection and
forwarding decisions remain unchanged. As a result, symmetric or asymmetric
traffic behavior depends solely on how the PEs perform routing and forwarding
under the existing specifications. For the moment we assume there is no need to
indicate that, but let us know otherwise, please.
[Med] I do see a value in mentioning this in the text, but leave it to you to
decide.
# DOMAIN-IDs in Section 3
The configuration of DOMAIN-IDs is mentioned at least twice in this section:
CURENT:
A gateway PE is always configured with multiple DOMAIN-
IDs.
And
A Gateway PE follows the procedures defined in Section 8. A
gateway PE is always configured with multiple DOMAIN-IDs.
These mentions seems to be provided too early on the document. At least the
following is not clear at this stage:
## Should the interco procedure be disable if no DOMAIN-ID is provided?
[Med] Any thought about this one?
## Should these IDs be bound to a specific network, interface, etc.?
[jorge] ok, we removed that and made sure it is specified later.
[Med] ACK
# ISF_SAFI_TYPE for correct service verification
CURRENT:
The ISF_SAFI_TYPE field is informational and
does not have any impact on the loop detection or BGP Path
selection procedures.
Conveying ISF_SAFI_TYPE is useful for operations as this can be used to check
that intended interworking is in place. Maybe consider adding a note about such
use (even as an example).
[jorge] Added:
NEW:
Encoding the ISF_SAFI_TYPE provides operational benefits, as it allows
operators to verify that the intended interworking is in place and that the
route has traversed the expected domains using the intended ISF SAFIs in each
domain.
[Med] Thank you.
# Provisions for topology hiding
CURRENT:
Intermediate entries
in the list are domains that the ISF IPVPN or EVPN route has
transited.
Are there deployment cases where intermediate domains would not need to reveal
their presence of leaf domains?
[jorge] we don’t see any. Intermediate domains need to be revealed in D-PATH so
that the loop procedures and best path selection procedures work.
[Med] OK.
# Logging
CURRENT:
If multiple instances of the D-PATH attribute are present, all
instances other than the first MUST be discarded, and the
UPDATE message MUST continue to be processed, as per
[RFC7606].
Can we mention that this event is logged at least once?
[jorge] we want to be consistent with RFC7606 when multiple instances of an
attribute exist, and that includes the logging considerations in RFC7606. Let
us know if that is not ok.
[Med] Can we remind that in the text?
# Automatic behavior are problematic
CURRENT:
1. Upon receiving an ISF route, the gateway PE imports the route
into the associated IP-VRF and stores the original BGP Path
Attributes.
For this part (and similar one), please add “assuming no validation error is
encountered and absent a policy otherwise”
[jorge] added.
[Med] Thanks
# Nits
## Introduction
OLD: This document defines the concept of an Interworking PE Section 3,
NEW: This document defines the concept of an Interworking PE (Section 3),
[jorge] fixed.
[Med] ACK
## Section 3
I’m curious which logic is used for the ordering of the terms in this section.
[jorge] we kept adding terms based on what was needed, the terms were normally
added together in groups. But we can sort them better if the editor prefers
that.
[Med] I would sort them for reader’s convenience.
## Figure 1
A “+” near “Eth-Tag x” which needs to be “|”
OLD:
----------------------*Bridge | | +------
| | | |Table(BT1)| | +-----------+ / \ \
MPLS/NVO tnl +-------->| *---------* |<--> | Eth |
-------+ | | | |Eth-Tag x + |IRB1| | \ / /
/ Eth / \<-+ | | +----------+ | | | +------
NEW:
----------------------*Bridge | | +------
| | | |Table(BT1)| | +-----------+ / \ \
MPLS/NVO tnl +-------->| *---------* |<--> | Eth |
-------+ | | | |Eth-Tag x | |IRB1| | \ / /
/ Eth / \<-+ | | +----------+ | | | +------
## Figure 1
CURRENT:
| +------------------+ | SAFIs |
| | 1 +---+ |
-------------------------------------------------+ 128 |BGP| |
| EVPN +---+ |
For consistency with other SAFIs, listing 70 would be more appropriate than the
label.
[jorge] fixed both things.
[Med] ACK
## ISF SAFI
When first reading this, it can be misinterpreted as this is about defining a
new SAFI, while this is more an alias.
[jorge] added:
NEW
The term “ISF SAFI” does not denote a new SAFI. Rather, it is used as a
collective reference to the group of SAFIs mentioned earlier.
[Med] Thanks.
## Change all “PE device” to “PE”
## Idem, change “CE device” to “CE”
[jorge] fixed both things.
[Med] ACK
## "peering domain level”
Peering has a specific when interconnecting domains. Unless you add a
qualifier, I would change to “domain interconnection level” or similar.
[jorge] ok, done.
[Med] ACK
## Add a note somewhere near the figure that “tnls” or “tnl” refer to
“tunnel(s)”.
[jorge] ok, done.
[Med] ACK
## ::
OLD: SHOULD NOT be propagated::
NEW: SHOULD NOT be propagated:
OLD: Applicable references include::
NEW: Applicable references include:
[jorge] fixed both things.
[Med] ACK
## optional means that this is not required
OLD:
While not required, prioritizing the advertisement of
the EVPN route before the IPVPN route is an OPTIONAL
optimization.
NEW:
Prioritizing the advertisement of
the EVPN route before the IPVPN route is an OPTIONAL
optimization.
[jorge] ok, done.
[Med] ACK.
Cheers,
Med
[1]
https://datatracker.ietf.org/doc/statement-iesg-statement-on-assignable-codepoints-for-examples-in-ietf-specifications/
____________________________________________________________________________________________________________
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.
_______________________________________________
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
