Re: [bess] Comments on the VPN Inter-AS Option BC draft

[Alexander Vainshtein]

Jorge,
Lots of thanks for a prompt response.

I tend to agree with your position.
Let's wait for a more detailed version of the draft.

Regards,
Sasha

Get Outlook for Android


From: Jorge Rabadan (Nokia) 
Sent: Wednesday, August 2, 2023 3:02:28 AM
To: Alexander Vainshtein 
Cc: bess@ietf.org ; Nitsan Dolev ; 
draft-zzhang-bess-vpn-option-bc.auth...@ietf.org 

Subject: [EXTERNAL] Re: Comments on the VPN Inter-AS Option BC draft

Sasha,

Jeffrey would want to reply to those questions, the draft would need to be 
specific about the TEA use. Personally I don’t see any issues in using the TEA 
if properly specified in this draft.

Thx
Jorge

From: Alexander Vainshtein 
Date: Tuesday, August 1, 2023 at 8:42 AM
To: Jorge Rabadan (Nokia) 
Cc: bess@ietf.org , Nitsan Dolev , 
draft-zzhang-bess-vpn-option-bc.auth...@ietf.org 

Subject: RE: Comments on the VPN Inter-AS Option BC draft

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.


Jorge,
I think that a more detailed definition of the TEA-based solution for inter-AS 
Option BC and EVPN is required.

According to RFC 9136, Encapsulation Extended Community can be attached to EVPN 
Ip Prefix routes in some cases.
And Section 4.1 of RFC 
9012
 says that the semantics of this extended community are the same as could be 
encoded in the “barebones Tunnel TLV”.

Are there valid scenarios in which Encapsulation Extended Community has to be 
attached to the EVPN IP Prefix route for the reasons defined in RFC 9136 the 
same route undergoes inter-AS Option BC handling based on the TEA, and, if yes, 
how these two usages can be clearly differentiated?

Regards, and lots of thanks in advance,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Monday, July 31, 2023 6:32 PM
To: Alexander Vainshtein ; 
draft-zzhang-bess-vpn-option-bc.auth...@ietf.org
Cc: bess@ietf.org; Nitsan Dolev 
Subject: [EXTERNAL] Re: Comments on the VPN Inter-AS Option BC draft

Hi everyone,

I mostly agree with Sasha’s points.
For completeness I’d like to add that, as I said on the mike, I believe a 
solution based on the TEA would be better (than based on multi-label NLRI). 
Reasons are:

-RFC8277 was only defined for SAFIs 1 and 128, never for EVPN

-EVPN route type 2 uses multiple labels in the NLRI already, so it would be 
simpler to use TEA.

Thanks.
Jorge

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Sunday, July 30, 2023 at 12:33 AM
To: 
draft-zzhang-bess-vpn-option-bc.auth...@ietf.org
 
mailto:draft-zzhang-bess-vpn-option-bc.auth...@ietf.org>>
Cc: bess@ietf.org mailto:bess@ietf.org>>, 
Nitsan Dolev mailto:nitsan.do...@rbbn.com>>
Subject: [bess] Comments on the VPN Inter-AS Option BC draft

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.


Hi,
A few comments on the VPN Inter-AS Option BC 
draft
 that has been presented at the BESS WG session in SF last Thursday.

I think that the draft presents an elegant and much needed solution for real 
problem.
I fully agree with the statement in the draft that “Option BC” combines the 
advantages and mitigates the disadvantages of both classic “Option B” and 
“classic” Option C.
I also think that “Option BC” provides a viable alternative to both emerging 
solutions for intent-driven service mapping  (BGP Classful Transport 
Planes
 and BGP Color-Aware 
Routing),
  because it is possible to set up intent=aware inter-AS/inter-domain tunnels 
for “colored” services based on the color of the original service routes.

At the same time, I think that:

1.   As mentioned during the session, Inter-AS Option B for EVPN has its 
own issues (documented in the EVPN Inter-Domain Option B 
draft),
 and these issues fully apply to “Option BC”

