[bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt

[Wen Lin]

Ali,

The reverted text looks good.  Thank you.

Wen



Juniper Business Use Only
From: Ali Sajassi (sajassi) 
Date: Tuesday, June 4, 2024 at 1:27 AM
To: Wen Lin , Ali Sajassi (sajassi) 
, Luc André Burdet 
, bess@ietf.org 
Subject: Re: [bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt
[External Email. Be cautious of content]


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



Juniper Business Use Only
From: Wen Lin 
Date: Monday, June 3, 2024 at 6:26 PM
To: Ali Sajassi (sajassi) , Luc André 
Burdet , Ali Sajassi (sajassi) , 
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) 
Date: Monday, June 3, 2024 at 11:31 AM
To: Luc André Burdet , Wen Lin , Ali 
Sajassi (sajassi) , 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 
Date: Monday, June 3, 2024 at 6:08 AM
To: Wen Lin , Ali Sajassi (sajassi) 
, Ali Sajassi (sajassi) 
, 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 
Date: Thursday, May 30, 2024 at 23:31
To: Ali Sajassi (sajassi) , Ali Sajassi (sajassi) 
, 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) 
Date: Thursday, May 30, 2024 at 11:13 PM
To: Wen Lin , Ali Sajassi (sajassi) 
, 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

[bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt

[Wen Lin]

@ 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) 
Date: Monday, June 3, 2024 at 11:31 AM
To: Luc André Burdet , Wen Lin , Ali 
Sajassi (sajassi) , 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 
Date: Monday, June 3, 2024 at 6:08 AM
To: Wen Lin , Ali Sajassi (sajassi) 
, Ali Sajassi (sajassi) 
, 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 
Date: Thursday, May 30, 2024 at 23:31
To: Ali Sajassi (sajassi) , Ali Sajassi (sajassi) 
, 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) 
Date: Thursday, May 30, 2024 at 11:13 PM
To: Wen Lin , Ali Sajassi (sajassi) 
, 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 
Date: Thursday, May 30, 2024 at 11:46 AM
To: Ali Sajassi (sajassi) , bess@ietf.org 
, Ali Sajassi (sajassi) 
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 ind

[bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt

[Wen Lin]

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) 
Date: Thursday, May 30, 2024 at 11:13 PM
To: Wen Lin , Ali Sajassi (sajassi) 
, 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 
Date: Thursday, May 30, 2024 at 11:46 AM
To: Ali Sajassi (sajassi) , bess@ietf.org 
, Ali Sajassi (sajassi) 
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) 
Date: Thursday, May 30, 2024 at 1:13 PM
To: Wen Lin , bess@ietf.org , Ali Sajassi 
(sajassi) 
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 
Date: Thursday, May 30, 2024 at 7:32 AM
To: Ali Sajassi (sajassi) , bess@ietf.org , 
i-d-annou...@ietf.org 
Cc: 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) 
Date: Wednesday, May 29, 2024 at 11:48 PM
To: Wen

[bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt

[Wen Lin]

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) 
Date: Thursday, May 30, 2024 at 1:13 PM
To: Wen Lin , bess@ietf.org , Ali Sajassi 
(sajassi) 
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 
Date: Thursday, May 30, 2024 at 7:32 AM
To: Ali Sajassi (sajassi) , bess@ietf.org , 
i-d-annou...@ietf.org 
Cc: 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) 
Date: Wednesday, May 29, 2024 at 11:48 PM
To: Wen Lin , bess@ietf.org , 
i-d-annou...@ietf.org 
Cc: 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 
Date: Wednesday, May 29, 2024 at 12:47 PM
To: Ali Sajassi (sajassi) , bess@ietf.org , 
i-d-annou...@ietf.org 
Cc: 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 

[bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt

[Wen Lin]

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) 
Date: Wednesday, May 29, 2024 at 11:48 PM
To: Wen Lin , bess@ietf.org , 
i-d-annou...@ietf.org 
Cc: 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 
Date: Wednesday, May 29, 2024 at 12:47 PM
To: Ali Sajassi (sajassi) , bess@ietf.org , 
i-d-annou...@ietf.org 
Cc: 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) 
Date: Wednesday, May 15, 2024 at 1:55 PM
To: Wen Lin , bess@ietf.org , 
i-d-annou...@ietf.org 
Cc: 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 
Date: Friday, May 10, 2024 at 11:06 AM
To: bess@ietf.org , i-d-annou...@ietf.org 
Cc: 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!D8FxrZ9AX

[bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt

[Wen Lin]

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) 
Date: Wednesday, May 15, 2024 at 1:55 PM
To: Wen Lin , bess@ietf.org , 
i-d-annou...@ietf.org 
Cc: 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 
Date: Friday, May 10, 2024 at 11:06 AM
To: bess@ietf.org , i-d-annou...@ietf.org 
Cc: 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  on behalf of internet-dra...@ietf.org 

Date: Friday, May 3, 2024 at 12:42 AM
To: i-d-annou...@ietf.org 
Cc: 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
   M

[bess] Re: I-D Action: draft-ietf-bess-rfc7432bis-09.txt

[Wen Lin]

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. 

 Ethernet Segment 
Route
+---+
|  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. 

 Inclusive Multicast Ethernet Tag 
Route

+---+

|  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  on behalf of internet-dra...@ietf.org 

Date: Friday, May 3, 2024 at 12:42 AM
To: i-d-annou...@ietf.org 
Cc: 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$

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$

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$

Internet-Drafts are also available by rsync at:

Re: [bess] WG Adoption and IPR Poll for draft-sr-bess-evpn-dpath-04

[Wen Lin]

As co-author, I support this for WG adoption.
I am unaware of any related undisclosed IPR.

Thanks,
Wen



Juniper Business Use Only
From: Patrice Brissette (pbrisset) 
Date: Wednesday, March 13, 2024 at 12:57 PM
To: Jeffrey (Zhaohui) Zhang , 'BESS' , 
draft-sr-bess-evpn-dp...@ietf.org 
Cc: idr@ietf. org , 'bess-cha...@ietf.org' 
Subject: Re: WG Adoption and IPR Poll for draft-sr-bess-evpn-dpath-04
[External Email. Be cautious of content]


As co-author, I support this document for WG adoption.
Not aware of any related undisclosed IPR.

Regards,
Patrice Brissette
Distinguished Engineer
Cisco Systems





On 2024-03-06, 13:32, "Jeffrey (Zhaohui) Zhang" mailto:zzh...@juniper.net>> wrote:




Hi,


This email begins a two-week WG adoption and IPR poll for 
draft-sr-bess-evpn-dpath-04 
(https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-sr-bess-evpn-dpath/__;!!NEt6yMaO-gk!Hz5Dfo5oyilmbgzNVoYxla56vghFb8JLCpZlLfvLr4lA2AaQlZV4zXQLBfUV-x4WvLbzpUw2IB_SGA$
  
).


Please review the draft and post any comments to the BESS working group list. 
The IDR list is copied in this call because of the Domain Path Attribute 
(D-PATH) introduced in draft-ietf-bess-evpn-ipvpn-interworking.


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, copying the BESS mailing list. The document will not progress 
without answers from all the authors and contributors.


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


This poll for adoption closes on 20th March 2024.


Thanks.




BESS chairs


Juniper Business Use Only




Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Genart early review of draft-ietf-bess-extended-evpn-optimized-ir-05

[Wen Lin]

 Hi Thomas,

Thank you so much for your thorough review and valuable inputs.  Please see 
replies inline below and diffs in the following link.

https://author-tools.ietf.org/iddiff?url1=draft-ietf-bess-extended-evpn-optimized-ir-05=draft-ietf-bess-extended-evpn-optimized-ir-06=--html

Wen



Juniper Business Use Only
From: Thomas Fossati via Datatracker 
Date: Sunday, December 17, 2023 at 4:37 PM
To: gen-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-extended-evpn-optimized-ir@ietf.org 

Subject: Genart early review of draft-ietf-bess-extended-evpn-optimized-ir-05
[External Email. Be cautious of content]


Reviewer: Thomas Fossati
Review result: Ready with Issues

I am not able to provide any feedback on the technical aspects as it is
beyond my expertise. However, I have marked the content as "ready with
issues" because I believe that the writing can be improved to make it
more accessible to people who are not hardcore BESS hackers :-) I have
made a few editorial suggestions to try and address this concern.

> Abstract
>
>[EVPN-AR] specifies an optimized ingress replication solution for

Please define [EVPN-AR].  [1] says:

"An abstract should be complete in itself, so it should not contain
 citations unless they are completely defined within the abstract."

[1] 
https://urldefense.com/v3/__https://authors.ietf.org/en/required-content__;!!NEt6yMaO-gk!HGNzVL5O3SuONL68ID9RkgvWVXQKE5p02Ng1HujKkz2fCOkhjoniaBHBMkrcrGlaW-MTcaLsjamXDg$

Besides, the [EVPN-AR] entry in §10 is pretty broken :-)
Wen: Fixed

>more efficient multicast and broadcast delivery in a Network
>Virtualization Overlay (NVO) network for EVPN.

Please expand EVPN
Wen: Done

>This document extends the optimized ingress replication procedures
>specified in [EVPN-AR] to overcome the limitation that an AR-
>REPLICATOR may have.  An AR-REPLICATOR may be unable to retain the
>source IP address or include the expected ESI label that is
>required for EVPN split-horizon filtering when replicating the
>packet on behalf of its multihomed AR-LEAF.  Under this
>circumstance, the extended procedures specified in this document
>allows the support of EVPN multihoming on the AR-LEAFs as well as
>optimized ingress replication for the rest of the EVPN overlay
>network.

I had to jump back and forth between this document and [EVPN-AR] three
times to get the definitions of AR-REPLICATOR, AR-LEAF and ESI.  I'm
wondering if there's a way to make the abstract less heavy on acronyms.
Wen: I updated the abstract based on your input.

> 1.  Terminology
>BD: Bridge Domain, as it is defined in the[RFC7432]

Suggestion:

 BD: Bridge Domain, as defined in [RFC7432]
Wen: Changed to Broadcast Domain based on RFC 7432,  and also modified based on 
your input .

>RNVE: Regular Network Virtualized Edge router that performs the
>procedure specified in the [RFC8365]

