Wen, the blue text is the reverted text and the red text is the additional
clarification:
“When the timer expires, each PE builds an ordered list of the IP
addresses of all the PE nodes connected to the Ethernet segment
(including itself), in increasing numeric value. Each IP address
in this list is extracted from the "Originating Router's IP
address" field of the advertised Ethernet Segment route. In
case of
the Ethernet Segment consisting of PEs with a mix of IPv4 and
IPv6 Originating
Router's IP addresses, such list is sorted by IPv4 addresses
first
and then followed by IPv6 addresses since the value of a unique
IPv6 address
(regardless of its type - Unique Local Address or Globally
Unique Address)
is always bigger than the value of an IPv4 address.”
Cheers,
Ali
From: Wen Lin <w...@juniper.net>
Date: Monday, June 3, 2024 at 6:26 PM
To: Ali Sajassi (sajassi) <sajassi=40cisco....@dmarc.ietf.org>, Luc André
Burdet <laburdet.i...@gmail.com>, Ali Sajassi (sajassi) <saja...@cisco.com>,
bess@ietf.org <bess@ietf.org>
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
@ Luc, Thanks for the link.
@Ali, I agree this implementation specific, it does not change the outcome of
the DF election result. It seems to be better to revert to the original text to
avoid confusion.
Thanks,
Wen
Juniper Business Use Only
From: Ali Sajassi (sajassi) <sajassi=40cisco....@dmarc.ietf.org>
Date: Monday, June 3, 2024 at 11:31 AM
To: Luc André Burdet <laburdet.i...@gmail.com>, Wen Lin <w...@juniper.net>, Ali
Sajassi (sajassi) <saja...@cisco.com>, bess@ietf.org <bess@ietf.org>
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
[External Email. Be cautious of content]
Luc,
That is the matter of implementation and in standards we don’t specify how the
implementation should be done! A given standard should specify the outcome and
the behavior in enough detailed level that there is no room for ambiguity or
misinterpretation but not a specific implementation. You don’t need to know the
type of the IPv6 address in order to perform the comparison. The point was that
any valid IPv6 address type used for the Originating router’s IP address has
the first byte as non-zero and thus the value of IPv6 address is always bigger
than the value of IPv4 address.
Wen,
I will revert the text back to what it was before with the additional
clarifications that I mentioned in my previous emails. As I mentioned
previously, the modified text in section 8.5 is not a new algorithm or
mechanism but rather was done only for clarifications; however, it apparently
caused some confusion because of getting into a specific implementation.
Cheers,
Ali
Juniper Business Use Only
From: Luc André Burdet <laburdet.i...@gmail.com>
Date: Monday, June 3, 2024 at 6:08 AM
To: Wen Lin <wlin=40juniper....@dmarc.ietf.org>, Ali Sajassi (sajassi)
<saja...@cisco.com>, Ali Sajassi (sajassi)
<sajassi=40cisco....@dmarc.ietf.org>, bess@ietf.org <bess@ietf.org>
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
Hi Wen, Ali,
The addition came from the following discussion:
https://mailarchive.ietf.org/arch/msg/bess/Afnejmi8rOkcrUY55E4YRGD2jkM/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/bess/Afnejmi8rOkcrUY55E4YRGD2jkM/__;!!NEt6yMaO-gk!COHTUv-jVa066HqrIQsQIob1VbKfG_QoO0azp2kkQfV85AyvY4rQ452vCZZUBtRnUwsxFodd-e7GrZ4gGddYlIX96nHYuA$>
In short, the question was how does one “compare” 4 octets to 16 octets.
> IPv4 read 4 octets as unsigned integer and IPv6 is considered as 16 octet
> unsigned integer.
The update’s intent is to make explicit the comparison by stating all 4-octet
values are “numerically smaller (4<16)” than any 16-octet Originating IP
(regardless of known-values, ULA, GUA) before comparing like-to-like dimensions.
Regards,
Luc André
Luc André Burdet | Cisco | laburdet.i...@gmail.com | Tel: +1 613 254 4814
From: Wen Lin <wlin=40juniper....@dmarc.ietf.org>
Date: Thursday, May 30, 2024 at 23:31
To: Ali Sajassi (sajassi) <saja...@cisco.com>, Ali Sajassi (sajassi)
<sajassi=40cisco....@dmarc.ietf.org>, bess@ietf.org <bess@ietf.org>
Subject: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
Hi Ali,
Thank you for the investigation. I think it will be good to specify the
followings:
1. changing the ordered list from IP address only to a tuple of IP address
length and IP address does not change the DF election result.
2. the reason for introducing the above change.
Thanks,
Wen
Juniper Business Use Only
From: Ali Sajassi (sajassi) <saja...@cisco.com>
Date: Thursday, May 30, 2024 at 11:13 PM
To: Wen Lin <w...@juniper.net>, Ali Sajassi (sajassi)
<sajassi=40cisco....@dmarc.ietf.org>, bess@ietf.org <bess@ietf.org>
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
[External Email. Be cautious of content]
Hi Wen,
Both texts say basically the same thing and translate into the same outcome
(7432bis is just a clarification). If you think they don’t, please explain why
not or provide an example. Basically both text say that if you have a mix of
IPv4 and IPv6 addresses in a list, sort IPv4 addresses first and then IPv6
addresses (as I said in my previous email). IPv4 values should always be less
than IPv6 values for all three types of IPv6 addresses (i.e., ULA, LLA, and
GUA).
Cheers,
Ali
Juniper Business Use Only
From: Wen Lin <w...@juniper.net>
Date: Thursday, May 30, 2024 at 11:46 AM
To: Ali Sajassi (sajassi) <sajassi=40cisco....@dmarc.ietf.org>, bess@ietf.org
<bess@ietf.org>, Ali Sajassi (sajassi) <saja...@cisco.com>
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
Hi Ali,
Thanks for your explanation.
To illustrate the differences between RFC7432 and RFC7432-bis, I have included
excerpts from both documents below. To constructing an ordered list under
RFC7432, we only extract “Originating Router's IP address" field of the
advertised Ethernet Segment route, while under RFC7432-bist, we extract both
the "IP Address length" and "Originating Router's IP address" fields of the
advertised Ethernet Segment route. IMHO, some text to explain whether there
is any interop issue will be helpful.
RFC7432:
“…each PE builds an ordered list of the IP addresses of all the PE nodes
connected to the Ethernet segment (including itself), in increasing numeric
value. Each IP address in this list is extracted from the "Originating
Router's IP address" field of the advertised Ethernet Segment route. Every PE
is then given an ordinal indicating its position in the ordered list, starting
with 0 as the ordinal for the PE with the numerically lowest IP address. “
RFC7432-bis:
“… each PE builds an ordered list of the IP addresses of all the PE nodes
connected to the Ethernet segment (including itself), in increasing numeric
value. Each IP address in this list is extracted from the "IP Address length"
and "Originating Router's IP address" fields of the advertised Ethernet Segment
route. Every PE is then given an ordinal indicating its position in the ordered
list, starting with 0 as the ordinal for the PE with the lowest IP address
length and numeric value tuple. The tuple list is ordered by the IP address
length first and IP address value second. “
Thanks,
Wen
Juniper Business Use Only
From: Ali Sajassi (sajassi) <sajassi=40cisco....@dmarc.ietf.org>
Date: Thursday, May 30, 2024 at 1:13 PM
To: Wen Lin <w...@juniper.net>, bess@ietf.org <bess@ietf.org>, Ali Sajassi
(sajassi) <saja...@cisco.com>
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
[External Email. Be cautious of content]
Hi Wen,
The text in RFC7432bis for section 8.5 is basically a clarification to RFC7432
and has been around for several years (i.e., introduced in 2021) to ensure that
the order list for DF election is uniformly formed among all the participating
PEs in the redundancy group. The intention of RFC7432 was always to allow a mix
of IPv4 and v6 in the DF list. So, if the RFC7432 was implemented as intended,
then there is no interop or backward compatibility issue (i.e., sort the list
based on v4 first and then v6 and further more based on the lowest value
first). And if it wasn’t, then we would have an interop issue for those
implementation of RFC7432 (i.e., it would be an interop issue and NOT backward
compatibility issue!).
Cheers,
Ali
Juniper Business Use Only
From: Wen Lin <wlin=40juniper....@dmarc.ietf.org>
Date: Thursday, May 30, 2024 at 7:32 AM
To: Ali Sajassi (sajassi) <saja...@cisco.com>, bess@ietf.org <bess@ietf.org>,
i-d-annou...@ietf.org <i-d-annou...@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
Hi Ali,
Under RFC7432, the ordered list used for electing the DF/BDF is formed based
solely on the numerical value of each router’s IP address, the originating
router’s IP address. RFC7432-bis introduces a refinement, i.e., the ordered
list is now formed based on the tuple of each router’s IP address length and
its numerical value.
It would be helpful to add some text to clarify whether there is any backward
combability issue if we have a mixed of IPv4 and IPv6 addresses for the
originating router’s IP addresses in the network and with some routers running
DF election based on RFC7432 and others based on RFC7432-bis.
Thanks,
Wen
Juniper Business Use Only
From: Ali Sajassi (sajassi) <sajassi=40cisco....@dmarc.ietf.org>
Date: Wednesday, May 29, 2024 at 11:48 PM
To: Wen Lin <w...@juniper.net>, bess@ietf.org <bess@ietf.org>,
i-d-annou...@ietf.org <i-d-annou...@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
[External Email. Be cautious of content]
Hi Wen,
There shouldn’t be any backward compatibility issue as section 8.5 states:
“Every PE is then given an ordinal
indicating its position in the ordered list, starting with 0 as
the ordinal for the PE with the lowest IP address length and
numeric value tuple. The tuple list is ordered by the IP address
length first and IP address value second.”
Because IP address length is factored into sorting the list, both IPv4 and IPv6
are allowed to be in the list. This is the expected behavior because in a
simple of dual-homing, an ES can span across two ASes with different address
families.
Cheers,
Ali
Juniper Business Use Only
From: Wen Lin <wlin=40juniper....@dmarc.ietf.org>
Date: Wednesday, May 29, 2024 at 12:47 PM
To: Ali Sajassi (sajassi) <saja...@cisco.com>, bess@ietf.org <bess@ietf.org>,
i-d-annou...@ietf.org <i-d-annou...@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
Hi Ali,
Thank you for providing the following text.
I think it will be helpful to mention the backward compatibility issue
regarding the change introduced in DF election (Section 8.5) as we need to
consider the possibility of originating router’s IP addresses coming in with
different IP address families.
Thanks,
Wen
Juniper Business Use Only
From: Ali Sajassi (sajassi) <sajassi=40cisco....@dmarc.ietf.org>
Date: Wednesday, May 15, 2024 at 1:55 PM
To: Wen Lin <w...@juniper.net>, bess@ietf.org <bess@ietf.org>,
i-d-annou...@ietf.org <i-d-annou...@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
[External Email. Be cautious of content]
Hi Wen,
I am thinking of adding the following paragraph as a clarification for the
originating router’s IP address.
“The Originating Router’s IP address does not need to be a routable address and
its purpose is to identify the originator of that EVPN route uniquely. It can
be either IPv4 or IPv6 address independent of the BGP next hop address type for
that NLRI and it must remain the same for all EVPN routes advertised by that
PE.”
Cheers,
Ali
Juniper Business Use Only
From: Wen Lin <wlin=40juniper....@dmarc.ietf.org>
Date: Friday, May 10, 2024 at 11:06 AM
To: bess@ietf.org <bess@ietf.org>, i-d-annou...@ietf.org <i-d-annou...@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>
Subject: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
Thank you for the updated draft.
I think we need to explicitly specify how we set the Originating Router’s IP
address – when it will be to IPv6 or IPv4 address for both Ethernet Segment
Route and Inclusive Multicast Ethernet Tag Route. Today, there is no
mentioning about it in the draft.
7.4.
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-09*section-7.4__;Iw!!NEt6yMaO-gk!D8FxrZ9AXM1VDe0Lr_x1vfnVhlT_Aa-m2k5dfbuYNwjcHjUrl4PwNDjonwQ2by0T_aS2klGdRdmVhPe9_ee4pOSj3vUNqw$>
Ethernet Segment
Route<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-09*name-ethernet-segment-route__;Iw!!NEt6yMaO-gk!D8FxrZ9AXM1VDe0Lr_x1vfnVhlT_Aa-m2k5dfbuYNwjcHjUrl4PwNDjonwQ2by0T_aS2klGdRdmVhPe9_ee4pOQZKTSEyg$>
+---------------------------------------+
| RD (8 octets) |
+---------------------------------------+
|Ethernet Segment Identifier (10 octets)|
+---------------------------------------+
| IP Address Length (1 octet) |
+---------------------------------------+
| Originating Router's IP Address |
| (4 or 16 octets) |
+---------------------------------------+
We need to add definition or reference for the Originating Router’s IP Address.
7.3.
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-09*section-7.3__;Iw!!NEt6yMaO-gk!D8FxrZ9AXM1VDe0Lr_x1vfnVhlT_Aa-m2k5dfbuYNwjcHjUrl4PwNDjonwQ2by0T_aS2klGdRdmVhPe9_ee4pORjQTaKBA$>
Inclusive Multicast Ethernet Tag
Route<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-09*name-inclusive-multicast-etherne__;Iw!!NEt6yMaO-gk!D8FxrZ9AXM1VDe0Lr_x1vfnVhlT_Aa-m2k5dfbuYNwjcHjUrl4PwNDjonwQ2by0T_aS2klGdRdmVhPe9_ee4pOSIekbGxQ$>
+---------------------------------------+
| RD (8 octets) |
+---------------------------------------+
| Ethernet Tag ID (4 octets) |
+---------------------------------------+
| IP Address Length (1 octet) |
+---------------------------------------+
| Originating Router's IP Address |
| (4 or 16 octets) |
+---------------------------------------+
For IMET route, we have the following definition in section 11.1:
“The Originating Router's IP Address field value MUST be set to an IP address
of the PE that should be common for all the EVIs on the PE (e.g., this address
may be the PE's loopback address). The IP Address Length field is in bits.”
A router may have both IPv4 and IPv6 addresses configured for the loopback. We
need to specify when IPv6 address will be used based on whether EVPN is used
IPv4 or IPv6 underlay.
Thanks,
Wen
Juniper Business Use Only
From: BESS <bess-boun...@ietf.org> on behalf of internet-dra...@ietf.org
<internet-dra...@ietf.org>
Date: Friday, May 3, 2024 at 12:42 AM
To: i-d-annou...@ietf.org <i-d-annou...@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>
Subject: [bess] I-D Action: draft-ietf-bess-rfc7432bis-09.txt
[External Email. Be cautious of content]
Internet-Draft draft-ietf-bess-rfc7432bis-09.txt is now available. It is a
work item of the BGP Enabled ServiceS (BESS) WG of the IETF.
Title: BGP MPLS-Based Ethernet VPN
Authors: Ali Sajassi
Luc Andre Burdet
John Drake
Jorge Rabadan
Name: draft-ietf-bess-rfc7432bis-09.txt
Pages: 73
Dates: 2024-05-02
Abstract:
This document describes procedures for Ethernet VPN (EVPN), a BGP
MPLS-based solution which addresses the requirements specified in the
corresponding RFC - "Requirements for Ethernet VPN (EVPN)". This
document obsoletes RFC7432 (BGP MPLS-Based Ethernet VPN) and updates
RFC8214 (Virtual Private Wire Service Support in Ethernet VPN).
The IETF datatracker status page for this Internet-Draft is:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-rfc7432bis/__;!!NEt6yMaO-gk!DQNdb1zziDhGamgqVCqazNaTWtGRyB4JfRJn_4PBJ-meIo5dUeuj3X1ZZzUL6Ak1xr3TX2QD68p6Le_VrAUK3PyL$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-rfc7432bis/__;!!NEt6yMaO-gk!DQNdb1zziDhGamgqVCqazNaTWtGRyB4JfRJn_4PBJ-meIo5dUeuj3X1ZZzUL6Ak1xr3TX2QD68p6Le_VrAUK3PyL$>
There is also an HTMLized version available at:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-09__;!!NEt6yMaO-gk!DQNdb1zziDhGamgqVCqazNaTWtGRyB4JfRJn_4PBJ-meIo5dUeuj3X1ZZzUL6Ak1xr3TX2QD68p6Le_VrD-_D2Jy$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-09__;!!NEt6yMaO-gk!DQNdb1zziDhGamgqVCqazNaTWtGRyB4JfRJn_4PBJ-meIo5dUeuj3X1ZZzUL6Ak1xr3TX2QD68p6Le_VrD-_D2Jy$>
A diff from the previous version is available at:
https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-rfc7432bis-09__;!!NEt6yMaO-gk!DQNdb1zziDhGamgqVCqazNaTWtGRyB4JfRJn_4PBJ-meIo5dUeuj3X1ZZzUL6Ak1xr3TX2QD68p6Le_VrF5Wvh7P$<https://urldefense.com/v3/__https:/author-tools.ietf.org/iddiff?url2=draft-ietf-bess-rfc7432bis-09__;!!NEt6yMaO-gk!DQNdb1zziDhGamgqVCqazNaTWtGRyB4JfRJn_4PBJ-meIo5dUeuj3X1ZZzUL6Ak1xr3TX2QD68p6Le_VrF5Wvh7P$>
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
_______________________________________________
BESS mailing list
BESS@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!DQNdb1zziDhGamgqVCqazNaTWtGRyB4JfRJn_4PBJ-meIo5dUeuj3X1ZZzUL6Ak1xr3TX2QD68p6Le_VrCT0gLFF$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!DQNdb1zziDhGamgqVCqazNaTWtGRyB4JfRJn_4PBJ-meIo5dUeuj3X1ZZzUL6Ak1xr3TX2QD68p6Le_VrCT0gLFF$>
_______________________________________________
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org