2.   The draft defines two possible solutions, one based on the Tunnel 

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] Comments on the VPN Inter-AS Option BC draft

[Jorge Rabadan (Nokia)]

Sasha,

Jeffrey would want to reply to those questions, the draft would need to be 
specific about the TEA use. Personally I don’t see any issues in using the TEA 
if properly specified in this draft.

Thx
Jorge

From: Alexander Vainshtein 
Date: Tuesday, August 1, 2023 at 8:42 AM
To: Jorge Rabadan (Nokia) 
Cc: bess@ietf.org , Nitsan Dolev , 
draft-zzhang-bess-vpn-option-bc.auth...@ietf.org 

Subject: RE: Comments on the VPN Inter-AS Option BC draft

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.


Jorge,
I think that a more detailed definition of the TEA-based solution for inter-AS 
Option BC and EVPN is required.

According to RFC 9136, Encapsulation Extended Community can be attached to EVPN 
Ip Prefix routes in some cases.
And Section 4.1 of RFC 
9012 says that the 
semantics of this extended community are the same as could be encoded in the 
“barebones Tunnel TLV”.

Are there valid scenarios in which Encapsulation Extended Community has to be 
attached to the EVPN IP Prefix route for the reasons defined in RFC 9136 the 
same route undergoes inter-AS Option BC handling based on the TEA, and, if yes, 
how these two usages can be clearly differentiated?

Regards, and lots of thanks in advance,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Monday, July 31, 2023 6:32 PM
To: Alexander Vainshtein ; 
draft-zzhang-bess-vpn-option-bc.auth...@ietf.org
Cc: bess@ietf.org; Nitsan Dolev 
Subject: [EXTERNAL] Re: Comments on the VPN Inter-AS Option BC draft

Hi everyone,

I mostly agree with Sasha’s points.
For completeness I’d like to add that, as I said on the mike, I believe a 
solution based on the TEA would be better (than based on multi-label NLRI). 
Reasons are:

-RFC8277 was only defined for SAFIs 1 and 128, never for EVPN

-EVPN route type 2 uses multiple labels in the NLRI already, so it would be 
simpler to use TEA.

Thanks.
Jorge

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Sunday, July 30, 2023 at 12:33 AM
To: 
draft-zzhang-bess-vpn-option-bc.auth...@ietf.org
 
mailto:draft-zzhang-bess-vpn-option-bc.auth...@ietf.org>>
Cc: bess@ietf.org mailto:bess@ietf.org>>, 
Nitsan Dolev mailto:nitsan.do...@rbbn.com>>
Subject: [bess] Comments on the VPN Inter-AS Option BC draft

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.


Hi,
A few comments on the VPN Inter-AS Option BC 
draft
 that has been presented at the BESS WG session in SF last Thursday.

I think that the draft presents an elegant and much needed solution for real 
problem.
I fully agree with the statement in the draft that “Option BC” combines the 
advantages and mitigates the disadvantages of both classic “Option B” and 
“classic” Option C.
I also think that “Option BC” provides a viable alternative to both emerging 
solutions for intent-driven service mapping  (BGP Classful Transport 
Planes
 and BGP Color-Aware 
Routing),
  because it is possible to set up intent=aware inter-AS/inter-domain tunnels 
for “colored” services based on the color of the original service routes.

At the same time, I think that:

1.   As mentioned during the session, Inter-AS Option B for EVPN has its 
own issues (documented in the EVPN Inter-Domain Option B 
draft),
 and these issues fully apply to “Option BC”

2.   The draft defines two possible solutions, one based on the Tunnel 
Encapsulation Attribute (TEA, RFC 
9012)
 and the other based on ability to carry multiple labels in the NLRI of 
“labeled” routes as defined in RFC 
8277:

a.   My guess (FWIW) is that these solutions are not interoperable and, 
therefore, ability to support each of these options should be 

Re: [bess] RtgDir Early review: draft-ietf-bess-evpn-irb-extended-mobility-10.txt

[Neeraj Malhotra (nmalhotr)]

Hi Donald,