Suggestion:

 RNVE: Regular Network Virtualized Edge router that performs the
 procedure specified in [RFC8365]
Wen: Done.

>This document heavily uses the terminology specified in [EVPN-AR].

Suggestion:

 This document extensively employs the terminology defined in
 [EVPN-AR].
Or, more simply:

 This document makes use of the terminology defined in [EVPN-AR].
Wen: done.

> 2.1.1.  EVPN Multihoming and split-horizon Filtering Rule
>
>[...]
>unicast or Multicast (BUM) packet received from an ES that is a
>part

Suggestion:

 unicast or Multicast (BUM) packet received from an ES that is part
Wen: Fixed

>[...] For EVPN with VXLAN encapsulation, the split-horizon
>filtering rule is based on the egress NVE examining the source IP
>address of the BUM packet received from an overlay tunnel.

Suggestion:

 When using EVPN with VXLAN encapsulation, the split-horizon
 filtering rule is applied by the egress NVE based on the source IP
 address of the BUM packet received from an overlay tunnel.
Wen: Done

>For ingress replication, an ESI label is downstream assigned per
>multihomed ES.

What does "downstream assigned" mean?
Wen: It is in the direction of packet destination, assigned by the egress PE.

>packet to the egress NVE if the BUM traffic is form the AC that is

s/form/from/
Wen: Fixed

> 2.2.  Optimized-IR and the Need to Maintain the Original Source IP
>   address or Include the ESI Label
>
>[EVPN-AR] specifies an optimized ingress replication solution for
>the delivery of Multicast and Broadcast (BM) traffic within a
>bridge

Should the acronym be "MB" instead?  (Ignorant question: is this
different from BUM traffic?)
Wen: Fixed.

>[...] To support EVPN AR-LEAF multihoming, [EVPN-AR] recommends
>that split-horizon filtering rule based on "Local-Bias" procedures
>is used for 

Re: [bess] Rtgdir early review of draft-ietf-bess-extended-evpn-optimized-ir-04

[Wen Lin]

 Hi Nicolai,

Thanks a lot for your thorough review and valuable inputs. I have addressed 
your comments, and you can find my responses inline below, along with the 
updated draft in the latest diff:

Diff: 
https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-extended-evpn-optimized-ir-05__;!!NEt6yMaO-gk!C1ibVk6b22e_0MZKMMPzp0fY5g36TkykAkkXb53HLm1FnTTV98cykYEoA574Vr3ljMoXZIf-GgfVhWPRkCyp9gSb$

Wen



Juniper Business Use Only
From: Nicolai Leymann via Datatracker 
Date: Wednesday, November 29, 2023 at 3:49 AM
To: rtg-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-extended-evpn-optimized-ir@ietf.org 

Subject: Rtgdir early review of draft-ietf-bess-extended-evpn-optimized-ir-04
[External Email. Be cautious of content]


Reviewer: Nicolai Leymann
Review result: Has Issues

Hi,

I have been selected to do a routing directorate “early” review of this draft:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-extended-evpn-optimized-ir__;!!NEt6yMaO-gk!GlhaPATHS2SyoyQSr-bVQRYUW88HKjEtwPu2RAlfy_2CZ-fhcMdcRchlv2x6OCh_TnWXLt5A3FgQJw$

The routing directorate will, on request from the working group chair,
perform an “early” review of a draft before it is submitted for
publication to the IESG. The early review can be performed at any time
during the draft’s lifetime as a working group document.

For more information about the Routing Directorate, please see
https://urldefense.com/v3/__https://wiki.ietf.org/en/group/rtg/RtgDir__;!!NEt6yMaO-gk!GlhaPATHS2SyoyQSr-bVQRYUW88HKjEtwPu2RAlfy_2CZ-fhcMdcRchlv2x6OCh_TnWXLt5UDfHfzw$

Document:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-extended-evpn-optimized-ir-04__;!!NEt6yMaO-gk!GlhaPATHS2SyoyQSr-bVQRYUW88HKjEtwPu2RAlfy_2CZ-fhcMdcRchlv2x6OCh_TnWXLt5_thqIog$
Reviewer: Nicolai Leymann Review Date: Nov 19, 2023 Intended Status: Standards
Track

Overall the draft is in good shape and extends the existing optimzed ingress
replication in multihoming scenarios. For such networks the draft  provides a
solution and also optimized ingress replication for the EVPN overlay.

The draft assumes that the reader is familiar with the details of the
underlying specs such as "Optimized Ingress Replication solution for EVPN".
There are a few things which would help to make the document more readable.

In general I recommend to extend abbreviation such as "A-D", "RNVE", "BD" (at
first occurence in the document).
Wen: Added in the terminology section
The first part of the draft describes
handling of BUM traffic, later BM is used (for Multicast/Broadcast) only; the
solution itself refers to BUM again. Please clarify a more in detail what the
solution/document is addressing.
Wen: Added the clarification that this document addresses BM traffic delivery 
with extended Optimized-IR. Also, I cleaned up relevant text accordingly.
Section 2 gives an detailed description of a
scenario used throughout the document but a figure as additional information
and reference would be really helpful to better understand the problem as well
as the solution (also because the scenario is referred from other sections such
as 4.2.1, making the draft hard to read).
Wen: Added a figure.

Other Nits:
Section 2 and following
  - inconsistent use of "split horizon" and "split-horizon"
  - inconsistent use of "extended optimized-IR" and "extended Optimized-IR" and
  "Extended Optimized-IR"
Wen: Fixed through the document.
Section 2.2
  - "[EVPN-AR] specifies an optimized ingress replication procedures for" to
"[EVPN-AR] specifies an optimized ingress replication procedure" for
Wen: Fixed.
Section 3.1
  - "it MUST informs"
  - "it MUST inform"
  - "The changes in the control plane and forwarding [...] is further explained
  in detail in section 5.2." - "The changes in the control plane and forwarding
  [...] are further explained in detail in section 5.2." - "It may also applies
  to Unknown unicast traffic." - "It may also apply to Unknown unicast traffic.
Wen: Fixed all the above.

Section 3.2
  - consider explaining/extending "BD"
Wen: Added in the terminology section.

  - "Consider an EVPN NVO network with a tenant domain consists of a set of 

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-mh-split-horizon

[Wen Lin]

As co-author, I support this draft.  I am unaware of any IPR related to this 
draft



Thanks,

Wen




Juniper Business Use Only


From: slitkows.i...@gmail.com 


Date: Wednesday, January 26, 2022 at 1:50 AM

To: bess@ietf.org 
, 
draft-ietf-bess-evpn-mh-split-hori...@ietf.org
 


Cc: bess-cha...@ietf.org 


Subject: WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-mh-split-horizon

Hello Working Group,


This email starts a two weeks Working Group Last Call on 
draft-ietf-bess-evpn-mh-split-horizon [1].



This poll runs until *the 9th of Feb*.



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 no IPR currently 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

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption and IPR poll for draft-trr-bess-bgp-srv6-args-02

[Wen Lin]

As co-author, support the WG adoption of this draft.   I am unaware of any IPR 
related to this draft.

Thanks,
Wen



Juniper Business Use Only
From: Mankamana Mishra (mankamis) 
Date: Thursday, September 28, 2023 at 2:15 PM
To: Matthew Bocci (Nokia) , bess@ietf.org 

Cc: draft-trr-bess-bgp-srv6-a...@ietf.org 

Subject: Re: WG adoption and IPR poll for draft-trr-bess-bgp-srv6-args-02
[External Email. Be cautious of content]

Support the adoption of this draft.

From: BESS  on behalf of Matthew Bocci (Nokia) 

Date: Thursday, September 28, 2023 at 7:51 AM
To: bess@ietf.org 
Cc: draft-trr-bess-bgp-srv6-a...@ietf.org 

Subject: [bess] WG adoption and IPR poll for draft-trr-bess-bgp-srv6-args-02
This email begins a two-week WG adoption and IPR poll for 
draft-trr-bess-bgp-srv6-args-02 [1].

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document will not progress 
without answers from all the authors and contributors.
Currently, there is currently no IPR disclosure against this document.

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

This poll for adoption closes on Thursday 12th October 2023.

[1] draft-trr-bess-bgp-srv6-args-02 - SRv6 Argument Signaling for BGP Services 
(ietf.org)
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Request for an expedited WG adoption call for draft-trr-bess-bgp-srv6-args

[Wen Lin]

As a co-author, I support the early WG adoption of this draft to address 
potential interoperability issue between different vendors' products.

Thanks,
Wen



Juniper Business Use Only
From: Patrice Brissette (pbrisset) 
Date: Tuesday, August 1, 2023 at 4:38 PM
To: Matthew Bocci (Nokia) , Ketan Talaulikar 
, bess-cha...@ietf.org 
Cc: draft-trr-bess-bgp-srv6-a...@ietf.org 
, BESS 
Subject: Re: [bess] Request for an expedited WG adoption call for 
draft-trr-bess-bgp-srv6-args
[External Email. Be cautious of content]

Hi,

I’m supporting this draft.
Regards,
Patrice Brissette
Distinguished Engineer
Cisco Systems




From: BESS  on behalf of "Matthew Bocci (Nokia)" 

Date: Tuesday, August 1, 2023 at 13:25
To: Ketan Talaulikar , "bess-cha...@ietf.org" 

Cc: "draft-trr-bess-bgp-srv6-a...@ietf.org" 
, BESS 
Subject: Re: [bess] Request for an expedited WG adoption call for 
draft-trr-bess-bgp-srv6-args

Hi Ketan

If we can do a quick implementation poll for the changes proposed in the draft, 
that would help.

Thanks

Matthew

From: Ketan Talaulikar 
Date: Thursday, 27 July 2023 at 15:02
To: bess-cha...@ietf.org 
Cc: draft-trr-bess-bgp-srv6-a...@ietf.org 
, BESS 
Subject: Request for an expedited WG adoption call for 
draft-trr-bess-bgp-srv6-args

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.


Hello Chairs,

The authors would like to drop this gentle reminder of our request for an 
expedited WG adoption call for this draft that we had presented at IETF116.

The draft is in essence an "errata" for a certain portion our BESS WG RFC9252. 
The concerned portions of the specification have been in development at various 
vendors for quite some time now. Interop issues were identified and these 
clarifications are needed for smooth interop and deployments that are ongoing.

Thanks,
Ketan (on behalf of co-authors)

On Thu, Apr 27, 2023 at 10:12 AM Ketan Talaulikar 
mailto:ketant.i...@gmail.com>> wrote:
Hello All,

We had presented 
https://datatracker.ietf.org/doc/draft-trr-bess-bgp-srv6-args/
 at the IETF 116.

The slides are available at: 
https://datatracker.ietf.org/meeting/116/materials/slides-116-bess-draft-trr-bess-srv6-args-00.pdf

Since this draft aims to fix some issues in the RFC9252 that was published by 
BESS WG, we had sought feedback/review from the WG and requested the WG chairs 
for an expedited WG adoption.

We also wanted to check if any follow-up was required for the comments that 
were discussed at the meeting.

Thanks,
Ketan (on behalf of co-authors)

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption for draft-brissette-bess-evpn-vpws-seamless

[Wen Lin]

Support as a co-author. I am unaware of any IPRs.

Thanks,
Wen



Juniper Business Use Only
From: BESS  on behalf of Mankamana Mishra (mankamis) 

Date: Thursday, May 25, 2023 at 11:31 AM
To: slitkows.i...@gmail.com , bess@ietf.org 

Cc: bess-cha...@ietf.org 
Subject: Re: [bess] WG adoption for draft-brissette-bess-evpn-vpws-seamless
[External Email. Be cautious of content]

Support the adoption .

From: slitkows.i...@gmail.com 
Date: Wednesday, May 24, 2023 at 1:02 AM
To: bess@ietf.org 
Cc: bess-cha...@ietf.org 
Subject: WG adoption for draft-brissette-bess-evpn-vpws-seamless
Hello,


This email begins a two-weeks WG adoption poll for 
draft-brissette-bess-evpn-vpws-seamless-07 [1].
Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document will not progress 
without answers from all the authors and contributors.
Currently, there is currently no IPR disclosure against this document.
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.

This poll for adoption closes on June 7th.

Regards,
Matthew and Stephane

[1] 
https://datatracker.ietf.org/doc/draft-brissette-bess-evpn-vpws-seamless/
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-redundant-mcast-source

[Wen Lin]

Indeed, we just realized it.

Wen

From: BESS  on behalf of "Jeffrey (Zhaohui) Zhang" 

Date: Wednesday, June 1, 2022 at 2:24 PM
To: "slitkows.i...@gmail.com" , 
"draft-ietf-bess-evpn-redundant-mcast-sou...@ietf.org" 
, "bess@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-redundant-mcast-source

[External Email. Be cautious of content]

Hi,

I recently became aware of a related IPR that Juniper’s Legal team is preparing 
for disclosure.
It should be filed soon.

Thanks.
Jeffrey



Juniper Business Use Only
From: slitkows.i...@gmail.com 
Sent: Wednesday, May 18, 2022 3:23 AM
To: draft-ietf-bess-evpn-redundant-mcast-sou...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-redundant-mcast-source

[External Email. Be cautious of content]


Hello WG,







This email starts a two weeks Working Group Last Call on 
draft-ietf-bess-evpn-redundant-mcast-source

 [1].







This poll runs until * the 1th of June *.







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-redundant-mcast-source/



[2]



https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption for draft-skr-bess-evpn-redundant-mcast-source

[Wen Lin]

Support as a co-authors. I am not aware of any IPR related to this.

Thanks,
Wen

From: "slitkows.i...@gmail.com" 
Date: Tuesday, December 1, 2020 at 4:31 AM
To: "bess@ietf.org" , 
"draft-skr-bess-evpn-redundant-mcast-sou...@ietf.org" 

Subject: WG adoption for draft-skr-bess-evpn-redundant-mcast-source
Resent-From: 
Resent-To: , , 
, , , 

Resent-Date: Tuesday, December 1, 2020 at 4:31 AM

[External Email. Be cautious of content]

Hello,

This email begins a two-weeks WG adoption poll for 
draft-skr-bess-evpn-redundant-mcast-source
 [1].

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document will not  progress 
without answers from all of the authors and contributors.

Currently, there are no IPR disclosures against this document.

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.

This poll for adoption closes on 15th December 2020.

Regards,
Matthew and Stephane

[1]  
https://datatracker.ietf.org/doc/draft-skr-bess-evpn-redundant-mcast-source/






Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-mvpn-evpn-aggregation-label-04

[Wen Lin]

Support as a co-authors. I am not aware of any IPR related to this.

Thanks,
Wen

From: "Jeffrey (Zhaohui) Zhang" 
Date: Monday, December 14, 2020 at 8:41 AM
To: "slitkows.i...@gmail.com" , 
"draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org" 
, "bess@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: RE: WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-mvpn-evpn-aggregation-label-04
Resent-From: 
Resent-To: , , , 
, 
Resent-Date: Monday, December 14, 2020 at 8:40 AM

Support as co-author.
Not aware of undisclosed IPRs.

Thanks.
Jeffrey

From: slitkows.i...@gmail.com 
Sent: Friday, December 11, 2020 10:53 AM
To: draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-mvpn-evpn-aggregation-label-04

[External Email. Be cautious of content]

This email starts a two-week working group last call for 
draft-ietf-bess-mvpn-evpn-aggregation-label-04 [1]

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a standards track RFC.

This poll runs until the 28th December 2020

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 one IPR disclosure.

In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].

Thank you,
Matthew & Stephane


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



Juniper Business Use Only


Juniper Business Use Only


Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption and IPR poll for draft-nr-bess-evpn-mh-split-horizon-03

[Wen Lin]

Support as a co-author for WG adoption of this draft.  I am unaware of any 
related IPR.

Thanks,
Wen

From: BESS  on behalf of "Nagaraj, Kiran (Nokia - 
US/Mountain View)" 
Date: Wednesday, September 9, 2020 at 1:24 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" , 
"Bocci, Matthew (Nokia - GB)" , "bess@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: Re: [bess] WG adoption and IPR poll for 
draft-nr-bess-evpn-mh-split-horizon-03

[External Email. Be cautious of content]

I support this draft as a co-author. I am not aware of any IPR related to this.

Thanks
Kiran


From: BESS  On Behalf Of Rabadan, Jorge (Nokia - 
US/Mountain View)
Sent: Wednesday, September 9, 2020 6:36 AM
To: Bocci, Matthew (Nokia - GB) ; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: Re: [bess] WG adoption and IPR poll for 
draft-nr-bess-evpn-mh-split-horizon-03

As a co-author, I support this document for WG adoption.
I’m not aware of any relevant IPR.

Thanks.
Jorge

From: BESS mailto:bess-boun...@ietf.org>>
Date: Wednesday, September 9, 2020 at 12:43 PM
To: bess@ietf.org mailto:bess@ietf.org>>
Cc: bess-cha...@ietf.org 
mailto:bess-cha...@ietf.org>>
Subject: [bess] WG adoption and IPR poll for 
draft-nr-bess-evpn-mh-split-horizon-03
Hello,

This email begins a two-weeks WG adoption poll for 
draft-nr-bess-evpn-mh-split-horizon-03 [1].

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document will not  progress 
without answers from all of the authors and contributors.

Currently, there are no IPR disclosures against this document.

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.

This poll for adoption closes on 23rd September 2020.

Regards,
Matthew and Stephane

[1] 
https://datatracker.ietf.org/doc/draft-nr-bess-evpn-mh-split-horizon/





Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] new WGLC on draft-ietf-bess-evpn-igmp-mld-proxy-05

[Wen Lin]

Thanks for the update based on the latest discussion.



Please also update the text in item 4 under section 6.2,  remove the text 
related to the sequence number and the Leave group synchronization procedure.


Wen

From: BESS  on behalf of "Mankamana Mishra (mankamis)" 

Date: Tuesday, May 19, 2020 at 4:30 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" , 
"slitkows.i...@gmail.com" , "bess@ietf.org" 

Cc: "Prabhu, Vinod (Nokia - CA/Ottawa)" , 
"bess-cha...@ietf.org" , "Dornon, Olivier (Nokia - 
BE/Antwerp)" 
Subject: Re: [bess] new WGLC on draft-ietf-bess-evpn-igmp-mld-proxy-05

[External Email. Be cautious of content]

Thanks Jorge, Noted it.  Will wait for any other comments. And make changes all 
together.

From: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Date: Tuesday, May 19, 2020 at 1:09 PM
To: "slitkows.i...@gmail.com" , "bess@ietf.org" 

Cc: "bess-cha...@ietf.org" , "Prabhu, Vinod (Nokia - 
CA/Ottawa)" , "Dornon, Olivier (Nokia - BE/Antwerp)" 

Subject: Re: [bess] new WGLC on draft-ietf-bess-evpn-igmp-mld-proxy-05
Resent-From: 
Resent-To: , , 

Resent-Date: Tuesday, May 19, 2020 at 1:09 PM

Hi,

I think the changes are ok, since they follow the latest discussions.
The document is ready to progress.

Not that should hold the WG Last Call, but please, fix the following text that 
we found confusing, as part of the following revision:

The IGMP Join Synch route MUST carry the ES-Import RT for the ES on
   which the IGMP Membership Report was received.  Thus it MUST only be
   sent to the PEs attached to that ES and not any other PEs.

s/ Thus it MUST only be sent to the PEs attached to that ES and not any other 
PEs. / Thus it MUST only be imported by the PEs attached to that ES and not any 
other PEs. /

That is, the ES-Import RT per-se does not determine to what PEs the route is 
sent. It determines the dissemination along with RT Constraint, but the MUST 
statement – if needed - should really be added along with the import action.

Thanks.
Jorge


From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Monday, May 18, 2020 at 9:54 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] new WGLC on draft-ietf-bess-evpn-igmp-mld-proxy-05

Hi WG,

Following the discussion and significant document update, we are starting a new 
Working Group Last Call on draft-ietf-bess-evpn-igmp-mld-proxy-05

This poll runs until the 1st of June.

Please read carefully the document and raise any concern about the changes that 
have been introduced.


Thanks,

Stephane & Matthew

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-igmp-mld-proxy



Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] IGMP / MLD Proxy Draft update (NLRI change)

[Wen Lin]