Many thanks for the details review and comments. I have published version 11 of 
the document that incorporates all of your comments. Please also see inline 
below for some additional clarifications.


This document repeatedly says that it may be considered a clarification of RFC 
7432. I believe it is true that the behavior specified in this document is 
permitted by RFC 7432 but other behaviors are permitted and perhaps common. In 
order to handle the mobility cases covered in this document the behaviors in 
the document would have to be implemented or some other solution adopted. Thus 
I think the title page header should show this document as updating RFC 7432 
and this should be mentioned in the Abstract and Introduction.



[NM]: Ack. I have updated the text in the abstract and introduction sections to 
say that this document updates sequence number procedures defined in [RFC7432] 
in addition to the title page header.



It seems to me that the last paragraph of Section 7.2 ignores the case where 
Mx-IPx with sequence number N movez to Mz-IPx where child IP-MACs under Mz were 
currently being advertised with sequence number M where M > N. The paragraph 
says the new Mz sequence number must be incremented to N+1 but if M>N I think 
it must be incremented to M+1. I have suggested changes to the last two 
paragraphs of Section 7.2 in the attached.



[NM]: that’s a really good catch. A later section (8) does cover this but the 
example in section 7.2 was missing this condition. Updated.



Drafts should generally be worded so the text will be correct in the final RFC. 
So both occurrences of "proposed" in this draft should be replaced by 
"specified" or "defined" and occurrences of "draft" in the body text should be 
replaced with "document".



[NM] updated.



Section 2.1 lists subsequent sections as Informative or Normative but omits 
Sections 3 and 7. I think Section 3 is Informative. The right category for 
Section 7 is a bit unclear but I'm inclined towards normative.



[NM]: Updated as above – except that I am also a bit unclear if section 7 
should be listed as normative as it is doing some ground work for the 
specifications in subsequent normative sections using some examples but is not 
meant to provide a complete specification. I have left it out for now, but 
happy to include it as normative if needed.



Section 10.2 refers to section 6.1 but there isn't any section 6.1. The bullet 
point in Section 10.2 seems essentially incomplete: What "MUST be higher than 
the "Mz" sequence number"?

In the last sentence of Section 4.3.1, it is not completely clear what "It" 
refers to. Assuming it is the interpretation in the previous sentence, I 
suggest "It could be interpreted as" -> "This interpretation could be 
considered".

"GW devices" occurs only once in this document in Section 2 and GW is never 
expanded. I suggest, assuming this is correct, that the phrase be replaced with 
"PE devices".

In section 9, since it is not expanded and not listed in the glossary, I think 
"EXT-COMM" -> "Extended Community".

Based on the usual order of RFC Sections and the RFC Editor's recommended table 
of contents, I think Sections 1 and 2 should be swapped.

The requirements language boilerplate at the beginning of Section 1 needs to be 
updated to the latest version also normatively referencing RFC 8174.



[NM]: incorporated all of the above comments and all inline changes in the 
marked-up document.



The document references RFC 7432 but I think it should reference the rfc7432bis 
draft instead.



[NM]: updated the reference link to point to RFC7432bis.



I am doubtful that there are truly no new security considerations. At a 
minimum, I would think the Security Consideration section (section 11) should 
refer readers to the Security Considerations sections of [EVPN-IRB] and 
rfc7432bis and should state that the methods specified in this document will 
increase the consumption of sequence numbers.



[NM]: added security section.



RFCs are generally limited to a maximum of five authors. This document lists 
six but does say why it needs to list that many. This could be in a first page 
note to be deleted before publication.



[NM]: missed adding this – let me wait a couple of days in case there are any 
additional comments and if not, update this by end of this week.

Nits:


Abstract: "Procedure to handle host mobility" -> "The procedure to handle host 
mobility"

Section 2, first sentence: "EVPN-IRB enables capability ..." -> "EVPN-IRB 
enables the capability ...

Section 2: "Purpose of this draft is to define additional ..." => "This 
document defines additional ... "

Section 4.3.1: "Complication with this ..." -> "The complication with this ..."