I am fine with changing this field to a reserved field.  Each originator MUST 
set the reserved field to zero and the reserved field is not a part of the key 
going forward.  RR propagates the route as it was received.

Thanks,
Wen

From: "Ali Sajassi (sajassi)" 
Date: Tuesday, April 28, 2020 at 12:04 PM
To: John Scudder 
Cc: "Mankamana Mishra (mankamis)" , "bess@ietf.org" 
, "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "Jakob Heitz (jheitz)" 

Subject: Re: [bess] IGMP / MLD Proxy Draft update (NLRI change)
Resent-From: 
Resent-To: , , , 
, 
Resent-Date: Tuesday, April 28, 2020 at 12:03 PM

[External Email. Be cautious of content]

Hi John,

To accommodate Jakob’s and Jeff’s comment, we can say:

“This field is not part of the route key. The originator MUST set the reserved 
field to Zero (because this field used to be part of the route key), the 
receiver SHOULD ignore it and if it needs to be propagated, it MUST propagate 
it unchanged”.

Once the new rev is published, we can comment and fine tune the text.

Cheers,
Ali

From: John Scudder 
Date: Tuesday, April 28, 2020 at 8:50 AM
To: Cisco Employee 
Cc: "Mankamana Mishra (mankamis)" , "bess@ietf.org" 
, "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "Jakob Heitz (jheitz)" 

Subject: Re: [bess] IGMP / MLD Proxy Draft update (NLRI change)

Hi Ali,

Yes, making the field reserved would be fine from my point of view, thanks.

Also to repeat the point that was raised at the mic during the meeting just 
now, there should be some text to the effect of “this field is reserved. It 
MUST be transmitted as zero. Any value MUST be accepted on receipt.”

Jakob added this comment in the WebEx chat: “Perhaps also, if propagated, it 
must be propagated the way it was received. For example RR”. That seems 
reasonable to me for an RR (or other device that propagates routes without 
consuming them, sometimes ASBRs can do this). So maybe this text? Jakob, what 
do you think?

“This field is reserved. It MUST be originated as zero. Any value MUST be 
accepted on receipt.”

I changed “transmitted” to “originated” to try to capture the distinction. I 
guess there might need to be some consideration of what exactly “accepted” 
means. I don’t mean that it should be part of the key, I just mean it shouldn’t 
be considered an error.

In any case this is a small detail to be ironed out in the final text, the 
approach Ali proposes is fine.

—John



On Apr 28, 2020, at 1:08 AM, Ali Sajassi (sajassi) 
mailto:saja...@cisco.com>> wrote:


Hi John,

My objection to using two code points for RT-8 and do a migration from old to 
new is two folds:

  1.  As I explained in my previous emails, there are vendors who have 
implemented both formats based on a single code point after our meeting around 
IETF 106 and I don’t want to have them yet again do another implementation. 
Basically, it is not fair to them.
  2.  One of the fundamental premise of EVPN is minimizing configuration and 
that’s why we have lots of auto-derivation / auto-configuration features in 
EVPN – e.g., auto-derivation of ESIs and auto-derivations of RTs, etc. I really 
don’t want to add any extra configuration knobs for BGP peer as to what format 
it supports considering how much efforts has gone into the EVPN protocol to 
minimize configurations.
AFAIK, there is only one vendor who implemented ONLY the existing format with 
deployments (your vendor) and there is only one vendor who implemented ONLY the 
new format with deployments (my vendor). Other vendors that I know (and we need 
to poll again) have either implemented both formats with a single code point or 
haven’t done the implementation yet.

So, after discussing the situation with my development team today, we are OK 
with using the old format and upgrade our field deployment toward that. This 
way we can avoid using two different code points and all the intricacies that 
comes with it – i.e.,  additional configuration knobs and migration stuff. So, 
we change the “Leave Synchronization Number” field to 4-byte reserved field (to 
be set zero upon transmission and ignored when received). It should also not be 
part of route-key processing of course.

Mankamana will present a few slides on this tomorrow and we will seek WG 
consensus on this. Once we have consensus, then the update of the draft is 
rather easy and we will move quickly on it.

Cheers,
Ali


From: John Scudder mailto:j...@juniper.net>>
Date: Monday, April 27, 2020 at 8:56 AM
To: Cisco Employee mailto:saja...@cisco.com>>
Cc: "Mankamana Mishra (mankamis)" 
mailto:manka...@cisco.com>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org"
 
mailto:draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org>>
Subject: Re: [bess] IGMP / MLD Proxy Draft update (NLRI change)
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Cisco Employee mailto:saja...@cisco.com>>, 
mailto:stho...@cisco.com>>, 

Re: [bess] IGMP / MLD Proxy Draft update (NLRI change)

[Wen Lin]

Hi All,

Thank you for bringing up the discussion on the WG mailing list.

I don’t think RT-4 is a good example to follow.  On the other hand, I am not 
sure if PBB-EVPN or EVPN multihoming was deployed in any real production 
network back in 2013 when the NLRI of RT-4 was updated.   In any case, the 
potential risk to the network is now clearly explained in this email thread.  
For type-8 we need a safe procedure to avoid any potential risk to the network.

Multihoming PEs may come from the same vendor in some networks, but we are 
talking about the standard procedure here.   Similarly, we have the standard in 
the EVPN DF election procedures among/between multihoming PEs.

Today EVPN is widely deployed, not only in DC, but also in service provider and 
enterprise networks.  We not only have PBB-EVPN, but also EVPN/VXLAN, 
EVPN/MPLS, EVPNoMPLSoUPD, etc.  EVPN is supported by many vendors today.

Thanks,
Wen

From: "Ali Sajassi (sajassi)" 
Date: Sunday, April 26, 2020 at 6:08 PM
To: John Scudder 
Cc: "Mankamana Mishra (mankamis)" , "bess@ietf.org" 
, "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 

Subject: Re: [bess] IGMP / MLD Proxy Draft update (NLRI change)
Resent-From: 
Resent-To: , , , 
, 
Resent-Date: Sunday, April 26, 2020 at 6:08 PM

[External Email. Be cautious of content]

Hi John,

I think we need a good operational procedures similar to what we did for RT-4 
regardless of what approach we take because currently we have two deployments 
(by two vendors) that use the RT-8 with two different lengths. And without 
proper procedure, mixing these boxes can cause issues such as BGP session reset 
(which you also pointed out previously). So, I believe we need to have a proper 
procedure while we are upgrading them to interoperate with each other. And for 
interoperability, let me categorize the use of the two different code-points as 
the 3rd option. So for sake of completeness, let me repeat them here:


  1.  Just go with the new format and for multi-vendor deployment, making sure 
the new format is used. Considering the current deployments situations where 
intra-DCs and intra-sites are  done using a single vendor but different vendors 
are used for different sites and DCs, this can be feasible. Maybe that’s why we 
haven’t run into the interop issues because for the current deployment model.
  2.  Accommodate both lengths (i.e., bullet b) above) and turn on 
RT-constraint on the PEs that support old RT-8 format. This way, the RR can 
properly reflect both RT-8 formats. The PEs supporting the new format can be 
inserted into the network without issue. And the PEs supporting the old format 
can be gradually migrated to the new format.
  3.  Use a new code point for the new format and the new PEs need to support 
both code points and then deprecate the old code point
If we look at the vendor situation (AFAIK), since IETF in Nov, the vendors that 
have implemented this feature except one, have upgraded their implementation to 
support either both format or both lengths because we thought we had a 
unanimous agreement. So, that means all vendors except one can do option 1 and 
2. Now if we are asking everyone to implement option 3, then that would impose 
additional burden on the vendors that they have already implemented to support 
both formats/length with the same code point. I agree that if we weren’t in the 
current situation, option 3 would have been somewhat cleaner, but at this 
point, if we go with option 3, we will be asking these vendors to do yet 
another implementation.

With regard to my RT-constraint comment, allow me to clarify it as follow: The 
RT-8 is only intended to be exchanged among multi-homing PEs and 99% of 
multi-homing scenarios are dual-homing. Furthermore, the dual-homing PEs are 
from the same vendor. This means when this route is advertised by a PE in an 
EVPN network that has 100 PEs, it uses a route-target that is for only one 
other PE. So, in a network with PE1 to PE100 where PE1 and PE2 are dual-homed 
and PE1 advertised this route, then only PE2 needs to import this route and all 
other PEs need to discard when they receive. So, let’s assume, we have a 
network where PE1 to PE 50 run the old format and the PE51 through PE100 run 
option-2 (e.g., they either support both formats or both lengths). Then, when 
PE1 wants to advertise an RT-8 intended for PE2, it will be received by PE3 to 
PE100 and they will discard the route. Now, we need to make sure if PE100 
advertises a route for PE99 (its dual-homing counterpart) with the new format, 
it doesn’t cause an issue for PE1 to PE50. These PEs can use RT-constraint to 
have the RR only send the routes that they have imports for. So, PE1 will not 
receive the RT-8 route from PE100 to cause it any issue.

Regards,
Ali




From: John Scudder 
Date: Sunday, April 26, 2020 at 12:33 PM
To: Cisco Employee 
Cc: "Mankamana Mishra (mankamis)" , "bess@ietf.org" 
, "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 

Subject: Re: 

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-irb-mcast-04

[Wen Lin]

Support as co-author.  I am unaware of any undisclosed IPRs.

Thanks,
Wen

From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Wednesday, February 26, 2020 at 9:26 AM
To: 'BESS' 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-irb-mcast-04

Hi WG,

This email starts a two weeks Working Group Last Call on 
draft-ietf-bess-evpn-irb-mcast-04 [2]

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a standards track RFC.

This poll runs until 11th March 2020.


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 one IPR disclosed.

https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-bess-evpn-irb-mcast



We are also polling for any existing implementation as per [1]. Please indicate 
if you are aware of any implementations.

 Thank you,

Stephane

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

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption and IP poll fordraft-wsv-bess-extended-evpn-optimized-ir

[Wen Lin]

Support as a co-author.  Juniper also has released code for this feature.

I am unaware of any undisclosed IPR.

Thanks,
Wen

From: BESS  on behalf of "UTTARO, JAMES" 
Date: Tuesday, February 4, 2020 at 9:34 AM
To: "ext-zhang.zh...@zte.com.cn" , 
"slitkows.i...@gmail.com" 
Cc: "draft-wsv-bess-extended-evpn-optimized...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: [bess] WG adoption and IP poll 
fordraft-wsv-bess-extended-evpn-optimized-ir

Support

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of zhang.zh...@zte.com.cn
Sent: Tuesday, February 04, 2020 9:00 AM
To: slitkows.i...@gmail.com
Cc: bess-cha...@ietf.org; draft-wsv-bess-extended-evpn-optimized...@ietf.org; 
bess@ietf.org
Subject: Re: [bess] WG adoption and IP poll 
fordraft-wsv-bess-extended-evpn-optimized-ir


I read this draft and support the adoption.



Thanks,

Sandy


原始邮件
发件人：slitkows.i...@gmail.com 
mailto:slitkows.i...@gmail.com>>
收件人：'BESS' 
mailto:bess@ietf.org>>;draft-wsv-bess-extended-evpn-optimized...@ietf.org
 
mailto:draft-wsv-bess-extended-evpn-optimized...@ietf.org>>;
抄送人：bess-cha...@ietf.org 
mailto:bess-cha...@ietf.org>>;
日 期 ：2020年02月04日 21:50
主 题 ：[bess] WG adoption and IP poll fordraft-wsv-bess-extended-evpn-optimized-ir
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
Hi,

This email begins a two-weeks WG adoption poll for 
draft-wsv-bess-extended-evpn-optimized-ir [1]
Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently, there are no IPR disclosures against this document.

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.

This poll for adoption closes on 18th Feb 2020.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-wsv-bess-extended-evpn-optimized-ir/


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption and IPR Poll for draft-brissette-bess-evpn-mh-pa-04

[Wen Lin]

Support the WG adoption, but please address the question raised below.

Thank you,
Wen

From: BESS  on behalf of Krzysztof Grzegorz Szarkowicz 

Date: Tuesday, January 21, 2020 at 3:08 PM
To: Luc André Burdet 
Cc: "draft-brissette-bess-evpn-mh...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-brissette-bess-evpn-mh-pa-04

Hi Luc,

Restricting Modulo function to octets 3-7, means, we are restricting optimized 
operation of draft-brissette-bess-evpn-mh-pa-04 to deployments, where ESI is 
differentiated within the subset of octets specified in this draft. While I 
agree, that best practice is to differentiate ESIs within octets 1-6 (or 2-7 -> 
depending how we number them), I see no reason to put such restriction, as I 
don’t see any complexity here, when all 10 octets are used instead of 5 octets.

My teenager son, who just recently started to learn python, has prepared python 
script to calculate IBAN (International Back Account Number) CHECKSUM 
(https://www.iban.com/iban-checker):

IBAN CHECKSUM
This is the first and most important check we perform.
The IBAN check digit consists of two digits in positions 3 and 4 of the IBAN.
It is calculated using the MOD97 algorithm and provides the primary integrity 
check for the IBAN standard.
Supported for all 116 countries.


within 20 minutes (and the script has only 8 lines). And, IBANs are longer (up 
to 24 digits).


So, what is the complexity here, that would mandate to restrict the Modulo 
function to 5 octets only?



Regards,
Krzysztof Grzegorz Szarkowicz
Juniper Networks





On 2020 -Jan-21, at 19:05, Luc André Burdet 
mailto:laburdet.i...@gmail.com>> wrote:

Hi Krystof,

Already tracking issue #1 for update, thanks for picking it up though

Issue #2 we’ve discussed before but the entropy here is meant to provide some 
delta “between ES” for DF... RFC7432 modulo doesn’t go into complicated HRW and 
this should not either...

  *   The specific set of bytes chosen are supposed to vary some but don’t have 
to vary tremendously. VLAN-ID/EVI in 7432 doesn’t very tremendously either.
  *   The byte(s) definitely vary more than byte 10 in previous versions which, 
for some ESI types, is 00...
Why use 10 bytes for an even/odd decision on 2PE when basically... one is 
enough? I don’t see the need to bring in HRW’s complexity to simply match 
RFC7432 DF-modulo.
FYI we have added a section specifically addressing HRW df-mode.

Regards,
Luc André Burdet |  Cisco  |  
laburdet.i...@gmail.com  |  Tel: +1 613 254 4814


From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Krzysztof Grzegorz Szarkowicz 
mailto:kszarkow...@gmail.com>>
Date: Tuesday, January 21, 2020 at 12:19
Cc: 
"draft-brissette-bess-evpn-mh...@ietf.org"
 
mailto:draft-brissette-bess-evpn-mh...@ietf.org>>,
 "bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-brissette-bess-evpn-mh-pa-04

Hello,


I have two comments regarding section 4.2


Comment 1:

draft-brissette-bess-evpn-mh-pa-04: “ES-Import RT community inherits from ESI 
only byte 1-7,”

As per RFC 7432, ES-Import RT community inherits from ESI only 6 (not 7, as in 
draft-brissette-bess-evpn-mh-pa-04) octets from ESI






Comment 2:



What is the benefit of restricting Modulo calculation to 5 octets only 
(draft-brissette-bess-evpn-mh-pa-04 specifies here octets 3-7), instead of 
taking all 9 (or even all 10) octets into account. For example, for HRW, RFC 
8584 already describes computing a 32 bit CRC over the concatenation of 
Ethernet Tag and ESI, so *all 10* ESI octets are used for better entropy. What 
is the benefit of restricting here for only subset of ESI octets?



Thanks,
Krzysztof




On 2020 -Jan-21, at 17:58, Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:

Support – though I’ve always thought MC-LAG was a hack, it is part of the 
landscape.
Thanks,
Acee

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
"Bocci, Matthew (Nokia - GB)" 
mailto:matthew.bo...@nokia.com>>
Date: Tuesday, January 21, 2020 at 9:51 AM
To: "bess@ietf.org" mailto:bess@ietf.org>>
Cc: 
"draft-brissette-bess-evpn-mh...@ietf.org"
 
mailto:draft-brissette-bess-evpn-mh...@ietf.org>>,
 "bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>
Subject: [bess] WG Adoption and IPR Poll for draft-brissette-bess-evpn-mh-pa-04

Hello,

This email begins a two-weeks WG adoption poll for 
draft-brissette-bess-evpn-mh-pa-04 [1] .

Please review the draft and post any comments to the BESS working group list.

We are also polling for 

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-pref-df

[Wen Lin]

Support as a co-author.  We don’t have any un-disclosed IPR.

Thanks,
Wen

From: "slitkows.i...@gmail.com" 
Date: Monday, November 4, 2019 at 8:57 AM
To: "bess@ietf.org" , "draft-ietf-bess-evpn-pref...@ietf.org" 
, Wen Lin , Antoni 
Przygienda 
Subject: RE: WGLC, IPR and implementation poll for draft-ietf-bess-evpn-pref-df

Hi Authors,

The poll is ending soon, and if I’m not mistaken, I’m missing the IPR poll 
replies from Tony P. and Wen L.

Tony, Wen,

Could you please reply to the IPR poll ?

Thanks !


From: slitkows.i...@gmail.com 
Sent: mardi 22 octobre 2019 16:46
To: bess@ietf.org; draft-ietf-bess-evpn-pref...@ietf.org
Cc: bess-cha...@ietf.org
Subject: WGLC, IPR and implementation poll for draft-ietf-bess-evpn-pref-df

Hello WG,

This email starts a two weeks Working Group Last Call on 
draft-ietf-bess-evpn-pref-df-04 [1].

This poll runs until * the 5th 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-pref-df/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/__;!8WoA6RjC81c!Xpl_39s9KfcTL0avekAJ22CtJyZ1CrUpNmMmoPNipJmaCXxzjIoubocYgaThWA$>
[2] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw__;!8WoA6RjC81c!Xpl_39s9KfcTL0avekAJ22CtJyZ1CrUpNmMmoPNipJmaCXxzjIoubodvmekTHw$>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-pref-df

[Wen Lin]

Support, and I am unaware of any IPR.

Thanks,
Wen

From: "slitkows.i...@gmail.com" 
Date: Tuesday, October 22, 2019 at 10:46 AM
To: "bess@ietf.org" , "draft-ietf-bess-evpn-pref...@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: WGLC, IPR and implementation poll for draft-ietf-bess-evpn-pref-df
Resent-From: 
Resent-To: , , 
, , , 
, 
Resent-Date: Tuesday, October 22, 2019 at 10:46 AM

Hello WG,

This email starts a two weeks Working Group Last Call on 
draft-ietf-bess-evpn-pref-df-04 [1].

This poll runs until * the 5th 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-pref-df/
[2] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect

[Wen Lin]

Support.  It is a very useful to EVPN.

Wen

From: BESS  on behalf of "Oya Luengo, Roberto (Nokia - 
US/Mountain View)" 
Date: Wednesday, October 2, 2019 at 2:01 PM
To: Stephane Litkowski , 
"stephane.litkow...@orange.com" 
Cc: "draft-snr-bess-evpn-loop-prot...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-snr-bess-evpn-loop-protect

Support


From: BESS  On Behalf Of Stephane Litkowski
Sent: Thursday, September 19, 2019 16:06
To: stephane.litkow...@orange.com
Cc: draft-snr-bess-evpn-loop-prot...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-snr-bess-evpn-loop-protect

Hi,

The poll has ended.
I haven't seen a lot of support from the various vendor while Jorge has 
mentioned that there are multiple implementations. Before closing definitely 
this poll, I would like to let the opportunity to other vendors to raise their 
voice and support the draft especially if they have implementations.
I will let an additional week.

Stephane


On Mon, Sep 2, 2019 at 4:29 PM 
mailto:stephane.litkow...@orange.com>> wrote:
Hi,

This email begins a two-weeks WG adoption poll for 
draft-snr-bess-evpn-loop-protect-04 [1]
Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently, there are no IPR disclosures against this document.

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.

This poll for adoption closes on 16th September 2019.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-snr-bess-evpn-loop-protect/