Section 8.8: "This sections is to be treated as optional ..." -> "This section 
is optional ..."

Although the above stuck out a bit more to me, there are many other nits 
including some spelling typos and a duplicated word, so I went 

[bess] I-D Action: draft-ietf-bess-evpn-irb-extended-mobility-11.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the BGP Enabled ServiceS
(BESS) WG of the IETF.

   Title   : Extended Mobility Procedures for EVPN-IRB
   Authors : Neeraj Malhotra
 Ali Sajassi
 Aparna Pattekar
 Jorge Rabadan
 Avinash Lingala
 John Drake
   Filename: draft-ietf-bess-evpn-irb-extended-mobility-11.txt
   Pages   : 25
   Date: 2023-08-01

Abstract:
   The procedure to handle host mobility in a layer 2 Network with EVPN
   control plane is defined as part of [RFC7432].  EVPN has since
   evolved to find wider applicability across various IRB use cases that
   include distributing both MAC and IP reachability via a common EVPN
   control plane.  MAC Mobility procedures defined in [RFC7432] are
   extensible to IRB use cases if a fixed 1:1 mapping between VM IP and
   MAC is assumed across VM moves.  Generic mobility support for IP and
   MAC addresses that allows these bindings to change across moves is
   required to support a broader set of EVPN IRB use cases.  EVPN all-
   active multi-homing further introduces scenarios that require
   additional consideration from mobility perspective.  This document
   enumerates a set of design considerations applicable to mobility
   across these EVPN IRB use cases and updates sequence number
   assignment procedures defined in [RFC7432] to address these IRB use
   cases.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-extended-mobility/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-11

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-evpn-irb-extended-mobility-11

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

Re: [bess] Routing Directorate early review for draft-ietf-bess-evpn-per-mcast-flow-df-election-09

[Mankamana Mishra (mankamis)]

Hi Acee,
Thanks for reviewing and comment.  While I make changes to existing draft based 
on your comments,  I had question on some of the comments

  1. Precisely explain the hashing algorithm in section 4.1 and 4.2. As
 written, they subject to multiple interpretations. Provide a reference
 to CRC_32() and expand acronyms on first use (e.g., MSB).

  2. In addition to explaining the hashing algorithm, the document should
 provide a discussion on why this hashing algorithm provides a good
 distribiution of flows.

https://datatracker.ietf.org/doc/html/rfc8584#section-3 defines most of the 
base HRW draft and its benefit . Do you expect it to be repeated in this draft 
too ? This draft does not change the base HRW algorithm but adds flow 
information as also an input parameter to calculate the weight ?

Please let me know if you want only reference to be given or content to be 
copied here ?

Mankamana

From: Acee Lindem 
Date: Friday, July 21, 2023 at 2:43 PM
To: Routing ADs , 
draft-ietf-bess-evpn-per-mcast-flow-df-elect...@ietf.org 

Cc: bess@ietf.org , Routing Directorate 
Subject: Routing Directorate early review for 
draft-ietf-bess-evpn-per-mcast-flow-df-election-09
Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see:

  http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs,
it would be helpful if you could consider them along with any other
IETF Early Review/Last Call  comments that you receive, and strive to
resolve them through discussion or by updating the draft.

Document: draft-ietf-bess-evpn-per-mcast-flow-df-election-09
Reviewer: Acee Lindem
Review Date: 07/20/2023
IETF LC End Date: N/A
Intended Status: Standards Track

Summary:
This document describes a per-multicast-flow DF election mechanism
which support per multicast flow load-balancing of the EVPN ES
forwarding amongst PEs in a redundancy group. While the document describes
a fairly straightforward function, it really needs some editing and never
should have been adopted as a WG document in this condition. Consequently,
I have entered a “Not Ready” disposition for the review.


Major Issues:
  1. Precisely explain the hashing algorithm in section 4.1 and 4.2. As
 written, they subject to multiple interpretations. Provide a reference
 to CRC_32() and expand acronyms on first use (e.g., MSB).

  2. In addition to explaining the hashing algorithm, the document should
 provide a discussion on why this hashing algorithm provides a good
 distribiution of flows.

 3. While this is a minor comment, it also pertains to the hashing
algorithm. To better distribute the flows, why not exclude the current
BUM DF from the list of PEs from which to choose a per-flow DF??


Minor Issues:

  1. Acronyms from RFC 7432 and RFC 8584 used without first expansion.
 For example, none of the acronyms in the figures are defined. I'd
 suggest adding a glossary with terms from other documents.
  2. The acronym "Es" is used for Ethernet Segment when ES is used in
 other EVPN documents.
  3. Missing articles make the text unwieldy to read.
  4. Multiple problems with agreement of subject and verb.
  5. Define what is referred to by DFn. Presumably, this is the selected
 PE in the redundancy group.
  5. Number 5 in section 5 doesn't make sense as written. I was trying to
 fix it but it needs attention from the author.
  6. The abstract cannot include RFC references from the draft. However,
 the RFCs may be referenced without the braces.
  7. The security considerations for RFC 8584 are also applicable. Additionally,
 you that you are going to be asked for a discussion of how the existing
 security mechanisms apply to per-flow DF selection, so you might as well
 provide it now.


Nits: See diff below.

Thanks,
Acee


*** draft-ietf-bess-evpn-per-mcast-flow-df-election-09.txt.orig Wed Jul 19 
11:43:37 2023
--- draft-ietf-bess-evpn-per-mcast-flow-df-election-09.txt  Wed Jul 19 
12:21:57 2023
***
*** 18,33 

  Abstract

![RFC7432] describes mechanism to elect designated forwarder (DF) at
 the granularity of (ESI, EVI) which is per VLAN (or per group of
 VLANs in case of VLAN bundle or VLAN-aware bundle service).  However,
 the current level of granularity of per-VLAN is not adequate for some
!applications.[RFC8584] improves base line DF election by introducing
!HRW DF election.  [RFC9251] introduces applicability of EVPN to
!Multicast flows, routes to sync them and a default DF election.  This
!document is an extension to HRW base draft [RFC8584] and 

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

[Patrice Brissette (pbrisset)]

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] Request for an expedited WG adoption call for draft-trr-bess-bgp-srv6-args

[Ketan Talaulikar]

+1

Cisco (IOS-XR) also has an implementation of this.

Thanks,
Ketan


On Tue, Aug 1, 2023 at 11:16 AM Jorge Rabadan (Nokia) <
jorge.raba...@nokia.com> wrote:

> Hi,
>
>
>
> Nokia has an implementation of draft-trr-bess-bgp-srv6-args in SROS.
>
>
>
> As Ketan says, it is important to make this work WG adopted as soon as
> possible so that new implementors become aware of the changes compared to
> RFC9252.
>
>
>
> Thanks,
>
> Jorge
>
>
>
> *From: *Matthew Bocci (Nokia) 
> *Date: *Tuesday, August 1, 2023 at 10:25 AM
> *To: *Ketan Talaulikar , bess-cha...@ietf.org <
> bess-cha...@ietf.org>
> *Cc: *draft-trr-bess-bgp-srv6-a...@ietf.org <
> draft-trr-bess-bgp-srv6-a...@ietf.org>, BESS 
> *Subject: *Re: 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 <
> 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 
> 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] Request for an expedited WG adoption call for draft-trr-bess-bgp-srv6-args

[Jorge Rabadan (Nokia)]

Hi,

Nokia has an implementation of draft-trr-bess-bgp-srv6-args in SROS.

As Ketan says, it is important to make this work WG adopted as soon as possible 
so that new implementors become aware of the changes compared to RFC9252.

Thanks,
Jorge

From: Matthew Bocci (Nokia) 
Date: Tuesday, August 1, 2023 at 10:25 AM
To: Ketan Talaulikar , bess-cha...@ietf.org 

Cc: draft-trr-bess-bgp-srv6-a...@ietf.org 
, BESS 
Subject: Re: 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] Request for an expedited WG adoption call for draft-trr-bess-bgp-srv6-args

[Matthew Bocci (Nokia)]

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] Comments on the VPN Inter-AS Option BC draft

[Alexander Vainshtein]

Jorge,
I think that a more detailed definition of the TEA-based solution for inter-AS 
Option BC and EVPN is required.

According to RFC 9136, Encapsulation Extended Community can be attached to EVPN 
Ip Prefix routes in some cases.
And Section 4.1 of RFC 
9012 says that the 
semantics of this extended community are the same as could be encoded in the 
"barebones Tunnel TLV".

Are there valid scenarios in which Encapsulation Extended Community has to be 
attached to the EVPN IP Prefix route for the reasons defined in RFC 9136 the 
same route undergoes inter-AS Option BC handling based on the TEA, and, if yes, 
how these two usages can be clearly differentiated?

Regards, and lots of thanks in advance,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Monday, July 31, 2023 6:32 PM
To: Alexander Vainshtein ; 
draft-zzhang-bess-vpn-option-bc.auth...@ietf.org
Cc: bess@ietf.org; Nitsan Dolev 
Subject: [EXTERNAL] Re: Comments on the VPN Inter-AS Option BC draft

Hi everyone,

I mostly agree with Sasha's points.
For completeness I'd like to add that, as I said on the mike, I believe a 
solution based on the TEA would be better (than based on multi-label NLRI). 
Reasons are:

-   RFC8277 was only defined for SAFIs 1 and 128, never for EVPN

-   EVPN route type 2 uses multiple labels in the NLRI already, so it would be 
simpler to use TEA.

Thanks.
Jorge

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Sunday, July 30, 2023 at 12:33 AM
To: 
draft-zzhang-bess-vpn-option-bc.auth...@ietf.org
 
mailto:draft-zzhang-bess-vpn-option-bc.auth...@ietf.org>>
Cc: bess@ietf.org mailto:bess@ietf.org>>, 
Nitsan Dolev mailto:nitsan.do...@rbbn.com>>
Subject: [bess] Comments on the VPN Inter-AS Option BC draft

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.


Hi,
A few comments on the VPN Inter-AS Option BC 
draft
 that has been presented at the BESS WG session in SF last Thursday.

I think that the draft presents an elegant and much needed solution for real 
problem.
I fully agree with the statement in the draft that "Option BC" combines the 
advantages and mitigates the disadvantages of both classic "Option B" and 
"classic" Option C.
I also think that "Option BC" provides a viable alternative to both emerging 
solutions for intent-driven service mapping  (BGP Classful Transport 
Planes
 and BGP Color-Aware 
Routing),
  because it is possible to set up intent=aware inter-AS/inter-domain tunnels 
for "colored" services based on the color of the original service routes.

At the same time, I think that:

1.   As mentioned during the session, Inter-AS Option B for EVPN has its 
own issues (documented in the EVPN Inter-Domain Option B 
draft),
 and these issues fully apply to "Option BC"

2.   The draft defines two possible solutions, one based on the Tunnel 
Encapsulation Attribute (TEA, RFC 
9012)
 and the other based on ability to carry multiple labels in the NLRI of 
"labeled" routes as defined in RFC 
8277:

a.   My guess (FWIW) is that these solutions are not interoperable and, 
therefore, ability to support each of these options should be advertised using 
appropriate Capability Codes

b.   In the TEA-based solution the draft mentions "Composite Tunnel", but 
there is no mention of composite tunnels in RFC 9012.  From my POV:


   i.  Specific tunnel type (one of the types 
defined in the IANA Tunnel Types 
registry)
 should be specified, or a 

Re: [bess] New Version Notification for draft-xu-idr-bgp-route-broker-01.txt

[xuxiaohu_i...@hotmail.com]

Hi all,

The BGP-based IP VPN technology has been used as an overlay routing protocol 
for data center network virtualization environments. However, in a hyperscale 
data center network virtualization environment with tens of thousands of 
virtual PEs, millions of VPNs and tens of millions of VPN routes, the BGP-based 
IP VPN technology will face significant scalability issues (e.g., the VPN route 
table capacity issue and the VPN neighbor capacity issue).

Assume two-level route reflector architecture is used, the scaling issue 
associated with the top-level route reflectors could be addressed by dividing 
all the VPNs supported by a data center into multiple route reflectors with 
each route reflector being preconfigured with a block of route targets 
associated with partial VPNs. However, the bottom-level router reflectors still 
have a scaling issue since they may have to maintain all the VPN routes within 
the whole data center.

By learning from the message queue mechanisms (e.g., RabbitMQ and RocketMQ), 
those bottom-level route reflectors, referred to as route brokers in the 
following text, work as follows: they just need to maintain the route target 
membership information of their BGP peers and reflect VPN routes on demands 
without the requirement of maintaining VPN routes 
permanently.¶

Any comments are welcome!

Best regards,
Xiaohu


发件人: internet-dra...@ietf.org 
日期: 星期二, 2023年8月1日 21:29
收件人: Shraddha Hegde , Srihari Sangli 
, Xiaohu Xu 
主题: New Version Notification for draft-xu-idr-bgp-route-broker-01.txt

A new version of I-D, draft-xu-idr-bgp-route-broker-01.txt
has been successfully submitted by Xiaohu Xu and posted to the
IETF repository.

Name:   draft-xu-idr-bgp-route-broker
Revision:   01
Title:  BGP Route Broker for Hyperscale SDN
Document date:  2023-08-01
Group:  Individual Submission
Pages:  6
URL:
https://www.ietf.org/archive/id/draft-xu-idr-bgp-route-broker-01.txt
Status: https://datatracker.ietf.org/doc/draft-xu-idr-bgp-route-broker/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-xu-idr-bgp-route-broker
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-xu-idr-bgp-route-broker-01

Abstract:
   This document describes an optimized BGP route reflector mechanism,
   referred to as a BGP route broker, so as to use BGP-based IP VPN as
   an overlay routing protocol for hyperscale data center network
   virtualization environments, also known as Software-Defined Network
   (SDN) environments.




The IETF Secretariat

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

[bess] Éric Vyncke's No Objection on draft-ietf-bess-evpn-pref-df-11: (with COMMENT)

[Éric Vyncke via Datatracker]

Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-pref-df-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/



--
COMMENT:
--


# Éric Vyncke, INT AD, comments for draft-ietf-bess-evpn-pref-df-11

Thank you for the work put into this document. Please note that I was close to
ballot a DISCUSS based on my non-blocking COMMENT points, but as I am not an
expert in EPVN, I am trusting the responsible AD.

Please find below osome non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and several nits (please run
your I-D through a spell-checker).

Special thanks to Stéphane Litkowski for the shepherd's detailed write-up
including the WG consensus and the justification of the intended status even if
using the old template.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS

## Abstract

Please fix the expansion of BUM as it is not `Broadcast, Unknown unicast and
Broadcast traffic (BUM)` ;-)

## Section 1.1

Please fix the expansion of BUM as it is not `Broadcast, Multicast and Unknown
unicast traffic (BUM)` ;-) I was amused to read two different wrong expansions
for BUM ;-)

I am sure that non SP will also use this technique, i.e., I wonder whether
s/Service Providers/Network Operators/ would be beneficial.

## Section 2

Rather than using "DP" in `DP - refers to the "Don't Preempt me"` should "DNP"
be more logical ?

## Section 3

Should RFC 8584 be formally updated as its reserved field is carved out ?

`The DP capability is supported by DF Algorithms Highest-Preference or
Lowest-Preference, and MAY be used with the default DF Algorithm or HRW
[RFC8584]` Is there any migration concern with the use of MAY ? I.e., part of
the participating routers will use the DP and the other part not => leading to
an inconsistent election result.

# NITS

s/tie-breakers/tiebreakers/
s/The existence of both provide/The existence of both provides/
s/achive/achieve/ ?
s/decribed/described/

'e.g.' is usually surrounded by ','



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