[Orange 
logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_



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
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-igmp-mld-proxy

[Wen Lin]

Support,  I am unaware of any undisclosed IPR.

Thanks,
Wen

From: BESS  on behalf of Krzysztof Szarkowicz 

Date: Monday, June 24, 2019 at 4:04 PM
To: "" 
Cc: "bess-cha...@ietf.org" , "bess@ietf.org" 

Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-igmp-mld-proxy




On 2019-Jun-17, at 10:53, 
stephane.litkow...@orange.com wrote:

Hello Working Group,

This email starts a three weeks Working Group Last Call on  
draft-ietf-bess-evpn-igmp-mld-proxy [1].

This poll runs until *the 28th of June*.

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.

We have several IPRs already 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-igmp-mld-proxy/
[2] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw



[Orange 
logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_



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
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

___
BESS mailing list
BESS@ietf.org

Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-evpn-na-flags-03

[Wen Lin]

Support.

Thanks,
Wen

From: Krzysztof Szarkowicz 
Date: Friday, June 7, 2019 at 12:05 PM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" , 
"draft-ietf-bess-evpn-na-fl...@ietf.org" 

Subject: Re: [bess] WG Last Call and IPR Poll for 
draft-ietf-bess-evpn-na-flags-03
Resent-From: 
Resent-To: , , 
, 
Resent-Date: Friday, June 7, 2019 at 12:05 PM

I support this draft. Not aware of any related IPR.

Regards,
Krzysztof



On 2019-Jun-07, at 15:44, Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>> wrote:

This email begins a two-week working group last call for 
draft-ietf-bess-evpn-na-flags-03.txt

Please review the draft and post any comments to the BESS working group list. 
Please also indicate if you support or do not support publishing the draft as 
an RFC.

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, copying the BESS mailing list. 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.

We are also polling for any existing implementations.

The working group last call closes on Friday 21st June 2019.

Regards,
Matthew and Stéphane



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Question about draft-rbickhart-evpn-ip-mac-proxy-adv

[Wen Lin]

Hi Sandy,

Also for inter-subnet traffic, if there is no trace of MAC/IP in the EVPN 
network due PE1 node/access link failure, PE4 cannot just use flood to reach 
the destination host - PE4 has to ARP first to find out MAC/IP binding before 
it can send traffic to the destination host.

Thanks,
Wen

From: BESS  on behalf of Ryan Bickhart 

Date: Friday, March 29, 2019 at 3:39 PM
To: Sandy Breeze , "bess@ietf.org" 

Subject: Re: [bess] Question about draft-rbickhart-evpn-ip-mac-proxy-adv

Hi Sandy,

It is intentional that PE4 sees an RT2 for the CE1 MAC/IP advertised from PE2 
and PE3 as well as PE1. The reason is that we want to cover the transition 
cases of link or node failure occurring on PE1. PE4 might be using CE1's IP 
carried in the RT2 for IRB or routing purposes and it is desirable for PE4 to 
maintain constant awareness of the existence of the CE1 IP across failures on 
PE1. Under normal 7432 behavior, if PE1 were the only PE advertising the RT2 
for CE1's MAC/IP and PE1's link to the multihomed site goes down, PE1 might 
withdraw the RT2 before PE2/PE3 are able to learn the CE1 IP->MAC binding in 
the data plane and advertise it as a RT2 to PE4. By having PE2/PE3 originate 
the proxy advertisements, we avoid the case where the CE1 MAC/IP might 
completely disappear and later reappear in the EVPN when there is a failure on 
PE1. (Maybe a general L2 way of phrasing this concept is that you can do 
aliasing only for entities that you know about. If there is no trace of a MAC's 
existence left in the EVPN, you would flood rather than use aliasing.)

Thanks,
-Ryan




Juniper Internal
From: BESS  On Behalf Of Sandy Breeze
Sent: Thursday, March 28, 2019 3:53 AM
To: bess@ietf.org
Subject: [bess] Question about draft-rbickhart-evpn-ip-mac-proxy-adv

Hi Wen,

First, thank you for this work, I see the problem you’re trying to solve and 
support trying to do that.  I have some questions.

Lets say for example, PEs: 1,2,3 have CE1 attached on the same all-active ES.  
PE4 is a remote PE participating in the same EVPN.  CE1’s MAC/IP is learned in 
the dataplane by PE1 only, and PE1 originates the RT2 initially.

At this point, with standard 7432 mechanisms, PE4 can already have aliasing and 
backup paths to CE1 via PEs 2 and 3 without the need to see an RT2 from either 
PE2 or PE3.  What PE2 and PE3 might be missing locally, however, is ARP/ND 
state for CE1, which is and which your draft looks to solve in BGP.  (If my 
understanding is correct?)

Now if PE2 and PE3 support the proxy-adv mechanism, then they sync ARP/ND upon 
receipt of the RT2 from PE1.  Why do PE2 and PE3 then need to originate their 
own RT2?  If they originate RT2’s then this can influence the forwarding 
decisions at other remote PE’s like PE4, who lets say doesn’t understand the 
proxy-adv bit in the ARP/ND extended community and will see the RT2 as 
originating from 3 different PE’s.  Is that the intention of the draft or just 
a consequence?  Or is it the intention to keep the proxy-adv mechanism for use 
amongst the multihomed PE’s only?

Thanks
Sandy

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Mail regarding draft-rbickhart-evpn-ip-mac-proxy-adv

[Wen Lin]

Hi James,

Thank you for your comments.  Please see replies inline below.

Thanks,
Wen

From: "UTTARO, JAMES" 
Date: Wednesday, March 27, 2019 at 12:20 PM
To: "draft-rbickhart-evpn-ip-mac-proxy-...@ietf.org" 

Cc: "bess@ietf.org" 
Subject: Mail regarding draft-rbickhart-evpn-ip-mac-proxy-adv
Resent-From: 
Resent-To: , , , 

Resent-Date: Wednesday, March 27, 2019 at 12:20 PM

Wen,

  A few comments.

  I think I understand the why of this draft. One could take the 
view that a MAC/IP learned via a single PE on an ESI has actually gone away and 
will not be re-learned via other PEs on said ESI.. In that case incorrectness 
is being injected into the VPN state machine for said customer for as long as 
it takes the timer to expire. Is that right??

Wen:  This solution is more useful if the MAC/IP can be re-learned through the 
data plane by other PE(s) attached to the same multihoming ES.

Generally speaking state learned via the control plane is never allowed to be 
re-advertised so PE1->PE2->PEX is disallowed. I am assuming that split horizon 
will be disabled for a MAC/IP learned from PE1 advertised to PE2, subsequently 
advertised to PE3 ( Actually everywhere ) as the ESI is in common.

Wen:  This is about PE2 originates, instead of re-advertising, a type-2 MAC+IP 
advertisement based on the knowledge that the said MAC is learned in the data 
plane from its locally attached multihomed ES, but through its peer PE(s).  
Also in this case PE2 sets a proxy bit for the type2 MAC+IP route it originates.

You could also use BGP Persistence on PE3.. PE3 would enable persistence on 
MAC/IP:NH=PE1, ESI10 if ESI10 is also available at PE2.. In this manner PE3 
would continue sending traffic to MAC/IP via PE2 as long as the ESI is valid 
and the timer on PE3 did not expire.

Wen:  Yes, other mechanism(s) can be used to close this gap and avoid traffic 
loss. The proposed solution in this draft uses EVPN method among multihomed PEs 
and it does not rely on actions of other remote PEs that are not attached to 
the same multihomed ES while at the same avoid traffic loss for traffic 
destined to that MAC (assuming this MAC is not moved.)


Thanks,
  Jim Uttaro




___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Slot requests for BESS WG session - IETF 104 - Prague

[Wen Lin]

Hi Mankamana,

I would like to request a slot for the following draft:
draft: draft-wsv-bess-extended-evpn-optimized-ir-01
duration: 10 min

Thanks,
Wen


From: BESS  on behalf of "Mankamana Mishra (mankamis)" 

Date: Monday, February 25, 2019 at 11:53 AM
To: "bess@ietf.org" 
Subject: [bess] Slot requests for BESS WG session - IETF 104 - Prague

All,

It is time we start building the BESS WG agenda for IETF 104 Prague.

Please send us your request for a presentation slot , indicating draft name, 
speaker, and desired duration (covering presentation and discussion). If it is 
not the first presentation of the draft, please give a reason why it is 
required to have a new presentation slot.

Preliminary agenda can be found at :
https://datatracker.ietf.org/meeting/104/agenda.html


Thank you

Mankamana , Stephane & Matthew

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Bier] FW: WG adoption poll fordraft-zzhang-bess-mvpn-evpn-aggregation-label-01

[Wen Lin]

Support the adoption.

I am not aware of any relevant undisclosed IPR.

Thanks,
Wen
From: BESS  On Behalf Of stephane.litkow...@orange.com
Sent: Tuesday, October 30, 2018 4:22 PM
To: bess@ietf.org
Subject: [bess] WG adoption poll for 
draft-zzhang-bess-mvpn-evpn-aggregation-label-01

Hi WG,

This email begins a two-week poll for BESS working group adoption 
draft-zzhang-bess-mvpn-evpn-aggregation-label-01 [1]

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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, copying  the BESS mailing list. 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.

The poll for working group adoption closes on Tue 13th November.

Regards,
Stéphane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-zzhang-bess-mvpn-evpn-aggregation-label/





[Orange 
logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_



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
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption and IPR poll for draft-sajassi-bess-evpn-vpws-fxc-03.txt

[Wen Lin]

Support as a co-author for WG adoption of this draft.

Thanks,
Wen

From: BESS  On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Monday, April 9, 2018 9:23 AM
To: draft-sajassi-bess-evpn-vpws-...@ietf.org; bess@ietf.org
Subject: [bess] WG adoption and IPR poll for 
draft-sajassi-bess-evpn-vpws-fxc-03.txt

This email begins a two-week poll for BESS working group adoption of 
draft-sajassi-bess-evpn-vpws-fxc-03.txt.

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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, copying the BESS mailing list. 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.

The poll for working group adoption closes on Monday 23rd April.

Regards,
Matthew and Stéphane

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

[Wen Lin]

Hi Sandy,

Yes, you can have all remote VTEPs share the same virtual ES.  The other 
alternative is that each remote VTEP is assigned with its own virtual ES, so 
that we can achieve load balance and quick mass withdrawal when a remote VTEP 
is no longer reachable.

Thanks,
Wen

From: Sandy Breeze <sandy.bre...@eu.clara.net>
Date: Wednesday, April 4, 2018 at 6:07 AM
To: Wen Lin <w...@juniper.net>, "Ali Sajassi (sajassi)" <saja...@cisco.com>, 
"UTTARO, JAMES" <ju1...@att.com>, John E Drake <jdr...@juniper.net>, "Rabadan, 
Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, Eric Rosen 
<ero...@juniper.net>, "Satya Mohanty (satyamoh)" <satya...@cisco.com>
Cc: "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Hi Wen,

Yes, we absolutely need to support more than one remote VTEP in the access 
side.  As for how to deal with one or more than one remote VTEP, I don’t agree 
it’s quite the same as one CE vs more than one CE.  For a single VNI in a BD, 
we should treat this as a single virtual ES in a BD, regardless of how many 
remote VTEPs there are participating in it.  This is treated differently to 
multiple CE on a BD, because multiple CE might imply multiple ES’s.

Cheers
Sandy

On 03/04/2018, 19:01, "Wen Lin" <w...@juniper.net<mailto:w...@juniper.net>> 
wrote:

The question is, in general,  whether we need to support more than one remote 
VTEP in this type of use case when VXLAN is used on the access side?   I think 
the answer is yes.

So the question about how to deal with “one remote VTEP verses more than one 
remote VTEP” is logically the same as “one CE verses more than one CE”.

Thanks,
Wen


From: BESS <bess-boun...@ietf.org> on behalf of "Ali Sajassi (sajassi)" 
<saja...@cisco.com>
Date: Monday, March 26, 2018 at 2:54 PM
To: "UTTARO, JAMES" <ju1...@att.com>, John E Drake <jdr...@juniper.net>, 
"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, Eric 
Rosen <ero...@juniper.net>, Sandy Breeze <sandy.bre...@eu.clara.net>, "Satya 
Mohanty (satyamoh)" <satya...@cisco.com>
Cc: "Ali Sajassi (sajassi)" <saja...@cisco.com>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Hi Jim,

Draft-mohanty-bess-evpn-bum-opt is for a very specific use case and that use 
case is described in section 4.4 of draft-ietf-bess-dci-evpn-overlay. The 
solution for optimization for this use case could have been covered either in 
igmp-mld-proxy draft itself or it could be covered in a separate draft. I 
suggested it to be covered in a separate draft because I wasn’t keen in adding 
a new section to igmp-mld-proxy given that it is getting ready for WG LC. 
However, if people think it should be covered in igmp-mld-proxy draft then we 
can take that under consideration.

The interconnect of L2 to IRB/L3 core will be covered in the corresponding IRB 
mcast drafts.

Cheers,
Ali

From: "UTTARO, JAMES" <ju1...@att.com>
Date: Monday, March 26, 2018 at 10:46 AM
To: Cisco Employee <saja...@cisco.com>, John E Drake <jdr...@juniper.net>, 
"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, Eric 
Rosen <ero...@juniper.net>, Sandy Breeze <sandy.bre...@eu.clara.net>, "Satya 
Mohanty (satyamoh)" <satya...@cisco.com>
Cc: "bess@ietf.org" <bess@ietf.org>
Subject: RE: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Ali,

So, is this going to be a family of drafts dealing with 
inter-connection aspects across a set of use cases ? Would it be useful to 
right up a requirements draft like we did with EVPN??

Thanks,
Jim Uttaro

From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Monday, March 26, 2018 1:20 PM
To: UTTARO, JAMES <ju1...@att.com>; John E Drake <jdr...@juniper.net>; Rabadan, 
Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>; Eric Rosen 
<ero...@juniper.net>; Sandy Breeze <sandy.bre...@eu.clara.net>; Satya Mohanty 
(satyamoh) <satya...@cisco.com>
Cc: bess@ietf.org
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Hi Jim,

draft-mohanty-bess-evpn-bum-opt will focus on L2 only between EVPN overlay 
(VxLAN) access domain and EVPN MPLS core. Connectivity EVPN IRB core (or EVPN 
L3 core) will be covered in the other drafts that I mentioned below because 
they are  already doing it for other use cases.

Cheers,
Ali

From: "UTTARO, JAMES" <ju1...@att.com<mailto:ju1...@att.com>>
Date: Monday, March 26, 2018 at 10:03 AM
To: Cisco Emp

Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

[Wen Lin]

Support.

Thanks,
Wen

From: BESS  On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Wednesday, March 28, 2018 8:50 AM
To: draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WG Last Call and IPR Poll for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

This email begins a two-week working group last call for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently there is one IPR declaration against this document.

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 implementations.

The working group last call closes on Wednesday 11th April.

Regards,

Matthew and Stéphane
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

[Wen Lin]

The question is, in general,  whether we need to support more than one remote 
VTEP in this type of use case when VXLAN is used on the access side?   I think 
the answer is yes.

So the question about how to deal with “one remote VTEP verses more than one 
remote VTEP” is logically the same as “one CE verses more than one CE”.

Thanks,
Wen


From: BESS  on behalf of "Ali Sajassi (sajassi)" 

Date: Monday, March 26, 2018 at 2:54 PM
To: "UTTARO, JAMES" , John E Drake , 
"Rabadan, Jorge (Nokia - US/Mountain View)" , Eric 
Rosen , Sandy Breeze , "Satya 
Mohanty (satyamoh)" 
Cc: "Ali Sajassi (sajassi)" , "bess@ietf.org" 
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Hi Jim,

Draft-mohanty-bess-evpn-bum-opt is for a very specific use case and that use 
case is described in section 4.4 of draft-ietf-bess-dci-evpn-overlay. The 
solution for optimization for this use case could have been covered either in 
igmp-mld-proxy draft itself or it could be covered in a separate draft. I 
suggested it to be covered in a separate draft because I wasn’t keen in adding 
a new section to igmp-mld-proxy given that it is getting ready for WG LC. 
However, if people think it should be covered in igmp-mld-proxy draft then we 
can take that under consideration.

The interconnect of L2 to IRB/L3 core will be covered in the corresponding IRB 
mcast drafts.

Cheers,
Ali

From: "UTTARO, JAMES" 
Date: Monday, March 26, 2018 at 10:46 AM
To: Cisco Employee , John E Drake , 
"Rabadan, Jorge (Nokia - US/Mountain View)" , Eric 
Rosen , Sandy Breeze , "Satya 
Mohanty (satyamoh)" 
Cc: "bess@ietf.org" 
Subject: RE: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Ali,

So, is this going to be a family of drafts dealing with 
inter-connection aspects across a set of use cases ? Would it be useful to 
right up a requirements draft like we did with EVPN??

Thanks,
Jim Uttaro

From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Monday, March 26, 2018 1:20 PM
To: UTTARO, JAMES ; John E Drake ; Rabadan, 
Jorge (Nokia - US/Mountain View) ; Eric Rosen 
; Sandy Breeze ; Satya Mohanty 
(satyamoh) 
Cc: bess@ietf.org
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Hi Jim,

draft-mohanty-bess-evpn-bum-opt will focus on L2 only between EVPN overlay 
(VxLAN) access domain and EVPN MPLS core. Connectivity EVPN IRB core (or EVPN 
L3 core) will be covered in the other drafts that I mentioned below because 
they are  already doing it for other use cases.

Cheers,
Ali

From: "UTTARO, JAMES" >
Date: Monday, March 26, 2018 at 10:03 AM
To: Cisco Employee >, John E Drake 
>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" >, 
Eric Rosen >, Sandy Breeze 
>, "Satya Mohanty 
(satyamoh)" >
Cc: "bess@ietf.org" >
Subject: RE: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Ali,

So is the plan to incorporate Sandy’s work in these docs??

Thanks,
Jim Uttaro


From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Monday, March 26, 2018 11:55 AM
To: UTTARO, JAMES >; John E Drake 
>; Rabadan, Jorge (Nokia - 
US/Mountain View) >; 
Eric Rosen >; Sandy Breeze 
>; Satya Mohanty 
(satyamoh) >
Cc: bess@ietf.org; Ali Sajassi (sajassi) 
>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description


Hi Jim,

Wrt multicast for L2 EVPN<-> L3 EVPN, that should be covered in corresponding 
EVPN multicast drafts:

Re: [bess] Call for adoption: draft-lin-bess-evpn-irb-mcast

[Wen Lin]

Support as co-author. Not aware of any IPR related to this draft.

Thanks,
Wen

On 1/11/18, 5:11 AM, "Martin Vigoureux"  wrote:

Hello working group,

This email starts a two-week call for adoption on 
draft-lin-bess-evpn-irb-mcast-04 [1] as a BESS Working Group Document.

Please state on the list if you support the adoption or not (in both 
cases, please also state the reasons).

This poll runs until *the 26th of January*.

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.

Currently no IPR has been disclosed against this Document.

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

Martin & Stéphane
bess chairs

[1] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dlin-2Dbess-2Devpn-2Dirb-2Dmcast_=DwID-g=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=VKPMoMVnuS9PMdvfBjjfWg=oyRuYflevkVly5GLhFnn2crPk4MY0uULdCa4Pc85U6k=kJJD1ON8TZnrmzYXhBkvntt1DZmzmJBy9GQnUxXMQjg=


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call for draft-ietf-bess-evpn-optimized-ir

[Wen Lin]

Support.  Not aware of any IPR.

From: BESS > on behalf of 
Aldrin Isaac >
Date: Friday, June 16, 2017 at 9:09 PM
To: Ravi Shekhar >, "Rabadan, 
Jorge (Nokia - US/Mountain View)" 
>, "EXT - 
thomas.mo...@orange.com" 
>, BESS 
>, 
"draft-ietf-bess-evpn-optimized...@ietf.org"
 
>
Subject: Re: [bess] WG Last Call for draft-ietf-bess-evpn-optimized-ir

Yes -- support for publication.

Cheers,
Aldrin

Sent using OWA for iPhone

From: Ravi Shekhar >
Sent: Friday, June 16, 2017 11:46:10 AM
To: Rabadan, Jorge (Nokia - US/Mountain View); EXT - 
thomas.mo...@orange.com; BESS; 
draft-ietf-bess-evpn-optimized...@ietf.org
Subject: RE: WG Last Call for draft-ietf-bess-evpn-optimized-ir

Support as co-author as well. Not aware of any IPR.
- Ravi Shekhar.

-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Rabadan, Jorge (Nokia - 
US/Mountain View)
Sent: Friday, June 16, 2017 11:35 AM
To: EXT - thomas.mo...@orange.com 
>; BESS 
>; 
draft-ietf-bess-evpn-optimized...@ietf.org
Subject: Re: [bess] WG Last Call for draft-ietf-bess-evpn-optimized-ir

Support this document for Standard Track RFC publication as co-author.
Not aware of any IPR.

Already mentioned, Nokia SROS has an implementation.

Thank you.
Jorge


On 6/16/17, 3:43 PM, "thomas.mo...@orange.com" 
> wrote:

Hello Working Group,

This email starts a Working Group Last Call on
draft-ietf-bess-evpn-optimized-ir-01 [1] which is considered mature and
ready for a final working group review.

Please read this document if you haven't read the most recent version
yet, and send your comments to the list, no later than *30th of June*.
Note that this is *not only* a call for comments on the document; it is
also a call for support (or not) to publish this document as a Standard
Track RFC.

*Coincidentally*, we are also polling for knowledge of any IPR that
applies to draft-ietf-bess-evpn-optimized-ir, 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 a document Author or Contributor of the draft
please respond to this email and indicate whether or not you are aware
of any relevant IPR.

Note that, as of today, no IPR has been disclosed against this document
or its earlier versions.

We are **also polling for knowledge of implementations** of part or all
of what this document specifies. This information is expected as per [2].
Please inform the mailing list, or the chairs, or only one of the chairs.

Thank you,
T

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



_

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
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call for draft-ietf-bess-dci-evpn-overlay-04

[Wen Lin]

Support and not aware of IPR related to this draft either.

Thanks,
Wen

On 2/7/17, 6:06 PM, "BESS on behalf of Henderickx, Wim (Nokia - BE)" 
 wrote:

Support, not aware of IPR related to this draft

On 07/02/2017, 07:42, "BESS on behalf of Dolganow, Andrew (Nokia - SG)" 
 wrote:

Support

Andrew

Sent from my iPhone

> On Feb 6, 2017, at 10:07 PM, Martin Vigoureux 
 wrote:
> 
> Hello Working Group,
> 
> This email starts a Working Group Last Call on 
draft-ietf-bess-dci-evpn-overlay-04 [1] which is considered mature and ready 
for a final working group review.
> 
> Please read the document if you haven't read the most recent
> version yet, and send your comments to the list, no later than
> *19th of February*.
> Note that this is *not only* a call for comments on the document; it 
is also a call for support (or not) to publish this document as a Proposed 
Standard RFC.
> 
> *Coincidentally*, we are also polling for knowledge of any IPR that 
applies to draft-ietf-bess-dci-evpn-overlay, 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 a document author or contributor of
> draft-ietf-bess-dci-evpn-overlay-04 please respond to this email and 
indicate whether or not you are aware of any relevant IPR.
> 
> Note that IPR exists and has been disclosed against this document [2].
> 
> Thank you,
> M
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-dci-evpn-overlay/
> [2] 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-bess-dci-evpn-overlay
> 
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [ALU] WG Last Call for draft-ietf-bess-dci-evpn-overlay-04

[Wen Lin]

Support.

Thanks,
Wen

On 2/7/17, 1:56 PM, "BESS on behalf of Oya Luengo, Roberto (Nokia - US)" 
 wrote:

Support

On 2/6/17, 5:07 AM, "BESS on behalf of Martin Vigoureux"
 wrote:

>Hello Working Group,
>
>This email starts a Working Group Last Call on
>draft-ietf-bess-dci-evpn-overlay-04 [1] which is considered mature and
>ready for a final working group review.
>
>Please read the document if you haven't read the most recent
>version yet, and send your comments to the list, no later than
>*19th of February*.
>Note that this is *not only* a call for comments on the document; it is
>also a call for support (or not) to publish this document as a Proposed
>Standard RFC.
>
>*Coincidentally*, we are also polling for knowledge of any IPR that
>applies to draft-ietf-bess-dci-evpn-overlay, 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 a document author or contributor of
>draft-ietf-bess-dci-evpn-overlay-04 please respond to this email and
>indicate whether or not you are aware of any relevant IPR.
>
>Note that IPR exists and has been disclosed against this document [2].
>
>Thank you,
>M
>
>[1] https://datatracker.ietf.org/doc/draft-ietf-bess-dci-evpn-overlay/
>[2] 
>https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-bess-d
>ci-evpn-overlay
>
>___
>BESS mailing list
>BESS@ietf.org
>https://www.ietf.org/mailman/listinfo/bess

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Call for adoption: draft-sajassi-bess-evpn-igmp-mld-proxy-01

[Wen Lin]

Support as a co-author.

Thanks,
Wen

On 1/31/17, 9:58 AM, "Thomas Morin"  wrote:

Hello working group,

This email starts a two-week poll on adopting 
draft-sajassi-bess-evpn-igmp-mld-proxy-01 [1] as a working group item.

Please send comments to the list and state if you support adoption or 
not (in the later case, please also state the reasons).

This poll runs until **February 14th**.

*Coincidentally*, we are also polling for knowledge of any IPR that 
applies to this draft, 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 a document author or contributor please 
respond to this email and indicate whether or not you are aware of any 
relevant IPR.

The draft will not be adopted until a response has been received from 
each author and contributor.

If you are not listed as an author or 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,

Martin & Thomas
bess chairs

[1] 
https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-igmp-mld-proxy-01


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Slots requests for BESS WG session - IETF 95 - Buenos Aires

[Wen Lin]

Hi Martin, Thomas,

We would like to request a slot for:

draft-lin-bess-evpn-irb-mcast-02: Speaker: Wen,  10 minutes.

Thanks,
Wen


On Mon, Mar 7, 2016 at 4:18 AM, Martin Vigoureux 
> wrote:
All,

it is time we start building the BESS WG agenda for Buenos Aires.
The IETF agenda is available at:
https://datatracker.ietf.org/meeting/95/agenda.html
Please note that it is still a preliminary agenda.

The BESS WG session (2h) is currently scheduled on
Thursday, 7th of April, Afternoon session I 14:00-16:00 (local time)

Please send us your request for a presentation slot, indicating:
draft name, speaker and desired duration (covering presentation + discussion)

Please send the requests no later than the 20th of March
Thank you

M

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call on draft-ietf-bess-evpn-etree

[Wen Lin]

Fully support as a co-author. I am not aware of any un-disclosed IPR.

Thanks,
Wen

>
>-Original Message-
>From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Thomas Morin
>Sent: Tuesday, January 19, 2016 2:51 AM
>To: BESS; draft-ietf-bess-evpn-et...@tools.ietf.org
>Subject: [bess] WG Last Call on draft-ietf-bess-evpn-etree
>
>Hello Working Group,
>
>This email starts a Working Group Last Call on draft-ietf-bess-evpn-etree
>[1] which is considered mature and ready for a final working group review.
>
>Please read the document if you haven't read the most recent version yet
>(-03), and send your comments to the list, no later than *February the
>2nd* (2016-02-02).
>
>This is not only a call for comments on the document, but also a call of
>support for its publication.
>
>*Coincidentally*, we are also polling for knowledge of any IPR that
>applies
>to draft-ietf-bess-evpn-etree, 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 a document author or contributor of
>draft-ietf-bess-evpn-etree please respond to this email and indicate
>whether
>or not you are aware of any relevant IPR.
>
>Thank you,
>
>Thomas/Martin
>
>[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree
>
>___
>BESS mailing list
>BESS@ietf.org
>https://www.ietf.org/mailman/listinfo/bess
>
>___
>BESS mailing list
>BESS@ietf.org
>https://www.ietf.org/mailman/listinfo/bess

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call for draft-ietf-bess-vpls-multihoming

[Wen Lin]

I am not aware of any IPR related to this draft.

Thanks,
Wen

On 7/21/15, 4:19 AM, "UTTARO, JAMES"  wrote:

>I am not aware of any IPR related to this draft
>
>Jim Uttaro
>
>-Original Message-
>From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Bhupesh Kothari
>Sent: Monday, July 20, 2015 4:56 PM
>To: bess@ietf.org
>Cc: w...@juniper.net; Senad Palislamovic; Florin Balus; Henderickx, Wim
>(Wim); Kireeti Kompella; UTTARO, JAMES;
>martin.vigour...@alcatel-lucent.com
>Subject: Re: [bess] WG Last Call for draft-ietf-bess-vpls-multihoming
>
>I'm not aware of any IPR related to this draft.
>
>Bhupesh
>
>> >> -- Forwarded message --
>> >> From: Martin Vigoureux 
>> >> Date: Fri, Jun 12, 2015 at 5:09 PM
>> >> Subject: [bess] WG Last Call for draft-ietf-bess-vpls-multihoming
>> >> To: BESS 
>> >>
>> >>
>> >> Hello
>> >>
>> >> this email starts a Working Group Last Call on
>> >> http://tools.ietf.org/html/draft-ietf-bess-vpls-multihoming
>> >> which is considered mature and ready for a last working group
>> >> review.
>> >>
>> >> Please read the document if you haven't read the most recent
>> >> version yet, and send your comments to the list, no later than
>> >> June the 26th.
>> >>
>> >> *Coincidentally*, we are also polling for knowledge of any IPR that
>> >> applies to this draft, 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 a document author or contributor* please
>> >> respond to this email and indicate whether or not you are aware of
>> >> any relevant IPR.
>> >>
>> >> The draft will not be moved forward until a response has been
>> >> received from each author and contributor.
>> >>
>> >> If you are not listed as an author or contributor, then please
>> >> explicitly respond only if you are aware of any IPR that has not
>> >> yet been disclosed in conformance with IETF rules.
>> >>
>> >> Please note that IPR has already been disclosed for this document:
>> >> https://datatracker.ietf.org/ipr/1809/
>> >>
>> >> Thank you
>> >> M
>> >>
>> >> ___
>> >> BESS mailing list
>> >> BESS@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/bess
>> >>
>> >>
>> >
>> 
>> 
>
>___
>BESS mailing list
>BESS@ietf.org
>https://www.ietf.org/mailman/listinfo/bess

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Poll for adoption: draft-sajassi-bess-evpn-etree

[Wen Lin]

Support.

Wen

__
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess