[bess] Comments about Section 7.11 of 7432bis

[Alexander Vainshtein]

Hi,
I have a couple of comments about the first two sentences in Section 7.11 of 
7432bis
 "EVPN Layer 2 Attributes Extended Community":


[RFC8214] defines and requires this 
extended community ("L2-Attr"), to be included with per-EVI Ethernet A-D routes 
when multihoming is enabled.

Usage and applicability of this Extended community to Bridging is clarified 
here.

My first comment is about interpretation of RFC 8214 as defining and requiring 
usage of L2-Attr Extended Community with per-EVI Ethernet A-D routes advertised 
for "bridging" EVI.  Please note that:

  *   Construction of per-EVI Ethernet A-D routes is defined in Section 8.4.1 
of RFC 7432 , and 
this definition does not mention attachment of L2-Attr Extended Community to 
these routes
  *   RFC 8214 is not marked as updating RFC 7432.

My second comment is about inclusion of L2-Attr Extended community with per-EVI 
Ethernet A-D routes when multi-homing is enabled. Actually, RFC 8214 requires, 
in the case of EVPN-VPLS instances, advertisement of per-EVI Ethernet A-D 
routes regardless of multihoming, and L2-Attr Extended Community may be 
attached to these routes. E.g., in order to enable L2-MTU check for the 
corresponding service instance.

May I suggest the following replacement for the quoted sentences (removed text 
is marked with red strikethrough font while  added text is marked with bold 
green italics):

[RFC8214] defines and requires this 
extended community ("L2-Attr"), to be included with per-EVI Ethernet A-D routes 
when multihoming is enabled advertised by EVPN-based VPWS instances.

Usage and applicability of this Extended community to Bridging EVPN instances 
is clarified defined here.

Regards,
Sasha

Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.
___
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org

Re: [bess] Comments about https://datatracker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bier-and-ir-00

[Chensiyu (Susie)]

Hi Jeffrey,
Sorry for our late response. Let me explain about each question below.
Q1. Type 1 to 7's functions and simplification?
We've uploaded a new version of draft and functions of each NLRIs has been 
modified.
https://datatracker.ietf.org/doc/draft-duan-bess-simplified-mvpn-for-bier-and-ir/
Segmentation scenario will be updated later.

Q2. Are we talking the same or different scenario?  
We think I-PMSI tunnel is no longer needed and we'd like to construct S-PMSI 
tunnel directly. 
In your draft section-1.2.1, you still maintain the procedure of establishing 
I-PMSI tunnel and then switch to S-PMSI tunnel without using s-pmsi ad and leaf 
ad route.

Q2. In order to merge type4/6/7, which way do we want to perform explicit 
tracking? Existing C-multicast route or new BGP route?
The key difference between your and our method is that the parameters used to 
perform explicit tracking. You use distinct Route-distinguishers and we uses 
BIER PTA such as sub-domain, BFR-ID.
For BIER and IR, explicit tracking is important because Ingress PE needs to 
distinguish different receiver sets of I-PMSI and S-PMSI.
Different BitString or routable IR addresses can represent the difference, and 
they are all underlay tunnel parameters. We think PTA carried by leaf A-D route 
can be carried by the existed C-multicast route or creating a new BGP route.
I think RDs cannot perform explicit tracking directly because transit nodes 
cannot recognize RD. Ingress PE needs to translate RDs into underlay.
The translation still needs leaf PE to send their underlay BIER parameters by 
certain MVPN routes, such as C-multicast route.

Q3. How to deal with (s,g,rpt) flag?
We think RFC6513 and RFC6514 use Source-Active route to perform (S,G,RPT) 
because 'BGP update mechanism does not provide "explicit tracking".' (S,G,RPT)s 
from different leaf PEs will be merged into one so that root PE won't know 
specific leaf PEs. But explicit tracking will be naturally supported in BIER 
and IR, so (S,G,RPT) flag can be set and used.

Best wishes,
Siyu

-Original Message-
From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=40juniper@dmarc.ietf.org] 
Sent: Thursday, December 7, 2023 4:11 AM
To: Chensiyu (Susie) ; 'BESS' 
Cc: duanfanghong 
Subject: RE: Comments about 
https://datatracker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bier-and-ir-00

Hi Siyu,

Let me list some high-level summary of BGP-MVPN protocol mechanisms before 
going into response to your comments.

BGP-MVPN has 7 route types:

- Type 1: To announce non-segmented inclusive tunnels
- Type 2: To announce segmented inter-as tunnels and for per-AS aggregation
- Type 3: To announce binding of flows to selective tunnels
- Type 4: For egress PEs to tell ingress PEs they're leaves of the selective 
tunnels in response to type 2/3. Needed for RSVP P2MP, IR/BIER
- Type 5: For source discovery, assert and (s,g,rpt) prune in case of shared 
tree across the provider network
- Type 6/7: For (*,g) or (s,g) joins

To compare against Rosen/PIM-MVPN:

- Type-1 route is comparable to the static configuration of per-VPN group for 
the default MDT
- Type-2 route is irrelevant because there is no concept of per-AS aggregation 
and inter-AS segmentation
- Type-3 route is comparable to the data MDT route
- Type-4 is for explicit tracking, and not needed for PIM/mLDP provider tunnels
- Type-5 is for the control plane based assert procedure and (s,g,rpt) prune
- Type 6/7 is comparable for PIM (*,g)/(s,g) joins but w/o the explicit 
tracking functionality

Please see zzh> below.


Juniper Business Use Only
-Original Message-
From: Chensiyu (Susie)
Sent: Thursday, November 30, 2023 10:23 PM
To: Jeffrey (Zhaohui) Zhang ; 'BESS'
Cc: duanfanghong
Subject: RE: Comments about 
https://datatracker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bier-and-ir-00

[External Email. Be cautious of content]


Hi Jeffrey,

Your summary about our method is great. I've also read your draft about 
explicit tracking. Explicit tracking is realized by our new procedure, but it's 
not the only goal we'd like to achieve.

Zzh> Explicit tracking is an important aspect in both drafts - separate 
type-6/7 and type-4 routes are merged. In draft-zzhang, it is into the existing 
type-6/7 routes and in draft-duan it is into a new route. The question is, 
which way do we want to go for explicit tracking.

Our goal is to provide the simplest MVPN signaling interaction when the tunnel 
type is BIER or IR. Previous 8 routes are simplified to 2 routes.

Zzh> The draft talks about the following:

 3.1.  Simplification of Type 1 to Type 4 NLRI . . . . . . . . .   4
 3.2.  Simplification of Type 6 to Type 7 NLRI . . . . . . . . .   5

Zzh> About "simplification of Type 1 to Type 4", I don't think your proposal 
handles segmentation and per-AS aggregation, so it is only about 
"simplification of Type 1/3/4". Specifically, the Type 1/3 functionality is 
folded into the UMH routes while the Type 4 

Re: [bess] Comments about https://datatracker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bier-and-ir-00

[Jeffrey (Zhaohui) Zhang]

Hi Siyu,

Let me list some high-level summary of BGP-MVPN protocol mechanisms before 
going into response to your comments.

BGP-MVPN has 7 route types:

- Type 1: To announce non-segmented inclusive tunnels
- Type 2: To announce segmented inter-as tunnels and for per-AS aggregation
- Type 3: To announce binding of flows to selective tunnels
- Type 4: For egress PEs to tell ingress PEs they're leaves of the selective 
tunnels in response to type 2/3. Needed for RSVP P2MP, IR/BIER
- Type 5: For source discovery, assert and (s,g,rpt) prune in case of shared 
tree across the provider network
- Type 6/7: For (*,g) or (s,g) joins

To compare against Rosen/PIM-MVPN:

- Type-1 route is comparable to the static configuration of per-VPN group for 
the default MDT
- Type-2 route is irrelevant because there is no concept of per-AS aggregation 
and inter-AS segmentation
- Type-3 route is comparable to the data MDT route
- Type-4 is for explicit tracking, and not needed for PIM/mLDP provider tunnels
- Type-5 is for the control plane based assert procedure and (s,g,rpt) prune
- Type 6/7 is comparable for PIM (*,g)/(s,g) joins but w/o the explicit 
tracking functionality

Please see zzh> below.


Juniper Business Use Only
-Original Message-
From: Chensiyu (Susie)
Sent: Thursday, November 30, 2023 10:23 PM
To: Jeffrey (Zhaohui) Zhang ; 'BESS'
Cc: duanfanghong
Subject: RE: Comments about 
https://datatracker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bier-and-ir-00

[External Email. Be cautious of content]


Hi Jeffrey,

Your summary about our method is great. I've also read your draft about 
explicit tracking. Explicit tracking is realized by our new procedure, but it's 
not the only goal we'd like to achieve.

Zzh> Explicit tracking is an important aspect in both drafts - separate 
type-6/7 and type-4 routes are merged. In draft-zzhang, it is into the existing 
type-6/7 routes and in draft-duan it is into a new route. The question is, 
which way do we want to go for explicit tracking.

Our goal is to provide the simplest MVPN signaling interaction when the tunnel 
type is BIER or IR. Previous 8 routes are simplified to 2 routes.

Zzh> The draft talks about the following:

 3.1.  Simplification of Type 1 to Type 4 NLRI . . . . . . . . .   4
 3.2.  Simplification of Type 6 to Type 7 NLRI . . . . . . . . .   5

Zzh> About "simplification of Type 1 to Type 4", I don't think your proposal 
handles segmentation and per-AS aggregation, so it is only about 
"simplification of Type 1/3/4". Specifically, the Type 1/3 functionality is 
folded into the UMH routes while the Type 4 functionality is folded into your 
new route type (a merge of Type 6/7 and Type 4). My previous email pointed out 
the issue with using UMH routes, and in draft-zzhang, the Type 3 functionality 
is folded into type 1 in case of BIER/IR (but still allow to use Type 3 when 
more granularity is needed, e.g., different flows may use different BIER 
sub-domains) and the Type 4 functionality (explicit tracking) is folded into 
Type 6/7 itself.
Zzh> My argument is that the solution in draft-zzhang is better.

Zzh> Now about "Simplification of Type 6 to Type 7 NLRI" - it's basically the 
explicit tracking plus (s,g,rpt) prune. We talked about explicit tracking 
already.

We don't aim at all existing tunnels and would like to construct a PIM-like 
procedure which consists of RPF route and J/P/SG-RPT route exchanging. The 
J/P/SG-RPT route can either be a new route or a modified one based on the 
existing C-multicast route. The new route will carry (S,G,RPT) information 
which weren't carried by the old C-multicast routes in RFC6514. These routes 
and exchanging procedures are designed based on BGP because BGP is widely 
deployed.

Zzh> draft-zzhang covers many different use cases with different solutions. In 
case of BIER/IR tunnel, it extends Type-6/7 routes with explicit tracking and 
removes the need for type-3 route. With that, it achieves the same goals you 
listed above except the (s,g,rpt) prune.
Zzh> When BGP-MVPN was designed, a deliberate decision was made to use type-5 
routes for (s,g,rpt) prune instead of using explicit (s,g,rpt) prune 
flag/route. I can't articulate the detailed reasons, but we don't have to rush 
to a change.

Therefore, we think that our draft actually focus on different scenario and 
problems and we'd like to continue our work on our draft. We are also working 
on solution for tunnel segmentation scenario and it will be updated in later 
version.

Zzh> As explained above, I don't agree that your draft focus on different 
scenarios and problems. You can say that you use different solutions for the 
same problem (for which there are already proposed solutions w/o using new 
route types), and the WG can debate and decide which way to go.

Zzh> Jeffrey

Best wishes,
Siyu
-Original Message-
From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=40juniper@dmarc.ietf.org]
Sent: Friday, November 10, 2023 9:59 

Re: [bess] Comments about https://datatracker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bier-and-ir-00

[Chensiyu (Susie)]

Hi Jeffrey,

Your summary about our method is great. I've also read your draft about 
explicit tracking. Explicit tracking is realized by our new procedure, but it's 
not the only goal we'd like to achieve.

Our goal is to provide the simplest MVPN signaling interaction when the tunnel 
type is BIER or IR. Previous 8 routes are simplified to 2 routes. We don't aim 
at all existing tunnels and would like to construct a PIM-like procedure which 
consists of RPF route and J/P/SG-RPT route exchanging. The J/P/SG-RPT route can 
either be a new route or a modified one based on the existing C-multicast 
route. The new route will carry (S,G,RPT) information which weren't carried by 
the old C-multicast routes in RFC6514. These routes and exchanging procedures 
are designed based on BGP because BGP is widely deployed.

Therefore, we think that our draft actually focus on different scenario and 
problems and we'd like to continue our work on our draft. We are also working 
on solution for tunnel segmentation scenario and it will be updated in later 
version.

Best wishes,
Siyu
-Original Message-
From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=40juniper@dmarc.ietf.org] 
Sent: Friday, November 10, 2023 9:59 PM
To: Chensiyu (Susie) ; 'BESS' 
Subject: RE: Comments about 
https://datatracker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bie 
r-and-ir-00

Actually, we don't need the extended community even in the case of tunnel 
segmentation, because the C-multicast route used for explicit tracking purposes 
should not be sent to the UMH but to the local upstream segmentation point (and 
the next hop of the route would not change so it can be used to identify the 
leaf PE).

Additionally, if the UMH route is used to advertise the PTA info, then the 
segmentation points need to update that info, which is not desired since 
they're just unicast routes not MVPN routes. The existing x-PMSI route 
procedures work very well with tunnel segmentation.


Juniper Business Use Only
-Original Message-
From: Jeffrey (Zhaohui) Zhang
Sent: Friday, November 10, 2023 2:30 PM
To: Chensiyu (Susie) ; 'BESS' 

Subject: Comments about 
https://datatracker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bier-and-ir-00

Hi Siyu,

To follow up my comments in the BESS session, it is indeed good to optimize 
provider tunnel procedures based on PMSI/Leaf AD route in the case of IR/BIER, 
but there are alternatives.

Essentially, draft-duan replaces the PMSI/Leaf AD routes with the following:

- Announce the PTA info in the UMH routes instead of PMSI routes
- Use a new route type, which is a variant of C-Multicast route instead Leaf 
route, for leaf tracking purposes

For leaf tracking purposes, an alternative is also proposed in 
https://datatracker.ietf.org/doc/html/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-01#section-1.2.1.

   Notice that the (C-*,C-G-BIDIR) C-Multicast routes from different PEs
   all have their own RDs so Route Reflectors (RRs) will reflect every
   one of them, and they already serve explicit tracking purpose (the
   BGP Next Hop identifies the originator of the route in non-
   segmentation case) - there is no need to use Leaf A-D routes
   triggered by the LIR bit in S-PMSI A-D routes.  In case of RSVP-TE
   P2MP tunnel, the S-PMSI A-D routes are still needed to announce the
   tunnel but the LIR bit does not need to be set.  In case of IR/BIER,
   there is no need for S-PMSI A-D routes at all.

Although that is in the context of the MVPN-RPL Method of C-BIDIR support, the 
same idea can be used in general: instead of using the UMH's RD, each leaf PE 
just uses its own RD. While in RFC6514 the UMH's RD is used, that is for 
exactly the opposite purpose - the RRs only need to re-advertise a single 
C-Multicast route to the UMH while here we want each C-Multicast route to reach 
the UMH for leaf tracking purposes.

This method does not need a new route type - just use the leaf PE's own RD and 
attach an extended community to identify the leaf PE (the extended community is 
only needed in case of tunnel segmentation).

To announce the PTA, we don't need to attach the PTA (info) to the UMH routes 
(which could be a lot). A single I-PMSI or (*,*) S-PMSI can be used, or 
additional S-PMSI routes can also be used when more granularity is needed 
(e.g., some flows use some sub-domains while some other flows use some other 
subdomains).

Thanks.
Jeffrey

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

Re: [bess] Comments about https://datatracker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bier-and-ir-00

[Jeffrey (Zhaohui) Zhang]

Actually, we don't need the extended community even in the case of tunnel 
segmentation, because the C-multicast route used for explicit tracking purposes 
should not be sent to the UMH but to the local upstream segmentation point (and 
the next hop of the route would not change so it can be used to identify the 
leaf PE).

Additionally, if the UMH route is used to advertise the PTA info, then the 
segmentation points need to update that info, which is not desired since 
they're just unicast routes not MVPN routes. The existing x-PMSI route 
procedures work very well with tunnel segmentation.


Juniper Business Use Only
-Original Message-
From: Jeffrey (Zhaohui) Zhang
Sent: Friday, November 10, 2023 2:30 PM
To: Chensiyu (Susie) ; 'BESS' 

Subject: Comments about 
https://datatracker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bier-and-ir-00

Hi Siyu,

To follow up my comments in the BESS session, it is indeed good to optimize 
provider tunnel procedures based on PMSI/Leaf AD route in the case of IR/BIER, 
but there are alternatives.

Essentially, draft-duan replaces the PMSI/Leaf AD routes with the following:

- Announce the PTA info in the UMH routes instead of PMSI routes
- Use a new route type, which is a variant of C-Multicast route instead Leaf 
route, for leaf tracking purposes

For leaf tracking purposes, an alternative is also proposed in 
https://datatracker.ietf.org/doc/html/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-01#section-1.2.1.

   Notice that the (C-*,C-G-BIDIR) C-Multicast routes from different PEs
   all have their own RDs so Route Reflectors (RRs) will reflect every
   one of them, and they already serve explicit tracking purpose (the
   BGP Next Hop identifies the originator of the route in non-
   segmentation case) - there is no need to use Leaf A-D routes
   triggered by the LIR bit in S-PMSI A-D routes.  In case of RSVP-TE
   P2MP tunnel, the S-PMSI A-D routes are still needed to announce the
   tunnel but the LIR bit does not need to be set.  In case of IR/BIER,
   there is no need for S-PMSI A-D routes at all.

Although that is in the context of the MVPN-RPL Method of C-BIDIR support, the 
same idea can be used in general: instead of using the UMH's RD, each leaf PE 
just uses its own RD. While in RFC6514 the UMH's RD is used, that is for 
exactly the opposite purpose - the RRs only need to re-advertise a single 
C-Multicast route to the UMH while here we want each C-Multicast route to reach 
the UMH for leaf tracking purposes.

This method does not need a new route type - just use the leaf PE's own RD and 
attach an extended community to identify the leaf PE (the extended community is 
only needed in case of tunnel segmentation).

To announce the PTA, we don't need to attach the PTA (info) to the UMH routes 
(which could be a lot). A single I-PMSI or (*,*) S-PMSI can be used, or 
additional S-PMSI routes can also be used when more granularity is needed 
(e.g., some flows use some sub-domains while some other flows use some other 
subdomains).

Thanks.
Jeffrey

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

[bess] Comments about https://datatracker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bier-and-ir-00

[Jeffrey (Zhaohui) Zhang]

Hi Siyu,

To follow up my comments in the BESS session, it is indeed good to optimize 
provider tunnel procedures based on PMSI/Leaf AD route in the case of IR/BIER, 
but there are alternatives.

Essentially, draft-duan replaces the PMSI/Leaf AD routes with the following:

- Announce the PTA info in the UMH routes instead of PMSI routes
- Use a new route type, which is a variant of C-Multicast route instead Leaf 
route, for leaf tracking purposes

For leaf tracking purposes, an alternative is also proposed in 
https://datatracker.ietf.org/doc/html/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-01#section-1.2.1.

   Notice that the (C-*,C-G-BIDIR) C-Multicast routes from different PEs
   all have their own RDs so Route Reflectors (RRs) will reflect every
   one of them, and they already serve explicit tracking purpose (the
   BGP Next Hop identifies the originator of the route in non-
   segmentation case) - there is no need to use Leaf A-D routes
   triggered by the LIR bit in S-PMSI A-D routes.  In case of RSVP-TE
   P2MP tunnel, the S-PMSI A-D routes are still needed to announce the
   tunnel but the LIR bit does not need to be set.  In case of IR/BIER,
   there is no need for S-PMSI A-D routes at all.

Although that is in the context of the MVPN-RPL Method of C-BIDIR support, the 
same idea can be used in general: instead of using the UMH's RD, each leaf PE 
just uses its own RD. While in RFC6514 the UMH's RD is used, that is for 
exactly the opposite purpose - the RRs only need to re-advertise a single 
C-Multicast route to the UMH while here we want each C-Multicast route to reach 
the UMH for leaf tracking purposes.

This method does not need a new route type - just use the leaf PE's own RD and 
attach an extended community to identify the leaf PE (the extended community is 
only needed in case of tunnel segmentation).

To announce the PTA, we don't need to attach the PTA (info) to the UMH routes 
(which could be a lot). A single I-PMSI or (*,*) S-PMSI can be used, or 
additional S-PMSI routes can also be used when more granularity is needed 
(e.g., some flows use some sub-domains while some other flows use some other 
subdomains).

Thanks.
Jeffrey

Juniper Business Use Only

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

Re: [bess] Comments on draft-malhotra-bess-evpn-centralized-anycast-gw

[Jorge Rabadan (Nokia)]

Thanks for replying, Neeraj.
Looking forward to reading your next version.

Thx
Jorge

From: Neeraj Malhotra (nmalhotr) 
Date: Thursday, November 9, 2023 at 4:01 PM
To: Jorge Rabadan (Nokia) , 
draft-malhotra-bess-evpn-centralized-anycast...@ietf.org 

Cc: bess@ietf.org 
Subject: Re: Comments on draft-malhotra-bess-evpn-centralized-anycast-gw

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 Jorge,

Many thanks for the review. Please see inline:


# Major comment: I believe section 5.1 is not correct:

“... GW MAC/IP MUST be advertised with a higher sequence number. ...”

And as per draft 7432bis:

“MAC Mobility extended community SHALL NOT be attached to routes which also 
have Default Gateway extended community on the sending side and SHALL be 
ignored on the receiving side.”

And section 7.13.1 in the 7432bis takes care of the GW MAC/IPs being protected 
and not subject to mobility. So IMHO the entire section 5.1 is not needed.

[NM]: Thanks for pointing me to this section. I do see that the need for 
sequence number can be avoided as per 7432bis. However, while 7432bis takes 
care of BGP best path selection, arbitration across local, bgp, and static 
route producers for the purpose of selecting the route to be installed in 
forwarding usually happens outside of BGP (in L2RIB). Section 5.1 is intended 
to ensure that a locally learnt MAC will not take precedence over BGP produced 
GW MAC route in the forwarding table. That said, one could arguably assume that 
the BGP best path selection in 7432bis implies forwarding route selection 
across bgp and local producers as well. Let me discuss with other co-authors 
and try to align this section with 7432bis in the next revision.

# Minor comments:

## If section 5.1 was the only new extension to EVPN, then it is not needed and 
the draft can be Informational?

[NM]: Besides section 5.1, there are procedures for L2 PE and CAG PE specified 
in section 3, for e.g., use of ARP snooping on L2 PEs to avoid ARP/ND sync. As 
well as re-origination procedures between L2-only fabric and Symmetric IRB 
fabric in section 6.1.1. While there isn’t any new specification for anything 
on the wire, L2-PE and CAG PE need to locally implement these procedures for 
the solution to work end to end. That seems like a standards track to me, but 
open to more input – will also discuss with co-authors.

## The following text:

”Optionally, the CAG IRB nodes may also have directly connected end-points.”

And this one:

“In case of VXLAN encapsulation, set of redundant CAG PEs provisioned as FHR 
for a common set of subnets MAY advertise the anycast GW MAC/IP RT-2 with an 
anycast VTEP IP as the next-hop.”

Are not really compatible. So you should consider to explain that single-homed 
local CAG ACs are only possible if anycast VTEPs are NOT used.

[NM]: Sure, makes sense. will clarify in the next revision that single homed 
local end-points are advertised with PIP as the next-hop VTEP.

## section 6.1.3 on split horizon groups on the CAGs should just follow 
RFC9014. I don’t think there is any new procedure here?

[NM]: ack. Will add a reference to RFC9014.


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

Re: [bess] Comments on draft-malhotra-bess-evpn-centralized-anycast-gw

[Neeraj Malhotra (nmalhotr)]

Hi Jorge,

Many thanks for the review. Please see inline:


# Major comment: I believe section 5.1 is not correct:

“... GW MAC/IP MUST be advertised with a higher sequence number. ...”

And as per draft 7432bis:

“MAC Mobility extended community SHALL NOT be attached to routes which also 
have Default Gateway extended community on the sending side and SHALL be 
ignored on the receiving side.”

And section 7.13.1 in the 7432bis takes care of the GW MAC/IPs being protected 
and not subject to mobility. So IMHO the entire section 5.1 is not needed.

[NM]: Thanks for pointing me to this section. I do see that the need for 
sequence number can be avoided as per 7432bis. However, while 7432bis takes 
care of BGP best path selection, arbitration across local, bgp, and static 
route producers for the purpose of selecting the route to be installed in 
forwarding usually happens outside of BGP (in L2RIB). Section 5.1 is intended 
to ensure that a locally learnt MAC will not take precedence over BGP produced 
GW MAC route in the forwarding table. That said, one could arguably assume that 
the BGP best path selection in 7432bis implies forwarding route selection 
across bgp and local producers as well. Let me discuss with other co-authors 
and try to align this section with 7432bis in the next revision.

# Minor comments:

## If section 5.1 was the only new extension to EVPN, then it is not needed and 
the draft can be Informational?

[NM]: Besides section 5.1, there are procedures for L2 PE and CAG PE specified 
in section 3, for e.g., use of ARP snooping on L2 PEs to avoid ARP/ND sync. As 
well as re-origination procedures between L2-only fabric and Symmetric IRB 
fabric in section 6.1.1. While there isn’t any new specification for anything 
on the wire, L2-PE and CAG PE need to locally implement these procedures for 
the solution to work end to end. That seems like a standards track to me, but 
open to more input – will also discuss with co-authors.

## The following text:

”Optionally, the CAG IRB nodes may also have directly connected end-points.”

And this one:

“In case of VXLAN encapsulation, set of redundant CAG PEs provisioned as FHR 
for a common set of subnets MAY advertise the anycast GW MAC/IP RT-2 with an 
anycast VTEP IP as the next-hop.”

Are not really compatible. So you should consider to explain that single-homed 
local CAG ACs are only possible if anycast VTEPs are NOT used.

[NM]: Sure, makes sense. will clarify in the next revision that single homed 
local end-points are advertised with PIP as the next-hop VTEP.

## section 6.1.3 on split horizon groups on the CAGs should just follow 
RFC9014. I don’t think there is any new procedure here?

[NM]: ack. Will add a reference to RFC9014.


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

[bess] Comments on draft-malhotra-bess-evpn-centralized-anycast-gw

[Jorge Rabadan (Nokia)]

Dear authors,

These are the comments that I couldn’t ask/say during the BESS session:


# Major comment: I believe section 5.1 is not correct:

“... GW MAC/IP MUST be advertised with a higher sequence number. ...”

And as per draft 7432bis:

“MAC Mobility extended community SHALL NOT be attached to routes which also 
have Default Gateway extended community on the sending side and SHALL be 
ignored on the receiving side.”

And section 7.13.1 in the 7432bis takes care of the GW MAC/IPs being protected 
and not subject to mobility. So IMHO the entire section 5.1 is not needed.



# Minor comments:

## If section 5.1 was the only new extension to EVPN, then it is not needed and 
the draft can be Informational?

## The following text:

”Optionally, the CAG IRB nodes may also have directly connected end-points.”

And this one:

“In case of VXLAN encapsulation, set of redundant CAG PEs provisioned as FHR 
for a common set of subnets MAY advertise the anycast GW MAC/IP RT-2 with an 
anycast VTEP IP as the next-hop.”

Are not really compatible. So you should consider to explain that single-homed 
local CAG ACs are only possible if anycast VTEPs are NOT used.

## section 6.1.3 on split horizon groups on the CAGs should just follow 
RFC9014. I don’t think there is any new procedure here?


Hope my comments are helpful.
Thank you!
Jorge
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Kaliraj Vairavakkalai]

Hi,

Sharing my impressions on draft-zzhang-bess-vpn-option-bc, which I had earlier 
shared offline with Jeffrey and Kireeti.

We lose “indirection” by carrying a label stack (combining service label and 
transport label) in service-routes.

That will affects us in following ways:


  *   Nexthop Scaling problems. Because of label-stack combinatorials.

(This could affect PE devices the most, which may be low end devices)

  *   BGP PIC is not possible. Since transport-layer does not exist.
  *   Service layer convergence. Any transport label changes will cause all 
service routes to be readvertised.
  *   ASBRs have service-routes now. in option-C ASBRs don’t have 
service-routes.
  *   ABRs also need service-routes now. In option-C they don’t. So it makes 
network’s core nodes “control plane” heavy.
  *   Label spoofing problem is not solved.
  *   Software upgrade is needed on all nodes: PEs, ASBRs, ABRs, RRs.

Because of these scaling and convergence problems, this mechanism doesn’t seem 
to be a good replacement for any transport-layer protocol.

I request the WG to consider these issues.

OTOH, the “MPLS Namespaces” solution presented in same BESS session solves all 
these problems.
Sec 
6.1<https://datatracker.ietf.org/doc/html/draft-kaliraj-bess-bgp-sig-private-mpls-labels-06#section-6.1>
 and 
6.2<https://datatracker.ietf.org/doc/html/draft-kaliraj-bess-bgp-sig-private-mpls-labels-06#section-6.2>
 of the draft describe how scaling, convergence and label spoofing protection is
achieved in an option-C network, using MPLS-NS. With software upgrade confined 
to ASBRs, regional-RRs.
The mechanisms described are for L3VPN label. But as noted in sec 6.1, they 
should work similarly for
any BGP service family carrying MPLS labels.

Just wanted to bring to attention of the WG.

Thanks
Kaliraj


Juniper Business Use Only
From: BESS  on behalf of Jorge Rabadan (Nokia) 

Date: Thursday, August 3, 2023 at 10:00 AM
To: Jeffrey (Zhaohui) Zhang , Alexander Vainshtein 

Cc: bess@ietf.org , Nitsan Dolev , 
draft-zzhang-bess-vpn-option-bc.auth...@ietf.org 

Subject: Re: [bess] Comments on the VPN Inter-AS Option BC draft
[External Email. Be cautious of content]

Jeffrey, thanks for your answers. At least you and I are in synch now.

Thx
Jorge



Juniper Business Use Only
From: Jeffrey (Zhaohui) Zhang 
Date: Thursday, August 3, 2023 at 2:25 AM
To: Alexander Vainshtein , 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.


Hi Sasha, Jorge,

Thanks for the comments. Please see zzh> below.



Juniper Business Use Only
From: Alexander Vainshtein 
Sent: Tuesday, August 1, 2023 5:42 PM
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

[External Email. Be cautious of content]

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

Zzh> For the TEA based solution, I had thought the method was described well 
enough (except the normative encoding format). It also includes the interop 
between the nodes that are incapable of handling the new “composite tunnel” 
(more below). Apparently, we need to elaborate it more.
Zzh> Indeed the draft was written more focused on IP VPN (RFC 4364) and in that 
case the double-label based approach is better in that many PEs may already be 
able to support it. In case of EVPN, as Jorge commented on the mic, TED based 
approach is needed.

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<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9012.html*section-4.1__;Iw!!NEt6yMaO-gk!EUjY1kE8mdkdkFbSDaemp05RDtmNVtCtYSqgIM3l9Q9azq6rxW-dDNzKPVPFSw2ZFHMAiAVzgucRZiTkdpu_Tt86Xho$>
 says that the semantics of this extended community are the same as could be 
encoded in the “barebones Tunnel TLV”.

Zzh> RFC9012 states:

   Section 6 of [RFC8365] talks about the use of the Encapsulation
   Extended Community to allow Network Virtualization Edge (NVE) devices
   to signal their supported encapsulations.  We note that with the
   introduction of this specification, the Tunnel Encapsulation
   attribute can also be used for this purpose.  For purposes where RFC
   8365 talks about "advertising supported encapsulations" (for example,
   in the second paragraph of Section 6), encapsulations advertised
   using the Tunnel Encapsulation attribute should be considered equally
   with those advertised using the Encapsulation Extended Community.

Are there valid scenarios in which Encapsulation Extended Community has to 

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

[Jorge Rabadan (Nokia)]

Jeffrey, thanks for your answers. At least you and I are in synch now.

Thx
Jorge

From: Jeffrey (Zhaohui) Zhang 
Date: Thursday, August 3, 2023 at 2:25 AM
To: Alexander Vainshtein , 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.


Hi Sasha, Jorge,

Thanks for the comments. Please see zzh> below.



Juniper Business Use Only
From: Alexander Vainshtein 
Sent: Tuesday, August 1, 2023 5:42 PM
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

[External Email. Be cautious of content]

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

Zzh> For the TEA based solution, I had thought the method was described well 
enough (except the normative encoding format). It also includes the interop 
between the nodes that are incapable of handling the new “composite tunnel” 
(more below). Apparently, we need to elaborate it more.
Zzh> Indeed the draft was written more focused on IP VPN (RFC 4364) and in that 
case the double-label based approach is better in that many PEs may already be 
able to support it. In case of EVPN, as Jorge commented on the mic, TED based 
approach is needed.

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<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9012.html*section-4.1__;Iw!!NEt6yMaO-gk!EUjY1kE8mdkdkFbSDaemp05RDtmNVtCtYSqgIM3l9Q9azq6rxW-dDNzKPVPFSw2ZFHMAiAVzgucRZiTkdpu_Tt86Xho$>
 says that the semantics of this extended community are the same as could be 
encoded in the “barebones Tunnel TLV”.

Zzh> RFC9012 states:

   Section 6 of [RFC8365] talks about the use of the Encapsulation
   Extended Community to allow Network Virtualization Edge (NVE) devices
   to signal their supported encapsulations.  We note that with the
   introduction of this specification, the Tunnel Encapsulation
   attribute can also be used for this purpose.  For purposes where RFC
   8365 talks about "advertising supported encapsulations" (for example,
   in the second paragraph of Section 6), encapsulations advertised
   using the Tunnel Encapsulation attribute should be considered equally
   with those advertised using the Encapsulation Extended Community.

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?

Zzh> For Option-BC, the new “composite tunnel” needs to be used to convey the 
semantics that the label in the tunnel is used for label switching the traffic.
Zzh> More below.

Regards, and lots of thanks in advance,
Sasha

From: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Sent: Monday, July 31, 2023 6:32 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>; 
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: [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

Zzh> On the mic I think I mentioned “protocols could be extended” – I thought 
you were saying about TEA for EVPN use. Now I see you were referring to the 
multi-label encoding. I agree with you.


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

Zzh> I agree that for EVPN we need to use TEA.
Zzh> More below for Sasha’s comments.

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>
 
mailto:draft-zzhang-bess-vpn-option-bc.auth...@ietf.org>>
Cc: bess@ietf.org<mailto: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 attach

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

[Jeffrey (Zhaohui) Zhang]

Hi Sasha, Jorge,

Thanks for the comments. Please see zzh> below.



Juniper Business Use Only
From: Alexander Vainshtein 
Sent: Tuesday, August 1, 2023 5:42 PM
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

[External Email. Be cautious of content]

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

Zzh> For the TEA based solution, I had thought the method was described well 
enough (except the normative encoding format). It also includes the interop 
between the nodes that are incapable of handling the new "composite tunnel" 
(more below). Apparently, we need to elaborate it more.
Zzh> Indeed the draft was written more focused on IP VPN (RFC 4364) and in that 
case the double-label based approach is better in that many PEs may already be 
able to support it. In case of EVPN, as Jorge commented on the mic, TED based 
approach is needed.

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<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9012.html*section-4.1__;Iw!!NEt6yMaO-gk!EUjY1kE8mdkdkFbSDaemp05RDtmNVtCtYSqgIM3l9Q9azq6rxW-dDNzKPVPFSw2ZFHMAiAVzgucRZiTkdpu_Tt86Xho$>
 says that the semantics of this extended community are the same as could be 
encoded in the "barebones Tunnel TLV".

Zzh> RFC9012 states:

   Section 6 of [RFC8365] talks about the use of the Encapsulation
   Extended Community to allow Network Virtualization Edge (NVE) devices
   to signal their supported encapsulations.  We note that with the
   introduction of this specification, the Tunnel Encapsulation
   attribute can also be used for this purpose.  For purposes where RFC
   8365 talks about "advertising supported encapsulations" (for example,
   in the second paragraph of Section 6), encapsulations advertised
   using the Tunnel Encapsulation attribute should be considered equally
   with those advertised using the Encapsulation Extended Community.

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?

Zzh> For Option-BC, the new "composite tunnel" needs to be used to convey the 
semantics that the label in the tunnel is used for label switching the traffic.
Zzh> More below.

Regards, and lots of thanks in advance,
Sasha

From: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Sent: Monday, July 31, 2023 6:32 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>; 
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: [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

Zzh> On the mic I think I mentioned "protocols could be extended" - I thought 
you were saying about TEA for EVPN use. Now I see you were referring to the 
multi-label encoding. I agree with you.


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

Zzh> I agree that for EVPN we need to use TEA.
Zzh> More below for Sasha's comments.

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>
 
mailto:draft-zzhang-bess-vpn-option-bc.auth...@ietf.org>>
Cc: bess@ietf.org<mailto: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<https://urldefense.com/v3/__https:/clicktime.symantec.com/15t5pPA4bD5KNabJWqiFE?h=yWp3H1PJEe4zH4c3i4dF5n7lEMli2TmtihCz3ZwOO0k==https:**Adatatracker.ietf.org*doc*html*draft-zzhang-bess-vpn-option-bc-00__;Ly8vLy8!!NEt6yMaO-gk!EUjY1kE8mdkdkFbSDaemp05RDtmNVtCtYSqgIM3l9Q9azq6rxW-dDNzKPVPFSw2ZFHMAiAVzgucRZiTkdpu_XbrqVo4$>
 that has been presented at 

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<https://aka.ms/AAb9ysg>


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<https://clicktime.symantec.com/15siFAn1RKeQBV28niQrX?h=Q05YbxJ5VmnNz13pCxBX5bAAu9TXh6SCpDGkNh0sS74==https://www.rfc-editor.org/rfc/rfc9012.html%23section-4.1>
 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>
 
mailto:draft-zzhang-bess-vpn-option-bc.auth...@ietf.org>>
Cc: bess@ietf.org<mailto: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<https://clicktime.symantec.com/15t5pPA4bD5KNabJWqiFE?h=yWp3H1PJEe4zH4c3i4dF5n7lEMli2TmtihCz3ZwOO0k==https://datatracker.ietf.org/doc/html/draft-zzhang-bess-vpn-option-bc-00>
 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<https://clicktime.symantec.com/15t5eimVfyi8YgwTRiuwz?h=hMCtCJ0CFBdHAlMw_J1sPfLPSwJtIKOIe1RPi3WAlq8==https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ct-12>
 and BGP Color-Aware 
Routing<https://clicktime.symantec.com/15t5ZtaDDN2Y8k7XtAWoN?h=iLtYqX5EuXFTvu91ipk88eTZimbi9nAXijmyuMHZ9RE==https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-car-02>),
  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<https://clicktime.symantec.com/15t5jYxn8bPixdmNyHK6c?h=Wqmp2FHrWkw75uGs4NJ_SawETnrpSdBEZz6r9HSuBrQ==https://datatracker.ietf.org/doc/html/draft-rabadan-bess-evpn-inter-domain-opt-b-01>),
 and these issues fully apply to “Option B

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<https://www.rfc-editor.org/rfc/rfc9012.html#section-4.1> 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>
 
mailto:draft-zzhang-bess-vpn-option-bc.auth...@ietf.org>>
Cc: bess@ietf.org<mailto: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<https://clicktime.symantec.com/15t5pPA4bD5KNabJWqiFE?h=yWp3H1PJEe4zH4c3i4dF5n7lEMli2TmtihCz3ZwOO0k==https://datatracker.ietf.org/doc/html/draft-zzhang-bess-vpn-option-bc-00>
 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<https://clicktime.symantec.com/15t5eimVfyi8YgwTRiuwz?h=hMCtCJ0CFBdHAlMw_J1sPfLPSwJtIKOIe1RPi3WAlq8==https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ct-12>
 and BGP Color-Aware 
Routing<https://clicktime.symantec.com/15t5ZtaDDN2Y8k7XtAWoN?h=iLtYqX5EuXFTvu91ipk88eTZimbi9nAXijmyuMHZ9RE==https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-car-02>),
  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<https://clicktime.symantec.com/15t5jYxn8bPixdmNyHK6c?h=Wqmp2FHrWkw75uGs4NJ_SawETnrpSdBEZz6r9HSuBrQ==https://datatracker.ietf.org/doc/html/draft-rabadan-bess-evpn-inter-domain-opt-b-01>),
 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<https://clicktime.symantec.com/15t5z3YdWSSWCUF9bxWYU?h=Eo8x2bOQorNn4An26KlhQGMaow4EDWU6fwDgx-LKhZg==https://datatracker.ietf.org/doc/html/rfc9012>)
 and the other based on ability to carry multiple labels in the NLRI of 
“labeled” routes as defined in RFC 
8277<https://clicktime.symantec.com/15t5uDMM3pkunXRE4Q7Pr?h=X5O-7WPStfY9Ws3f_gOPo314zCnRjXQrJAId3fyJJSc==https://datatracker.ietf.org/doc/html/rfc8277>:

a.   My guess (FWIW) is that these solutions ar

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<https://www.rfc-editor.org/rfc/rfc9012.html#section-4.1> 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>
 
mailto:draft-zzhang-bess-vpn-option-bc.auth...@ietf.org>>
Cc: bess@ietf.org<mailto: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<https://clicktime.symantec.com/15t5pPA4bD5KNabJWqiFE?h=yWp3H1PJEe4zH4c3i4dF5n7lEMli2TmtihCz3ZwOO0k==https://datatracker.ietf.org/doc/html/draft-zzhang-bess-vpn-option-bc-00>
 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<https://clicktime.symantec.com/15t5eimVfyi8YgwTRiuwz?h=hMCtCJ0CFBdHAlMw_J1sPfLPSwJtIKOIe1RPi3WAlq8==https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ct-12>
 and BGP Color-Aware 
Routing<https://clicktime.symantec.com/15t5ZtaDDN2Y8k7XtAWoN?h=iLtYqX5EuXFTvu91ipk88eTZimbi9nAXijmyuMHZ9RE==https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-car-02>),
  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<https://clicktime.symantec.com/15t5jYxn8bPixdmNyHK6c?h=Wqmp2FHrWkw75uGs4NJ_SawETnrpSdBEZz6r9HSuBrQ==https://datatracker.ietf.org/doc/html/draft-rabadan-bess-evpn-inter-domain-opt-b-01>),
 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<https://clicktime.symantec.com/15t5z3YdWSSWCUF9bxWYU?h=Eo8x2bOQorNn4An26KlhQGMaow4EDWU6fwDgx-LKhZg==https://datatracker.ietf.org/doc/html/rfc9012>)
 and the other based on ability to carry multiple labels in the NLRI of 
"labeled" routes as defined in RFC 
8277<https://clicktime.symantec.com/15t5uDMM3pkunXRE4Q7Pr?h=X5O-7WPStfY9Ws3f_gOPo314zCnRjXQrJAId3fyJJSc==https://datatracker.ietf.org/doc/html/rfc8277>:

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<https://clicktime.symantec.com/15t

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

[Jorge Rabadan (Nokia)]

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  on behalf of Alexander Vainshtein 

Date: Sunday, July 30, 2023 at 12:33 AM
To: draft-zzhang-bess-vpn-option-bc.auth...@ietf.org 

Cc: bess@ietf.org , Nitsan Dolev 
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<https://datatracker.ietf.org/doc/html/draft-zzhang-bess-vpn-option-bc-00> 
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<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ct-12> and BGP 
Color-Aware 
Routing<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-car-02>),  
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<https://datatracker.ietf.org/doc/html/draft-rabadan-bess-evpn-inter-domain-opt-b-01>),
 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<https://datatracker.ietf.org/doc/html/rfc9012>) and the other based on 
ability to carry multiple labels in the NLRI of “labeled” routes as defined in 
RFC 8277<https://datatracker.ietf.org/doc/html/rfc8277>:

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<https://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsulation.xhtml>)
 should be specified, or a request for allocating a new tunnel type should be 
added to the next revision of the document


 ii.  I wonder if MPLS Encapsulation Tunnel type and the Label Stack 
Sub-TLV can be used in the TEA-based solution. My guess is that this would 
require an update to RFC 8365<https://www.rfc-editor.org/rfc/rfc8365.html>

Hopefully these issues will be addressed in the next revision of the draft.

My 2c,
Sasha



Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Alexander Vainshtein]

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:
 *   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
 *   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 request for allocating a new tunnel type should be 
added to the next revision of the document

 ii.  I wonder 
if MPLS Encapsulation Tunnel type and the Label Stack Sub-TLV can be used in 
the TEA-based solution. My guess is that this would require an update to RFC 
8365

Hopefully these issues will be addressed in the next revision of the draft.

My 2c,
Sasha

Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Comments welcome///Re: New Version Notification for draft-chen-bess-evpn-wtr-on-fast-df-recovery-00.txt

[chen.ran]

Hi WG,



We have submmitted 
https://datatracker.ietf.org/doc/draft-chen-bess-evpn-wtr-on-fast-df-recovery/. 
In this draft, the SCT-EC is extended to the A-D per EVI routes, so that the 
ingress PEs can perform the revertive FRR switching based on the time specified 
by the SCT-EC for the non-adjacent ESes that support the fast DF recovery. Any 
comments are welcome.






Best Regards,


Ran






Original



From: internet-dra...@ietf.org 
To: 陈然00080434;王玉保10045807;
Date: 2023年07月10日 19:22
Subject: New Version Notification for 
draft-chen-bess-evpn-wtr-on-fast-df-recovery-00.txt



 
A new version of I-D, draft-chen-bess-evpn-wtr-on-fast-df-recovery-00.txt
has been successfully submitted by Yubao Wang and posted to the
IETF repository.
 
Name:draft-chen-bess-evpn-wtr-on-fast-df-recovery
Revision:00
Title:WTR signaling on Fast DF Recovery of Single-Active ESIs
Document date:2023-07-10
Group:Individual Submission
Pages:9
URL:
https://www.ietf.org/archive/id/draft-chen-bess-evpn-wtr-on-fast-df-recovery-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-chen-bess-evpn-wtr-on-fast-df-recovery/
Html:   
https://www.ietf.org/archive/id/draft-chen-bess-evpn-wtr-on-fast-df-recovery-00.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-chen-bess-evpn-wtr-on-fast-df-recovery
 
 
Abstract:
   The non-DF of a Single-Active Ethernet Segment (SA-ES) can filter
   both unicast traffic and BUM traffic.  In such case, when a specific
   Single-Active ES performs fast DF recovery, the corresponding
   revertive FRR switching should be performed on the ingress PEs that
   are not adjacent to this ES.  This revertive FRR switching needs to
   be performed immediately after the A-D per EVI route with the "P=1" 
   is received from the new DF node.  In other words, the revertive FRR
   switching cannot perform the WTR procedures, otherwise unicast
   traffic will be dropped on the new NDF node during the WTR.
 
   In this draft, the SCT-EC is extended to the A-D per EVI routes, so
   that the ingress PEs can perform the revertive FRR switching based on
   the time specified by the SCT-EC for the non-adjacent ESes that
   support the fast DF recovery.
 

   
 
 
The IETF Secretariat___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Comments on draft-ietf-bess-evpn-ipvpn-interworking-07

[Jorge Rabadan (Nokia)]

Hi John, all,

We published version 08. This version removes the use of D-PATH from SAFI 1 
routes completely (this is still an ongoing discussion with the IDR chairs) and 
addresses your comments below.

Please see in-line with [jorge].

Thanks for the email!
Jorge


From: John Scudder 
Date: Wednesday, January 11, 2023 at 3:55 PM
To: draft-ietf-bess-evpn-ipvpn-interwork...@ietf.org 

Cc: bess@ietf.org 
Subject: Comments on draft-ietf-bess-evpn-ipvpn-interworking-07
Hi Authors and WG,

I recently looked at some parts of draft-ietf-bess-evpn-ipvpn-interworking-07. 
This isn't a full review but I noticed some things of concern that I thought 
I'd share.

Regards,

--John

# COMMENTS

## Section 4

```
An ISF route received by a gateway PE with a D-PATH attribute that contains one 
or more of its locally associated DOMAIN-IDs for the IP-VRF is considered to be 
a looped ISF route. The ISF route in this case MUST be flagged as "looped" and 
be installed in the IP-VRF only in case there is no better route after the best 
path selection (Section 6).
```

But... this is just a restatement of the general condition for route 
installation in any case. A route is never installed unless there is no better 
route after best path selection -- if there is a better route, the better route 
is installed instead.

It seems to me that either the explanatory text here is wrong/missing 
something, or loop detection is genuinely not being used for anything.

I did notice that Section 8 (2(b)) contains a rule related to loops ("In this 
case the route is considered to be a looped ISF route, as described in Section 
4 and hence MUST NOT be exported in ISF SAFI-y."), maybe that is where the 
entire meat of loop suppression resides? But this was not clear to me.

For comparison, here is how RFC 4271 says to handle AS_PATH loops (Section 
9.1.2):

```
   If the AS_PATH attribute of a BGP route contains an AS loop, the BGP
   route should be excluded from the Phase 2 decision function.
```

(If this were an IESG ballot, this would be a DISCUSS question, since loop 
suppression is presented as a major feature of this spec.)

[jorge] excellent point as usual. Indeed, in the first versions of the draft 
the text followed the loop detection as in the as_path case, however in the 
latest versions the authors agreed to change this since there were use cases 
where installing the route provided faster convergence upon certain failures in 
the Gateways and, in order to avoid loops, we only needed to prevent 
re-exporting the ‘looped’ route. So we missed to clarify this aspect in section 
4. The new text says:


  1.  An ISF IPVPN or EVPN route received by a gateway PE with a D-PATH 
attribute that contains one or more of its locally associated DOMAIN-IDs (for 
the IP-VRF) is considered to be a looped ISF route for the purpose of 
re-exporting the route to the adjacent domain in a Gateway PE. The ISF route in 
this case MUST be flagged as "looped", MUST NOT be exported, and MAY be 
installed in the IP-VRF only in case there is no better route after the best 
path selection (Section 
6).
 The ISF_SAFI_TYPE is irrelevant for the purpose of loop detection of an ISF 
route. In other words, an ISF route is considered as a looped route if it 
contains a D-PATH attribute with at least one DOMAIN-ID matching a local 
DOMAIN-ID, irrespective of the ISF_SAFI_TYPE of the DOMAIN-ID.

For instance, in the example of Figure 
2,
 gateway GW1 receives TS1 prefix in two different ISF routes:

oIn an EVPN IP Prefix route with next-hop PE1 and no D-PATH attribute.

oIn a SAFI 128 route with next-hop GW2 and D-PATH = {length=1, 
<6500:1:EVPN>}, assuming that DOMAIN-ID for domain 1 is 6500:1.

Gateway GW1 flags the SAFI 128 route as "looped" (since 6500:1 is a local 
DOMAIN-ID in GW1) and it will not install it in the tenant IP-VRF, since the 
route selection process selects the EVPN IP Prefix route due to a shorter 
D-PATH attribute (Section 
6).
 Gateway GW1 identifies the route as "looped" even if the ISF_SAFI_TYPE value 
is unknown to GW1, i.e., any value different from the ones specified in this 
document).



## Section 4

Also, I don't think the method of assignment of the Local Admin part of the 
Domain ID is specified. I mean, presumably it's... local... but it seems like 
some words should be said. Indeed, I found the entire definition of the 
domain-id pretty mystifying -- it uses six bytes for two fields that appear to 
be arbitrary (the global-admin part) and even more arbitrary (the local-admin 
part) without getting 

[bess] Comments on draft-ietf-bess-evpn-ipvpn-interworking-07

[John Scudder]

Hi Authors and WG,

I recently looked at some parts of draft-ietf-bess-evpn-ipvpn-interworking-07. 
This isn't a full review but I noticed some things of concern that I thought 
I'd share.

Regards,

--John 

# COMMENTS

## Section 4

```
An ISF route received by a gateway PE with a D-PATH attribute that contains one 
or more of its locally associated DOMAIN-IDs for the IP-VRF is considered to be 
a looped ISF route. The ISF route in this case MUST be flagged as "looped" and 
be installed in the IP-VRF only in case there is no better route after the best 
path selection (Section 6).
```

But... this is just a restatement of the general condition for route 
installation in any case. A route is never installed unless there is no better 
route after best path selection -- if there is a better route, the better route 
is installed instead.

It seems to me that either the explanatory text here is wrong/missing 
something, or loop detection is genuinely not being used for anything.

I did notice that Section 8 (2(b)) contains a rule related to loops ("In this 
case the route is considered to be a looped ISF route, as described in Section 
4 and hence MUST NOT be exported in ISF SAFI-y."), maybe that is where the 
entire meat of loop suppression resides? But this was not clear to me.

For comparison, here is how RFC 4271 says to handle AS_PATH loops (Section 
9.1.2):

```
   If the AS_PATH attribute of a BGP route contains an AS loop, the BGP
   route should be excluded from the Phase 2 decision function.
```

(If this were an IESG ballot, this would be a DISCUSS question, since loop 
suppression is presented as a major feature of this spec.)

## Section 4

Also, I don't think the method of assignment of the Local Admin part of the 
Domain ID is specified. I mean, presumably it's... local... but it seems like 
some words should be said. Indeed, I found the entire definition of the 
domain-id pretty mystifying -- it uses six bytes for two fields that appear to 
be arbitrary (the global-admin part) and even more arbitrary (the local-admin 
part) without getting any evident benefit from creating that structure. 

## Section 5.2

5.2 (1) implies that Wide Communities (draft-ietf-idr-wide-bgp-communities-08) 
SHOULD NOT be propagated (since your rule is in effect, "anything not permitted 
is prohibited"). Is this exclusion deliberate? FWIW I see that Wide Communities 
has passed IDR WGLC. 

## Section 5.2

While I'm talking about it, the final bullet of (1) is a little ambiguous:

```
The following set of Path Attributes SHOULD be propagated by the gateway PE to 
other ISF SAFIs (other BGP Path Attributes SHOULD NOT be propagated):
...
- Communities, Extended Communities and Large Communities, except for the EVPN 
extended communities, Route Target extended communities and BGP Encapsulation 
extended communities.
```

I guess you mean that everything after the "except for" is excluded? Because of 
the shortcomings of English grammar, this isn't clear as written. Perhaps 
something like, "Communities, Extended Communities and Large Communities, 
except in the exception cases detailed in point 4."

## General

By the way, I think the usual concern about the use of SHOULD (NOT) instead of 
MUST (NOT) is going to apply, and the document would benefit from a review to 
convert these to MUST when possible or supply further explanation about what 
exception cases exist otherwise.

## Section 5.3

```
AS_PATH is aggregated based on the rules in [RFC4271]. The gateway PEs SHOULD 
NOT receive AS_PATH attributes with path segments of type AS_SET [RFC6472].
```

That's not a good use of the RFC 2119 keyword, I think you mean something like 
"gateway PEs are not expected to receive...". 

# NITS:

- "as though it would" --> "as it would" (drop 'though')
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Comments on L2-Attr Extended Community of draft-ietf-bess-rfc7432bis-04

[wang.yubao2]

Hi authors,










I also have some other comments on draft-ietf-bess-rfc7432bis-04, 


they are about entropy label, flow label and control word,


maybe some of them are also related to the OPE TLV of 
draft-heitz-bess-evpn-option-b or RFC7447.









5) Is the entropy label in the following paragraph (in section 18) an entropy 
label of PSN tunnel (e.g. LDP LSP)?


or is it just an entropy label inside the EVPN label?


I noticed that RFC7447 (after RFC7432) had deprecated the BGP Entropy Label 
Capability (ELC) attribute.


and RFC7447 says that "A forthcoming document will propose a replacement".


Has the replacement of old BGP ELC attribute been defined?


Does the following paragraph have any relation with (new) BGP ELC attribute?











" *  If a network uses entropy labels per [RFC6790], then the control


  word SHOULD NOT be used when sending EVPN-encapsulated packets


  over an MP2P LSP."







6）In previous question 2, I am a little confused in the option b scenario where 
ASBR may change all inter-AS RT-2 routes' nexthop


 into the same IP address (identifying that ASBR).


 But some of these RT-2 route  may  originate from PEs with flow label 
capability,


 while some of these RT-2 route may originate from PEs without flow label 
capability,


 How can these different flow label capabilities of RT-2 routes be 
distinguished?


 I think the IMET route's Originator IP Address may help, 


 but RT-2 routes don't carry an originator IP address, maybe the OPE TLV of 
draft-heitz-bess-evpn-option-b-01 can be used,


 in order to find out the correct flow label capability and avoid the 
black-hole caused by incorrect flow label capability.


 I think this is very similar to the procedures used to select leaf labels 
for EVPN E-Tree services.









7) I noticed that RFC7432 has already used a control-word, although RFC7432 
don't recognize a C bit (or L2-Attr EC).


So when PE1 sends a Inclusive Multicast route to an old RFC7432-only node 
PE2 along with a C bit = 1,


but PE2 doesn't insert a control-word for it in the data packet, 


I think PE1 may not decapsulate that data packet correctly.


Because PE1 can't know that PE2 doesn't insert a control word.


It may be easy to determine whether a data packet is inserted with a flow 
label,


but it is not easy to determine whether a data packet is inserted with a 
control word.


I think there may be compatibility issues in such scenarios.


Otherwise maybe the IMET route from PE1 to PE2 and the IMET route from PE2 
to PE1 should be used together to determine whether a control word can be 
expected in the data plane. This may requires a PED label similar to that is in 
draft-ietf-bess-evpn-virtual-hub.



But a special purpose label (similar to ELI label) may be easier to 
indicate there is (or isn't) a control-word in the data packet.


 






8) IMHO, the problem which is pointed out by RFC7447 is a common problem, not 
just the ELC Attribute will be affected.


 Other BGP Attributes (e.g. flow label, control word)  which can match the 
following features will  all have the similar problems:


 8.1) these attributes are optional transitive BGP attributes


 8.2) these attributes has a corresponding protocol-header in the data 
packets (e.g. flow label, control word, leaf label by OPE TLV)






 Maybe  we need a new attr. flag (thus we don't have to set the transitive 
flag in the future optional attributes when we want such optional attributes to 
pass through a future RR which can't recognize it) to address these problems. 






9) How can the egress PE know whether the ingress PE will use a P2P RSVP-TE LSP 
or not ?


how should the egress PE know whether it can expect there is a control word 
in corresponding data packet or not?


In RFC7432, these responsibilities is left to manual configurations,


but now it is a dynamical signalling/negotiation, the manual work may not 
need to care about these things any more.








   *  When sending EVPN-encapsulated packets over a P2MP or P2P RSVP-TE

  LSP, then the control word SHOULD NOT be used.













Thanks


Yubao














原始邮件



发件人：王玉保10045807
收件人：draft-ietf-bess-rfc7432...@ietf.org;
抄送人：bess@ietf.org;
日 期 ：2022年03月17日 13:36
主 题 ：Comments on L2-Attr Extended Community of draft-ietf-bess-rfc7432bis-04








Hi authors,





I read draft-ietf-bess-rfc7432bis-04 and I have the follwing questions and 
comments:





1) In section 7.11.1, F bit (flow label capability) of L2 Attr Extended 
Community is conveyed in Inclusive Multicast routes only,


and F bit will not be conveyed in Etherne A-D per EVI routes.


It will mean that the Inclusive Multicast route (which is used for BUM packets 
only in RFC7432) will be used for known-unicast packets too?


Because that the flow label is not pushed onto BUM packets, it is only pushed 
onto known-unicast packets.

[bess] Comments on L2-Attr Extended Community of draft-ietf-bess-rfc7432bis-04

[wang.yubao2]

Hi authors,





I read draft-ietf-bess-rfc7432bis-04 and I have the follwing questions and 
comments:





1) In section 7.11.1, F bit (flow label capability) of L2 Attr Extended 
Community is conveyed in Inclusive Multicast routes only,


and F bit will not be conveyed in Etherne A-D per EVI routes.


It will mean that the Inclusive Multicast route (which is used for BUM packets 
only in RFC7432) will be used for known-unicast packets too?


Because that the flow label is not pushed onto BUM packets, it is only pushed 
onto known-unicast packets.


Is my understanding correct?






2) If my previous understanding is correct, then I have the following questions 
and I can't find explicit describing in rfc7432bis.


When PE1 received an Inclusive Multicast route with (tunnel 
type=ingress-replication, Tunnel Identifier of PMSI tunnel attr = IP1, nexthop 
= IP2, originator IP address = IP3), 


so which one of the following cases should be inserted with a flow label?


2.1) a RT-2 route whose nexthop is IP1 and ESI is 0;


2.2) a RT-2 route whose nexthopp is IP2 and ESI is 0;


2.3) a RT-2 route whose nexthop is IP3 and ESI is 0;


2.4) a RT-2 route whose nexthop is IP1(or IP2) and ESI is an all-active ESI, 
but the Ethernet A-D per EVI route's nexthop is IP4





2.5) a RT-2 route whose nexthop is IP4 and ESI is a single-active ESI and MPLS 
label is L2, but the Ethernet A-D per EVI route's nexthop is IP1(or IP2) and 
MPLS label is L1.


In question 2.5, I also don't find any explicit describing about which MPLS 
label should be used in such case.


so which MPLS label should be used L2 or L1 in such case according to 
rfc7432bis? 





I think it will be more clear than this way if the Flow label capability is 
carried by RT-2 routes themselves.






3) How to interpret "a given MAC address is only  reachable only via the PE 
announcing the associated MAC/IP  Advertisement route" ?


 I mean that: When PE1 receives a RT-2 route whose nexthop is IP1, and the 
corresponding Etherne A-D per EVI route (whose nexthop is also IP1) conveys a 
non-zero B bit, but there is another Ethernet A-D per EVI route whose P bit is 
not zero, but its nexthop is IP4 (not IP1, who has announced that RT-2 route), 
should that RT-2 route be installed into the dataplane and be used to 
forwarding traffics?


This case may happens in some temporary conditions.












   This means that for a given [EVI, BD], a given MAC address is only


   reachable only via the PE announcing the associated MAC/IP


   Advertisement route - this PE will also have advertised an Ethernet


   A-D per EVI route for that [EVI, BD] with an L2-Attr extended


   community in which the P bit is set.  I.e., the Primary DF Elected PE


   is also responsible for sending known unicast frames to the CE and


   receiving unicast and BUM frames from it.  Similarly, the Backup DF


   Elected PE will have advertised an Ethernet AD per EVI route for


   [EVI, BD] with an L2-Attr extended community in which the B bit is


   set.








4)  When flow label is not used (as per RFC7432) in Ingress Replication mode,


I try to find out whether the downstream assinged VPN label for known unicast 
must be different than for BUM traffic.


And I don't find any explicit describing for this, and I just noticed that in 
EVPN VXLAN they can be the same.


So when flow label is not used in MPLS EVPN, 


can the downstream assinged VPN label for known unicast be the same as for BUM 
traffic following rfc7432bis?


If this is just for flow-label only, I think it will be better to say "If 
flow-label is used, the downstream assigned VPN label for known unicast 
can/should be different than for BUM traffic"





 


   *  If a PE receives a unicast packet with two labels, then it can


  differentiate between [VPN label + ESI label] and [VPN label +


  Flow label] and there should be no ambiguity between ESI and Flow


  labels even if they overlap.  The reason for this is that the


  downstream assigned VPN label for known unicast is different than


  for BUM traffic and ESI label (if present) comes after BUM VPN


  label.  Therefore, from the VPN label, the receiving PE knows


  whether the next label is a ESI label or a Flow label - i.e., if


  the VPN label is for known unicast, then the next label MUST be a


  flow label and if the VPN label is for BUM traffic, then the next


  label MUST be an ESI label because BUM packets are not sent with


  Flow labels.








Thanks,


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

Re: [bess] Comments on draft-ietf-bess-evpn-prefix-advertisement and draft-wang-bess-evpn-distributed-bump-in-the-wire

[wang.yubao2]

Hi Jorge,


 


Please see in-line with [yubao].


 


Thanks


Yubao


 










原始邮件



发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：bess@ietf.org;
日 期 ：2021年11月13日 03:00
主 题 ：Re: Re:Comments on  draft-ietf-bess-evpn-prefix-advertisement and 
draft-wang-bess-evpn-distributed-bump-in-the-wire




Hi Yubao,


 


Thanks for explaining, although I’m afraid we disagree on both things  but 
that’s ok. Others can chime in as well.

If you receive an RT1 with ESI-1 and a route-target identifying BD1, the RT5 
with ESI-1 can be resolved to the RT1, hence the traffic will use the IRB 
connected to BD1 (and the MAC of the IRB as MAC SA). You have all the 
information, so it is up to the implementation how to use it or if it can use 
it.




[Yubao] I agree with you on that such implementation can be used in slide 5. 
but I haven't considered it is as a good choice because of the following 
considerations:




the first reason is that: this requires the RT-1 per EVI routes of 
BD-10 and BD-20 to be imported into the context of the IP-VRF,

But we would like to treat BD-10 and BD-20 as normal BDs of [RFC9135], 

I don't think a normal BD of [RFC9135] would import all or parts of its 
RT-1 per EVI routes into the context of the IP-VRF of its IRB.

because that behavior will burden the IP-VRF if no Bump-in-the-wire 
RT-5 routes will be received in the future.




the second reason is that: If the use case of slide 5 is slightly 
changed, that implementation will not work.

Now we can imagine that VA1 and VA2 are provisioned on the same pair of 
TS nodes, and these TS nodes are attached to NVE2 and NVE3 using ESI23 as 
illustrated in slide 6.

In this use case, that implementation will not work. But the RT-5 
routes with a route-target identifying a BD (described in slide 5) will work 
well. 

Note that slide 5 is still a centerlized Bump-in-the-wire use case, but 
BD-10 and BD-20 are assumed to be all configured on all the DGWs.

The supplementary overlay index is mainly used in slide 6, which is a 
distributed Bump-in-the-wire use case and not all of the NVEs should be 
configured with BD-10 or BD-20.

That's why the left side of slide 6 is a NVE node, but the left side of 
slide 5 is a DGW node.

The slide 5 is about the route processing improvement in centerlized 
multiple Bump-in-the-wire insances, whether ESI23a and ESI23b is the same ESI23 
or not. 




The slide 6 is about the route processing improvement in distributed 
multiple Bump-in-the-wire insances, especially when ESI23a and ESI23b is the 
same ESI23. 







I also disagree with the reasons you give to not use a virtual ES. The virtual 
ES spec is implemented and deployed for a long time now.






[Yubao] I agree with you on that the vES draft is there for a long time, but 
not long enough than [draft-ietf-bess-evpn-inter-subnet-forwarding].




What we have concerned on is that, hove a existing normal BD of 
[draft-ietf-bess-evpn-inter-subnet-forwarding] can be smoothly evolved into a 
distributed Bump-in-the-wire or a IP-aliasing-enhanced symmetric IRB.

   Even in the future, there would be some normal BDs of 
[draft-ietf-bess-evpn-inter-subnet-forwarding] which don't use a vES at the 
network operator's choice.

we want to help these deployments to be soothly evolved into a 
distributed Bump-in-the-wire or a IP-aliasing-enhanced symmetric IRB.

I think that we can't assume that the original form of BDs of 
[draft-ietf-bess-evpn-inter-subnet-forwarding] will not be deployed after the 
vES is introduced.





Thanks.


Jorge   


 


 



From: wang.yub...@zte.com.cn 
 Date: Friday, November 12, 2021 at 8:04 AM
 To: Rabadan, Jorge (Nokia - US/Mountain View) 
 Cc: bess@ietf.org 
 Subject: Re:Comments on  draft-ietf-bess-evpn-prefix-advertisement and 
draft-wang-bess-evpn-distributed-bump-in-the-wire



 


Hi Jorge,


 


Please see in-line with [yubao].


 


Thanks


Yubao


 


 


 


原始邮件



发件人：Rabadan,Jorge(Nokia-US/MountainView)



收件人：王玉保10045807;



抄送人：bess@ietf.org;



日 期 ：2021年11月12日 04:06



主 题 ：Re: Re:Comments on  draft-ietf-bess-evpn-prefix-advertisement and 
draft-wang-bess-evpn-distributed-bump-in-the-wire 




Hi Yubao,


 


I realized I did not respond to this (my apologies), and you reflected the same 
questions in your slides about 
draft-wang-bess-evpn-distributed-bump-in-the-wire during the BESS session.


I think it is okay if you want to describe a “distributed” bump-in-the-wire 
scenario, but I don’t understand why you need any new extension.



 
 


[Yubao] Thanks for your response, I will explain why we need the Supplementary 
Overlay Index (or the ACI-specific Ethernet A-D mode) in the following.


 


· In your slide 5, the RT5s can be resolved to the proper RT1, based on 
the ESI overlay index. The ESI is unique (cannot be configured in multiple 
ESes) and 

Re: [bess] Comments on draft-ietf-bess-evpn-prefix-advertisement and draft-wang-bess-evpn-distributed-bump-in-the-wire

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Yubao,

Thanks for explaining, although I’m afraid we disagree on both things  but 
that’s ok. Others can chime in as well.

  *   If you receive an RT1 with ESI-1 and a route-target identifying BD1, the 
RT5 with ESI-1 can be resolved to the RT1, hence the traffic will use the IRB 
connected to BD1 (and the MAC of the IRB as MAC SA). You have all the 
information, so it is up to the implementation how to use it or if it can use 
it.
  *   I also disagree with the reasons you give to not use a virtual ES. The 
virtual ES spec is implemented and deployed for a long time now.
Thanks.
Jorge


From: wang.yub...@zte.com.cn 
Date: Friday, November 12, 2021 at 8:04 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
Cc: bess@ietf.org 
Subject: Re:Comments on  draft-ietf-bess-evpn-prefix-advertisement and 
draft-wang-bess-evpn-distributed-bump-in-the-wire



Hi Jorge,



Please see in-line with [yubao].



Thanks

Yubao






原始邮件
发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：bess@ietf.org;
日 期 ：2021年11月12日 04:06
主 题 ：Re: Re:Comments on  draft-ietf-bess-evpn-prefix-advertisement and 
draft-wang-bess-evpn-distributed-bump-in-the-wire
Hi Yubao,

I realized I did not respond to this (my apologies), and you reflected the same 
questions in your slides about 
draft-wang-bess-evpn-distributed-bump-in-the-wire during the BESS session.
I think it is okay if you want to describe a “distributed” bump-in-the-wire 
scenario, but I don’t understand why you need any new extension.


[Yubao] Thanks for your response, I will explain why we need the Supplementary 
Overlay Index (or the ACI-specific Ethernet A-D mode) in the following.


· In your slide 5, the RT5s can be resolved to the proper RT1, based on 
the ESI overlay index. The ESI is unique (cannot be configured in multiple 
ESes) and the RT1 for the ESI carries the route-target of the BD, hence you 
have all the information to resolve the RT5. What are you missing?



[Yubao] In my slide 5, I mainly wan't to say that, when there are two 
Bump-in-the-wire instances in the same IP-VRF,

Those RT-5 routes don't known which source MAC should their 
corresponding data packets be encapsulated with,

even if their ESI are different.

The notes2 in slide 5 is mainly talking about the use case of slide 6.

But Those RT-5 routes don't known inside which BD should their ESI be 
resolved either, even if their ESI are different.

So I put it together with notes1 in the slide 5, but I have no time to 
explain the reasons in the prensetation.

So, as I explained above, the information is not enough even if their 
ESI are different, that's why we let the RT5 routes carry the export 
Router-Targets of the BD/SBD.

Please note that in slide 5, there are no SBD. Those RT-1 per EVI 
routes will be imported into BD-10 or BD-20 respectively.



[Yubao] Some paragraphs from RFC9136 section 4.3 Bump-in-the-wire may help us 
to understand this:



*  The IP packet destined to IPx is encapsulated with:



   -  Inner source MAC = IRB1 MAC.



   -  Inner destination MAC = M2 (this MAC will be obtained from

  the EVPN Router's MAC Extended Community received along

  with the RT-5 for SN1).  Note that the EVPN Router's MAC

  Extended Community is used in this case to carry the TS's

  MAC address, as opposed to the MAC address of the NVE/PE.



   -  Tunnel information for the NVO tunnel is provided by the

  Ethernet A-D route per EVI for ESI23 (VNI and VTEP IP for

  the VXLAN case).





· In your slide 6 you have a use-case with two ACs in the same ESI23, 
and you seem to use the ethernet tag ID to encode the ACI. Can you not use a 
different virtual Ethernet Segment per BD instead, and use RT1s for each ESI? 
In that way you don’t need to use the ethernet-tag-id, which is used for 
vlan-aware-bundle in general.



[Yubao] We can't use different vES per BD instead, because we can't assume that 
BD-10 and BD-20 is always a new BD, which is created after 
draft-wang-bess-evpn-distributed-bump-in-the-wire.
These BDs may be already there for a long time before they will be 
given a virtual-appliance (VA1 or VA2) who will make them become to BDs of 
bump-in-the-wire instances in the future.
So, before the evolution, they have nothing different from normal BDs, 
I don't think there are any motivations for them to be deployed in the form of 
vES other than a normal ESI.
The vESes have other disadvantages, for example, the RT-4 routes will 
be increased. the service carving will be complicated, the management will be 
complicated, etc.

Thanks.
Jorge


From: wang.yub...@zte.com.cn 
Date: Friday, July 30, 2021 at 5:18 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
Cc: bess@ietf.org 
Subject: Re:Comments on  draft-ietf-bess-evpn-prefix-advertisement



Hi Jorge,



Thank you for your 

Re: [bess] Comments on draft-ietf-bess-evpn-prefix-advertisement and draft-wang-bess-evpn-distributed-bump-in-the-wire

[wang.yubao2]

Hi Jorge,






Please see in-line with [yubao].






Thanks


Yubao


















原始邮件



发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：bess@ietf.org;
日 期 ：2021年11月12日 04:06
主 题 ：Re: Re:Comments on  draft-ietf-bess-evpn-prefix-advertisement and 
draft-wang-bess-evpn-distributed-bump-in-the-wire 




Hi Yubao,


 


I realized I did not respond to this (my apologies), and you reflected the same 
questions in your slides about 
draft-wang-bess-evpn-distributed-bump-in-the-wire during the BESS session.


I think it is okay if you want to describe a “distributed” bump-in-the-wire 
scenario, but I don’t understand why you need any new extension.






[Yubao] Thanks for your response, I will explain why we need the Supplementary 
Overlay Index (or the ACI-specific Ethernet A-D mode) in the following.


 

In your slide 5, the RT5s can be resolved to the proper RT1, based on the ESI 
overlay index. The ESI is unique (cannot be configured in multiple ESes) and 
the RT1 for the ESI carries the route-target of the BD, hence you have all the 
information to resolve the RT5. What are you missing?


 


[Yubao] In my slide 5, I mainly wan't to say that, when there are two 
Bump-in-the-wire instances in the same IP-VRF,


Those RT-5 routes don't known which source MAC should their 
corresponding data packets be encapsulated with, 


even if their ESI are different.


The notes2 in slide 5 is mainly talking about the use case of slide 6.






But Those RT-5 routes don't known inside which BD should their ESI be 
resolved either, even if their ESI are different.


So I put it together with notes1 in the slide 5, but I have no time to 
explain the reasons in the prensetation.


So, as I explained above, the information is not enough even if their 
ESI are different, that's why we let the RT5 routes carry the export 
Router-Targets of the BD/SBD.


Please note that in slide 5, there are no SBD. Those RT-1 per EVI 
routes will be imported into BD-10 or BD-20 respectively.




[Yubao] Some paragraphs from RFC9136 section 4.3 Bump-in-the-wire may help us 
to understand this:




*  The IP packet destined to IPx is encapsulated with:




   -  Inner source MAC = IRB1 MAC.




   -  Inner destination MAC = M2 (this MAC will be obtained from

  the EVPN Router's MAC Extended Community received along

  with the RT-5 for SN1).  Note that the EVPN Router's MAC

  Extended Community is used in this case to carry the TS's

  MAC address, as opposed to the MAC address of the NVE/PE.




   -  Tunnel information for the NVO tunnel is provided by the

  Ethernet A-D route per EVI for ESI23 (VNI and VTEP IP for

  the VXLAN case).









In your slide 6 you have a use-case with two ACs in the same ESI23, and you 
seem to use the ethernet tag ID to encode the ACI. Can you not use a different 
virtual Ethernet Segment per BD instead, and use RT1s for each ESI? In that way 
you don’t need to use the ethernet-tag-id, which is used for vlan-aware-bundle 
in general.




[Yubao] We can't use different vES per BD instead, because we can't assume that 
BD-10 and BD-20 is always a new BD, which is created after 
draft-wang-bess-evpn-distributed-bump-in-the-wire.


These BDs may be already there for a long time before they will be 
given a virtual-appliance (VA1 or VA2) who will make them become to BDs of 
bump-in-the-wire instances in the future.


So, before the evolution, they have nothing different from normal BDs, 
I don't think there are any motivations for them to be deployed in the form of 
vES other than a normal ESI.


The vESes have other disadvantages, for example, the RT-4 routes will 
be increased. the service carving will be complicated, the management will be 
complicated, etc.


 


Thanks.


Jorge


 


 



From: wang.yub...@zte.com.cn 
 Date: Friday, July 30, 2021 at 5:18 PM
 To: Rabadan, Jorge (Nokia - US/Mountain View) 
 Cc: bess@ietf.org 
 Subject: Re:Comments on  draft-ietf-bess-evpn-prefix-advertisement



 


Hi Jorge,


 


Thank you for your email.


I  know that  EVPN application will pick up one. 


But my question is how can you make sure that the exact one in your expectation 
will be picked out?


Other scenarios just need to pick up one for all RT-2 routes that refers to 
that ESI, 


but the Bump-in-the-wire use case need to pick the exact one per each RT-5 
route.


That's the difference.


 


In the example I have described , if the IP-VRF picks up the RT1 route 
R1_BD2,


The data packets to SN1 will be sent over another BD (BD-20), and BD-20 can't 
reach SN1. 


That's the problem. 


Note that BD-20 and BD-10 are on the same ES but on different VLAN of that ES. 


This problem requires the EVPN Application to use both R5's RD and ESI overlay 
index to ensure that only R1_BD1 will be picked out.  

Re: [bess] Comments on draft-ietf-bess-evpn-prefix-advertisement and draft-wang-bess-evpn-distributed-bump-in-the-wire

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Yubao,

I realized I did not respond to this (my apologies), and you reflected the same 
questions in your slides about 
draft-wang-bess-evpn-distributed-bump-in-the-wire during the BESS session.
I think it is okay if you want to describe a “distributed” bump-in-the-wire 
scenario, but I don’t understand why you need any new extension.


  *   In your slide 5, the RT5s can be resolved to the proper RT1, based on the 
ESI overlay index. The ESI is unique (cannot be configured in multiple ESes) 
and the RT1 for the ESI carries the route-target of the BD, hence you have all 
the information to resolve the RT5. What are you missing?



  *   In your slide 6 you have a use-case with two ACs in the same ESI23, and 
you seem to use the ethernet tag ID to encode the ACI. Can you not use a 
different virtual Ethernet Segment per BD instead, and use RT1s for each ESI? 
In that way you don’t need to use the ethernet-tag-id, which is used for 
vlan-aware-bundle in general.

Thanks.
Jorge


From: wang.yub...@zte.com.cn 
Date: Friday, July 30, 2021 at 5:18 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
Cc: bess@ietf.org 
Subject: Re:Comments on  draft-ietf-bess-evpn-prefix-advertisement



Hi Jorge,



Thank you for your email.

I  know that  EVPN application will pick up one.

But my question is how can you make sure that the exact one in your expectation 
will be picked out?

Other scenarios just need to pick up one for all RT-2 routes that refers to 
that ESI,

but the Bump-in-the-wire use case need to pick the exact one per each RT-5 
route.

That's the difference.



In the example I have described , if the IP-VRF picks up the RT1 route 
R1_BD2,

The data packets to SN1 will be sent over another BD (BD-20), and BD-20 can't 
reach SN1.

That's the problem.

Note that BD-20 and BD-10 are on the same ES but on different VLAN of that ES.

This problem requires the EVPN Application to use both R5's RD and ESI overlay 
index to ensure that only R1_BD1 will be picked out.

As far as I know, such approach has never been used in symmetric IRB, for 
ARP/ND tables and for interface-ful models up to now.



Whe should note that EVPN not only have port-based service interface, but also 
have VLAN-based service interface.

When the EVPN Instances on ESI23 uses VLAN-based service interface, and these 
BDs are integrated with the same Routing Instance (IP-VRF),

How can the IP-VRF pick out the exact one (behind which the prefix SN1 of that 
RT-5 lies there) from many RT-1 routes (one per BD) ?

Do you think that each one (if it is picked out) of them will reach SN1 ?



If anything about the problem statement is not clear, let me know where is it 
please.



This is the example (based on  Figure 7 of [IP Prefix 
Advertisement]
 ) I have described for problem statement, I repeat it here:

"To be clear, If the DGW1 receives a RT-5 route R5 (IPL=24, IP=SN1, ESI=ESI23, 
from NVE2) and two RT1 routes R1_BD1 and R1_BD2.

These two RT1 routes both can be imported into the same IP-VRF instance.

Which RT-1 route will  R5's ESI overlay index be resolved to?

The R1_BD1 or the R1_BD2 ?"



Thanks,

Yubao


原始邮件
发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：bess@ietf.org;
日 期 ：2021年07月30日 21:47
主 题 ：Re: Comments on  draft-ietf-bess-evpn-prefix-advertisement
Hi Yubao,

For GW-IP overlay indexes, until the PE does not receive at least one RT2 for 
the GW-IP, you can’t resolve the RT5. If you receive multiple for the same IP 
with the same key, it is bgp best path selection. If you receive multiple for 
the same IP, different key, the EVPN application picks up one. Implementations 
have been doing that selection for symmetric IRB, for ARP/ND tables and for 
interface-ful models for years, why is it a problem.

Similar for ESI as overlay index.

Thanks.

Jorge


From: wang.yub...@zte.com.cn 
Date: Friday, July 30, 2021 at 5:01 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
Cc: bess@ietf.org 
Subject: Comments on  draft-ietf-bess-evpn-prefix-advertisement



Hi Jorge,



In our discussion in another thread, we discussed two types ot the use cases of 
 draft-ietf-bess-evpn-prefix-advertisement,

They are the GW-IP as overlay index use cases (just let me call them 
GW-IP-Style use-cases for short) and the Bump-in-the-wire use case.

I think it is better to discuss it more clearly in a new thread.



1) For the GW-IP-Style use cases, thank you for telling me that the following 
text may be contradictory (But I don't think it is like that, I will explain it 
later)  with my approach :

 ". If the RT-5 specifies a GW IP address as the Overlay Index,

   recursive resolution can only be done if the NVE has received and

   installed an RT-2 (MAC/IP route) specifying that IP address in

   the IP address field of its NLRI."

 It seems that we have to find out that RT-2 before the recursive 
resolution.

 I 

Re: [bess] Comments on draft-ietf-bess-evpn-prefix-advertisement

[wang.yubao2]

Hi Jorge,






Thank you for your email.


I  know that  EVPN application will pick up one. 


But my question is how can you make sure that the exact one in your expectation 
will be picked out?


Other scenarios just need to pick up one for all RT-2 routes that refers to 
that ESI, 


but the Bump-in-the-wire use case need to pick the exact one per each RT-5 
route.


That's the difference.






In the example I have described , if the IP-VRF picks up the RT1 route 
R1_BD2,


The data packets to SN1 will be sent over another BD (BD-20), and BD-20 can't 
reach SN1. 


That's the problem. 


Note that BD-20 and BD-10 are on the same ES but on different VLAN of that ES. 


This problem requires the EVPN Application to use both R5's RD and ESI overlay 
index to ensure that only R1_BD1 will be picked out.  


As far as I know, such approach has never been used in symmetric IRB, for 
ARP/ND tables and for interface-ful models up to now.






Whe should note that EVPN not only have port-based service interface, but also 
have VLAN-based service interface.


When the EVPN Instances on ESI23 uses VLAN-based service interface, and these 
BDs are integrated with the same Routing Instance (IP-VRF),


How can the IP-VRF pick out the exact one (behind which the prefix SN1 of that 
RT-5 lies there) from many RT-1 routes (one per BD) ?


Do you think that each one (if it is picked out) of them will reach SN1 ?






If anything about the problem statement is not clear, let me know where is it 
please.






This is the example (based on  Figure 7 of [IP Prefix Advertisement] ) I have 
described for problem statement, I repeat it here:


"To be clear, If the DGW1 receives a RT-5 route R5 (IPL=24, IP=SN1, ESI=ESI23, 
from NVE2) and two RT1 routes R1_BD1 and R1_BD2. 


These two RT1 routes both can be imported into the same IP-VRF instance.


Which RT-1 route will  R5's ESI overlay index be resolved to?


The R1_BD1 or the R1_BD2 ?"






Thanks,


Yubao










原始邮件



发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：bess@ietf.org;
日 期 ：2021年07月30日 21:47
主 题 ：Re: Comments on  draft-ietf-bess-evpn-prefix-advertisement




Hi Yubao,

For GW-IP overlay indexes, until the PE does not receive at least one RT2 for 
the GW-IP, you can’t resolve the RT5. If you receive multiple for the same IP 
with the same key, it is bgp best path selection. If you receive multiple for 
the same IP, different key, the EVPN application picks up one. Implementations 
have been doing that selection for symmetric IRB, for ARP/ND tables and for 
interface-ful models for years, why is it a problem.

Similar for ESI as overlay index.

Thanks.

Jorge


 


 



From: wang.yub...@zte.com.cn 
 Date: Friday, July 30, 2021 at 5:01 AM
 To: Rabadan, Jorge (Nokia - US/Mountain View) 
 Cc: bess@ietf.org 
 Subject: Comments on  draft-ietf-bess-evpn-prefix-advertisement



 


Hi Jorge,


 


In our discussion in another thread, we discussed two types ot the use cases of 
 draft-ietf-bess-evpn-prefix-advertisement, 


They are the GW-IP as overlay index use cases (just let me call them 
GW-IP-Style use-cases for short) and the Bump-in-the-wire use case.


I think it is better to discuss it more clearly in a new thread.


 


1) For the GW-IP-Style use cases, thank you for telling me that the following 
text may be contradictory (But I don't think it is like that, I will explain it 
later)  with my approach : 


 ". If the RT-5 specifies a GW IP address as the Overlay Index,


   recursive resolution can only be done if the NVE has received and


   installed an RT-2 (MAC/IP route) specifying that IP address in


   the IP address field of its NLRI."


 It seems that we have to find out that RT-2 before the recursive 
resolution.


 I just don't know that how can we know there is such a RT-2 before the 
recursive resolution ?


We should note that the keys of that RT-2 is , but the GW-IP 
is just an IP. 


So how can we find out that RT-2 just using an IP before the recursive 
resolution?


 


2) For the ESI as overlay index use cases, there is similar text as the 
following:


 ". If the RT-5 specifies an ESI as the Overlay Index, recursive


 resolution can only be done if the NVE has received and 
installed


an RT-1 (Auto-Discovery per-EVI) route specifying that ESI."


Given that the keys of RT-1 are ,


So how can we find out that RT-2 before recursive resolution just using  ?


 


3) For Bump-in-the-wire use case, we would find many RT-1 routes for that ESI 
even after the recursive rosolution.


 


Just take the Figure 7 of [IP Prefix Advertisement] for example, 


How can DGW1 in that Figure find out the exact RT-1 of  ?


We should note that the RDs of BDs are different from the RD of that IP-VRF.


   To be clear, If the DGW1 receives a RT-5 route R5 (IPL=24, IP=SN1, 
ESI=ESI23, from NVE2) and two RT1 routes R1_BD1 and 
R1_BD2. 


  These 

[bess] Comments on draft-ietf-bess-evpn-prefix-advertisement

[wang.yubao2]

Hi Jorge,






In our discussion in another thread, we discussed two types ot the use cases of 
 draft-ietf-bess-evpn-prefix-advertisement, 


They are the GW-IP as overlay index use cases (just let me call them 
GW-IP-Style use-cases for short) and the Bump-in-the-wire use case.


I think it is better to discuss it more clearly in a new thread.






1) For the GW-IP-Style use cases, thank you for telling me that the following 
text may be contradictory (But I don't think it is like that, I will explain it 
later)  with my approach : 


 ". If the RT-5 specifies a GW IP address as the Overlay Index,


   recursive resolution can only be done if the NVE has received and


   installed an RT-2 (MAC/IP route) specifying that IP address in


   the IP address field of its NLRI."


 It seems that we have to find out that RT-2 before the recursive 
resolution.


 I just don't know that how can we know there is such a RT-2 before the 
recursive resolution ?


We should note that the keys of that RT-2 is , but the GW-IP 
is just an IP. 


So how can we find out that RT-2 just using an IP before the recursive 
resolution?






2) For the ESI as overlay index use cases, there is similar text as the 
following:

 ". If the RT-5 specifies an ESI as the Overlay Index, recursive

 resolution can only be done if the NVE has received and 
installed

an RT-1 (Auto-Discovery per-EVI) route specifying that ESI."


Given that the keys of RT-1 are ,


So how can we find out that RT-2 before recursive resolution just using  ?






3) For Bump-in-the-wire use case, we would find many RT-1 routes for that ESI 
even after the recursive rosolution.






Just take the Figure 7 of [IP Prefix Advertisement] for example, 


How can DGW1 in that Figure find out the exact RT-1 of  ?


We should note that the RDs of BDs are different from the RD of that IP-VRF.


   To be clear, If the DGW1 receives a RT-5 route R5 (IPL=24, IP=SN1, 
ESI=ESI23, from NVE2) and two RT1 routes R1_BD1 and 
R1_BD2. 


  These two RT1 routes both can be imported into the same IP-VRF instance.


  Which RT-1 route will  R5's ESI overlay index be resolved to?


  The R1_BD1 or the R1_BD2 ?






4) For Bump-in-the-wire use case, Both of NVE2 and NVE3 will advertise a RT-5 
route to DGW1,


 Will the common ESI23 of these two RT-5 routes be resolved to the same 
RT-1 route? and how?


 Note that even the RD of BD-10 will be different on NVE2 and NVE3.


 When they are the same RD,I think there wil be method that the RT-5 from 
NVE3 can be resolved to the same RT-1 from NVE2. 






5) For Bump-in-the-wire use case, If NVE3 advertise another RT-5 route R5b for 
another BD (say BD-20) but for the another prefix (e.g. SN2) of the same IP-VRF.


 If the RD of that R5b is the same as R5 (see question 3), will the ESI23 
of R5b be resolved to the same RT-1 as what R5 will be resolved to?


 It seems that they will,  according current procedures. But is this result 
in expectation ?


 Note that ESI23 is provisioned on attachment ports, but both BD-10 and 
BD-20 can have an separate AC on the same port. 










Regards,


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

Re: [bess] Comments on draft-sajassi-bess-evpn-ip-aliasing-02

[wang.yubao2]

Hi Jorge,






I still don't agree that the procedures on Leaf-5 are already in 
draft-ietf-bess-evpn-prefix-advertisement-11.






Note that the key of RT1 route is ,  not just .


Take the DGW1 of the Bump-in-the-wire use case for example,



If the DGW1 receives a RT-5 route R5 (IPL=24, IP=SN1, ESI=ESI23) and two RT1 
routes R1_BD1 and R1_BD2. 


These two RT1 routes both can be imported into the same IP-VRF instance.


Which RT-1 route will  R5's ESI overlay index be resolved to?


The R1_BD1 or the R1_BD2 ?


Because that the RD of RT-1 route in  Bump-in-the-wire is not the same as yours.


Thus the procedures of that use case is not the same as the discussed use case.


Doing anything different than what is in section 4.3 will not interoperate with 
non-upgraded DGW1.






Actually, I have used ESI as overlay index in the early revision of 
draft-wang-bess-evpn-arp-nd-synch-without-irb .


But later I found that the route resolution of the Bump-in-the-wire use case is 
not the same as I have expected at that time.


But the GW-IP overlay index is much better.


So I mainly use the GW-IP Overlay index, I just use the ESI Overlay index when 
there is already an ESI (e.g. the ESI is configured for other purpose), 


I don't think we need to configure an ESI just for using it as overlay index.


Note that even in Bump-in-the-wire use case, the ESI23 is configured for BD-10 
(see Figure 7 of IP prefix advertisement), not just for using it as overlay 
index.






Please see more in-line with [Yubao_3]






Thanks,


Bob.














原始邮件



发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：bess@ietf.org;
日 期 ：2021年07月29日 00:14
主 题 ：Re: Re:Comments on draft-sajassi-bess-evpn-ip-aliasing-02




Hi Yubao,


 


More in-line.


 


Thanks.


Jorge


 


 



From: wang.yub...@zte.com.cn 
 Date: Wednesday, July 28, 2021 at 5:35 PM
 To: Rabadan, Jorge (Nokia - US/Mountain View) 
 Cc: bess@ietf.org 
 Subject: Re:Comments on draft-sajassi-bess-evpn-ip-aliasing-02



 


Hi Jorge,


 


I don't  agree with you for that the recursive resolution for such ESI overlay 
index is already there.

[jorge] The resolution of an RT5 with non-zero ESI to a RT1 is already in 
draft-ietf-bess-evpn-prefix-advertisement. The resolution of an RT5 with 
non-zero ESI to a local ESI for the synchronization or the route-table belongs 
to the ip-aliasing draft. See more below.




[Yubao_3] As I discussed above, the resolution procedures there is very 
different from here. 

  Please see more in-line below with [Yubao_3] 








Current recursive resolution is very different from such ESI overlay index.


 


Please see in-line with [Yubao].


 


Thanks,


Yubao


 


原始邮件



发件人：Rabadan,Jorge(Nokia-US/MountainView)



收件人：王玉保10045807;



抄送人：bess@ietf.org;



日 期 ：2021年07月28日 21:23



主 题 ：Re: Re:Comments on draft-sajassi-bess-evpn-ip-aliasing-02




Hi Yubao,


 


Assuming we agree we can’t have a RT5 with non-zero GW-IP and non-zero ESI, 
I’ll try to compare using a) gw-ip *or* b) ESI in the RT5 for this use case 
when leaf-5 is a non-upgraded PE:


 


a) non-zero GW-IP. Suppose if Leaf-5 is a non-upgraded PE but it complies with 
draft-evpn-prefix-advertisement. Leaf-5 receives a RT5 with GW-IP=1.1.1.1, and 
will expect a RT2 to resolve the overlay index. So Leaf-5 will not forward any 
traffic till that RT2 is received. You could extend your suggestion to 
advertise an RT2 with the VNF loopback, but the MAC could not be the VNF MAC, 
or you would run into issues. Also the RT2 would need IP-VRF route-target and 
label. Also we don’t want to do that, we want to leave the RT2 for either the 
interface-ful model, or the symmetric IRB model. Using RT2s in the 
interface-less model would bring ambiguity and issues.



 
 


[Yubao] I don't think the GW-IP have to expect a RT2 to resolve the overlay 
index.


It just need to expect to find the GW-IP in the FIB, regardless of that 
which form of route will be resolved.


In this use case, it will be another RT5 route for 1.1.1.1.


As you have pointed out, this is nothing new. so it will works.


< 


[jorge] I don’t think I pointed that out. Let me clarify:

A RT5 that uses the NLRI next-hop for resolution (so no overlay index) can be 
resolved to another RT5. That is, if the RT5’s next-hop was 1.1.1.1 and you 
have another RT5 for 1.1.1.1/32, I agree that is not new. But this is not the 
case we are discussing.

A RT5 that uses a GW-IP overlay index for resolution it is expecting a RT2 as 
per draft-ietf-bess-evpn-prefix-advertisement:


“. If an NVE receives an RT-5 that specifies an Overlay Index, the


   NVE cannot use the RT-5 in its IP-VRF unless (or until) it can


   recursively resolve the Overlay Index.





 . If the RT-5 specifies a GW IP address as the Overlay Index,


   recursive resolution can only be done if the NVE has received and


   installed an RT-2 (MAC/IP route) 

Re: [bess] Comments on draft-sajassi-bess-evpn-ip-aliasing-02

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Yubao,

More in-line.

Thanks.
Jorge


From: wang.yub...@zte.com.cn 
Date: Wednesday, July 28, 2021 at 5:35 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
Cc: bess@ietf.org 
Subject: Re:Comments on draft-sajassi-bess-evpn-ip-aliasing-02



Hi Jorge,



I don't  agree with you for that the recursive resolution for such ESI overlay 
index is already there.

[jorge] The resolution of an RT5 with non-zero ESI to a RT1 is already in 
draft-ietf-bess-evpn-prefix-advertisement. The resolution of an RT5 with 
non-zero ESI to a local ESI for the synchronization or the route-table belongs 
to the ip-aliasing draft. See more below.

Current recursive resolution is very different from such ESI overlay index.



Please see in-line with [Yubao].



Thanks,

Yubao


原始邮件
发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：bess@ietf.org;
日 期 ：2021年07月28日 21:23
主 题 ：Re: Re:Comments on draft-sajassi-bess-evpn-ip-aliasing-02
Hi Yubao,

Assuming we agree we can’t have a RT5 with non-zero GW-IP and non-zero ESI, 
I’ll try to compare using a) gw-ip *or* b) ESI in the RT5 for this use case 
when leaf-5 is a non-upgraded PE:

a) non-zero GW-IP. Suppose if Leaf-5 is a non-upgraded PE but it complies with 
draft-evpn-prefix-advertisement. Leaf-5 receives a RT5 with GW-IP=1.1.1.1, and 
will expect a RT2 to resolve the overlay index. So Leaf-5 will not forward any 
traffic till that RT2 is received. You could extend your suggestion to 
advertise an RT2 with the VNF loopback, but the MAC could not be the VNF MAC, 
or you would run into issues. Also the RT2 would need IP-VRF route-target and 
label. Also we don’t want to do that, we want to leave the RT2 for either the 
interface-ful model, or the symmetric IRB model. Using RT2s in the 
interface-less model would bring ambiguity and issues.


[Yubao] I don't think the GW-IP have to expect a RT2 to resolve the overlay 
index.
It just need to expect to find the GW-IP in the FIB, regardless of that 
which form of route will be resolved.
In this use case, it will be another RT5 route for 1.1.1.1.
As you have pointed out, this is nothing new. so it will works.
<
[jorge] I don’t think I pointed that out. Let me clarify:

  *   A RT5 that uses the NLRI next-hop for resolution (so no overlay index) 
can be resolved to another RT5. That is, if the RT5’s next-hop was 1.1.1.1 and 
you have another RT5 for 1.1.1.1/32, I agree that is not new. But this is not 
the case we are discussing.
  *   A RT5 that uses a GW-IP overlay index for resolution it is expecting a 
RT2 as per draft-ietf-bess-evpn-prefix-advertisement:
“. If an NVE receives an RT-5 that specifies an Overlay Index, the
   NVE cannot use the RT-5 in its IP-VRF unless (or until) it can
   recursively resolve the Overlay Index.

 . If the RT-5 specifies a GW IP address as the Overlay Index,
   recursive resolution can only be done if the NVE has received and
   installed an RT-2 (MAC/IP route) specifying that IP address in
   the IP address field of its NLRI.”

<


b) non-zero ESI. A non-upgraded Leaf-5 receives the RT5 with non-zero ESI and 
will expect a RT1 to resolve the overlay index as per 
draft-evpn-prefix-advertisement. When the RT1 comes along, it may not do 
aliasing, but it will forward the traffic.

[Yubao] If you mean the procedures in the 
Bump-in-the-wire
 use case,
I would say that the ESI23 will expect a RT1 to resolve the overlay 
index,
But not a random RT1 of ESI23, it Must be the RT1 of an expected BD.
But an IP-VRF may have many BDs attached to it, all of them may 
advertise a RT1 for ESI23.
Which BD's RT1 should the ESI23 of that RT5 be resolved?
The Bump-in-the-wire contains such requirements, but this use case 
don't.
I don't think they can be considered as the same procedure.
So I don't think that a non-upgraded Leaf-5 should act as you have 
expected.
<<
[jorge] I’m referring to this text in 
draft-ietf-bess-evpn-prefix-advertisement. As specified in the ip-aliasing 
draft, to import the RT1 we slap the IP-VRF route-target on it:

. If the RT-5 specifies an ESI as the Overlay Index, recursive

   resolution can only be done if the NVE has received and installed

   an RT-1 (Auto-Discovery per-EVI) route specifying that ESI.
<<

(b) is the solution we chose in this draft because it is simpler (no complexity 
associated to RT2s) and it is already there also for ESes associated to 
physical links.


[Yubao] I don't agree with that it is already there. please see my above 
explanation.

I don't see any other usage of ESI overlay index in RT5 route, except 
for the Bump-in-the-wire use case.

Are there other ESI usage specifications for RT5 that I have missed out 
?
<<
[jorge] I’m 

Re: [bess] Comments on draft-sajassi-bess-evpn-ip-aliasing-02

[wang.yubao2]

Hi Jorge,






I don't  agree with you for that the recursive resolution for such ESI overlay 
index is already there.


Current recursive resolution is very different from such ESI overlay index.


 


Please see in-line with [Yubao].






Thanks,


Yubao










原始邮件



发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：bess@ietf.org;
日 期 ：2021年07月28日 21:23
主 题 ：Re: Re:Comments on draft-sajassi-bess-evpn-ip-aliasing-02




Hi Yubao,


 


Assuming we agree we can’t have a RT5 with non-zero GW-IP and non-zero ESI, 
I’ll try to compare using a) gw-ip *or* b) ESI in the RT5 for this use case 
when leaf-5 is a non-upgraded PE:


 


a) non-zero GW-IP. Suppose if Leaf-5 is a non-upgraded PE but it complies with 
draft-evpn-prefix-advertisement. Leaf-5 receives a RT5 with GW-IP=1.1.1.1, and 
will expect a RT2 to resolve the overlay index. So Leaf-5 will not forward any 
traffic till that RT2 is received. You could extend your suggestion to 
advertise an RT2 with the VNF loopback, but the MAC could not be the VNF MAC, 
or you would run into issues. Also the RT2 would need IP-VRF route-target and 
label. Also we don’t want to do that, we want to leave the RT2 for either the 
interface-ful model, or the symmetric IRB model. Using RT2s in the 
interface-less model would bring ambiguity and issues.






[Yubao] I don't think the GW-IP have to expect a RT2 to resolve the overlay 
index.


It just need to expect to find the GW-IP in the FIB, regardless of that 
which form of route will be resolved.


In this use case, it will be another RT5 route for 1.1.1.1.


As you have pointed out, this is nothing new. so it will works.






b) non-zero ESI. A non-upgraded Leaf-5 receives the RT5 with non-zero ESI and 
will expect a RT1 to resolve the overlay index as per 
draft-evpn-prefix-advertisement. When the RT1 comes along, it may not do 
aliasing, but it will forward the traffic.


 


[Yubao] If you mean the procedures in the Bump-in-the-wire use case,


I would say that the ESI23 will expect a RT1 to resolve the overlay 
index,


But not a random RT1 of ESI23, it Must be the RT1 of an expected BD.


But an IP-VRF may have many BDs attached to it, all of them may 
advertise a RT1 for ESI23.


Which BD's RT1 should the ESI23 of that RT5 be resolved?


The Bump-in-the-wire contains such requirements, but this use case 
don't.


I don't think they can be considered as the same procedure.


So I don't think that a non-upgraded Leaf-5 should act as you have 
expected.






(b) is the solution we chose in this draft because it is simpler (no complexity 
associated to RT2s) and it is already there also for ESes associated to 
physical links.






[Yubao] I don't agree with that it is already there. please see my above 
explanation.





I don't see any other usage of ESI overlay index in RT5 route, except 
for the Bump-in-the-wire use case.


Are there other ESI usage specifications for RT5 that I have missed out 
?






If you want to use the VNF loopback for the resolution of the RT5 to another 
RT5, please use a different attribute, and not the GW-IP since it will cause 
backwards interop issues.


 


[Yubao] Interfaceful mode says that the GW-IP overlay index will be used for 
the recursive route resolution,


not for just a pre-restricted RT1, it just happens to be a RT1 in that 
use case.


just like it happens to be another RT5 in this use case.


So I think the gap between Interfaceful mode and this use case is more 
smaller


than the gap between Bump-in-the-wire and this use case.


Because in Bump-in-the-wire use case that expected RT1 need to be found 
out among lots of competitors of the same ESI.







[Yubao] This is the orignal text in Interfaceful mode  :




o GW IP address=IRB-IP of the SBD (this is the Overlay Index

  that will be used for the recursive route resolution).






[Yubao] I don't think the route-type is pre-restricted before the recursive 
route resolution. it is techincally not necessary.


 If you know draft-ietf-bess-evpn-prefix-advertisement has said 
that  in wich section , let me know please.






About your comment that RT5s can be advertised with all the leaf nodes with 
different attributes, sure, then you rely on the bgp best path selection done 
on the Leaf-5, nothing new. Here we want the simple primary/backup signaling 
decided by the multihomed leaf nodes, in the same way it is done for L2.






[Yubao] Maybe you mean it is the same way as L2 EVPNs on Leaf-5, 


But it will be differnt way on Leaf-2 and on Leaf-5.


I think the difference between L2 and L3 service is just in expectation,


But Leaf-2 don't have to be so different from Leaf-5.


Will the dataplane be extended on Leaf-2 ?


 


Thanks.


Jorge


 


 



From: wang.yub...@zte.com.cn 
 Date: 

Re: [bess] Comments on draft-sajassi-bess-evpn-ip-aliasing-02

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Yubao,

Assuming we agree we can’t have a RT5 with non-zero GW-IP and non-zero ESI, 
I’ll try to compare using a) gw-ip *or* b) ESI in the RT5 for this use case 
when leaf-5 is a non-upgraded PE:

a) non-zero GW-IP. Suppose if Leaf-5 is a non-upgraded PE but it complies with 
draft-evpn-prefix-advertisement. Leaf-5 receives a RT5 with GW-IP=1.1.1.1, and 
will expect a RT2 to resolve the overlay index. So Leaf-5 will not forward any 
traffic till that RT2 is received. You could extend your suggestion to 
advertise an RT2 with the VNF loopback, but the MAC could not be the VNF MAC, 
or you would run into issues. Also the RT2 would need IP-VRF route-target and 
label. Also we don’t want to do that, we want to leave the RT2 for either the 
interface-ful model, or the symmetric IRB model. Using RT2s in the 
interface-less model would bring ambiguity and issues.

b) non-zero ESI. A non-upgraded Leaf-5 receives the RT5 with non-zero ESI and 
will expect a RT1 to resolve the overlay index as per 
draft-evpn-prefix-advertisement. When the RT1 comes along, it may not do 
aliasing, but it will forward the traffic.

(b) is the solution we chose in this draft because it is simpler (no complexity 
associated to RT2s) and it is already there also for ESes associated to 
physical links.

If you want to use the VNF loopback for the resolution of the RT5 to another 
RT5, please use a different attribute, and not the GW-IP since it will cause 
backwards interop issues.

About your comment that RT5s can be advertised with all the leaf nodes with 
different attributes, sure, then you rely on the bgp best path selection done 
on the Leaf-5, nothing new. Here we want the simple primary/backup signaling 
decided by the multihomed leaf nodes, in the same way it is done for L2.

Thanks.
Jorge


From: wang.yub...@zte.com.cn 
Date: Wednesday, July 28, 2021 at 2:06 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
Cc: bess@ietf.org 
Subject: Re:Comments on draft-sajassi-bess-evpn-ip-aliasing-02



Hi Jorge,



Please see in-line with [Yubao_2].



Thanks,

Yubao




原始邮件
发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：bess@ietf.org;
日 期 ：2021年07月28日 18:18
主 题 ：Re: Re:Comments on draft-sajassi-bess-evpn-ip-aliasing-02
Hi Yubao,

Please see in-line with [jorge].
Thanks.
Jorge

From: wang.yub...@zte.com.cn 
Date: Wednesday, July 28, 2021 at 9:53 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
Cc: bess@ietf.org 
Subject: Re:Comments on draft-sajassi-bess-evpn-ip-aliasing-02



Hi Jorge,



Thanks for your email, but I still don't understand why an ESI is needed here.

I  know there is a static-route 1.1.1.1 on Leaf-2, but my question is that how 
leaf-2 knows the overlay nexthop of 50.0.0.0/24 is 1.1.1.1  (by which that ARP 
entry is found out at last)?

[jorge] leaf-2 does a recursive resolution. It has a RT5 for 50.0.0.0/24 with 
next-hop e.g., Leaf-1, and ESI=ESI-1. So when Leaf-2 receives packets with IP 
DA = 50.0.0.x, it will have a route installed pointing at the local ESI-1, and 
the local ESI-1 is associated to 1.1.1.1, for which leaf-2 has a route (static 
or igp).

As you illustrated in slide 7, Leaf-2 can't get this information from VNF-1 
directly,

[jorge] but it does get it via RT5 with ESI, which is resolved locally.

Leaf-2 just have to get this informatio from the IP Prefix Route Advertisement  
of Leaf-1 or Leaf-4,

But you explained that these route are advertised without GW-IP.

I don't understand it very well.

[jorge] see above. Hope it helps now.

maybe you mean we can inferred from the ESI field that the overlay nexthop is 
the static-route 1.1.1.1 whose ESI is ESI-1?

This approach maybe works.

but the IP address 1.1.1.1 can be directly advertised as GW-IP overlay index 
along with prefix 50.0.0.0/24 naturally if we don't manually change its 
behavior.

so why should we bother to infer from a manual-configured ESI?

[jorge] Some points:


· The ESI can be auto derived as indicated in the draft

· Using the GW-IP as overlay-index is used in interface-ful models and 
the use-cases resolved by an RT2 in draft-ietf-bess-evpn-prefix-advertisement. 
Non upgraded PEs may have an issue with the resolution. However the ESI as an 
overlay-index resolved to AD routes is documented in the prefix-advertisement 
draft.



[Yubao_2] Non-upraded PEs may have an issue to resolution an ESI to an 
static-route too.

  I don't think these two similar issues should be a big 
concern.

 Most of protocol extensions have similar issues.

The ESI overlay index is just used in the bump in the wire use 
case in draft-ietf-bess-evpn-prefix-advertisement.

In that use case, the ESI is configured on L2 ACs and its Ethernet A-D 
per EVI is advertised for a BD,

But in the use case we discussed here, there are no BD1 or BD2 on 
Leaf-5.

They are very different use cases and forwarding procedures.



Even in the 

Re: [bess] Comments on draft-sajassi-bess-evpn-ip-aliasing-02

[wang.yubao2]

Hi Jorge,






Please see in-line with [Yubao_2].






Thanks,


Yubao














原始邮件



发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：bess@ietf.org;
日 期 ：2021年07月28日 18:18
主 题 ：Re: Re:Comments on draft-sajassi-bess-evpn-ip-aliasing-02




Hi Yubao,


 


Please see in-line with [jorge].


Thanks.


Jorge


 



From: wang.yub...@zte.com.cn 
 Date: Wednesday, July 28, 2021 at 9:53 AM
 To: Rabadan, Jorge (Nokia - US/Mountain View) 
 Cc: bess@ietf.org 
 Subject: Re:Comments on draft-sajassi-bess-evpn-ip-aliasing-02



 


Hi Jorge,


 


Thanks for your email, but I still don't understand why an ESI is needed here.


I  know there is a static-route 1.1.1.1 on Leaf-2, but my question is that how 
leaf-2 knows the overlay nexthop of 50.0.0.0/24 is 1.1.1.1  (by which that ARP 
entry is found out at last)?

[jorge] leaf-2 does a recursive resolution. It has a RT5 for 50.0.0.0/24 with 
next-hop e.g., Leaf-1, and ESI=ESI-1. So when Leaf-2 receives packets with IP 
DA = 50.0.0.x, it will have a route installed pointing at the local ESI-1, and 
the local ESI-1 is associated to 1.1.1.1, for which leaf-2 has a route (static 
or igp).


As you illustrated in slide 7, Leaf-2 can't get this information from VNF-1 
directly, 

[jorge] but it does get it via RT5 with ESI, which is resolved locally.


Leaf-2 just have to get this informatio from the IP Prefix Route Advertisement  
of Leaf-1 or Leaf-4,


But you explained that these route are advertised without GW-IP. 


I don't understand it very well.

[jorge] see above. Hope it helps now.


maybe you mean we can inferred from the ESI field that the overlay nexthop is 
the static-route 1.1.1.1 whose ESI is ESI-1?


This approach maybe works.


but the IP address 1.1.1.1 can be directly advertised as GW-IP overlay index 
along with prefix 50.0.0.0/24 naturally if we don't manually change its 
behavior.


so why should we bother to infer from a manual-configured ESI? 

[jorge] Some points:


The ESI can be auto derived as indicated in the draft

Using the GW-IP as overlay-index is used in interface-ful models and the 
use-cases resolved by an RT2 in draft-ietf-bess-evpn-prefix-advertisement. Non 
upgraded PEs may have an issue with the resolution. However the ESI as an 
overlay-index resolved to AD routes is documented in the prefix-advertisement 
draft.




[Yubao_2] Non-upraded PEs may have an issue to resolution an ESI to an 
static-route too.

  I don't think these two similar issues should be a big 
concern.

 Most of protocol extensions have similar issues.

The ESI overlay index is just used in the bump in the wire use 
case in draft-ietf-bess-evpn-prefix-advertisement.

In that use case, the ESI is configured on L2 ACs and its Ethernet A-D 
per EVI is advertised for a BD,

But in the use case we discussed here, there are no BD1 or BD2 on 
Leaf-5.

They are very different use cases and forwarding procedures.




Even in the Bump-in-the-wire use case, although the RT-5 route has the 
ESI23 as overlay index,

but how does the DGWs know which BD should that ESI23 belongs to ?

Note that many BDs(or MAC-VRFs) can advertise Ethernet A-D per EVI 
routes for the same ESI23 independently.




so I think Bump-in-the-wire is very different from the ESI for 
static-route.

And the control-plane defined in Bump-in-the-wire may be not so 
sufficient for the ESI for static-route.






Here we really want to use the ESI as an overlay index and resolve based on the 
AD routes, which gives a consistent solution for the three use cases in the 
draft, and other things like e.g., not only aliasing, but also primary/backup 
behavior


 





[Yubao_2]  Use GW-IP overlay index, primary/backup behavior can also be 
supported.


  Leaf-1/2/3/4 will advertise a RT-5 route for 1.1.1.1 
separately, and they can advertise different preferences/metrics separately.


  GW-IP overlay index can be a consistent solution whether the 
PE-CE BGP sessions are established between Leaf-1/2/3/4 and VNF-1 or between 
DGW and VNF-1.






Yubao


 


 


原始邮件



发件人：Rabadan,Jorge(Nokia-US/MountainView)



收件人：王玉保10045807;



抄送人：bess@ietf.org;



日 期 ：2021年07月28日 14:46



主 题 ：Re: Comments on draft-sajassi-bess-evpn-ip-aliasing-02




Hi Yubao,


 


Thanks for your email. Yes, you misunderstood the use-case  but these are good 
questions, we will clarify in the next revision.


 


1.   The IP Prefix routes are advertised with the ESI and always a 
zero-GW-IP.


a.   Three co-authors of this draft are also co-authors of 
draft-ietf-bess-evpn-prefix-advertisement and the latter explicitly prohibits 
the use of non-zero ESI and non-zero GW-IP simultaneously. So you will not see 
the use of the GW-IP in draft-sajassi-bess-evpn-ip-aliasing.


b.   In fact that is also one of my comments for 

Re: [bess] Comments on draft-sajassi-bess-evpn-ip-aliasing-02

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Yubao,

Please see in-line with [jorge].
Thanks.
Jorge

From: wang.yub...@zte.com.cn 
Date: Wednesday, July 28, 2021 at 9:53 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
Cc: bess@ietf.org 
Subject: Re:Comments on draft-sajassi-bess-evpn-ip-aliasing-02



Hi Jorge,



Thanks for your email, but I still don't understand why an ESI is needed here.

I  know there is a static-route 1.1.1.1 on Leaf-2, but my question is that how 
leaf-2 knows the overlay nexthop of 50.0.0.0/24 is 1.1.1.1  (by which that ARP 
entry is found out at last)?

[jorge] leaf-2 does a recursive resolution. It has a RT5 for 50.0.0.0/24 with 
next-hop e.g., Leaf-1, and ESI=ESI-1. So when Leaf-2 receives packets with IP 
DA = 50.0.0.x, it will have a route installed pointing at the local ESI-1, and 
the local ESI-1 is associated to 1.1.1.1, for which leaf-2 has a route (static 
or igp).

As you illustrated in slide 7, Leaf-2 can't get this information from VNF-1 
directly,

[jorge] but it does get it via RT5 with ESI, which is resolved locally.

Leaf-2 just have to get this informatio from the IP Prefix Route Advertisement  
of Leaf-1 or Leaf-4,

But you explained that these route are advertised without GW-IP.

I don't understand it very well.

[jorge] see above. Hope it helps now.

maybe you mean we can inferred from the ESI field that the overlay nexthop is 
the static-route 1.1.1.1 whose ESI is ESI-1?

This approach maybe works.

but the IP address 1.1.1.1 can be directly advertised as GW-IP overlay index 
along with prefix 50.0.0.0/24 naturally if we don't manually change its 
behavior.

so why should we bother to infer from a manual-configured ESI?

[jorge] Some points:

  *   The ESI can be auto derived as indicated in the draft
  *   Using the GW-IP as overlay-index is used in interface-ful models and the 
use-cases resolved by an RT2 in draft-ietf-bess-evpn-prefix-advertisement. Non 
upgraded PEs may have an issue with the resolution. However the ESI as an 
overlay-index resolved to AD routes is documented in the prefix-advertisement 
draft.
  *   Here we really want to use the ESI as an overlay index and resolve based 
on the AD routes, which gives a consistent solution for the three use cases in 
the draft, and other things like e.g., not only aliasing, but also 
primary/backup behavior



Yubao




原始邮件
发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：bess@ietf.org;
日 期 ：2021年07月28日 14:46
主 题 ：Re: Comments on draft-sajassi-bess-evpn-ip-aliasing-02
Hi Yubao,

Thanks for your email. Yes, you misunderstood the use-case  but these are good 
questions, we will clarify in the next revision.


1.   The IP Prefix routes are advertised with the ESI and always a 
zero-GW-IP.

a.   Three co-authors of this draft are also co-authors of 
draft-ietf-bess-evpn-prefix-advertisement and the latter explicitly prohibits 
the use of non-zero ESI and non-zero GW-IP simultaneously. So you will not see 
the use of the GW-IP in draft-sajassi-bess-evpn-ip-aliasing.

b.   In fact that is also one of my comments for 
draft-mackenzie-bess-evpn-l3aa-proto-00: using non-zero ESI *and* non-zero 
GW-IP in the IP Prefix routes is non-backwards compatible and will break 
interoperability with existing RRs. But I will send a separate email with my 
comments.



2.   About the use-case of slide 7:

a.   As mentioned, the (virtual) ES is associated to the VNF loopback, i.e. 
1.1.1.1, and its operational state is tied to the reachability of that loopback.

b.   On leaf-1/2/3/4, the reachability of the loopback is determined by a 
static-route or IGP, and can be used along with BFD to speed up fault detection.

c.   As an example, suppose leaf-2 has a static-route to 1.1.1.1 with 
next-hops {20.0.0.1,20.0.0.2,20.0.0.3}, and 1.1.1.1 is associated to ES-1.

1. The ARP resolution to those next-hops is done as usual, nothing especial, 
it’s done as soon as the static-route is added.

2. ES-1 will be oper-up as long as the static route is active in the IP-VRF 
route-table. When it goes inactive, ES-1 will go down and the AD routes 
withdrawn.

3. Obviously, and individual AC going down in leaf-2 will not make the 
static-route inactive, hence will not bring down the ES. The IRB going down 
will make the static-route inactive, hence the ES will go down.

d.   A similar example would work with an IGP instead of a static route to 
1.1.1.1.

I think that should clarify your questions.
Let me know otherwise.

Thanks.
Jorge


From: wang.yub...@zte.com.cn 
Date: Wednesday, July 28, 2021 at 12:14 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
Cc: bess@ietf.org 
Subject: Comments on draft-sajassi-bess-evpn-ip-aliasing-02



Hi Jorge,



This is the detailed explanation of the question I asked in the IETF 111 
meeting.

In page 7 of 
slides-111-bess-sessa-evpn-ip-aliasing,
 when leaf-5 send traffic to leaf-2,  how does leaf-2 find 

Re: [bess] Comments on draft-sajassi-bess-evpn-ip-aliasing-02

[wang.yubao2]

Hi Jorge,






Thanks for your email, but I still don't understand why an ESI is needed here.


I  know there is a static-route 1.1.1.1 on Leaf-2, but my question is that how 
leaf-2 knows the overlay nexthop of 50.0.0.0/24 is 1.1.1.1  (by which that ARP 
entry is found out at last)?


As you illustrated in slide 7, Leaf-2 can't get this information from VNF-1 
directly, 


Leaf-2 just have to get this informatio from the IP Prefix Route Advertisement  
of Leaf-1 or Leaf-4,


But you explained that these route are advertised without GW-IP. 


I don't understand it very well.


maybe you mean we can inferred from the ESI field that the overlay nexthop is 
the static-route 1.1.1.1 whose ESI is ESI-1?


This approach maybe works.


but the IP address 1.1.1.1 can be directly advertised as GW-IP overlay index 
along with prefix 50.0.0.0/24 naturally if we don't manually change its 
behavior.


so why should we bother to infer from a manual-configured ESI? 






Yubao














原始邮件



发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：bess@ietf.org;
日 期 ：2021年07月28日 14:46
主 题 ：Re: Comments on draft-sajassi-bess-evpn-ip-aliasing-02




Hi Yubao,


 


Thanks for your email. Yes, you misunderstood the use-case  but these are good 
questions, we will clarify in the next revision.


 

The IP Prefix routes are advertised with the ESI and always a zero-GW-IP.

Three co-authors of this draft are also co-authors of 
draft-ietf-bess-evpn-prefix-advertisement and the latter explicitly prohibits 
the use of non-zero ESI and non-zero GW-IP simultaneously. So you will not see 
the use of the GW-IP in draft-sajassi-bess-evpn-ip-aliasing.

In fact that is also one of my comments for 
draft-mackenzie-bess-evpn-l3aa-proto-00: using non-zero ESI *and* non-zero 
GW-IP in the IP Prefix routes is non-backwards compatible and will break 
interoperability with existing RRs. But I will send a separate email with my 
comments.


 

About the use-case of slide 7:

As mentioned, the (virtual) ES is associated to the VNF loopback, i.e. 1.1.1.1, 
and its operational state is tied to the reachability of that loopback.

On leaf-1/2/3/4, the reachability of the loopback is determined by a 
static-route or IGP, and can be used along with BFD to speed up fault detection.

As an example, suppose leaf-2 has a static-route to 1.1.1.1 with next-hops 
{20.0.0.1,20.0.0.2,20.0.0.3}, and 1.1.1.1 is associated to ES-1.


i.   The ARP resolution to those next-hops is done as 
usual, nothing especial, it’s done as soon as the static-route is added.


  ii.   ES-1 will be oper-up as long as the static route is 
active in the IP-VRF route-table. When it goes inactive, ES-1 will go down and 
the AD routes withdrawn.


 iii.   Obviously, and individual AC going down in leaf-2 
will not make the static-route inactive, hence will not bring down the ES. The 
IRB going down will make the static-route inactive, hence the ES will go down.

A similar example would work with an IGP instead of a static route to 1.1.1.1.


 


I think that should clarify your questions.


Let me know otherwise.


 


Thanks.


Jorge


 


 



From: wang.yub...@zte.com.cn 
 Date: Wednesday, July 28, 2021 at 12:14 AM
 To: Rabadan, Jorge (Nokia - US/Mountain View) 
 Cc: bess@ietf.org 
 Subject: Comments on draft-sajassi-bess-evpn-ip-aliasing-02



 


Hi Jorge,


 


This is the detailed explanation of the question I asked in the IETF 111 
meeting. 


In page 7 of slides-111-bess-sessa-evpn-ip-aliasing, when leaf-5 send traffic 
to leaf-2,  how does leaf-2 find the corresponding ARP entry for 20.0.0.2 or 
20.0.0.1 or 20.1.1.3 ?


I guess the GW-IP 1.1.1.1 will be advertised as overlay index along with the 
ESI.


But the draft-ietf-bess-evpn-prefix-advertisement-11 does not define an IP 
Prefix Advertisement Route with both GW-IP and ESI both as overlay index.


I suggest that this should be updated if you want to do so.


And the preference of ESI overlay index should be considered higher than GW-IP 
overlay index for Leaf-5's sake.


But the preference of ESI overlay index should be considered lower than (or 
maybe they should both be used? ) GW-IP overlay index for Leaf-2's sake


These are new rules that can't be found in 
draft-ietf-bess-evpn-prefix-advertisement-11 .


 


But on the contary,  if the IP Prefix Advertisement Route has a GW-IP overlay 
index,


It can support the same protection procedures without any ESI overlay index.


( The details to do such protection using GW-IP overlay index I have described 
in draft-wang-bess-evpn-arp-nd-synch-without-irb-06. )


So I don't get the point why we need two redundant overlay index?


Can you clearify it?


 


Maybe an IP Prefix Route Style with a GW-IP overlay index is engough here.


And such Route Style is in compliance with  
draft-ietf-bess-evpn-prefix-advertisement-11 already.


 


Another question is that: If the ESI overlay index is 

[bess] Comments about draft-mackenzie-bess-evpn-l3aa-proto-00

[Rabadan, Jorge (Nokia - US/Mountain View)]

Michael,

The chairs asked me to take my comments to the list, so here you are.


  1.  Section 2.6 – RT5 synch
 *   using non-zero ESI *and* non-zero GW-IP in the IP Prefix routes is 
non-backwards compatible with draft-ietf-bess-evpn-prefix-advertisement and 
will break interoperability with existing RRs. So I think it is a serious 
concern.
 *   If you really need to encode the CE next-hop, my suggestion would be 
to use a different attribute. I think the TEA (tunnel encap attribute) could be 
used, with maybe the egress endpoint sub-TLV, or even a new TLV.



  1.  Multicast state synch
 *   Section 1.2 talks about PIM DR election between PE1 and PE2. Doesn’t 
that imply PE1 and PE2 are attached to the same Broadcast Domain? And if so, 
existing procedures for routes type 7/8 would suffice? Could you please clarify?



  1.  Multicast sources
 *   The doc talks about synchronization of states, or in other words 
multihomed receivers. But it does not talk about multihomed sources. Is that 
out of scope? If not, I think you should clarify how you avoid the downstream 
MVPN PE (assuming you use MVPN) from doing a UMH selection to the PE that does 
not receive the multicast stream from the multihomed PE.

I would appreciate feedback on those points.

Thank you!
Jorge

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

Re: [bess] Comments on draft-sajassi-bess-evpn-ip-aliasing-02

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Yubao,

Thanks for your email. Yes, you misunderstood the use-case  but these are good 
questions, we will clarify in the next revision.


  1.  The IP Prefix routes are advertised with the ESI and always a zero-GW-IP.
 *   Three co-authors of this draft are also co-authors of 
draft-ietf-bess-evpn-prefix-advertisement and the latter explicitly prohibits 
the use of non-zero ESI and non-zero GW-IP simultaneously. So you will not see 
the use of the GW-IP in draft-sajassi-bess-evpn-ip-aliasing.
 *   In fact that is also one of my comments for 
draft-mackenzie-bess-evpn-l3aa-proto-00: using non-zero ESI *and* non-zero 
GW-IP in the IP Prefix routes is non-backwards compatible and will break 
interoperability with existing RRs. But I will send a separate email with my 
comments.



  1.  About the use-case of slide 7:
 *   As mentioned, the (virtual) ES is associated to the VNF loopback, i.e. 
1.1.1.1, and its operational state is tied to the reachability of that loopback.
 *   On leaf-1/2/3/4, the reachability of the loopback is determined by a 
static-route or IGP, and can be used along with BFD to speed up fault detection.
 *   As an example, suppose leaf-2 has a static-route to 1.1.1.1 with 
next-hops {20.0.0.1,20.0.0.2,20.0.0.3}, and 1.1.1.1 is associated to ES-1.

i.   The ARP resolution to those next-hops is done as 
usual, nothing especial, it’s done as soon as the static-route is added.

  ii.   ES-1 will be oper-up as long as the static route is 
active in the IP-VRF route-table. When it goes inactive, ES-1 will go down and 
the AD routes withdrawn.

 iii.   Obviously, and individual AC going down in leaf-2 
will not make the static-route inactive, hence will not bring down the ES. The 
IRB going down will make the static-route inactive, hence the ES will go down.

 *   A similar example would work with an IGP instead of a static route to 
1.1.1.1.

I think that should clarify your questions.
Let me know otherwise.

Thanks.
Jorge


From: wang.yub...@zte.com.cn 
Date: Wednesday, July 28, 2021 at 12:14 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
Cc: bess@ietf.org 
Subject: Comments on draft-sajassi-bess-evpn-ip-aliasing-02



Hi Jorge,



This is the detailed explanation of the question I asked in the IETF 111 
meeting.

In page 7 of 
slides-111-bess-sessa-evpn-ip-aliasing,
 when leaf-5 send traffic to leaf-2,  how does leaf-2 find the corresponding 
ARP entry for 20.0.0.2 or 20.0.0.1 or 20.1.1.3 ?

I guess the GW-IP 1.1.1.1 will be advertised as overlay index along with the 
ESI.

But the draft-ietf-bess-evpn-prefix-advertisement-11 does not define an IP 
Prefix Advertisement Route with both GW-IP and ESI both as overlay index.

I suggest that this should be updated if you want to do so.

And the preference of ESI overlay index should be considered higher than GW-IP 
overlay index for Leaf-5's sake.

But the preference of ESI overlay index should be considered lower than (or 
maybe they should both be used? ) GW-IP overlay index for Leaf-2's sake

These are new rules that can't be found in 
draft-ietf-bess-evpn-prefix-advertisement-11
 .



But on the contary,  if the IP Prefix Advertisement Route has a GW-IP overlay 
index,

It can support the same protection procedures without any ESI overlay index.

( The details to do such protection using GW-IP overlay index I have described 
in 
draft-wang-bess-evpn-arp-nd-synch-without-irb-06.
 )

So I don't get the point why we need two redundant overlay index?

Can you clearify it?



Maybe an IP Prefix Route Style with a GW-IP overlay index is engough here.

And such Route Style is in compliance with  
draft-ietf-bess-evpn-prefix-advertisement-11
 already.



Another question is that: If the ESI overlay index is advertised, when will the 
IP A-D per EVI route of Leaf-2 be withdrawn?

When the IRB interface on Leaf-2 fails?

When one of the three ACs fails?

When all of the three ACs fails?

If you want to do so, I suggest that the ESI-1 to be configured onto the IRB 
interfaces,

But in Figure 2 of  
draft-sajassi-bess-evpn-ip-aliasing-02,
 I see the ESI is configured on the ACs of the BDs.



Is anything I have misunderstood?



Best,

Yubao


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

[bess] Comments on draft-sajassi-bess-evpn-ip-aliasing-02

[wang.yubao2]

Hi Jorge,






This is the detailed explanation of the question I asked in the IETF 111 
meeting. 


In page 7 of slides-111-bess-sessa-evpn-ip-aliasing, when leaf-5 send traffic 
to leaf-2,  how does leaf-2 find the corresponding ARP entry for 20.0.0.2 or 
20.0.0.1 or 20.1.1.3 ?


I guess the GW-IP 1.1.1.1 will be advertised as overlay index along with the 
ESI.



But the draft-ietf-bess-evpn-prefix-advertisement-11 does not define an IP 
Prefix Advertisement Route with both GW-IP and ESI both as overlay index.


I suggest that this should be updated if you want to do so.


And the preference of ESI overlay index should be considered higher than GW-IP 
overlay index for Leaf-5's sake.


But the preference of ESI overlay index should be considered lower than (or 
maybe they should both be used? ) GW-IP overlay index for Leaf-2's sake


These are new rules that can't be found in 
draft-ietf-bess-evpn-prefix-advertisement-11 .






But on the contary,  if the IP Prefix Advertisement Route has a GW-IP overlay 
index,


It can support the same protection procedures without any ESI overlay index.


( The details to do such protection using GW-IP overlay index I have described 
in draft-wang-bess-evpn-arp-nd-synch-without-irb-06. )


So I don't get the point why we need two redundant overlay index?


Can you clearify it?






Maybe an IP Prefix Route Style with a GW-IP overlay index is engough here.


And such Route Style is in compliance with  
draft-ietf-bess-evpn-prefix-advertisement-11 already.






Another question is that: If the ESI overlay index is advertised, when will the 
IP A-D per EVI route of Leaf-2 be withdrawn?


When the IRB interface on Leaf-2 fails?


When one of the three ACs fails?


When all of the three ACs fails?


If you want to do so, I suggest that the ESI-1 to be configured onto the IRB 
interfaces,


But in Figure 2 of  draft-sajassi-bess-evpn-ip-aliasing-02, I see the ESI is 
configured on the ACs of the BDs.






Is anything I have misunderstood?






Best,


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

Re: [bess] Comments about draft-ietf-bess-evpn-bfd-03

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Donald,

Thanks.
Looking forward to reading the updated draft.

Jorge

From: Donald Eastlake 
Date: Tuesday, April 6, 2021 at 10:17 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
Cc: draft-ietf-bess-evpn-...@ietf.org , 
bess@ietf.org 
Subject: Re: Comments about draft-ietf-bess-evpn-bfd-03
Hi Jorge,

Thanks for your comments. Sorry for the delay in responding. Please see
below.

On Wed, Mar 10, 2021 at 4:21 AM Rabadan, Jorge (Nokia - US/Mountain
View)  wrote:
>
> Dear authors,
>
> (Most of) these comments were made during the last IETF as
> well. Thank you in advance for considering them.

My apologies for missing things.

> About fault detection for unicast:
>
>By default, it advertises this discriminator with
>BGP using the BFD Discriminator Attribute [ietf-bess-mvpn-fast-
>failover] with BFD Mode TBD4 in an EVPN MAC/IP Advertisement Route
>[RFC7432] and extracts its peer's discriminator from such an
>attribute.
>
> In typical EVPN deployments there are no MAC/IP advertisement routes
> advertised by a PE until the PE does not learn a MAC for a locally
> attached host. Based on the text above, the operator cannot
> establish BFD session against an EVPN PE that has not learn a local
> MAC yet.
>
> Is that the intent? Or is the intend to advertise a local management
> MAC for the purpose of distributing the BFD discriminator required
> for unicast fault detection? Or is it the MAC allocated in section
> 8.2?
>
> Please add text is missing to clarify this.

Yes, we will add text and update the draft to support BFD sessions
between PEs independent of the advertisement of locally attached host
MAC addresses.

> Unicast mpls encapsulation
>
> - The destination IP port MUST be 3784 [RFC5881].
>
>
> s/IP port/UDP port/

OK. "source IP port" in the following line also needs to be fixed and
there are a few other places in the draft that just say "source port"
or "destination port" and could be clarified by adding "UDP".

> The draft does not support BDF for IP multicast traffic in EVPN networks
>
> Is this intended?
> Are you planning to address this gap? If so, text is needed and the
> discriminator added to S-PMSI A-D routes.

Yes, we will add text and update the draft to support BFD for IP BUM
traffic in EVPN networks including adding BFD discriminator attribute
to additional routes as needed.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

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

[bess] Comments, review of - draft-dskc-bess-bgp-car-01 presentation

[Kaliraj Vairavakkalai]

Hi CAR authors,



Thanks for the presentations in IDR and BESS meetings at IETF-110 last week.



We could not discuss in detail during the session because of time constraints. 
So

sharing my comments to the mailing lists.



Starting with follow-up on what Ketan mentioned in the IDR meetecho chat,

regarding SRTE is pull model vs CAR is push model:

I wanted to clarify, that may not be accurate. SRTE is also push model. PCE

provides the ‘pull’ part, which SRTE responds to. So, I think the question

Linda was alluding to remains.



viz: Why do we need another SRTE like family, when we have SRTE already?

Further, following are my own thoughts on the CAR encoding proposal, and 
challenges:

1/ The claim on better packing, and NLRI extensibility:

IMHO, micro-optimizing the NLRI wanting to support better packing introduces 
complexity in

a different dimension. Mixing key and non-key values in the NLRI increases 
implementation

complexity and hampers debuggability.



More-over, the claim of packing goes away when attributes like AIGP need to be 
carried in the

CAR routes. Because AIGP value may be different for different EP:Color NLRIs, 
those cannot be

packed.

One could suggest to put AIGP like attributes also into the NLRI to support 
better packing.

But you can easily see where this leads us. Having per-NLRI attributes leads us 
to the notion

of having “zero packing”. Because now everything is per-prefix. The SID, label, 
SRv6-SID,

other attributes. Etc..

About carrying SRv6 SIDs per NLRI: not being able to share the same SRv6 SID 
for different EP:C

NLRIs (i.e. per-prefix label/sid) may also be inefficient, it may cause huge 
size BGP updates,

which may increase Control plane convergence time.



So, we need to be cautious. Having a kitchen sink NLRI that can have “anything” 
could become a

reason to abuse the protocol in unforeseeable ways. IMHO, it is OK for a BGP 
family to have a

typed NLRI as long as it avoids non-key fields.

2/ using Color in the NLRI as both “Identifier/Distinguisher” as well as the 
“Route-Target” equivalent.

This tight-coupling has the problem that we cannot form Venn diagram of Colors 
to support cases,

where core-network has more colors than access networks. Have the authors 
considered such use-cases?

This also has the problem of not being able to strip color out, to do 
path-selection on EP alone,

as is possible when using RD like distinguisher. When an Anycast EP-address is 
present in multiple

domains, that don’t agree on the same color-namespace, such problems may become 
evident. Albeit a

corner-case, not impossible to conceive in real world.



Also, it is worth noting that IDR has seen similar proposal in the past (BGP 
LCU from Juniper) which

was not pursued further after self reflection on such considerations.

3/ Claim on wide SRTE deployment experience.

I would like to note that, SRTE has so far been used as a single BGP-hop 
family, between

controller and BGP-speaker. And it has no deployment experience doing hop by 
hop readvertisement

and carrying forwarding state thru the inter-domain networks. So applicability 
of ‘SRTE

deployment experience’ in inter-domain BGP networks is questionable.

Comparing it to L3VPN/LU, which CT derives of – it is widely deployed in such a 
role in inter-domain networks.

Authors of CT recognize the scaling challenges that Seamless-MPLS networks see 
today on the transport-layer.

And have proposed multiple ways on how that can be dealt with. Some of those 
mechanisms not only help CT,

but existing LU deployments as-well.



To me, re-using existing functionality, and start improving on the scaling 
challenges seems like a better

approach, than re-inventing existing mechanisms, making them work functionally 
and then coming to the scaling

part.



4/ Filter routes vs CAR routes.



Mechanisms of the Filter-routes is not clearly described yet in the draft.



But taking a guess, it could be either



  *   a new route-type in the same family? (more likely)
  *   OR, uses RTC family routes to provide filtering for CAR routes

If Filter routes are a separate RouteType in the same CAR family,



  Please note that the Filter-routes need to be propagated in the opposite 
direction

  as the CAR transport-advertisements.



  And learning from RTC mechanisms, the initial transport-route-advertisements 
may need to wait for

  EOR of Filter-routes. If those are just different route-types in same NLRI, 
such EOR based

  mechanisms cannot be employed, unless we introduce a per-route-type EOR 
(EORT).



  This also means that the rules for dealing with each route-type needs to be 
specified separately,

  In essence each route-type becomes a new family equivalent, with its own 
distinct needs and rules.

  This looks difficult to comprehend, implement, troubleshoot. Imagine 
specifying both RTC and VPN

  procedures in same bgp-family, carrying them in same RIBs.



 This is just a thought experiment on why 

[bess] Comments about draft-ietf-bess-evpn-bfd-03

[Rabadan, Jorge (Nokia - US/Mountain View)]

Dear authors,

(Most of) these comments were made during the last IETF as well. Thank you in 
advance for considering them.



  1.  About fault detection for unicast:


By default, it advertises this discriminator with

   BGP using the BFD Discriminator Attribute [ietf-bess-mvpn-fast-

   failover] with BFD Mode TBD4 in an EVPN MAC/IP Advertisement Route

   [RFC7432] and extracts its 
peer's discriminator from such an

   attribute.

In typical EVPN deployments there are no MAC/IP advertisement routes advertised 
by a PE until the PE does not learn a MAC for a locally attached host. Based on 
the text above, the operator cannot establish BFD session against an EVPN PE 
that has not learn a local MAC yet.
Is that the intend? Or is the intend to advertise a local management MAC for 
the purpose of distributing the BFD discriminator required for unicast fault 
detection? Or is it the MAC allocated in section 8.2?
Please add text is missing to clarify this.



  1.  Unicast mpls encapsulation


- The destination IP port MUST be 3784 
[RFC5881].

s/IP port/UDP port/



  1.  The draft does not support BDF for IP multicast traffic in EVPN networks

  *   Is this intended?
  *   Are you planning to address this gap? If so, text is needed and the 
discriminator added to S-PMSI A-D routes.


Thanks.
Jorge


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

Re: [bess] Comments regarding draft-schmutzer-bess-ple-01

[Christian Schmutzer (cschmutz)]

Hi Yaakov,

Apology upfront for not coming back to you earlier. Back in November we 
considered organising a adhoc live discussion where people interested could 
join and discuss recent input. This didn’t happen and then we forgot to get 
back via email.

You are right the intention of this draft is to define a mechanism that allows 
for carrying traffic without touching it (aka being bit transparent). 
Essentially what OTN does by GMP/BMP mapping traffic into ODUs. But also very 
similar to what SAToP defined for low speed TDM interfaces but across a packet 
switched network (i.e. MPLS). We now want to bring this “SAToP like” concept to 
high(er) speed interfaces.

Why?

Optical transmission is quickly evolving from 100Gbps per wavelength to 
200Gbps, 400Gbps and Tbps very soon. However the rate of point 2 point service 
connections (aka circuits) is still predominantly <=10G (10GE, OC192, STM64, 
FC) or 100G (100GE) so there is a need for a “electrical switching layer” to 
make efficient use of the DWDM transmission capacity over an arbitrary network 
topology.

As has already been outlined in the past during the early work of PWE3 
(https://tools.ietf.org/html/rfc3916#section-1), using MPLS for this switching 
layer allows for optimising the infrastructure by consolidating onto a single 
network instead of maintaining multiple parallel/overlay networks

Having said that you are right that synchronisation is very important and 
requires careful consideration.

I hope this does provide a bit more context and we are happy to discuss further 
input/feedback to improve the draft further

Christian


On 04.11.2020, at 15:25, Yaakov Stein 
mailto:yaako...@rad.com>> wrote:

Sasha,

Thanks for forwarding this to me – I have been out of the plumbing business for 
a while ☺

However, I took a look at the beginning of this ID and am already confused.


The first line says  encapsulating high-speed bit-streams as VPWS over packet 
switched networks.

I am not sure what is meant by carrying a service over a PSN.

I believe that encapsulating bit streams as PWs was meant,

but as I said I have been away for a while and perhaps in the meantime someone 
has found a way of encapsulating service attributes

(I do hope that includes failure recovery, since it was always a pain the neck 
to have to build mechanisms rather than just doing an encapsulation).


Backtracking, the first line says
This document describes a method for encapsulating high-speed bit-streams
but in the 2nd paragraph the examples given are both Ethernet centric (well, 
the draft says Ethernet with a small “e”, but I assume that it means Ethernet).

L2 Ethernet is of course not a bit-stream, so I am forced to understand that we 
are talking about L1 Ethernet,
with the 66b and all the K-codes and such (like in GFP-T).
Really? Do we really need yet another non-byte such monstrosity because of 
SyncE?

What is meant by control protocol transparency concerns for carrier ethernet 
(sic) services,

beyond the behavior definitions of MEF specifications?

MEF defines L2CP behavior, but doesn’t touch the L1 stuff. What do you want to 
do with the K-codes and the FECs anyway?

(BTW, SyncE’s ESMC is a slow L2 protocol, and so only uses the L1 from the CBR 
PoV).


The next paragraph mentioned fiber channel. If there was one thing we learned 
about FC in the old PWE work
is that it can’t be transparently transported, and required a rather complex 
NSP function.

In any case, we already have a FC PW. That same paragraph talks about treating 
SDH as a bit stream. What I assume is meant is some kind of SAToP for SDH.
I believe that this was discussed to death in the past.
Perhaps the purpose of this draft is to make some universal mechanism that 
works unchanged for all traffic types (like RFC 6658).
What is the need here? Do you envision a pipe one moment being SDH and then 
unannounced changing to OTN of similar rate?

In any case, I see from Sasha’s questions that OTN is being handled.
I personally think that an OTN PW is a particularly bad idea, but at least I 
would understand what an OTN PW proposal was talking about.
In any case, for high rate bit streams that real challenge is the 
synchronization, and not the encapsulation.

Please forgive my not reading further, as I was simply too confused to continue.

Y(J)S

From: Alexander Vainshtein [mailto:alexander.vainsht...@rbbn.com]
Sent: 04/11/2020 14:26
To: cpign...@cisco.comp; 
naiku...@cisco.com; 
cschm...@cisco.com; 
jeremy.whitta...@verizon.com; 
steven.gring...@verizon.com
Cc: p...@ietf.org; bess@ietf.org; 
Yaakov Stein mailto:yaako...@rad.com>>
Subject: RE: Comments regarding draft-schmutzer-bess-ple-01

Resenting to  correct Yaakov’s address...

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302

Re: [bess] Comments regarding draft-schmutzer-bess-ple-01

[Christian Schmutzer (cschmutz)]

Hi Alexander,

Apology upfront for not coming back to you earlier. Back in November we 
considered organising a adhoc live discussion where people interested could 
join and discuss recent input. This didn’t happen and then we forgot to get 
back via email.

See responses from Luca and me inline via [cs/ldc]

Regards
Christian

On 08.11.2020, at 14:25, Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>> wrote:

Christian and Luca,
Lots of thanks for a prompt response.

Please see some responses to your comments inline below.

Please note also that both SONET and Synchronous Ethernet provide information 
about the quality of their clock that would be carried transparently with the 
PLE mechanism you have described. There is probably no way to guarantee that 
these indications would remain relevant after the corresponding bit-stream has 
been carried across a PSN, and I think that the corresponding caveat in the 
draft is necessary.

[cs/ldc] I think this the same concern you raised during your review of the -00 
version? 
https://mailarchive.ietf.org/arch/msg/pals/vEL1-Azc76YoHlgExO0CwHuyZ5o/.

Based on your input we actually added information related to clock recovery 
performance targets in section 
https://tools.ietf.org/html/draft-schmutzer-bess-ple-01#section-6.2.2 of our 
draft that an implementation has to comply with. This is similar to how other 
technologies such as OTN are covering the aspect of client clock recovery 
across a server layer transport network.


Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@rbbn.com

From: Christian Schmutzer (cschmutz) 
mailto:cschm...@cisco.com>>
Sent: Thursday, November 5, 2020 1:31 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Cc: Christian Schmutzer (cschmutz) 
mailto:cschm...@cisco.com>>; 
cpign...@cisco.comp; Nagendra Kumar Nainar 
(naikumar) mailto:naiku...@cisco.com>>; 
jeremy.whitta...@verizon.com; 
steven.gring...@verizon.com; 
p...@ietf.org; bess@ietf.org; 
yaako...@rad.com; Luca Della Chiesa (ldellach) 
mailto:ldell...@cisco.com>>
Subject: Re: Comments regarding draft-schmutzer-bess-ple-01


NOTICE: This email was received from an EXTERNAL sender


Hi Alexander,

Thank you very much again for going through the draft. Please find our 
responses inline via [cs]

regards
Christian & Luca


On 04.11.2020, at 13:25, Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>> wrote:

Resenting to  correct Yaakov’s address...

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@rbbn.com

From: Alexander Vainshtein
Sent: Wednesday, November 4, 2020 2:24 PM
To: cpign...@cisco.comp; 
naiku...@cisco.com; 
cschm...@cisco.com; 
jeremy.whitta...@verizon.com; 
steven.gring...@verizon.com
Cc: p...@ietf.org; bess@ietf.org; 
yaako...@rad.co
Subject: Comments regarding draft-schmutzer-bess-ple-01

Hi,
I have a few questions regarding 
draft-schmutzer-bess-ple-01.

1.   Section 4.2.1 of the draft says that the FRG bits in the CW “MUST be 
set to zero by the sender and ignored by the receiver except for frame aligned 
payloads; see Section 5.2.”  However, this is the only mention of frame-aligned 
payload in the -01 version of the draft, and section 5.2 in this version is 
called “Byte aligned Payload”.  My guess is that frame-aligned payload for ODUk 
streams have been dropped completely, and that the FRG bits must always be set 
to zero by the sender and ignored by the receiver – can you please confirm?

[cs] good catch, we forgot to change this part when working on the -01 draft 
where we moved from ODUk frame to byte alignment. We will reword this in the 
-02 draft to "These bits MUST be set to zero by the sender and ignored by the 
receiver." [[Sasha]] OK


2.   Section 5.2 of the draft seems to imply that byte-aligned payload is 
only applicable to the PLE services emulating ODUk streams. Can you please 
confirm that this mode is not applicable to, say, OC-192 (SONET framing creates 
native bye alignment)?

[cs] Yes the byte aligned mode is only applicable for ODUk streams and SONET 
streams will be carried via the CBR mode.[[Sasha]] Got it, thanks


3.   Section 6.2.2 states that “the payload of a lost packet MUST be 
replaced with equivalent amount of replacement data”.  Can you please clarify 
how wraparound of the 16-bit sequence number (be it in the 

Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

[Ali Sajassi (sajassi)]

Hi Jorge,

Yes, EVPN has evolved over many years and that’s why it has such a big traction 
in industry (thanks to your contributions and many others) and we have always 
been open to improvements (mostly driven by our customers) and evaluated them 
objectively. So, if there is any suggestion wrt to Anycast ID, we can 
definitely evaluate it based on what use cases it covers, All-active mode (both 
equal and unequal LB), failure scenarios, convergence, impact to underlay and 
overlay protocols, as well as applicability to different encapsulations to name 
a few.

Cheers,
Ali

From: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Date: Friday, November 20, 2020 at 12:26 PM
To: Cisco Employee , "Jeffrey (Zhaohui) Zhang" 
, Sami Boutros 
Cc: "bess@ietf.org" 
Subject: Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

Hi Ali,

Yes, I understand it has pros and cons. What I meant is that, if using anycast 
SID in EVPN satisfies Sami’s requirements (or most), there is no need to add a 
completely new technology that needs to reinvent how to do all services (elan, 
eline, etree, L3, mcast, etc) and relies on data-plane mac-learning - we can 
apply anycast SIDs to existing EVPN.

Thanks.
Jorge

From: Ali Sajassi (sajassi) 
Date: Friday, November 20, 2020 at 7:21 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) , 
Jeffrey (Zhaohui) Zhang , Sami Boutros 

Cc: bess@ietf.org 
Subject: Re: [bess] comments on draft-boutros-bess-elan-services-over-sr
Hi Jorge,


Agreed, any technology can use any cast SID.
[jorge] if you want to specify an anycast SID solution for EVPN as an 
alternative to aliasing, since it may have its merits, I’ll be glad to 
investigate it with you and help. However data plane-learning sounds a step 
back to me.


I looked at this long time ago and it had some issues. For example, if you pass 
the anycast ID in underlay, then the load balancing is dictated by your 
underlay topology instead of the actual link BW of MCLAG. If you try to get 
fancier and distribute link bw info in the underlay (IGP), then you are 
burdening the underly protocol with overlay info.  And finally if you 
distribute it in the overlay (e.g., BGP), it becomes very similar to what we do 
currently.

BTW, Aliasing feature in EVPN is not mandatory but rather optional as you know.

Cheers,
Ali



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

Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Ali,

Yes, I understand it has pros and cons. What I meant is that, if using anycast 
SID in EVPN satisfies Sami’s requirements (or most), there is no need to add a 
completely new technology that needs to reinvent how to do all services (elan, 
eline, etree, L3, mcast, etc) and relies on data-plane mac-learning - we can 
apply anycast SIDs to existing EVPN.

Thanks.
Jorge

From: Ali Sajassi (sajassi) 
Date: Friday, November 20, 2020 at 7:21 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) , 
Jeffrey (Zhaohui) Zhang , Sami Boutros 

Cc: bess@ietf.org 
Subject: Re: [bess] comments on draft-boutros-bess-elan-services-over-sr
Hi Jorge,


Agreed, any technology can use any cast SID.
[jorge] if you want to specify an anycast SID solution for EVPN as an 
alternative to aliasing, since it may have its merits, I’ll be glad to 
investigate it with you and help. However data plane-learning sounds a step 
back to me.


I looked at this long time ago and it had some issues. For example, if you pass 
the anycast ID in underlay, then the load balancing is dictated by your 
underlay topology instead of the actual link BW of MCLAG. If you try to get 
fancier and distribute link bw info in the underlay (IGP), then you are 
burdening the underly protocol with overlay info.  And finally if you 
distribute it in the overlay (e.g., BGP), it becomes very similar to what we do 
currently.

BTW, Aliasing feature in EVPN is not mandatory but rather optional as you know.

Cheers,
Ali



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

Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

[Ali Sajassi (sajassi)]

Hi Jorge,


Agreed, any technology can use any cast SID.
[jorge] if you want to specify an anycast SID solution for EVPN as an 
alternative to aliasing, since it may have its merits, I’ll be glad to 
investigate it with you and help. However data plane-learning sounds a step 
back to me.


I looked at this long time ago and it had some issues. For example, if you pass 
the anycast ID in underlay, then the load balancing is dictated by your 
underlay topology instead of the actual link BW of MCLAG. If you try to get 
fancier and distribute link bw info in the underlay (IGP), then you are 
burdening the underly protocol with overlay info.  And finally if you 
distribute it in the overlay (e.g., BGP), it becomes very similar to what we do 
currently.

BTW, Aliasing feature in EVPN is not mandatory but rather optional as you know.

Cheers,
Ali



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

Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Sami and Jeffrey,

Please see some comments/replies in-line.

Thank you!
Jorge

From: Jeffrey (Zhaohui) Zhang 
Date: Thursday, November 19, 2020 at 7:20 PM
To: Sami Boutros , Rabadan, Jorge (Nokia - US/Mountain 
View) 
Cc: bess@ietf.org 
Subject: RE: [bess] comments on draft-boutros-bess-elan-services-over-sr
To clarify, when I said “evpn-like solution” I was referring to the fact that 
it uses service-SID/label instead of per-PW labels, and it supports split 
horizon for multi-homing.

As for control  plane learning vs. data plane learning, I don’t know about the 
history, but my impression is that control plane learning is considered as a 
feature but not as a fallback solution for not having the PW contexts for do 
data plane learning. I could be wrong though.
[jorge] I agree with you Jeffrey, to me is an improvement too. More below.


Jeffrey

From: Sami Boutros 
Sent: Thursday, November 19, 2020 12:11 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
Cc: Jeffrey (Zhaohui) Zhang ; bess@ietf.org
Subject: Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

[External Email. Be cautious of content]

Hi Jorge,




On Nov 19, 2020, at 5:09 AM, Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>> wrote:

Hi everyone,

Jeffrey, not sure how much of EVPN this solution is, since there are no 
‘overlay’ routes advertised. In fact the draft says that no routes type 1..4 
are needed at all.
But I see your point Jeffrey, and I agree the concept of the source 
identification is not SR specific.

Agreed, source identification is not SR specific.




@Sami,

I couldn’t speak during the meeting so I’ll throw a couple of general 
comments/questions:


1.   While I see the anycast-SID as an interesting point, I disagree with 
the document’s motivation that EVPN needed to introduce control-plane learning 
due to the MP2P tunnels.

What I said is with MP2P tunnels EVPN was forced to only control plane Mac 
learning. Are you saying this is incorrect? If so, Why?
[jorge] No, I didn’t make myself clear enough – control plane is needed with 
MP2P tunnels, yes, but what I meant is that in your motivation it *sounds* like 
control-plane learning was a necessary evil due to the need for MP2P tunnels to 
fix the scale issue. I see control-plane learning as an additional 
improvement/feature, as Jeffrey was saying.




1.   Control plane learning has a lot of advantages and data-plane 
learning/aging has tons of issues. So this should be debated in the WG.

Sure, will be good to get Service providers input on that too. One thing to 
note here, our proposal is by no mean don’t use EVPN, it is simply another 
option that greatly simplify the control plane and remove tons of control plane 
overhead, as well simplify the data plane and remove need for any overlay 
convergence.





2.   Irrespective, the anycast-SID idea could work in regular EVPN as an 
optional alternative to aliasing. You don’t need to do data-plane learning for 
that, right?

Agreed, any technology can use any cast SID.
[jorge] if you want to specify an anycast SID solution for EVPN as an 
alternative to aliasing, since it may have its merits, I’ll be glad to 
investigate it with you and help. However data plane-learning sounds a step 
back to me.






3.   The document seems to claim fast mac move. How can that be guaranteed 
if the mac learning is data plane based?

In data plane when a MAC move from one port to another, or one PW to another, 
routers simply adjust no need for any EVPN procedure for MAC move.
[jorge] you are assuming that when that MAC moves to another port, it sends BUM 
traffic that is flooded and all the nodes can update. That is not always the 
case. The host that moves can simply generate known unicast traffic, and hence 
most nodes in the network will have stale information for the aging time. EVPN 
takes care of the mobility immediately as soon as the MAC that moves generates 
*any* type of frame.





4.   ARP suppression is not a merit of this solution. It could work even in 
RFC4761/74762 VPLS networks.


Agreed, we don’t claim any of that, the proposal doesn’t claim that it invented 
ARP suppression, or invented SR, it simply say it will use it this way, I hope 
this is OK.
[jorge] yes, that’s ok, just wanted to clarify Sami.





I have a few more, but those are enough to start.

Thanks,

Sami


Thank you!
Jorge


From: BESS mailto:bess-boun...@ietf.org>>
Date: Thursday, November 19, 2020 at 12:46 PM
To: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Subject: [bess] comments on draft-boutros-bess-elan-services-over-sr
Hi,

It seems that the draft is about using data-plane mac learning in an EVPN-like 
solution. That retains other properties of EVPN, but removes the need for 
advertising MAC addresses, with the consequences/problems that Ali was trying 
to point out.

Leaving the pros and cons of data plane mac learning out, I want to 

Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

[Jeffrey (Zhaohui) Zhang]

To clarify, when I said “evpn-like solution” I was referring to the fact that 
it uses service-SID/label instead of per-PW labels, and it supports split 
horizon for multi-homing.

As for control  plane learning vs. data plane learning, I don’t know about the 
history, but my impression is that control plane learning is considered as a 
feature but not as a fallback solution for not having the PW contexts for do 
data plane learning. I could be wrong though.

Jeffrey

From: Sami Boutros 
Sent: Thursday, November 19, 2020 12:11 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
Cc: Jeffrey (Zhaohui) Zhang ; bess@ietf.org
Subject: Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

[External Email. Be cautious of content]

Hi Jorge,



On Nov 19, 2020, at 5:09 AM, Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>> wrote:

Hi everyone,

Jeffrey, not sure how much of EVPN this solution is, since there are no 
‘overlay’ routes advertised. In fact the draft says that no routes type 1..4 
are needed at all.
But I see your point Jeffrey, and I agree the concept of the source 
identification is not SR specific.

Agreed, source identification is not SR specific.



@Sami,

I couldn’t speak during the meeting so I’ll throw a couple of general 
comments/questions:


  1.  While I see the anycast-SID as an interesting point, I disagree with the 
document’s motivation that EVPN needed to introduce control-plane learning due 
to the MP2P tunnels.

What I said is with MP2P tunnels EVPN was forced to only control plane Mac 
learning. Are you saying this is incorrect? If so, Why?



  1.  Control plane learning has a lot of advantages and data-plane 
learning/aging has tons of issues. So this should be debated in the WG.

Sure, will be good to get Service providers input on that too. One thing to 
note here, our proposal is by no mean don’t use EVPN, it is simply another 
option that greatly simplify the control plane and remove tons of control plane 
overhead, as well simplify the data plane and remove need for any overlay 
convergence.




  1.  Irrespective, the anycast-SID idea could work in regular EVPN as an 
optional alternative to aliasing. You don’t need to do data-plane learning for 
that, right?

Agreed, any technology can use any cast SID.



  1.

  1.  The document seems to claim fast mac move. How can that be guaranteed if 
the mac learning is data plane based?

In data plane when a MAC move from one port to another, or one PW to another, 
routers simply adjust no need for any EVPN procedure for MAC move.




  1.  ARP suppression is not a merit of this solution. It could work even in 
RFC4761/74762 VPLS networks.


Agreed, we don’t claim any of that, the proposal doesn’t claim that it invented 
ARP suppression, or invented SR, it simply say it will use it this way, I hope 
this is OK.




I have a few more, but those are enough to start.

Thanks,

Sami

Thank you!
Jorge


From: BESS mailto:bess-boun...@ietf.org>>
Date: Thursday, November 19, 2020 at 12:46 PM
To: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Subject: [bess] comments on draft-boutros-bess-elan-services-over-sr
Hi,

It seems that the draft is about using data-plane mac learning in an EVPN-like 
solution. That retains other properties of EVPN, but removes the need for 
advertising MAC addresses, with the consequences/problems that Ali was trying 
to point out.

Leaving the pros and cons of data plane mac learning out, I want to point out 
that the idea is actually orthogonal with SR - even if SR were not invented 
this concept still applies. With VXLAN the source address corresponds to the 
"source node SID", and with MPLS the "PE Distinguisher Label" in MVPN (and 
extended to other use cases) serves the same purpose. That same "PE 
Distinguisher Label" concept is also used in my Generic Fragmentation proposal.

With that, the discussion for this draft should be in BESS, not in SPRING.

Jeffrey

Juniper Business Use Only

___
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!VxGsf2muy1oOc43yyMHygNmGkHp0T1soQk5peu2Fy52TPBZCmPstnw7sc4NEkzej$>
___
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!VxGsf2muy1oOc43yyMHygNmGkHp0T1soQk5peu2Fy52TPBZCmPstnw7sc4NEkzej$>



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

Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

[Sami Boutros]

Hi Jorge,


> On Nov 19, 2020, at 5:09 AM, Rabadan, Jorge (Nokia - US/Mountain View) 
>  wrote:
> 
> Hi everyone,
>  
> Jeffrey, not sure how much of EVPN this solution is, since there are no 
> ‘overlay’ routes advertised. In fact the draft says that no routes type 1..4 
> are needed at all.
> But I see your point Jeffrey, and I agree the concept of the source 
> identification is not SR specific.

Agreed, source identification is not SR specific.

>  
> @Sami, 
>  
> I couldn’t speak during the meeting so I’ll throw a couple of general 
> comments/questions:
>  
> While I see the anycast-SID as an interesting point, I disagree with the 
> document’s motivation that EVPN needed to introduce control-plane learning 
> due to the MP2P tunnels.

What I said is with MP2P tunnels EVPN was forced to only control plane Mac 
learning. Are you saying this is incorrect? If so, Why?

> Control plane learning has a lot of advantages and data-plane learning/aging 
> has tons of issues. So this should be debated in the WG.

Sure, will be good to get Service providers input on that too. One thing to 
note here, our proposal is by no mean don’t use EVPN, it is simply another 
option that greatly simplify the control plane and remove tons of control plane 
overhead, as well simplify the data plane and remove need for any overlay 
convergence.

>  
> Irrespective, the anycast-SID idea could work in regular EVPN as an optional 
> alternative to aliasing. You don’t need to do data-plane learning for that, 
> right?

Agreed, any technology can use any cast SID.

> The document seems to claim fast mac move. How can that be guaranteed if the 
> mac learning is data plane based?

In data plane when a MAC move from one port to another, or one PW to another, 
routers simply adjust no need for any EVPN procedure for MAC move.

>  
> ARP suppression is not a merit of this solution. It could work even in 
> RFC4761/74762 VPLS networks.
>  

Agreed, we don’t claim any of that, the proposal doesn’t claim that it invented 
ARP suppression, or invented SR, it simply say it will use it this way, I hope 
this is OK.

>  

> I have a few more, but those are enough to start.

Thanks,

Sami
> Thank you!
> Jorge
>  
>  
> From: BESS 
> Date: Thursday, November 19, 2020 at 12:46 PM
> To: bess@ietf.org 
> Subject: [bess] comments on draft-boutros-bess-elan-services-over-sr
> 
> Hi,
> 
> It seems that the draft is about using data-plane mac learning in an 
> EVPN-like solution. That retains other properties of EVPN, but removes the 
> need for advertising MAC addresses, with the consequences/problems that Ali 
> was trying to point out.
> 
> Leaving the pros and cons of data plane mac learning out, I want to point out 
> that the idea is actually orthogonal with SR - even if SR were not invented 
> this concept still applies. With VXLAN the source address corresponds to the 
> "source node SID", and with MPLS the "PE Distinguisher Label" in MVPN (and 
> extended to other use cases) serves the same purpose. That same "PE 
> Distinguisher Label" concept is also used in my Generic Fragmentation 
> proposal.
> 
> With that, the discussion for this draft should be in BESS, not in SPRING.
> 
> Jeffrey
> 
> Juniper Business Use Only
> 
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess 
> <https://www.ietf.org/mailman/listinfo/bess>___
> BESS mailing list
> BESS@ietf.org <mailto:BESS@ietf.org>
> https://www.ietf.org/mailman/listinfo/bess 
> <https://www.ietf.org/mailman/listinfo/bess>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

[Sami Boutros]

Hi Jeff,


> On Nov 19, 2020, at 3:46 AM, Jeffrey (Zhaohui) Zhang 
>  wrote:
> 
> Hi,
> 
> It seems that the draft is about using data-plane mac learning in an 
> EVPN-like solution.


Actually the draft explicitly mention that we don’t need any EVPN routes, and 
not sure what EVPN-like solution you are referring too.

> That retains other properties of EVPN, but removes the need for advertising 
> MAC addresses, with the consequences/problems that Ali was trying to point 
> out.
> 

It will be good that you point out those specific consequences/problems.

> Leaving the pros and cons of data plane mac learning out, I want to point out 
> that the idea is actually orthogonal with SR - even if SR were not invented 
> this concept still applies.

Agreed, but SR enabled the concept, via the ability to define SRGB for services 
across the network.

> With VXLAN the source address corresponds to the "source node SID", and with 
> MPLS the "PE Distinguisher Label" in MVPN (and extended to other use cases) 
> serves the same purpose. That same "PE Distinguisher Label" concept is also 
> used in my Generic Fragmentation proposal.
> 
> With that, the discussion for this draft should be in BESS, not in SPRING.
> 

As I mentioned this is still about BGP enabled services, however we can still 
present this in SPRING.

Thanks,

Sami

> Jeffrey
> 
> Juniper Business Use Only
> 
> ___
> 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] comments on draft-boutros-bess-elan-services-over-sr

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi everyone,

Jeffrey, not sure how much of EVPN this solution is, since there are no 
‘overlay’ routes advertised. In fact the draft says that no routes type 1..4 
are needed at all.
But I see your point Jeffrey, and I agree the concept of the source 
identification is not SR specific.

@Sami,

I couldn’t speak during the meeting so I’ll throw a couple of general 
comments/questions:


  1.  While I see the anycast-SID as an interesting point, I disagree with the 
document’s motivation that EVPN needed to introduce control-plane learning due 
to the MP2P tunnels. Control plane learning has a lot of advantages and 
data-plane learning/aging has tons of issues. So this should be debated in the 
WG.



  1.  Irrespective, the anycast-SID idea could work in regular EVPN as an 
optional alternative to aliasing. You don’t need to do data-plane learning for 
that, right?



  1.  The document seems to claim fast mac move. How can that be guaranteed if 
the mac learning is data plane based?



  1.  ARP suppression is not a merit of this solution. It could work even in 
RFC4761/74762 VPLS networks.



I have a few more, but those are enough to start.
Thank you!
Jorge


From: BESS 
Date: Thursday, November 19, 2020 at 12:46 PM
To: bess@ietf.org 
Subject: [bess] comments on draft-boutros-bess-elan-services-over-sr
Hi,

It seems that the draft is about using data-plane mac learning in an EVPN-like 
solution. That retains other properties of EVPN, but removes the need for 
advertising MAC addresses, with the consequences/problems that Ali was trying 
to point out.

Leaving the pros and cons of data plane mac learning out, I want to point out 
that the idea is actually orthogonal with SR - even if SR were not invented 
this concept still applies. With VXLAN the source address corresponds to the 
"source node SID", and with MPLS the "PE Distinguisher Label" in MVPN (and 
extended to other use cases) serves the same purpose. That same "PE 
Distinguisher Label" concept is also used in my Generic Fragmentation proposal.

With that, the discussion for this draft should be in BESS, not in SPRING.

Jeffrey

Juniper Business Use Only

___
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] comments on draft-boutros-bess-elan-services-over-sr

[Jeffrey (Zhaohui) Zhang]

Hi,

It seems that the draft is about using data-plane mac learning in an EVPN-like 
solution. That retains other properties of EVPN, but removes the need for 
advertising MAC addresses, with the consequences/problems that Ali was trying 
to point out.

Leaving the pros and cons of data plane mac learning out, I want to point out 
that the idea is actually orthogonal with SR - even if SR were not invented 
this concept still applies. With VXLAN the source address corresponds to the 
"source node SID", and with MPLS the "PE Distinguisher Label" in MVPN (and 
extended to other use cases) serves the same purpose. That same "PE 
Distinguisher Label" concept is also used in my Generic Fragmentation proposal.

With that, the discussion for this draft should be in BESS, not in SPRING.

Jeffrey

Juniper Business Use Only

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

[bess] Comments on draft-schmutzer-bess-ple-00

[Brown, Christopher]

Hello,


We have the following questions and feedback regarding 
https://tools.ietf.org/html/draft-schmutzer-bess-ple-00



Q1: Section 4.2.2 RTP Header



>From the draft,



 "Timestamp values are used in accordance with the rules

  established in [RFC3550].  Frequency of the clock used

  for generatingtimestamps MUST be 25 MHz based on a

  local reference."



Does 25MHz provide enough resolution to meet the jitter requirements of higher 
bit rate signals?  A 25MHz clock provides 40ns of resolution in the timestamp 
while a 125MHz clock would provide 8ns of resolution.  It is easier to filter 
out steps of 8ns than 40ns when recovering the client clock.



Q2: Section 5. PLE Payload Layer



The suggested default payload sizes for a constant bit rate payload (S5.1) is 
480 bytes and an ODUk frame aligned payload (S5.2) is 478 bytes.  Should we 
consider a bigger packet size in each case to lower the effective packet rate 
and added overhead?  Doubling the default payload size would result in the 
maximum number of 10G clients per 100G link.


Thank you,
Chris
cbr...@ciena.com

Chris Brown | System Design & Development
cbr...@ciena.com | Building B, 385 Terry Fox Drive | 
Ottawa, ON K2K 2P5 CA
Direct +1.613.670.2554


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

Re: [bess] Comments on draft-schmutzer-bess-ple-00

[Christian Schmutzer (cschmutz)]

Hi Chris,

Thank you very much for you comments. Please see inline via [cs]

Regards
christian

On 30.10.2020, at 16:24, Brown, Christopher 
mailto:cbr...@ciena.com>> wrote:

Hello,


We have the following questions and feedback regarding 
https://tools.ietf.org/html/draft-schmutzer-bess-ple-00



Q1: Section 4.2.2 RTP Header



From the draft,



 “Timestamp values are used in accordance with the rules

  established in [RFC3550].  Frequency of the clock used

  for generatingtimestamps MUST be 25 MHz based on a

  local reference.”



Does 25MHz provide enough resolution to meet the jitter requirements of higher 
bit rate signals?  A 25MHz clock provides 40ns of resolution in the timestamp 
while a 125MHz clock would provide 8ns of resolution.  It is easier to filter 
out steps of 8ns than 40ns when recovering the client clock.

[cs] This is a good suggestion, we will adopt this change in the upcoming -01 
revision of the draft




Q2: Section 5. PLE Payload Layer



The suggested default payload sizes for a constant bit rate payload (S5.1) is 
480 bytes and an ODUk frame aligned payload (S5.2) is 478 bytes.  Should we 
consider a bigger packet size in each case to lower the effective packet rate 
and added overhead?  Doubling the default payload size would result in the 
maximum number of 10G clients per 100G link.

[cs] this also makes sense and we can adopt 1024 as the new default size.

Side note : in upcoming -01 draft we will change from frame to byte alignment 
for the payload type used to carry OTN bit streams so we can have a single 
common default size for both payload types



Thank you,
Chris
cbr...@ciena.com

Chris Brown | System Design & Development
cbr...@ciena.com | Building B, 385 Terry Fox Drive | 
Ottawa, ON K2K 2P5 CA
Direct +1.613.670.2554



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

Re: [bess] Comments on draft-ietf-bess-evpn-pref-df

[Satya Mohanty (satyamoh)]

Hi Stephane,

An alternative way to guarantee precedence per vlan (i.e. the most granular) 
rather than the vlan-range in the vlan-based service models, could be by using 
the DF extcom in the per EVI AD route instead of the procedures in Section 4.2 
relevant to the vlan range.

But this may not be required in a real deployment and specification of 
precedence per a vlan-range is probably sufficient.

So, I agree with Jorge regarding his observation of vES.

Best,
--Satya

From: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Date: Sunday, September 29, 2019 at 4:10 AM
To: "slitkows.i...@gmail.com" , 
"draft-ietf-bess-evpn-pref...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: Comments on draft-ietf-bess-evpn-pref-df
Resent-From: 
Resent-To: , , 
, , "jdr...@juniper.net" 
, , 
Resent-Date: Sunday, September 29, 2019 at 4:09 AM

Hi Stephane,

Please see in-line.

If you think we should add some text making my comments below more explicit, 
I’d be happy to do it.
Thank you.
Jorge

From: "slitkows.i...@gmail.com" 
Date: Saturday, September 28, 2019 at 4:57 AM
To: "draft-ietf-bess-evpn-pref...@ietf.org" 
, "bess@ietf.org" 
Subject: Comments on draft-ietf-bess-evpn-pref-df
Resent-From: 
Resent-To: , , 
, , , 
, 
Resent-Date: Saturday, September 28, 2019 at 4:57 AM

Hi Authors,

I had a look on your draft and I have some concerns/questions that I would like 
to discuss.
I like the fact of being able to tune the pref DF election per VLAN range, 
however:

-  Don’t you think that using a local configuration may open to 
inconsistent configurations resulting in issues ?
[JORGE] We discussed quite a few times whether we should signal the vlan ranges 
for which you desire high_pref or low_pref. We ended up coming to the 
conclusion that it is better/simpler (and already supported) to define virtual 
ethernet segments for ranges of vlans and then have the default high_pref that 
is defined in the spec. That is less prone to errors. E.g. on a given port, 
define two ranges: vlan (1-2k) --> vES-1 and [(2k+1)-4k] -->vES-2. On a given 
PE, vES-1 and vES-2 have different pref values.


-  How does the high_or_low works if I have more than 2 links in the ES 
? (multihoming with 4 links with 4 levels of preference ?)
[JORGE] if you want 4 levels of preference so that each of the 4 PEs is DF for 
a range of vlans, the easiest way as discussed above is to define 4 vESes. The 
high_or_low is an easy way of having load balancing if you have only 2 PEs in 
the ES and you really want to define only one ES.

Thanks,

Stephane

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

Re: [bess] Comments on draft-ietf-bess-evpn-pref-df

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Stephane,

Please see in-line.

If you think we should add some text making my comments below more explicit, 
I’d be happy to do it.
Thank you.
Jorge

From: "slitkows.i...@gmail.com" 
Date: Saturday, September 28, 2019 at 4:57 AM
To: "draft-ietf-bess-evpn-pref...@ietf.org" 
, "bess@ietf.org" 
Subject: Comments on draft-ietf-bess-evpn-pref-df
Resent-From: 
Resent-To: , , 
, , , 
, 
Resent-Date: Saturday, September 28, 2019 at 4:57 AM

Hi Authors,

I had a look on your draft and I have some concerns/questions that I would like 
to discuss.
I like the fact of being able to tune the pref DF election per VLAN range, 
however:

-  Don’t you think that using a local configuration may open to 
inconsistent configurations resulting in issues ?
[JORGE] We discussed quite a few times whether we should signal the vlan ranges 
for which you desire high_pref or low_pref. We ended up coming to the 
conclusion that it is better/simpler (and already supported) to define virtual 
ethernet segments for ranges of vlans and then have the default high_pref that 
is defined in the spec. That is less prone to errors. E.g. on a given port, 
define two ranges: vlan (1-2k) --> vES-1 and [(2k+1)-4k] -->vES-2. On a given 
PE, vES-1 and vES-2 have different pref values.


-  How does the high_or_low works if I have more than 2 links in the ES 
? (multihoming with 4 links with 4 levels of preference ?)
[JORGE] if you want 4 levels of preference so that each of the 4 PEs is DF for 
a range of vlans, the easiest way as discussed above is to define 4 vESes. The 
high_or_low is an easy way of having load balancing if you have only 2 PEs in 
the ES and you really want to define only one ES.

Thanks,

Stephane

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

[bess] Comments on the ND refresh message in draft-ietf-bess-evpn-proxy-arp-nd-08

[wang.yubao2]

Hi Jorge,


The ND refresh message is assumed to be a NS message with its Sender's IP = 
Link Local Address in section 4.4 of draft-ietf-bess-evpn-proxy-arp-nd-08.







  An ARP refresh issued by the PE will be an ARP-Request message   


  with the Sender's IP = 0 sent from the PE's MAC SA. If the PE has

  an IP address in the subnet, for instance on an IRB interface,

  then it MAY use it as a source for the ARP request (instead of   

  Sender's IP = 0). An ND refresh will be a NS message issued from

  the PE's MAC SA and a Link Local Address associated to the PE's

  MAC.










But I think there may be no Link Local Address when the bridge domain is not 
assigned with an IRB interface.


Will the Link Local Address of ND refresh message be used in the reply message?


Otherwise it is just an IPv6 address with the Link Local Address format, but it 
won't function as a real Link Local Address? 


Why not we use the 0:0:0:0:0:0 ?  






Best Regards,


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

Re: [bess] comments on draft-ietf-bess-evpn-bum-procedure-updates-06

[Jeffrey (Zhaohui) Zhang]

Hi Sandy,

Thanks for your review and comments. I have submitted -07 revision.

Please see zzh> below.

From: zhang.zh...@zte.com.cn 
Sent: Wednesday, July 17, 2019 9:43 PM
To: Jeffrey (Zhaohui) Zhang ; Wen Lin ; 
jorge.raba...@nokia.com; ke...@arrcus.com; saja...@cisco.com; 
ext-zzhang_i...@hotmail.com 
Cc: bess@ietf.org; stephane.litkow...@orange.com; matthew.bo...@nokia.com
Subject: [bess] comments on draft-ietf-bess-evpn-bum-procedure-updates-06


Hi authors,



I read this version and have some comments.



Thanks,

Sandy

==

  1.  In section 6.1, since the example is about AS, if it is better to change 
the title of this section to "AS/Area va. Region" ?

Zzh> Changed.

  1.  In section 6.2, the last sentence of the fourth paragrah, if it should be 
"there is no per-region S-PMSI aggregation routes"?

Zzh> "Per-region" itself already means aggregation.

  1.  In section 6.2, if it is better to add some detail description for area 
ID EC construction?

Zzh> Added.

  1.  In section 6.3, if it is better to add some detail description for Route 
Target construction?

Zzh> Added.

5. The following is the idnits result:

Zzh> Addressed.

Zzh> Thanks!

Zzh> Jeffrey

idnits 2.16.02

/tmp/draft-ietf-bess-evpn-bum-procedure-updates-06.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see

  https://trustee.ietf.org/license-info):

  

 No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:

  

 No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :

  

  ** There are 16 instances of too long lines in the document, the longest

 one being 3 characters in excess of 72.

  -- The draft header indicates that this document updates RFC7432, but the

 abstract doesn't seem to mention this, which it should.



  Miscellaneous warnings:

  

  -- The document date (June 17, 2019) is 22 days in the past.  Is this

 intentional?



  Checking references for intended status: Proposed Standard

  



 (See RFCs 3967 and 4897 for information about using normative references

 to lower-maturity documents in RFCs)



  == Missing Reference: 'RFC 7524' is mentioned on line 196, but not defined

  == Unused Reference: 'RFC2119' is defined on line 763, but no explicit

 reference was found in the text

  == Unused Reference: 'RFC7432' is defined on line 773, but no explicit

 reference was found in the text

  == Unused Reference: 'RFC7524' is defined on line 778, but no explicit

 reference was found in the text

  == Unused Reference: 'RFC7988' is defined on line 784, but no explicit

 reference was found in the text

  == Unused Reference: 'I-D.ietf-bier-architecture' is defined on line 791,

 but no explicit reference was found in the text

  == Unused Reference: 'I-D.ietf-bier-evpn' is defined on line 797, but no

 explicit reference was found in the text

  == Unused Reference: 'RFC6513' is defined on line 802, but no explicit

 reference was found in the text

  == Unused Reference: 'RFC6514' is defined on line 806, but no explicit

 reference was found in the text

  == Outdated reference: draft-ietf-bess-evpn-df-election-framework has been

 published as RFC 8584

  == Outdated reference: draft-ietf-bess-mvpn-expl-track has been published

 as RFC 8534

  == Outdated reference: draft-ietf-bier-architecture has been published as

 RFC 8279



 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 2 comments (--).



 Run idnits with the --verbose option for more detailed information about

 the items above.




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

[bess] comments on draft-ietf-bess-evpn-bum-procedure-updates-06

[zhang.zheng]

Hi authors,







I read this version and have some comments.






Thanks,


Sandy


==

1. In section 6.1, since the example is about AS, if it is better to change the 
title of this section to "AS/Area va. Region" ?

2. In section 6.2, the last sentence of the fourth paragrah, if it should be 
"there is no per-region S-PMSI aggregation routes"?


3. In section 6.2, if it is better to add some detail description for area ID 
EC construction?


4. In section 6.3, if it is better to add some detail description for Route 
Target construction?


5. The following is the idnits result:





idnits 2.16.02 

/tmp/draft-ietf-bess-evpn-bum-procedure-updates-06.txt:


  Checking boilerplate required by RFC 5378 and the IETF Trust (see


  https://trustee.ietf.org/license-info):

  

 No issues found here.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:


  

 No issues found here.


  Checking nits according to https://www.ietf.org/id-info/checklist :


  

  ** There are 16 instances of too long lines in the document, the longest


 one being 3 characters in excess of 72.

  -- The draft header indicates that this document updates RFC7432, but the


 abstract doesn't seem to mention this, which it should.




  Miscellaneous warnings:

  

  -- The document date (June 17, 2019) is 22 days in the past.  Is this


 intentional?




  Checking references for intended status: Proposed Standard


  




 (See RFCs 3967 and 4897 for information about using normative references

 to lower-maturity documents in RFCs)




  == Missing Reference: 'RFC 7524' is mentioned on line 196, but not defined

  == Unused Reference: 'RFC2119' is defined on line 763, but no explicit


 reference was found in the text

  == Unused Reference: 'RFC7432' is defined on line 773, but no explicit


 reference was found in the text

  == Unused Reference: 'RFC7524' is defined on line 778, but no explicit


 reference was found in the text

  == Unused Reference: 'RFC7988' is defined on line 784, but no explicit


 reference was found in the text

  == Unused Reference: 'I-D.ietf-bier-architecture' is defined on line 791,


 but no explicit reference was found in the text

  == Unused Reference: 'I-D.ietf-bier-evpn' is defined on line 797, but no


 explicit reference was found in the text

  == Unused Reference: 'RFC6513' is defined on line 802, but no explicit


 reference was found in the text

  == Unused Reference: 'RFC6514' is defined on line 806, but no explicit


 reference was found in the text

  == Outdated reference: draft-ietf-bess-evpn-df-election-framework has been


 published as RFC 8584

  == Outdated reference: draft-ietf-bess-mvpn-expl-track has been published


 as RFC 8534

  == Outdated reference: draft-ietf-bier-architecture has been published as


 RFC 8279




 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 2 comments (--).




 Run idnits with the --verbose option for more detailed information about

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

Re: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop-04

[Kesavan Thiruvenkatasamy (kethiruv)]

Hi Jingrong

Thanks for your comments. Please find responses below.

Regards,
Kesavan



[bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop-04

Xiejingrong  Mon, 08 July 2019 11:47 UTCShow 
header<https://mailarchive.ietf.org/arch/msg/bess/SWY3fzK1unFbY5MYnD7dkaBSZ9I>

Hi



Thanks the authors to introduce this very useful, very clear draft.

I do think it deserves very much the adoption by the WG as an solution option.



Here are some minor comments after I read the latest draft (which I think does 
not affect the adoption):



6.  Solution Overview

   This section describes a multicast VPN solution based on [RFC6513]

   and [RFC6514] for EVPN PEs operating in IRB mode that want to perform

   seamless interoperability with their counterparts MVPN PEs.

[XJR] with or without their counterparts MVPN PEs (since this document covers 
both).



Kesavan>> This section covers with MVPN PE. Later section covers EVPN only PEs.





   EVPN-PEs advertise unicast routes as host routes using EVPN route

   type 2 for sources that are directly attached to a tenant BD that has

   been extended in the EVPN fabric. EVPN-PE may summarize sources (IP

   networks) behind a router that are attached to EVPN-PE or sources

   that are connected to a BD, which is not extended across EVPN fabric

   and advertises those routes with EVPN route type 5. EVPN host-routes

   are advertised as IPVPN host-routes to MVPN-PEs only incase of

   seamless interop mode.

[XJR] Editorial error. Incase of -> in case of



Kesavan>> Will take care in the next revision





   In gateway model, EVPN-PE advertises unicast routes as IPVPN routes

   along with VRI extended community for all multicast sources attached

   behind EVPN-PEs. All IPVPN routes SHOULD be summarized while

   adverting to MVPN-PEs.

[XJR] VRI is used before its definition  VRF Route Import(6514) or IPv6 VRF 
Route Import(rfc6515) in my opinion.





Kesavan>> Will take care in the next revision







   VRI is constructed as following:

  -  The 4-octet Global Administrator field MUST be set to an IP

 address of the PE.  This address SHOULD be common for all the

 IP-VRFs on the PE (e.g., this address may be the PE's loopback

 address or VTEP address).

  -  The 2-octet Local Administrator field associated with a given

 IP-VRF contains a number that uniquely identifies that IP-VRF

 within the PE that contains the IP-VRF.

[XJR] Does this document want to cover Underlay IPv6 network (described in 
RFC6515) ? If it does(I guess), then the VRI can be IPv6 VRF Route Import as 
pointed above, and the Global Administrator can be a 16-octet field.





Kesavan>>  Thanks for pointing this out.  Will add this in the next revision.







   EVPN PE MUST have Route Target Extended Community to import/export

   MVPN routes. In data center environment, it is desirable to have this

   RT configured using auto-generated method than static configuration.

[XJR] is it a new specification for EVPN PE to have RT Extended Community ? if 
it does not, then MUST word is unnecessary.





   The following is one recommended model to auto-generate MVPN RT:

  - The Global Administrator field of the MVPN RT MAY be set

to BGP AS Number.

  - The Local Administrator field of the MVPN RT MAY be set to

the VNI associated with the tenant VRF.

[XJR] It's very helpful to have a method to auto-generate RT. Should this case 
be pointed out to help decision of using this method or not : the VNI is 24bit, 
and the Local Administrator is 16bit ?





Kesavan>> This is an AS specific EC. Local Administrator field is 4 bytes







9.2.3.  Other Encapsulation

   In order to signal a different tunneling encapsulation such as NVGRE,

  GPE, or GENEVE the corresponding BGP encapsulation extended community

   [TUNNEL-ENCAP] SHOULD be appended to the MVPN I-PMSI and S-PMSI A-D

   routes. If the Tunnel Type field in the encapsulation extended-

   community is set to a type which requires Virtual Network Identifier

   (VNI), e.g., VXLAN-GPE or NVGRE [TUNNEL-ENCAP], then the MPLS label

   in the PMSI Tunnel Attribute MUST be the VNI associated with the

   customer MVPN. Same as in VXLAN case, a gateway is needed for inter-

   operation between the EVPN-IRB PEs and non-EVPN MVPN PEs.

[XJR] I suggest remove the over-thought about various Encapsulation, we have 
seen different BGP attribute other than the TUNNEL-ENCAP attribute in 
https://datatracker.ietf.org/doc/draft-geng-bier-ipv6-inter-domain/

Hope you have a look at that one, and see if this kind of BIERv6 tunnel be 
useful for some scenario this document want to solve  to have a 
non-segmented P2MP tunnel from TOR in SPDC to BNGs outside of the SPDC.

Welcome your comments as well.



Kesavan>>  We need to cover encapsulation methods used in the underlay.  Will 
check other draft that has been poin

Re: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop

[Kesavan Thiruvenkatasamy (kethiruv)]

Hi  Jeffrey,

Thanks for your comments. Please find inline responses below (Kesavan>>)

Thanks,
Kesavan


--



Hi Ashutosh,

Sorry for the late response. Please see zzh> below.

From: Ashutosh Gupta 
mailto:ashutoshgupta.i...@gmail.com>>
Sent: Wednesday, August 15, 2018 3:57 AM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>
Cc: Ali Sajassi mailto:saja...@cisco.com>>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop

Hey Jeffrey,

Thanks for your comments & please find my responses inline  .

On Fri, Jul 20, 2018 at 9:53 AM, Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>> wrote:
Hi Ali,

Here are the comments that I did not get a chance for in the meeting today.

Regarding "ttl decrement" and "src mac change":
--

Since "bridging/switching in the same BD" is not put down as a requirement in 
the spec but rather discounted citing "emulation", the listed "requirements" 
should be changed to "properties" as well - one could also argue that those may 
not be true requirements and could also discounted.

 seamless-Interop solution supports both intra-subnet and inter-subnet 
forwarding which are the basic requirement along with Efficient fabric 
utilization and Operational simplicity. More specifically, having many 
discussions with customers we didn't come across any use-case where strict 
intra-subnet bridging was needed along with inter-subnet routing, so we can 
argue that "strict bridging/switching in the same BD" is just an idealistic 
requirement.

Zzh> The point is, those “requirements” are really somewhat 
arbitrary/subjective. We have not heard real requirements about “seamless 
integration” either, and even when the requirement comes, the OISM can do that 
seamless integration by having every EVPN as an MEG.

Even if RFC7432 does not prove true ethernet service, "ttl decrement" and "src 
mac change" for intra-subnet traffic does NOT happen with RFC7432. In other 
words, this is a step-down from RFC7432.

Kesavan>>  New revision proposes a method to keep ttl and src mac intact for 
intra subnet traffic.

 It is not a step down since we are not losing any needed functionality.

Zzh> It is a step down from what RFC7432 provides. The argument that TTL/mac 
change for intra-subnet is not an issue is subjective.

Again, seamless-interop solution utilizes existing and well deployed technology 
(MVPN) instead of re-defining all the constructs of MVPN into EVPN. 
evpn-irb-multicast draft takes later approach and achieves in-signification 
functionality gain at the expense of huge overhead in control-plane (Explained 
on a separate thread). From our customer interactions, we understand that 
Multicast is a complex technology to deploy, operate and troubleshoot. So any 
amount of simplification results in Opex reduction. Additionally, re-use of 
existing MVPN implementation for additional EVPN use-cases results in quick 
time-to-market with lower investment.

Zzh> Please see Eric’s comment on a separate thread. Both Eric and I are from 
MVPN background - trust us that we’d not be against “just use MVPN” if it 
solves EVPN problems effectively.

>> Have responded to Eric’s comments. If there are any other comments, we can 
>> discuss.


Zzh> BTW, with the seamless approach, aren’t you guys abandoning the SMET 
solution defined in draft-ietf-bess-evpn-igmp-mld-proxy?

Kesavan>> SMET solution is not needed for L3 only fabric ( Where all nodes 
support routing on their IRB interfaces).

About the comment "MVPN also decrements ttl and change src mac address" - 
that's expected behavior because it is routing between subnets not "intra 
subnet", and no application that uses MVPN service has assumption on constant 
TTL and src mac.

More regarding the "requirements" (or "properties")
---

With the other solution (evpn-irb-multicast, aka OISM), if every EVPN PE runs 
the MEG procedures then the same set of "requirements" is also achieved - it is 
also "seamless interop" but based on the OISM procedures, but that does not 
"translate into this method" (as defined in the seamless-interop draft) (I 
think that's what you mentioned when addressing Jorge's comment). What's more, 
it does not have the "ttl decrementing" and "src mac change" issue for intra 
subnet traffic.
 The point was made that once multicast traffic reaches MVPN domain, it 
doesn't belong to any specific BD and hence intra-subnet and inter-subnet 
receivers are treated similarly. Even with evpn-irb-multicast solution, it 
would be the same unless a second copy of traffic is sen

Re: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop

[Kesavan Thiruvenkatasamy (kethiruv)]

Hi Eric,

Thanks for  your comments.   Please see the inline responses below.

Regards,
Kesavan

From: BESS  on behalf of Eric C Rosen 

Date: Monday, September 10, 2018 at 10:39 AM
To: "Ali Sajassi (sajassi)" , Bess WG 
Subject: Re: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop

Eric> 1. It seems that the proposal does not do correct ethernet emulation.  
Intra-subnet multicast only sometimes preserves MAC SA and IP TTL, sometimes 
not, depending upon the topology.

Ali> EVPN doesn't provide LAN service per IEEE 802.1Q but rather an emulation 
of LAN service. This document defines what that emulation means

The fact that the proposal doesn't do correct ethernet emulation cannot be 
resolved by having the proposal redefine "emulation" to mean "whatever the 
proposal does".

EVPN needs to ensure that whatever works on a real ethernet will work on the 
emulated ethernet as well; the externally visible service characteristics on 
which the higher layers may depend must be properly offered by the emulation.  
This applies to both unicast and multicast equally.

Otherwise anyone attempting to replace a real ethernet with EVPN will find that 
not every application and/or protocol working on the real ethernet will 
continue to work on the EVPN.

Kesavan>>  A solution has been proposed  in the new revision to preserve MAC-SA 
and IP TTL for intra-subnet  traffic.


Eric> TTL handling for inter-subnet multicast seems inconsistent as well, 
depending upon the topology.

Ali> BTW, TTL handling for inter-subnet IP multicast traffic is done consistent!

Consider the following in a pure MVPN environment:

- Source S is on subnet1, which is attached to PE1.

- Receivers R1 and R2 are on subnet2, which is attached to both PE1 and PE2.

- Subnet1 and subnet2 are different subnets.

Now every (S,G) packet will follow the same path: either (a) 
subnet1-->PE1-->subnet2 or (b) subnet1-->PE1-->PE2-->subnet2.

Both paths cannot be used at the same time, because L3 multicast will not allow 
both PE1 and PE2 to transmit the (S,G) flow to subnet2.  So an (S,G) packet 
received by R1 will always have the same TTL as the same packet received by R2. 
 TTL scoping will therefore work consistently; depending on the routing, and 
from the perspective of any given flow, the two subnets are either one hop away 
from each other, or two hops away from each other.

In the so-called "seamless-mcast" scheme, on the other hand, if R1 and R2 get 
the same (S,G) packet, each may see a different TTL.  Suppose R1 is on an ES 
attached to PE1 but not to PE2, S is on an ES attached to PE1 but not to PE2, 
and R2 is on an ES attached to PE2 but not to PE1.  Then a given (S,G) packet 
received by R1 will have a smaller TTL than the same packet received by R2, 
even though R1 and R2 are on the same subnet.

Note that the seamless-mcast proposal does not provide the behavior that would 
be provided by MVPN, despite the claim that it is "just MVPN".

This user-visible inconsistency may break any use of TTL scoping, and is just 
the sort of thing that tends generate a stream of service calls from customers 
that pay attention to this sort of stuff.

In general, TTL should be decremented by 0 for intra-subnet and by 1 (within 
the EVPN domain) for inter-subnet.  Failure to handle the TTL decrement 
properly will break anything that depends upon RFC 3682 ("The Generalized TTL 
Security Mechanism").  Have you concluded that no use of multicast together 
with RFC 3682 will, now or in the future, ever need to run over EVPN?  I'd like 
to know how that conclusion is supported.  You may also wish to do a google 
search for "multicast ttl scoping".

A related issue is that the number of PEs through which a packet passes should 
not be inferrable by a tenant.  Any sort of multicast traceroute tool used by a 
tenant will give unexpected results if TTL is not handled properly; at the very 
least this will result in service calls.

The OISM proposal (as described in the irb-mcast draft) will decrement TTL by 1 
when packets go from one subnet to another, as an IP multicast frame is 
distributed unchanged to the PEs that need it, and its TTL is decremented by 1 
if an egress PE needs to deliver it to a subnet other than its source subnet.

Kesavan>>  TTL is handled very similar to inter-subnet unicast traffic.  ( In 
EVPN-IRB model,  TTL will get decremented once for hosts that are attached to 
same PE.  TTL. will get decremented twice, if hosts are connected behind two 
different PEs.)


The draft still makes the following peculiar claim:

   "Based on past experiences with MVPN over last dozen years for supported IP 
multicast applications, layer-3 forwarding of intra-subnet multicast traffic 
should be fine."

Since MVPN does not do intra-subnet multicast, experience with MVPN has no 
bearing whatsoever on the needs of intra-

Re: [bess] Comments on

[Gaurav Dawra]

Hi Jingrong,
I have updated -02 version to fix a typo and some minor nits. Rest of
comments are addressed in the latest version as mentioned by Swadesh as
well.
Cheers,
Gaurav


On Mon, Jul 8, 2019 at 1:47 PM Swadesh Agrawal (swaagraw) <
swaag...@cisco.com> wrote:

> Hi Jingrong
>
>
>
> Thanks for reviewing and comments. Please see my response inline starting
> with [SA] .
>
>
>
> Regards
>
> Swadesh
>
>
>
> *From: *BESS  on behalf of Xiejingrong <
> xiejingr...@huawei.com>
> *Date: *Thursday, June 27, 2019 at 7:51 PM
> *To: *"draft-dawra-bess-srv6-servi...@ietf.org" <
> draft-dawra-bess-srv6-servi...@ietf.org>, "bess@ietf.org" 
> *Subject: *[bess] Comments on 
>
>
>
> Hi
>
> I have read this documents several times.
>
> I think it is useful and stable to advance as a solution of L3VPN/EVPN
> service over IPv6 networks.
>
> Here are some minor comments:
>
>
>
>SRv6 Service SID refers to an SRv6 SID that MAY be associated with
>
>one of the service specific behavior on the advertising Provider
>
>Edge(PE) router, such as (but not limited to), in the case of L3VPN
>
>service, END.DT (Table lookup in a VRF) or END.DX (crossconnect to a
>
>nexthop) functions
>
> [xjr] what are the things “but not limited to” ? Please specify explicitly
> or delete the words in this paragraph and other places.
>
> [SA] In future, new behaviors could be defined on Egress PE extension to
> network programming. So we don’t want to restrict behaviors.
>
>
>
>To provide SRv6 service with best-effort connectivity, the egress PE
>
>signals an SRv6 Service SID with the BGP overlay service route.  The
>
>ingress PE encapsulates the payload in an outer IPv6 header where the
>
>destination address is the SRv6 Service SID provided by the egress
>
>PE.  The underlay between the PEs only need to support plain IPv6
>
>forwarding [RFC2460].
>
> [xjr]“with best-effort connectivity” is not clear to me.
>
> [SA] Based on IGP shortest path reachability.
>
> [xjr] I suggest a section can be added to say about “not using color and
> SRH”, “using color and SRH” for easy-deployment and for path-optimization
> respectively.
>
> [SA] hopefully above response clarifies.
>
> [xjr] s/RFC2460/RFC8200/g
>
> [SA] Ack.
>
>
>
>To provide SRv6 service in conjunction with an underlay SLA from the
>
>ingress PE to the egress PE, the egress PE colors the overlay service
>
>route with a Color extended
>
>community[I-D.ietf-idr-segment-routing-te-policy].  The ingress PE
>
>encapsulates the payload packet in an outer IPv6 header with an SRH
>
>that contains the SR policy associated with the related SLA followed
>
>by the SRv6 Service SID associated with the route.  The underlay
>
>nodes whose SRv6 SID's are part of the SRH must support SRv6 data
>
>plane.
>
> [xjr] see above suggestion.
>
>
>
> SRv6 Service Sub-TLV Type (1 octet): This field is set to 1 to
>
>   represent SRv6 SID Informaton Sub-TLV.
>
> [xjr] s/Informaton/information/g
>
> [SA] fixed in new version.
>
>
>
>Egress PEs which supports SRv6 based L3 services advertises overlay
>
>service prefixes along with a Service SID enclosed in a SRv6 L3
>
>Service TLV within the BGP SID attribute.  This TLV serves two
>
>purposes - first, it indicates that the egress PE is reachable via an
>
>SRv6 underlay and the BGP ingress PE receiving this route MAY choose
>
>to encapsulate or insert an SRv6 SRH; second ,it indicates the value
>
>of the SID to include in the SRH encapsulation.
>
> [xjr] The two purposes I can see, the indication of the reachability to
> this PE, and the indication of a specific Service this SRv6 SID bound to.
>
> [xjr] Use of SRH or not is determined by Color Extended Community, or more
> precisely, the SR-policy installed on Ingress Node, not this TLV.
>
> [SA] Please refer to updated version which hopefully clarifies this
> comment. Further there is a typing error in new version. Last line of
> paragraph will be modified to below is next version.
>
>
>
> “second ,it indicates the value of the Service SID to be used in the
> encapsulation.”
>
>
>
> 4.6.  EVPN multicast routes (Route Types 6, 7, 8) over SRv6 core
>
>These routes do not require the advertisement of SRv6 Service TLVs
>
>along with them.  Similar to EVPN Route Type 4, the BGP Nexthop is
>
>equal to the IPv6 address of egress PE.  More details may be added in
>
>future revisions of this document.
>
> [xjr] is 

Re: [bess] Comments on

[Swadesh Agrawal (swaagraw)]

Hi Jingrong

Thanks for reviewing and comments. Please see my response inline starting with 
[SA] .

Regards
Swadesh

From: BESS  on behalf of Xiejingrong 

Date: Thursday, June 27, 2019 at 7:51 PM
To: "draft-dawra-bess-srv6-servi...@ietf.org" 
, "bess@ietf.org" 
Subject: [bess] Comments on 

Hi
I have read this documents several times.
I think it is useful and stable to advance as a solution of L3VPN/EVPN service 
over IPv6 networks.
Here are some minor comments:

   SRv6 Service SID refers to an SRv6 SID that MAY be associated with
   one of the service specific behavior on the advertising Provider
   Edge(PE) router, such as (but not limited to), in the case of L3VPN
   service, END.DT (Table lookup in a VRF) or END.DX (crossconnect to a
   nexthop) functions
[xjr] what are the things “but not limited to” ? Please specify explicitly or 
delete the words in this paragraph and other places.
[SA] In future, new behaviors could be defined on Egress PE extension to 
network programming. So we don’t want to restrict behaviors.

   To provide SRv6 service with best-effort connectivity, the egress PE
   signals an SRv6 Service SID with the BGP overlay service route.  The
   ingress PE encapsulates the payload in an outer IPv6 header where the
   destination address is the SRv6 Service SID provided by the egress
   PE.  The underlay between the PEs only need to support plain IPv6
   forwarding [RFC2460].
[xjr]“with best-effort connectivity” is not clear to me.
[SA] Based on IGP shortest path reachability.
[xjr] I suggest a section can be added to say about “not using color and SRH”, 
“using color and SRH” for easy-deployment and for path-optimization 
respectively.
[SA] hopefully above response clarifies.
[xjr] s/RFC2460/RFC8200/g
[SA] Ack.

   To provide SRv6 service in conjunction with an underlay SLA from the
   ingress PE to the egress PE, the egress PE colors the overlay service
   route with a Color extended
   community[I-D.ietf-idr-segment-routing-te-policy].  The ingress PE
   encapsulates the payload packet in an outer IPv6 header with an SRH
   that contains the SR policy associated with the related SLA followed
   by the SRv6 Service SID associated with the route.  The underlay
   nodes whose SRv6 SID's are part of the SRH must support SRv6 data
   plane.
[xjr] see above suggestion.

SRv6 Service Sub-TLV Type (1 octet): This field is set to 1 to
  represent SRv6 SID Informaton Sub-TLV.
[xjr] s/Informaton/information/g
[SA] fixed in new version.

   Egress PEs which supports SRv6 based L3 services advertises overlay
   service prefixes along with a Service SID enclosed in a SRv6 L3
   Service TLV within the BGP SID attribute.  This TLV serves two
   purposes - first, it indicates that the egress PE is reachable via an
   SRv6 underlay and the BGP ingress PE receiving this route MAY choose
   to encapsulate or insert an SRv6 SRH; second ,it indicates the value
   of the SID to include in the SRH encapsulation.
[xjr] The two purposes I can see, the indication of the reachability to this 
PE, and the indication of a specific Service this SRv6 SID bound to.
[xjr] Use of SRH or not is determined by Color Extended Community, or more 
precisely, the SR-policy installed on Ingress Node, not this TLV.
[SA] Please refer to updated version which hopefully clarifies this comment. 
Further there is a typing error in new version. Last line of paragraph will be 
modified to below is next version.

“second ,it indicates the value of the Service SID to be used in the 
encapsulation.”

4.6.  EVPN multicast routes (Route Types 6, 7, 8) over SRv6 core
   These routes do not require the advertisement of SRv6 Service TLVs
   along with them.  Similar to EVPN Route Type 4, the BGP Nexthop is
   equal to the IPv6 address of egress PE.  More details may be added in
   future revisions of this document.
[xjr] is this determined that No SRv6 Service TLVs required ? the document 
 had seen the use of SRv6 Service TLV in multicast 
VPN.
[xjr] Suggest to say simply this is outside of this document, which I think 
covers unicast service only, and helpful to advance.
[SA] This is specific to EVPN RT 6,7,8 and not MVPN (RT 6 and 7). This may be 
updated in future version of document based on future analysis.

Thanks
Jingrong

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

[bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop-04

[Xiejingrong]

Hi

Thanks the authors to introduce this very useful, very clear draft.
I do think it deserves very much the adoption by the WG as an solution option.

Here are some minor comments after I read the latest draft (which I think does 
not affect the adoption):

6.  Solution Overview
   This section describes a multicast VPN solution based on [RFC6513]
   and [RFC6514] for EVPN PEs operating in IRB mode that want to perform
   seamless interoperability with their counterparts MVPN PEs.
[XJR] with or without their counterparts MVPN PEs (since this document covers 
both).


   EVPN-PEs advertise unicast routes as host routes using EVPN route
   type 2 for sources that are directly attached to a tenant BD that has
   been extended in the EVPN fabric. EVPN-PE may summarize sources (IP
   networks) behind a router that are attached to EVPN-PE or sources
   that are connected to a BD, which is not extended across EVPN fabric
   and advertises those routes with EVPN route type 5. EVPN host-routes
   are advertised as IPVPN host-routes to MVPN-PEs only incase of
   seamless interop mode.
[XJR] Editorial error. Incase of -> in case of


   In gateway model, EVPN-PE advertises unicast routes as IPVPN routes
   along with VRI extended community for all multicast sources attached
   behind EVPN-PEs. All IPVPN routes SHOULD be summarized while
   adverting to MVPN-PEs.
[XJR] VRI is used before its definition  VRF Route Import(6514) or IPv6 VRF 
Route Import(rfc6515) in my opinion.


   VRI is constructed as following:
  -  The 4-octet Global Administrator field MUST be set to an IP
 address of the PE.  This address SHOULD be common for all the
 IP-VRFs on the PE (e.g., this address may be the PE's loopback
 address or VTEP address).
  -  The 2-octet Local Administrator field associated with a given
 IP-VRF contains a number that uniquely identifies that IP-VRF
 within the PE that contains the IP-VRF.
[XJR] Does this document want to cover Underlay IPv6 network (described in 
RFC6515) ? If it does(I guess), then the VRI can be IPv6 VRF Route Import as 
pointed above, and the Global Administrator can be a 16-octet field.


   EVPN PE MUST have Route Target Extended Community to import/export
   MVPN routes. In data center environment, it is desirable to have this
   RT configured using auto-generated method than static configuration.
[XJR] is it a new specification for EVPN PE to have RT Extended Community ? if 
it does not, then MUST word is unnecessary.


   The following is one recommended model to auto-generate MVPN RT:
  - The Global Administrator field of the MVPN RT MAY be set
to BGP AS Number.
  - The Local Administrator field of the MVPN RT MAY be set to
the VNI associated with the tenant VRF.
[XJR] It's very helpful to have a method to auto-generate RT. Should this case 
be pointed out to help decision of using this method or not : the VNI is 24bit, 
and the Local Administrator is 16bit ?


9.2.3.  Other Encapsulation
   In order to signal a different tunneling encapsulation such as NVGRE,
  GPE, or GENEVE the corresponding BGP encapsulation extended community
   [TUNNEL-ENCAP] SHOULD be appended to the MVPN I-PMSI and S-PMSI A-D
   routes. If the Tunnel Type field in the encapsulation extended-
   community is set to a type which requires Virtual Network Identifier
   (VNI), e.g., VXLAN-GPE or NVGRE [TUNNEL-ENCAP], then the MPLS label
   in the PMSI Tunnel Attribute MUST be the VNI associated with the
   customer MVPN. Same as in VXLAN case, a gateway is needed for inter-
   operation between the EVPN-IRB PEs and non-EVPN MVPN PEs.
[XJR] I suggest remove the over-thought about various Encapsulation, we have 
seen different BGP attribute other than the TUNNEL-ENCAP attribute in 
https://datatracker.ietf.org/doc/draft-geng-bier-ipv6-inter-domain/
Hope you have a look at that one, and see if this kind of BIERv6 tunnel be 
useful for some scenario this document want to solve  to have a 
non-segmented P2MP tunnel from TOR in SPDC to BNGs outside of the SPDC.
Welcome your comments as well.


Thanks
Jingrong

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

[bess] Comments on draft-sajassi-bess-evpn-ip-aliasing-00 and/or draft-ietf-bess-evpn-inter-subnet-forwarding

[wang.yubao2]

Hi Ali and everyone,







I reviewed the [EVPN IP Aliasing] draft and found that it conflicts with 
draft-ietf-bess-evpn-inter-subnet-forwarding-05 in MPLS encapsulation.










draft-sajassi-bess-evpn-ip-aliasing-00 section 2.1 Constructing Ethernet A-D 
per EVPN Instance Route


... ...

   * The L3 EAD/EVI SHOULD carry one or more IP VRF Route-Target (RT)   

   attributes.


   * The L3 EAD/EVI SHOULD carry the RMAC Extended Community attribute.


   * The MPLS Label usage should be as described in RFC 7432. 



... ..











draft-ietf-bess-evpn-inter-subnet-forwarding-05 section 3.2.3 Data Plane - 
Ingress PE


 ... ...

   If the tunnel type is that of MPLS or IP-only NVO tunnel, then TS's

   IP packet is sent over the tunnel without any Ethernet header.

   However, if the tunnel type is that of Ethernet NVO tunnel, then an

   Ethernet header needs to be added to the TS's IP packet. The source

   MAC address of this inner Ethernet header is set to the ingress PE's

   router MAC address and the destination MAC address of this inner

   Ethernet header is set to the egress PE's router MAC address. The

   MPLS VPN label or VNI fields are set accordingly and the packet is

   forwarded to the egress PE. 





 ... ...











In the first draft the L3 EAD/EVI Route for symmetric IRB uses a L2 MPLS Label, 


so the PE expects to receive a EVPN data packet with an overlay ethernet header 
as per RFC7432.


But unfortunatly, in the second draft, the inter-subnet forwarding procedures 
for symmetric IRB 


will always send the EVPN data packet without the overlay ethernet header. 


So I think these two drafts conflicts with each other, and one of them should 
be updated.


and I propose that the [EVPN IP Aliasing] draft should use a L3 MPLS Label in 
the L3 EAD/EVI route.






How do you think about it?






Best Regards


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

[bess] Comments on

[Xiejingrong]

Hi
I have read this documents several times.
I think it is useful and stable to advance as a solution of L3VPN/EVPN service 
over IPv6 networks.
Here are some minor comments:

   SRv6 Service SID refers to an SRv6 SID that MAY be associated with
   one of the service specific behavior on the advertising Provider
   Edge(PE) router, such as (but not limited to), in the case of L3VPN
   service, END.DT (Table lookup in a VRF) or END.DX (crossconnect to a
   nexthop) functions
[xjr] what are the things "but not limited to" ? Please specify explicitly or 
delete the words in this paragraph and other places.

   To provide SRv6 service with best-effort connectivity, the egress PE
   signals an SRv6 Service SID with the BGP overlay service route.  The
   ingress PE encapsulates the payload in an outer IPv6 header where the
   destination address is the SRv6 Service SID provided by the egress
   PE.  The underlay between the PEs only need to support plain IPv6
   forwarding [RFC2460].
[xjr]"with best-effort connectivity" is not clear to me.
[xjr] I suggest a section can be added to say about "not using color and SRH", 
"using color and SRH" for easy-deployment and for path-optimization 
respectively.
[xjr] s/RFC2460/RFC8200/g

   To provide SRv6 service in conjunction with an underlay SLA from the
   ingress PE to the egress PE, the egress PE colors the overlay service
   route with a Color extended
   community[I-D.ietf-idr-segment-routing-te-policy].  The ingress PE
   encapsulates the payload packet in an outer IPv6 header with an SRH
   that contains the SR policy associated with the related SLA followed
   by the SRv6 Service SID associated with the route.  The underlay
   nodes whose SRv6 SID's are part of the SRH must support SRv6 data
   plane.
[xjr] see above suggestion.

SRv6 Service Sub-TLV Type (1 octet): This field is set to 1 to
  represent SRv6 SID Informaton Sub-TLV.
[xjr] s/Informaton/information/g

   Egress PEs which supports SRv6 based L3 services advertises overlay
   service prefixes along with a Service SID enclosed in a SRv6 L3
   Service TLV within the BGP SID attribute.  This TLV serves two
   purposes - first, it indicates that the egress PE is reachable via an
   SRv6 underlay and the BGP ingress PE receiving this route MAY choose
   to encapsulate or insert an SRv6 SRH; second ,it indicates the value
   of the SID to include in the SRH encapsulation.
[xjr] The two purposes I can see, the indication of the reachability to this 
PE, and the indication of a specific Service this SRv6 SID bound to.
[xjr] Use of SRH or not is determined by Color Extended Community, or more 
precisely, the SR-policy installed on Ingress Node, not this TLV.

4.6.  EVPN multicast routes (Route Types 6, 7, 8) over SRv6 core
   These routes do not require the advertisement of SRv6 Service TLVs
   along with them.  Similar to EVPN Route Type 4, the BGP Nexthop is
   equal to the IPv6 address of egress PE.  More details may be added in
   future revisions of this document.
[xjr] is this determined that No SRv6 Service TLVs required ? the document 
 had seen the use of SRv6 Service TLV in multicast 
VPN.
[xjr] Suggest to say simply this is outside of this document, which I think 
covers unicast service only, and helpful to advance.

Thanks
Jingrong

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

Re: [bess] Comments on BGP procedures for draft-ietf-bess-evpn-igmp-mld-proxy

[Jeffrey Haas]

On Thu, May 09, 2019 at 06:46:02PM +, Mankamana Mishra (mankamis) wrote:
> On May 9, 2019, at 11:42 AM, Jeffrey Haas 
> mailto:jh...@pfrc.org>> wrote:
> > Section 7.1:
> > The lengths of the various fields and their consistency should be spelled
> > out in more detail.
> > 
> > For example, a source could be 0 for (*,G), or should be the length of an
> > IPv4 or IPv6 host address (32/128).  Other lengths likely do not make sense.
> 
> From 
> 7.1.1
>  Constructing the Selective Multicast Ethernet Tag route
> 
> 
>The Multicast Source length MUST be set to length of multicast source
>address in bits. In case of a (*, G) Join, the Multicast Source
>Length is set to 0.
> 
> 
> in case of (*,G) join , source length would be 0. and it does say in this 
> section.

It does not specify that 32 or 128 is the only other two useful options
though.

Basically, the point is that in the absence of text that "this is a host",
the implication is "this might be a subnet".  

For example, if the length is 24, even properly encoded on the wire for that
length, what do you do with 24 bits of a source?

> > The length of a multicast group also likely should be a "host" length -
> > 32/128.
> > 
> > For the source and the group, it is likely an error if the lengths do not
> > agree.  E.g. S may be 0, but when 32 or 128 the group must be 32 or 128
> > respectively.
> 
> Do you mean,  draft should spell out different possible errored length ?  or 
> may be statement similar to https://tools.ietf.org/html/rfc6514 would be good 
> enough ?

Consider 6514, section 4.3:

:   The Multicast Source field contains the C-S address.  If the
:   Multicast Source field contains an IPv4 address, then the value of
:   the Multicast Source Length field is 32.  If the Multicast Source
:   field contains an IPv6 address, then the value of the Multicast
:   Source Length field is 128.

So, yes, that would be what I was expecting here.

> > The originator router also should likely be a host length, although I'm a
> > bit unclear what the intent of the contents of this field should be.  Is
> > this intended to be a loopback?  If so, how does one choose it among
> > several, if more than one is available?  Should the length of the originator
> > also agree with the S,G fields?
> 
> Do you mean (S,G) len should be driving factor Originator len / IP  ?

If I have ipv4 (S,G), is it reasonable that I got that from a router that is
via IPv6?  

> > The flags field is somewhat confusing when the addresses are IPv6 and thus
> > the procedures are expected to be for MLD rather than IGMP.  The draft as a
> > whole, in spite of its title, is worded heavily toward IGMP.  I would
> > suggest requesting some appropriate review to help normalize the terminology
> > here.  However, the flags field should be clarified for MLD cases.
> 
> This is being already addressed in next version.

Thanks.

-- Jeff

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

[bess] Comments on BGP procedures for draft-ietf-bess-evpn-igmp-mld-proxy

[Jeffrey Haas]

I have a few comments on this draft, in particular on the BGP PDU encoding
procedures:

Section 7.1:
The lengths of the various fields and their consistency should be spelled
out in more detail.  

For example, a source could be 0 for (*,G), or should be the length of an
IPv4 or IPv6 host address (32/128).  Other lengths likely do not make sense.

The length of a multicast group also likely should be a "host" length -
32/128. 

For the source and the group, it is likely an error if the lengths do not
agree.  E.g. S may be 0, but when 32 or 128 the group must be 32 or 128
respectively.

The originator router also should likely be a host length, although I'm a
bit unclear what the intent of the contents of this field should be.  Is
this intended to be a loopback?  If so, how does one choose it among
several, if more than one is available?  Should the length of the originator
also agree with the S,G fields?

Some discussion about what to do when the fields are syntactially valid but
semantically invalid (e.g. mis-matched lengths) is needed.  See RFC 7606
about what to discuss.  Likely "treat as withdraw" semantics are desired.

The flags field is somewhat confusing when the addresses are IPv6 and thus
the procedures are expected to be for MLD rather than IGMP.  The draft as a
whole, in spite of its title, is worded heavily toward IGMP.  I would
suggest requesting some appropriate review to help normalize the terminology
here.  However, the flags field should be clarified for MLD cases.

Similar comments apply to section 7.2 and 7.3.

Section 7.3 does not discuss the two new fields Leave Group Synchornization
and Maximum Response Time or the procedures for these fields.  It should
refer back to section 4.2.

-- Jeff

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

[bess] Comments on draft-ietf-bess-evpn-yang-07

[Yu Tianpeng]

Hi authors,
Thanks a lot for the -07 version of EVPN yang, which fixes many points ever
raised in the mail list also some we did not notice. This version moves
this document a big step forward.
Thanks for the presentation and update in 104 also.

Related with the  P-tunnel been discussed before, I think there are two
points to fix:
1. Current version lacks a definition of P-tunnel type in inclusive
multicast ethernet tag route (for route query only, read only), raised by
Sasha initially.
It may be fixed in this way, Import the "typedef p-tunnel" defined in
draft-ietf-bess-mvpn-yang-01, and add a leaf called tunnel-type in
inclusive multicast ethernet tag route.
2. Related with the place to configure IR or P2MP, since P-tunnel is a
concept per EVI basis, I would suggest moving this into evpn-instances.
And this leaf is read+write.

And I had a line-by-line read again before LC starts, and there are some
comments as below (Probably a long list.. I hope most of them not issues or
can be fixed easily).

Appreciate if the authors could have a look.

Thanks in advance.
Regards,
Tim

##

ethernet-segment yang

1. the key of "container ethernet-segments" is "name", should not it be
ESI?
I have no clue how to fill the name field TBH, does it mean "interface"? If
so it should be read-only I suppose.  If no, where is the mount point to
interface...

2. service-type, what does it mean?? Does it mean vlan-based, vlan-bundle,
vlan-aware-bundle? If so why there is "vpws-vlan-aware" in evpn yang..

3. related with leaf "ac-or-pw"
I would suggest to use evc instead of ac as it is quite confusing. Also in
vES draft it is using evc.
And for ac, it is the interface that bound to the evi, right? What if the
es is not ves, can I fill in the interface with physical interface? If no,
we may need another leaf indicating the interface for ES.


4. vlan in leaf df, please add range restriction and use uint16. This is
aligned with many yang modules already standardised

5. leaf esi-label, it should have been covered by evpn route in evpn yang
right?  this is the label in ESI Label Extended Community right?
And if I look at evpn yang, the Extended community is defined to be a raw
string.
Also, I cannot see e-tree label.. and I cannot find the bit saying this ES
is leaf of etree or not..
TBH I have concerns on if a raw string is a proper way to reflect all
extended communities

6. leaf ead-evi-route: similarly, this is Aliasing right? Is es or evpn
yang the better place to put this function?

7. In es yang: what is the meaning of member, which is an IP address?  Is
it the router-id of the device? Please add some description here.


evpn.yang
1. Counters I would suggest to use counter64 instead of counter 32,
counter32 is too likely to get overflowed.

2. Control word function defined in 7432 is not included (VPWS one should
be fine as it is mounted to l2vpn pw yang, i suppose).

3. leaf vpws-vlan-aware looks abrupt to me in evpn yang... what is it used
for?

4. leaf bestpath in path-detail-grp in evpn yang should use boolean instead
of empty. I suppose?

5. related with statistics, this is a sum of the counter of all interfaces
bound to the corresponding EVI right? Please add a bit description on this
if possible..

6. Related with the mount point of EVPN VPWS, only a container called
"evpn-pw" is defined? I am not sure how many functions being missed in EVPN
VPWS tbh... In my mind so far:
no EAD route query,
no statistics
rd-rt info..?
Also we may need to exclude some leaf from pw yang for evpn vpws
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Comments to draft-sajassi-bess-secure-evpn-00

[Linda Dunbar]

Ali, et al,

One of the requirement you stated in the document is (under the section 2.3)

   "1) Per pair of PEs: A single IPsec tunnel between a pair of PEs to be used 
for all tenants' traffic supported by the pair of PEs."





Assuming that the solution is intended for SD-WAN.  The SD-WAN edge nodes 
usually have some ports connected to trusted domain (e.g. MPLS network) which 
doesn't need IPsec tunnel, and some ports connected to untrusted domain (e.g. 
Internet) which needs IPsec tunnel. Therefore, for PE based IPsec tunnel, it is 
necessary to associate the WAN ports (facing untrusted domain) with the IPsec 
tunnels.

Actually, even for other granularity (such as Per tenant, Per Subnet, or per 
IP) IPsec tunnels, it is necessary to associate with the WAN ports as well 
because the trusted domain doesn't need IPsec SA.

Linda Dunbar

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

Re: [bess] Comments about draft-gmsm-bess-evpn-bfd-01

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Donald,

-Original Message-
From: Donald Eastlake 
Date: Tuesday, November 6, 2018 at 6:59 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Cc: "bess@ietf.org" , 
"draft-gmsm-bess-evpn-bfd.auth...@ietf.org" 

Subject: Re: Comments about draft-gmsm-bess-evpn-bfd-01

Hi Jorge,

On Mon, Nov 5, 2018 at 9:12 PM Rabadan, Jorge (Nokia - US/Mountain
View)  wrote:
>
> Hi Donald,
>
> Thank you for this.
> For the second question, I get from your answer that you will keep both 
encapsulations for the time being?

Well, once a draft is posted, it can't be changed, so the currently
posted -01 won't change but the -02 version that is being worked on
and is not yet posted eliminates the alternative encapsulation.

[JORGE] :-) of course. I misunderstood your answer. Sounds good then. Thank you!

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e...@gmail.com

> Thanks.
> Jorge
>
>
> -Original Message-
> From: Donald Eastlake 
> Date: Monday, November 5, 2018 at 8:48 PM
> To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
> Cc: "bess@ietf.org" , 
"draft-gmsm-bess-evpn-bfd.auth...@ietf.org" 

> Subject: Re: Comments about draft-gmsm-bess-evpn-bfd-01
>
> Hi Jorge,
>
> On Mon, Nov 5, 2018 at 4:44 AM Rabadan, Jorge (Nokia - US/Mountain
> View)  wrote:
> >
> > Dear authors,
> >
> > I couldn’t make it to the BESS meeting, so my apologies if some of 
these things have been discussed.
> >
> > Some comments/questions:
>
> Thanks for sending comments.
>
> > - In the last IETF, I suggested the use of BGP and the BGP-BFD 
attribute to exchange discriminators, as in section 3.1.6 of 
draft-ietf-bess-mvpn-fast-failover. The idea seemed to be accepted, but it is 
not in the new version. This would allow the signaling of the discriminators 
along with MAC/IP routes, IMET routes, AD per-EVI routes, IP-Prefix routes, 
etc. without the burden of having to support the EVPN LSP-ping draft.
>
> There is a draft version -02 in the works intended to include
> distribution of BFD discriminators in BGP but this revision was not
> completed to the agreement of the authors in time to posted before
> this meeting.
>
> > - The draft describes an encapsulation and an alternative 
encapsulation. Is the intend to keep both? Wouldn't be better to leave only one 
to ease implementations and interoperability?
>
> Currently, the candidate version -02 draft dispenses with with the
> alternative encapsulation.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  1424 Pro Shop Court, Davenport, FL 33896 USA
>  d3e...@gmail.com
>
> > Thank you.
> > Jorge
>
>


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

Re: [bess] Comments about draft-gmsm-bess-evpn-bfd-01

[Donald Eastlake]

Hi Jorge,

On Mon, Nov 5, 2018 at 9:12 PM Rabadan, Jorge (Nokia - US/Mountain
View)  wrote:
>
> Hi Donald,
>
> Thank you for this.
> For the second question, I get from your answer that you will keep both 
> encapsulations for the time being?

Well, once a draft is posted, it can't be changed, so the currently
posted -01 won't change but the -02 version that is being worked on
and is not yet posted eliminates the alternative encapsulation.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e...@gmail.com

> Thanks.
> Jorge
>
>
> -Original Message-
> From: Donald Eastlake 
> Date: Monday, November 5, 2018 at 8:48 PM
> To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
> Cc: "bess@ietf.org" , 
> "draft-gmsm-bess-evpn-bfd.auth...@ietf.org" 
> 
> Subject: Re: Comments about draft-gmsm-bess-evpn-bfd-01
>
> Hi Jorge,
>
> On Mon, Nov 5, 2018 at 4:44 AM Rabadan, Jorge (Nokia - US/Mountain
> View)  wrote:
> >
> > Dear authors,
> >
> > I couldn’t make it to the BESS meeting, so my apologies if some of 
> these things have been discussed.
> >
> > Some comments/questions:
>
> Thanks for sending comments.
>
> > - In the last IETF, I suggested the use of BGP and the BGP-BFD 
> attribute to exchange discriminators, as in section 3.1.6 of 
> draft-ietf-bess-mvpn-fast-failover. The idea seemed to be accepted, but it is 
> not in the new version. This would allow the signaling of the discriminators 
> along with MAC/IP routes, IMET routes, AD per-EVI routes, IP-Prefix routes, 
> etc. without the burden of having to support the EVPN LSP-ping draft.
>
> There is a draft version -02 in the works intended to include
> distribution of BFD discriminators in BGP but this revision was not
> completed to the agreement of the authors in time to posted before
> this meeting.
>
> > - The draft describes an encapsulation and an alternative 
> encapsulation. Is the intend to keep both? Wouldn't be better to leave only 
> one to ease implementations and interoperability?
>
> Currently, the candidate version -02 draft dispenses with with the
> alternative encapsulation.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  1424 Pro Shop Court, Davenport, FL 33896 USA
>  d3e...@gmail.com
>
> > Thank you.
> > Jorge
>
>

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

Re: [bess] Comments about draft-gmsm-bess-evpn-bfd-01

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Donald,

Thank you for this.
For the second question, I get from your answer that you will keep both 
encapsulations for the time being? 

Thanks.
Jorge


-Original Message-
From: Donald Eastlake 
Date: Monday, November 5, 2018 at 8:48 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Cc: "bess@ietf.org" , 
"draft-gmsm-bess-evpn-bfd.auth...@ietf.org" 

Subject: Re: Comments about draft-gmsm-bess-evpn-bfd-01

Hi Jorge,

On Mon, Nov 5, 2018 at 4:44 AM Rabadan, Jorge (Nokia - US/Mountain
View)  wrote:
>
> Dear authors,
>
> I couldn’t make it to the BESS meeting, so my apologies if some of these 
things have been discussed.
>
> Some comments/questions:

Thanks for sending comments.

> - In the last IETF, I suggested the use of BGP and the BGP-BFD attribute 
to exchange discriminators, as in section 3.1.6 of 
draft-ietf-bess-mvpn-fast-failover. The idea seemed to be accepted, but it is 
not in the new version. This would allow the signaling of the discriminators 
along with MAC/IP routes, IMET routes, AD per-EVI routes, IP-Prefix routes, 
etc. without the burden of having to support the EVPN LSP-ping draft.

There is a draft version -02 in the works intended to include
distribution of BFD discriminators in BGP but this revision was not
completed to the agreement of the authors in time to posted before
this meeting.

> - The draft describes an encapsulation and an alternative encapsulation. 
Is the intend to keep both? Wouldn't be better to leave only one to ease 
implementations and interoperability?

Currently, the candidate version -02 draft dispenses with with the
alternative encapsulation.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e...@gmail.com

> Thank you.
> Jorge


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

Re: [bess] Comments about draft-gmsm-bess-evpn-bfd-01

[Donald Eastlake]

Hi Jorge,

On Mon, Nov 5, 2018 at 4:44 AM Rabadan, Jorge (Nokia - US/Mountain
View)  wrote:
>
> Dear authors,
>
> I couldn’t make it to the BESS meeting, so my apologies if some of these 
> things have been discussed.
>
> Some comments/questions:

Thanks for sending comments.

> - In the last IETF, I suggested the use of BGP and the BGP-BFD attribute to 
> exchange discriminators, as in section 3.1.6 of 
> draft-ietf-bess-mvpn-fast-failover. The idea seemed to be accepted, but it is 
> not in the new version. This would allow the signaling of the discriminators 
> along with MAC/IP routes, IMET routes, AD per-EVI routes, IP-Prefix routes, 
> etc. without the burden of having to support the EVPN LSP-ping draft.

There is a draft version -02 in the works intended to include
distribution of BFD discriminators in BGP but this revision was not
completed to the agreement of the authors in time to posted before
this meeting.

> - The draft describes an encapsulation and an alternative encapsulation. Is 
> the intend to keep both? Wouldn't be better to leave only one to ease 
> implementations and interoperability?

Currently, the candidate version -02 draft dispenses with with the
alternative encapsulation.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e...@gmail.com

> Thank you.
> Jorge

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

[bess] Comments about draft-gmsm-bess-evpn-bfd-01

[Rabadan, Jorge (Nokia - US/Mountain View)]

Dear authors,

I couldn’t make it to the BESS meeting, so my apologies if some of these things 
have been discussed.
 
Some comments/questions:

- In the last IETF, I suggested the use of BGP and the BGP-BFD attribute to 
exchange discriminators, as in section 3.1.6 of 
draft-ietf-bess-mvpn-fast-failover. The idea seemed to be accepted, but it is 
not in the new version. This would allow the signaling of the discriminators 
along with MAC/IP routes, IMET routes, AD per-EVI routes, IP-Prefix routes, 
etc. without the burden of having to support the EVPN LSP-ping draft.

- The draft describes an encapsulation and an alternative encapsulation. Is the 
intend to keep both? Wouldn't be better to leave only one to ease 
implementations and interoperability?

Thank you.
Jorge





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

Re: [bess] Comments on L3VPN yang

[stephane.litkowski]

I'm also wondering if the RPF should not sit in the MPLS module as it could be 
used for any types of labels advertised to a neighbor.

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, October 22, 2018 15:25
To: draft-ietf-bess-l3vpn-y...@ietf.org; bess@ietf.org
Subject: [bess] Comments on L3VPN yang

Hi Authors,

Please find some comments on the current model:

-  I don't understand the "advertise-as-vpn" leaf under global-imports, 
what is the use case ?

-  Same question for "bgp-valid-route" leaf

-  Why do you have a long list of protocols within the global-imports ? 
Isn't it the goal of the route-policy referenced earlier ? Moreover I do not 
think that it is a good idea to use the enum type here as protocol names ,when 
referring to, should not change across all routing configurations within a node.

-  Export to global may also require a policy to filter

-  Some description fields are just "."

-  How do you plan the tunnel policy to be used ?

-  Would be great to have RTs configurable for both IPv4/IPv6 without 
redefining the config for each address family.

-  While I think the "forwarding-mode" under interface is a good thing, 
it looks really a Cisco like config statement that other implementations do not 
have. Wouldn't it be better  to have a knob to enable mpls packet processing on 
an interface ; maybe in the MPLS yang model ?

-   What is the goal of the "route-policy" within 
"retain-route-targets" under the BGP peer AFI/SAFI ? I usually two use case 
(auto policy => import RTs are derived from VRF configuration, or keep all), 
what is the use case you want to address here ?

-  What is the "vpn-prefix-limit" within "retain-route-targets" under 
the BGP peer AFI/SAFI ? Is it a generic BGP prefix-limit ? If yes, we need to 
keep it generic within the BGP model.

-  IMO, the label mode should sit within the VRF and not at the BGP 
level. Each VRF may have a different flavor.

-  Why do you define bgp-label-mode and routing-table-limit for ipv4 
unicast and ipv6 unicast ? Does not seem to be L3VPN related..

-  For iBGP PE-CE, notion of independent domain with attr-set usage 
seems to miss in the model

-  Unequal cost path loadbalancing option is missing from the VRF config

-  Do we need a config statement to enable local import/export between 
local VRFs ?

-  I suppose that IGP/BGP configuration in VRF is inherited from core 
routing model.

-  Do you have to enrich routing policy model with ability to 
set/delete/match RTs, SoOs ?

-  Do we have to create/enrich RIB-in/RIB-out/Loc-RIB entries for BGP 
L3VPN prefixes ?

-  What about PIC Edge/PE-CE link protection configuration ?

-  Need notification for the route table limit alert

-  Do we have operational states with number of IPv4 and IPv6 routes 
within the instance ?

-  Do we have everything to support Carrier's of Carrier case ?


Brgds,

Stephane


_



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.

_

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 em

Re: [bess] Comments on L3VPN yang

[Alexander Vainshtein]

Hi all,
I fully agree with Stephane's point "the label mode should sit within the VRF 
and not at the BGP level. Each VRF may have a different flavor".  One relevant 
use case is the VRF that provides inet-subnet forwarding i EVPN with Symmetric 
IRB - it must use per-VRF label allocation policy with the label in question 
being advertised ad Label2 in MAC/IP Advertisement routes rgardless of how 
other VRFs allocate their labels.

My 2c.

Thumb typed by Sasha Vainshtein


From: BESS  on behalf of stephane.litkow...@orange.com 

Sent: Monday, October 22, 2018 4:24:35 PM
To: draft-ietf-bess-l3vpn-y...@ietf.org; bess@ietf.org
Subject: [bess] Comments on L3VPN yang

Hi Authors,

Please find some comments on the current model:

-  I don’t understand the “advertise-as-vpn” leaf under global-imports, 
what is the use case ?

-  Same question for “bgp-valid-route” leaf

-  Why do you have a long list of protocols within the global-imports ? 
Isn’t it the goal of the route-policy referenced earlier ? Moreover I do not 
think that it is a good idea to use the enum type here as protocol names ,when 
referring to, should not change across all routing configurations within a node.

-  Export to global may also require a policy to filter

-  Some description fields are just “.”

-  How do you plan the tunnel policy to be used ?

-  Would be great to have RTs configurable for both IPv4/IPv6 without 
redefining the config for each address family.

-  While I think the “forwarding-mode” under interface is a good thing, 
it looks really a Cisco like config statement that other implementations do not 
have. Wouldn’t it be better  to have a knob to enable mpls packet processing on 
an interface ; maybe in the MPLS yang model ?

-   What is the goal of the “route-policy” within 
“retain-route-targets” under the BGP peer AFI/SAFI ? I usually two use case 
(auto policy => import RTs are derived from VRF configuration, or keep all), 
what is the use case you want to address here ?

-  What is the “vpn-prefix-limit” within “retain-route-targets” under 
the BGP peer AFI/SAFI ? Is it a generic BGP prefix-limit ? If yes, we need to 
keep it generic within the BGP model.

-  IMO, the label mode should sit within the VRF and not at the BGP 
level. Each VRF may have a different flavor.

-  Why do you define bgp-label-mode and routing-table-limit for ipv4 
unicast and ipv6 unicast ? Does not seem to be L3VPN related..

-  For iBGP PE-CE, notion of independent domain with attr-set usage 
seems to miss in the model

-  Unequal cost path loadbalancing option is missing from the VRF config

-  Do we need a config statement to enable local import/export between 
local VRFs ?

-  I suppose that IGP/BGP configuration in VRF is inherited from core 
routing model.

-  Do you have to enrich routing policy model with ability to 
set/delete/match RTs, SoOs ?

-  Do we have to create/enrich RIB-in/RIB-out/Loc-RIB entries for BGP 
L3VPN prefixes ?

-  What about PIC Edge/PE-CE link protection configuration ?

-  Need notification for the route table limit alert

-  Do we have operational states with number of IPv4 and IPv6 routes 
within the instance ?

-  Do we have everything to support Carrier’s of Carrier case ?


Brgds,

Stephane


_

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.


___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
__
BESS mailing list
BESS@i

[bess] Comments on L3VPN yang

[stephane.litkowski]

Hi Authors,

Please find some comments on the current model:

-  I don't understand the "advertise-as-vpn" leaf under global-imports, 
what is the use case ?

-  Same question for "bgp-valid-route" leaf

-  Why do you have a long list of protocols within the global-imports ? 
Isn't it the goal of the route-policy referenced earlier ? Moreover I do not 
think that it is a good idea to use the enum type here as protocol names ,when 
referring to, should not change across all routing configurations within a node.

-  Export to global may also require a policy to filter

-  Some description fields are just "."

-  How do you plan the tunnel policy to be used ?

-  Would be great to have RTs configurable for both IPv4/IPv6 without 
redefining the config for each address family.

-  While I think the "forwarding-mode" under interface is a good thing, 
it looks really a Cisco like config statement that other implementations do not 
have. Wouldn't it be better  to have a knob to enable mpls packet processing on 
an interface ; maybe in the MPLS yang model ?

-   What is the goal of the "route-policy" within 
"retain-route-targets" under the BGP peer AFI/SAFI ? I usually two use case 
(auto policy => import RTs are derived from VRF configuration, or keep all), 
what is the use case you want to address here ?

-  What is the "vpn-prefix-limit" within "retain-route-targets" under 
the BGP peer AFI/SAFI ? Is it a generic BGP prefix-limit ? If yes, we need to 
keep it generic within the BGP model.

-  IMO, the label mode should sit within the VRF and not at the BGP 
level. Each VRF may have a different flavor.

-  Why do you define bgp-label-mode and routing-table-limit for ipv4 
unicast and ipv6 unicast ? Does not seem to be L3VPN related.

-  For iBGP PE-CE, notion of independent domain with attr-set usage 
seems to miss in the model

-  Unequal cost path loadbalancing option is missing from the VRF config

-  Do we need a config statement to enable local import/export between 
local VRFs ?

-  I suppose that IGP/BGP configuration in VRF is inherited from core 
routing model.

-  Do you have to enrich routing policy model with ability to 
set/delete/match RTs, SoOs ?

-  Do we have to create/enrich RIB-in/RIB-out/Loc-RIB entries for BGP 
L3VPN prefixes ?

-  What about PIC Edge/PE-CE link protection configuration ?

-  Need notification for the route table limit alert

-  Do we have operational states with number of IPv4 and IPv6 routes 
within the instance ?

-  Do we have everything to support Carrier's of Carrier case ?


Brgds,

Stephane


_

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] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop

[Jeffrey (Zhaohui) Zhang]

Hi Ashutosh,

Sorry for the late response. Please see zzh> below.

From: Ashutosh Gupta 
mailto:ashutoshgupta.i...@gmail.com>>
Sent: Wednesday, August 15, 2018 3:57 AM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>
Cc: Ali Sajassi mailto:saja...@cisco.com>>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop

Hey Jeffrey,

Thanks for your comments & please find my responses inline  .

On Fri, Jul 20, 2018 at 9:53 AM, Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>> wrote:
Hi Ali,

Here are the comments that I did not get a chance for in the meeting today.

Regarding "ttl decrement" and "src mac change":
--

Since "bridging/switching in the same BD" is not put down as a requirement in 
the spec but rather discounted citing "emulation", the listed "requirements" 
should be changed to "properties" as well - one could also argue that those may 
not be true requirements and could also discounted.

 seamless-Interop solution supports both intra-subnet and inter-subnet 
forwarding which are the basic requirement along with Efficient fabric 
utilization and Operational simplicity. More specifically, having many 
discussions with customers we didn't come across any use-case where strict 
intra-subnet bridging was needed along with inter-subnet routing, so we can 
argue that "strict bridging/switching in the same BD" is just an idealistic 
requirement.

Zzh> The point is, those “requirements” are really somewhat 
arbitrary/subjective. We have not heard real requirements about “seamless 
integration” either, and even when the requirement comes, the OISM can do that 
seamless integration by having every EVPN as an MEG.

Even if RFC7432 does not prove true ethernet service, "ttl decrement" and "src 
mac change" for intra-subnet traffic does NOT happen with RFC7432. In other 
words, this is a step-down from RFC7432.

 It is not a step down since we are not losing any needed functionality.

Zzh> It is a step down from what RFC7432 provides. The argument that TTL/mac 
change for intra-subnet is not an issue is subjective.

Again, seamless-interop solution utilizes existing and well deployed technology 
(MVPN) instead of re-defining all the constructs of MVPN into EVPN. 
evpn-irb-multicast draft takes later approach and achieves in-signification 
functionality gain at the expense of huge overhead in control-plane (Explained 
on a separate thread). From our customer interactions, we understand that 
Multicast is a complex technology to deploy, operate and troubleshoot. So any 
amount of simplification results in Opex reduction. Additionally, re-use of 
existing MVPN implementation for additional EVPN use-cases results in quick 
time-to-market with lower investment.

Zzh> Please see Eric’s comment on a separate thread. Both Eric and I are from 
MVPN background - trust us that we’d not be against “just use MVPN” if it 
solves EVPN problems effectively.
Zzh> BTW, with the seamless approach, aren’t you guys abandoning the SMET 
solution defined in draft-ietf-bess-evpn-igmp-mld-proxy?

About the comment "MVPN also decrements ttl and change src mac address" - 
that's expected behavior because it is routing between subnets not "intra 
subnet", and no application that uses MVPN service has assumption on constant 
TTL and src mac.

More regarding the "requirements" (or "properties")
---

With the other solution (evpn-irb-multicast, aka OISM), if every EVPN PE runs 
the MEG procedures then the same set of "requirements" is also achieved - it is 
also "seamless interop" but based on the OISM procedures, but that does not 
"translate into this method" (as defined in the seamless-interop draft) (I 
think that's what you mentioned when addressing Jorge's comment). What's more, 
it does not have the "ttl decrementing" and "src mac change" issue for intra 
subnet traffic.
 The point was made that once multicast traffic reaches MVPN domain, it 
doesn't belong to any specific BD and hence intra-subnet and inter-subnet 
receivers are treated similarly. Even with evpn-irb-multicast solution, it 
would be the same unless a second copy of traffic is send over BD specific 
tunnel.

Zzh> But for traffic reaching MVPN domain, we don’t need to worry about TTL and 
src mac address change, while we do need to worry about that on EVPN side in 
case of intra-subnet. Indeed separate copies are sent for EVPN and MVPN, but 
the MVPN copy is only when a remote MVPN PE is not also an EVPN PE. It’s hard 
to argue that removing that one extra MVPN copy (that is sent towards MVPN-only 
PEs) is a hard “requirement”.
Zzh&

Re: [bess] Comments on draft-ietf-bess-evpn-irb-mcast

[Eric C Rosen]

On 8/15/2018 4:07 AM, Ashutosh Gupta wrote:

Hi Folks,

I have following comments on draft-ietf-bess-evpn-irb-mcast. I also 
compare it to draft-sajassi-bess-evpn-mvpn-seamless-interop, which 
utilizes existing MVPN technology to achieve mcast-irb functionality 
in EVPN.



*1. Re-branding MVPN constructs into EVPN *
/evpn-irb/draft proposes a lot of MVPN constructs into EVPN. 
Originating multicast receiver interest "per PE"  instead of "per BD", 
use of selective tunnels are few examples. If solution really is 
achievable through MVPN, why do we need to re-brand it in EVPN?


As I and others have endeavored to explain in several messages to this 
list, the solution is not achievable by simply using MVPN routes and 
procedures.  Correct emulation of the ethernet muliticast service 
requires the addition of BD-specific information and procedures.  
Without this information, the distinction between "ES" and "BD" is 
lost.   This results in such problems as:


- Failure to correctly emulate ethernet behavior, and

- Inability to summarize routes on a per-subnet basis, thus requiring 
the MVPN PEs to be bombarded with host routes.


The seamless-mcast draft also severely underspecifies the behavior 
needed when interconnecting an EVPN domain to an MVPN domain that uses a 
different tunnel type, and does not appear to recognize either how 
common that scenario is, or how tricky it is to get that right.  (That's 
why the MVPN P-tunnel segmentation procedures are so intricate;  that's 
a whole area that seems to be ignored in the seamless-mcast draft.)


It's also worth reminding folks that 90% of EVPN is based on messages 
and procedures borrowed from L3VPN/MVPN, with the addition of 
information and procedures that are needed to do EVPN-specific things 
involving Ethernet Segments and Broadcast Domains.  This is certainly 
true of the EVPN procedures for advertising unicast IP routes, which do 
not "just use L3VPN".  The OISM proposal in the irb-mcast draft just 
follows along these lines.


Furthermore, it's worth noting that the so-called "seamless-mcast" draft 
has EVPN-specific procedures as well.  And more keep getting added as 
additional problems get discovered (e.g., the new intra-ES tunnels).   
It's very far from being "just use MVPN protocols as is".


Finally, one might also point out that the folks with the most in-depth 
knowledge of MVPN seem to be the least enthusiastic about the 
"seamless-mcast" draft.  Just saying ;-)


In the remainder of this message I want to focus on Ashutosh's 
criticisms of the OISM proposal (as we call the proposal in the 
irb-mcast draft).



*4. Data Plane considerations*
*
*
*4.1.* The data-plane nuances of solution has been underplayed. For 
example, if a PE1 has a (S, G) receivers in BD2, BD3 till BD10, 
whereas source S belongs in BD1 subnet on PE2. And if BD1 is not 
configured locally on PE1, a special BD (called SBD) is programmed as 
IIF in forwarding entry. Later if BD1 gets configured on PE1, it would 
cause IIF to change on PE1 from SBD to BD1.


So far correct.

This would result in traffic disruption for all existing receivers in 
BD2, BD3 till BD10.


The IIF in an (S,G) or (*,G) state can change at any time, due to 
distant (or not so distant) link failures, and/or due to other routing 
changes.  It changes whenever the UMH selection changes, and it changes 
if the ingress PE decides to move a flow from an I-PMSI to an S-PMSI.  
Of all the events that might cause a particular multicast state to 
change its IIF, the addition of a BD on the local PE does not seem to be 
one of the more frequent.


Some PIM implementations try to delay changing the IIF in a given (S,G) 
state until an (S,G) packet actually arrives from the new IIF.  However, 
such data-driven state changes introduce a lot of complexity.  MVPN has 
always tried to avoid data-driven state changes, and MVPN 
implementations will generally see some small amount of disruption when 
the IIF changes.  Methods for minimizing this are really an 
implementation matter.


In the case where a new BD is configured, there may be some risk of an 
(S,G) packet getting lost in the following situation:


- Time t0: The packet arrives and gets marked as being from the SBD.
- Time t1: The IIF changes from SBD to BD1
- Time t2: The packet is processed against the (S,G) state and discarded 
as having arrived from the wrong IIF


Given (a) how short the time t2-t0 is, (b) how infrequently new BDs get 
configured on a PE, and (c) the fact that there are many other causes of 
IIF changes, this does not seem like a real problem.  If it is regarded 
as a problem, resolving it would be an implementation matter.




*4.2. *Also, /evpn-irb/ solution proposes to relax the RPF check for a 
(*, G) multicast entry. This poses a great risk of traffic loops 
especially in transient network conditions in addition to poor 
debug-ability.


In the case where the receiving tenant systems ask for (*,G), and all 
the sources 

Re: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop

[Eric C Rosen]

Eric> 1. It seems that the proposal does not do correct ethernet 
emulation.  Intra-subnet multicast only sometimes preserves MAC SA and 
IP TTL, sometimes not, depending upon the topology.


Ali> EVPN doesn't provide LAN service per IEEE 802.1Q but rather an 
emulation of LAN service. This document defines what that emulation means


The fact that the proposal doesn't do correct ethernet emulation cannot 
be resolved by having the proposal redefine "emulation" to mean 
"whatever the proposal does".


EVPN needs to ensure that whatever works on a real ethernet will work on 
the emulated ethernet as well; the externally visible service 
characteristics on which the higher layers may depend must be properly 
offered by the emulation.  This applies to both unicast and multicast 
equally.


Otherwise anyone attempting to replace a real ethernet with EVPN will 
find that not every application and/or protocol working on the real 
ethernet will continue to work on the EVPN.


Eric> TTL handling for inter-subnet multicast seems inconsistent as 
well, depending upon the topology.


Ali> BTW, TTL handling for inter-subnet IP multicast traffic is done 
consistent!


Consider the following in a pure MVPN environment:

- Source S is on subnet1, which is attached to PE1.

- Receivers R1 and R2 are on subnet2, which is attached to both PE1 and PE2.

- Subnet1 and subnet2 are different subnets.

Now every (S,G) packet will follow the same path: either (a) 
subnet1-->PE1-->subnet2 or (b) subnet1-->PE1-->PE2-->subnet2.


Both paths cannot be used at the same time, because L3 multicast will 
not allow both PE1 and PE2 to transmit the (S,G) flow to subnet2.  So an 
(S,G) packet received by R1 will always have the same TTL as the same 
packet received by R2.  TTL scoping will therefore work consistently; 
depending on the routing, and from the perspective of any given flow, 
the two subnets are either one hop away from each other, or two hops 
away from each other.


In the so-called "seamless-mcast" scheme, on the other hand, if R1 and 
R2 get the same (S,G) packet, each may see a different TTL. Suppose R1 
is on an ES attached to PE1 but not to PE2, S is on an ES attached to 
PE1 but not to PE2, and R2 is on an ES attached to PE2 but not to PE1.  
Then a given (S,G) packet received by R1 will have a smaller TTL than 
the same packet received by R2, even though R1 and R2 are on the same 
subnet.


Note that the seamless-mcast proposal does not provide the behavior that 
would be provided by MVPN, despite the claim that it is "just MVPN".


This user-visible inconsistency may break any use of TTL scoping, and is 
just the sort of thing that tends generate a stream of service calls 
from customers that pay attention to this sort of stuff.


In general, TTL should be decremented by 0 for intra-subnet and by 1 
(within the EVPN domain) for inter-subnet.  Failure to handle the TTL 
decrement properly will break anything that depends upon RFC 3682 ("The 
Generalized TTL Security Mechanism").  Have you concluded that no use of 
multicast together with RFC 3682 will, now or in the future, ever need 
to run over EVPN?  I'd like to know how that conclusion is supported.  
You may also wish to do a google search for "multicast ttl scoping".


A related issue is that the number of PEs through which a packet passes 
should not be inferrable by a tenant.  Any sort of multicast traceroute 
tool used by a tenant will give unexpected results if TTL is not handled 
properly; at the very least this will result in service calls.


The OISM proposal (as described in the irb-mcast draft) will decrement 
TTL by 1 when packets go from one subnet to another, as an IP multicast 
frame is distributed unchanged to the PEs that need it, and its TTL is 
decremented by 1 if an egress PE needs to deliver it to a subnet other 
than its source subnet.



The draft still makes the following peculiar claim:

"Based on past experiences with MVPN over last dozen years for supported 
IP multicast applications, layer-3 forwarding of intra-subnet multicast 
traffic should be fine."


Since MVPN does not do intra-subnet multicast, experience with MVPN has 
no bearing whatsoever on the needs of intra-subnet multicast.


Eric> 2. In order to do inter-subnet multicast in EVPN, the proposal 
requires L3VPN/MVPN configuration on ALL the EVPN PEs.  This is required 
even when there is no need for MVPN/EVPN interworking. This is portrayed 
as a "low provisioning" solution!


Ali> Using MVPN constructs doesn't requires additional configuration on 
EVPN PEs beyond multicast configuration needed for IRB-mcast operation.


I think you'll find that if you don't reconfigure all the BGP sessions 
to carry AFI/SAFIs 1/128, 2/128, 1/5, and 2/5, you'll have quite a bit 
of trouble running any of the native MVPN procedures ;-) This is perhaps 
the simplest example of additional configuration that is needed.


If doing MVPN/EVPN interworking, one needs to go to every EVPN PE and 
set 

[bess] Comments on draft-ietf-bess-evpn-irb-mcast

[Ashutosh Gupta]

Hi Folks,

I have following comments on draft-ietf-bess-evpn-irb-mcast. I also compare
it to draft-sajassi-bess-evpn-mvpn-seamless-interop, which utilizes
existing MVPN technology to achieve mcast-irb functionality in EVPN.


*1. Re-branding MVPN constructs into EVPN *
*evpn-irb* draft proposes a lot of MVPN constructs into EVPN.
Originating multicast
receiver interest "per PE"  instead of "per BD", use of selective tunnels
are few examples. If solution really is achievable through MVPN, why do we
need to re-brand it in EVPN?


*2. Scale of BGP routes*
*evpn-irb* solution mandates a PE to process and store all IMET NLRI's from
all peer PE's in tenant domain (as opposed to processing and storing only
NLRI's for BD's it has locally present). This is proposed because multicast
traffic could be originating from any PE in any BD. To put this in
perspective, lets take an example of a tenant domain with 101 PE's with
each PE having 1000 BD's. Each PE has at most 10 BD's common with any other
PE in network. In this case PE1 will have to process and store, 100 (remote
PE's) x 1000 (BD's per PE) x 1 (IMET per BD) = 0.1 Million IMET routes.
Essentially, it is of order *"Num of BD's" x "Num of PE's"*.

Whereas for *seamless-interop* solution, a PE would need to process and
store 100 I-PMSI (IMET equivalent in MVPN) routes, means one route from
each peer PE. . This is of order *"num of PE's".* It should be noted that
VxLAN supports and max of ~16 million BD's thus *evpn-irb* solution results
in huge overhead per PE if compared with *seamless-interop*.


*3. Control plane scale in fabric / core *
Also each PE one additional Tunnel per BD apart from existing BUM tunnel.
Essentially one tunnel for B+U and another for M. This is proposed to avoid
all B+U traffic in the BD1, indiscriminately reaching all PE's in domain,
irrespective of whether they have BD1 configured locally or not. This
increases the state in fabric by *"num of PE" x "num of BD"*. In above
example it would again come to 0.1 Million additional tunnels.

*seamless-interop* solution uses one tunnel per PE, so 100 additional
tunnels to achieve same objective.


*4. Data Plane considerations*

*4.1.* The data-plane nuances of solution has been underplayed. For
example, if a PE1 has a (S, G) receivers in BD2, BD3 till BD10, whereas
source S belongs in BD1 subnet on PE2. And if BD1 is not configured locally
on PE1, a special BD (called SBD) is programmed as IIF in forwarding entry.
Later if BD1 gets configured on PE1, it would cause IIF to change on PE1
from SBD to BD1. This would result in traffic disruption for all existing
receivers in BD2, BD3 till BD10. It should be noted that no state changes
are observed in any of the receiver BD's. This is a significant drawback of
the solution given the latency requirement of applications running in
data-centers. Additionally, since host mobility and on-demand BD
configuration are critical functionalities for DC solutions, such case
can't be discounted.

*4.2. *Also, *evpn-irb* solution proposes to relax the RPF check for a (*,
G) multicast entry. This poses a great risk of traffic loops especially in
transient network conditions in addition to poor debug-ability.

*seamless-interop* solution doesn't possess these drawbacks and any BD
configuration or de-configuration wouldn't cause any change in existing
forwarding state.


In nutshell, even after borrowing MVPN constructs, *evpn-irb* solution
presents significant overhead in comparison to *seamless-interop* for
modern day data-center use-cases where flexible workload placement,
workload mobility and data-plane efficiency are critical features.

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

Re: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop

[Ashutosh Gupta]

Hey Jeffrey,

Thanks for your comments & please find my responses inline ** .

On Fri, Jul 20, 2018 at 9:53 AM, Jeffrey (Zhaohui) Zhang  wrote:

> Hi Ali,
>
> Here are the comments that I did not get a chance for in the meeting today.
>
> Regarding "ttl decrement" and "src mac change":
> --
>
> Since "bridging/switching in the same BD" is not put down as a requirement
> in the spec but rather discounted citing "emulation", the listed
> "requirements" should be changed to "properties" as well - one could also
> argue that those may not be true requirements and could also discounted.


** s*eamless-Interop* solution supports both intra-subnet and
inter-subnet forwarding which are the basic requirement along with
Efficient fabric utilization and Operational simplicity. More specifically,
having many discussions with customers we didn't come across any use-case
where strict intra-subnet bridging was needed along with inter-subnet
routing, so we can argue that "strict bridging/switching in the same BD" is
just an idealistic requirement.

>
>
Even if RFC7432 does not prove true ethernet service, "ttl decrement" and
> "src mac change" for intra-subnet traffic does NOT happen with RFC7432. In
> other words, this is a step-down from RFC7432.
>

** It is not a step down since we are not losing any needed
functionality. Again, *seamless-interop* solution utilizes existing and
well deployed technology (MVPN) instead of re-defining all the constructs
of MVPN into EVPN. *evpn-irb-multicast* draft takes later approach and
achieves in-signification functionality gain at the expense of huge
overhead in control-plane (Explained on a separate thread). From our
customer interactions, we understand that Multicast is a complex technology
to deploy, operate and troubleshoot. So any amount of simplification
results in Opex reduction. Additionally, re-use of existing MVPN
implementation for additional EVPN use-cases results in quick
time-to-market with lower investment.

About the comment "MVPN also decrements ttl and change src mac address" -
> that's expected behavior because it is routing between subnets not "intra
> subnet", and no application that uses MVPN service has assumption on
> constant TTL and src mac.
>
> More regarding the "requirements" (or "properties")
> ---
>
> With the other solution (evpn-irb-multicast, aka OISM), if every EVPN PE
> runs the MEG procedures then the same set of "requirements" is also
> achieved - it is also "seamless interop" but based on the OISM procedures,
> but that does not "translate into this method" (as defined in the 
> *seamless-interop
> *draft) (I think that's what you mentioned when addressing Jorge's
> comment). What's more, it does not have the "ttl decrementing" and "src mac
> change" issue for intra subnet traffic.
>
> * *The point was made that once multicast traffic reaches MVPN
domain, it doesn't belong to any specific BD and hence intra-subnet and
inter-subnet receivers are treated similarly. Even with *evpn-irb-multicast*
solution, it would be the same unless a second copy of traffic is send over
BD specific tunnel.

Regarding "9.  DCs with only EVPN PEs"


>
> For comparison, the OISM method does not need any provisioning/procedures
> related to RP and registering. That is a significant simplification that an
> EVPN-only operator should be aware of.
>
> * * Same functionality is achieved in *s**eamless-Interop* by
utilizing SPT-only mode of MVPN in which shared multicast trees are not
formed in the core.

Thanks.
> Jeffrey
>
>
> Regards,
Ashutosh


> ___
> 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] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop

[Jeffrey (Zhaohui) Zhang]

Hi Ali,

Here are the comments that I did not get a chance for in the meeting today.

Regarding "ttl decrement" and "src mac change":
--

Since "bridging/switching in the same BD" is not put down as a requirement in 
the spec but rather discounted citing "emulation", the listed "requirements" 
should be changed to "properties" as well - one could also argue that those may 
not be true requirements and could also discounted.

Even if RFC7432 does not prove true ethernet service, "ttl decrement" and "src 
mac change" for intra-subnet traffic does NOT happen with RFC7432. In other 
words, this is a step-down from RFC7432.

About the comment "MVPN also decrements ttl and change src mac address" - 
that's expected behavior because it is routing between subnets not "intra 
subnet", and no application that uses MVPN service has assumption on constant 
TTL and src mac.

More regarding the "requirements" (or "properties")
---

With the other solution (evpn-irb-multicast, aka OISM), if every EVPN PE runs 
the MEG procedures then the same set of "requirements" is also achieved - it is 
also "seamless interop" but based on the OISM procedures, but that does not 
"translate into this method" (as defined in the seamless-interop draft) (I 
think that's what you mentioned when addressing Jorge's comment). What's more, 
it does not have the "ttl decrementing" and "src mac change" issue for intra 
subnet traffic.

Regarding "9.  DCs with only EVPN PEs"


For comparison, the OISM method does not need any provisioning/procedures 
related to RP and registering. That is a significant simplification that an 
EVPN-only operator should be aware of.

Thanks.
Jeffrey


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

Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

[UTTARO, JAMES]

Jeff,

IMO, there is going to be a need for that the various flavors 
of SD-WAN to inter-operate with the current suite of network services with an 
emphasis on 2547.  May be best to approach this as we did with EVPN and create 
a requirements draft detailing what the need is.

Thanks,
Jim Uttaro

From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Tuesday, July 10, 2018 10:11 AM
To: UTTARO, JAMES ; Ron Bonica 
Cc: bess@ietf.org; RTGWG ; Eric Rosen ; 
Robert Raszuk ; Linda Dunbar 
Subject: Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Hi Jim,

This is a general statement applicable to overall SD-WAN effort.

Cheers,
Jeff

From: "UTTARO, JAMES" mailto:ju1...@att.com>>
Date: Tuesday, July 10, 2018 at 05:22
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>, 
Ron Bonica mailto:rbon...@juniper.net>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" 
mailto:bess@ietf.org>>, RTGWG 
mailto:rt...@ietf.org>>, Eric Rosen 
mailto:ero...@juniper.net>>, Robert Raszuk 
mailto:rob...@raszuk.net>>, Linda Dunbar 
mailto:linda.dun...@huawei.com>>
Subject: RE: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Jeff,

Comments In-Line..

Thanks,
Jim Uttaro

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, July 06, 2018 8:16 PM
To: Ron Bonica mailto:rbon...@juniper.net>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; RTGWG 
mailto:rt...@ietf.org>>; Eric Rosen 
mailto:ero...@juniper.net>>; Robert Raszuk 
mailto:rob...@raszuk.net>>; Linda Dunbar 
mailto:linda.dun...@huawei.com>>
Subject: Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

There are also many companies using EVPN as the control plane.
It is important to find a “golden middle” where on one side we achieve 
interoperability but on another don’t hinder the innovation in that, fast 
growing space.
[Jim U>] Is this specific to inter-operability with secure-l3vpn-01 or intended 
as a general statement in re interoperability with the 2547 ?
Data planes are a jungle and would not be standardized any time soon.
However - an abstraction on top would be very useful.

Regards,
Jeff

On Jul 6, 2018, at 14:23, Ron Bonica 
mailto:rbon...@juniper.net>> wrote:
+1

Let’s follow up on this discussion in Montreal.

From: Linda Dunbar mailto:linda.dun...@huawei.com>>
Sent: Friday, July 6, 2018 4:33 PM
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>; 
Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Ron Bonica mailto:rbon...@juniper.net>>; RTGWG 
mailto:rt...@ietf.org>>; Eric Rosen 
mailto:ero...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Jess,

Great Action! There are much more than the Data modeling.
A lot to be done in Control Plane. Many SD-WAN deployment (ours included) use 
NHRP/DMVPN/DSPVN to manage routes via internet. But NHRP being developed 
decades ago (for ATM) just doesn’t scale to support Managed Overlay network of 
100s or 1000s CPEs.

Linda

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, July 06, 2018 3:20 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Ron Bonica mailto:rbon...@juniper.net>>; RTGWG 
mailto:rt...@ietf.org>>; Eric Rosen 
mailto:ero...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>; Linda Dunbar 
mailto:linda.dun...@huawei.com>>
Subject: Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Robert/Linda,

RTGWG chairs have been thinking of starting SD-WAN discussion in RTGWG.
Service data modeling(data modeling in general)is an obvious candidate (at ONUG 
we started, there’s some early effort, but IETF help is needed).
Control plane interworking is another interesting topic.
Please bring your ideas, I’m still working on agenda

Regards,
Jeff

On Jul 6, 2018, at 13:12, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Hi Linda,

What you are expressing is very clear and in fact happens today on any good 
SD-WAN controller.

But in the context of this discussion are you bringing it here to suggest that 
draft-rosen-bess-secure-l3vpn should have such functionality build in ?

Personally I don't think it really belongs in this draft as perfect sweet spot 
for it still IMHO resides on a SD-WAN controller. Pushing all that logic into 
BGP may be a bit excessive ...

Many thx,
R.


On Fri, Jul 6, 2018 at 9:32 PM, Linda Dunbar 
mailto:linda.dun...@huawei.com>> wrote:
Ron,

This is referring to a Managed Overlay WAN services with many CPEs (large scale 
SD-WAN) and where

-there are many CPEs at each location and multiple WAN ports on each CPE

-SD-WAN Controller needs to detour a path between Site -A-&  Site-B via 
another site (e.

Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

[Jeff Tantsura]

Hi Jim,

 

This is a general statement applicable to overall SD-WAN effort.

 

Cheers,

Jeff

 

From: "UTTARO, JAMES" 
Date: Tuesday, July 10, 2018 at 05:22
To: Jeff Tantsura , Ron Bonica 
Cc: "bess@ietf.org" , RTGWG , Eric Rosen 
, Robert Raszuk , Linda Dunbar 

Subject: RE: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

 

Jeff,

 

Comments In-Line..

 

Thanks,

Jim Uttaro

 

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, July 06, 2018 8:16 PM
To: Ron Bonica 
Cc: bess@ietf.org; RTGWG ; Eric Rosen ; 
Robert Raszuk ; Linda Dunbar 
Subject: Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

 

There are also many companies using EVPN as the control plane.

It is important to find a “golden middle” where on one side we achieve 
interoperability but on another don’t hinder the innovation in that, fast 
growing space.

[Jim U>] Is this specific to inter-operability with secure-l3vpn-01 or intended 
as a general statement in re interoperability with the 2547 ?

Data planes are a jungle and would not be standardized any time soon.

However - an abstraction on top would be very useful.

 

Regards,

Jeff


On Jul 6, 2018, at 14:23, Ron Bonica  wrote:

+1

 

Let’s follow up on this discussion in Montreal.

 

From: Linda Dunbar  
Sent: Friday, July 6, 2018 4:33 PM
To: Jeff Tantsura ; Robert Raszuk 
Cc: Ron Bonica ; RTGWG ; Eric Rosen 
; bess@ietf.org
Subject: RE: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

 

Jess, 

 

Great Action! There are much more than the Data modeling. 

A lot to be done in Control Plane. Many SD-WAN deployment (ours included) use 
NHRP/DMVPN/DSPVN to manage routes via internet. But NHRP being developed 
decades ago (for ATM) just doesn’t scale to support Managed Overlay network of 
100s or 1000s CPEs. 

 

Linda

 

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, July 06, 2018 3:20 PM
To: Robert Raszuk 
Cc: Ron Bonica ; RTGWG ; Eric Rosen 
; bess@ietf.org; Linda Dunbar 
Subject: Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

 

Robert/Linda,

 

RTGWG chairs have been thinking of starting SD-WAN discussion in RTGWG.

Service data modeling(data modeling in general)is an obvious candidate (at ONUG 
we started, there’s some early effort, but IETF help is needed).

Control plane interworking is another interesting topic.

Please bring your ideas, I’m still working on agenda

 

Regards,

Jeff


On Jul 6, 2018, at 13:12, Robert Raszuk  wrote:

Hi Linda,

 

What you are expressing is very clear and in fact happens today on any good 
SD-WAN controller. 

 

But in the context of this discussion are you bringing it here to suggest that 
draft-rosen-bess-secure-l3vpn should have such functionality build in ? 

 

Personally I don't think it really belongs in this draft as perfect sweet spot 
for it still IMHO resides on a SD-WAN controller. Pushing all that logic into 
BGP may be a bit excessive ...

 

Many thx,

R.

 

 

On Fri, Jul 6, 2018 at 9:32 PM, Linda Dunbar  wrote:

Ron, 

 

This is referring to a Managed Overlay WAN services with many CPEs (large scale 
SD-WAN) and where 

-there are many CPEs at each location and multiple WAN ports on each CPE

-SD-WAN Controller needs to detour a path between Site -A-&  Site-B via 
another site (e.g. Site-C) for reasons like Performance, Regulatory,  or 
others. Instead of designating to specific CPE of the site-C. 

 

It is preferable to partition CPEs to clusters, as shown in the figure below:

 

 

Do I explain well? If not, can we talk face to face in Montreal?

 

Thanks, Linda Dunbar

 

From: Ron Bonica [mailto:rbon...@juniper.net] 
Sent: Friday, July 06, 2018 1:25 PM
To: Linda Dunbar ; Eric Rosen ; 
bess@ietf.org
Subject: RE: comments and suggestions to draft-rosen-bess-secure-l3vpn-01

 

Hi Linda,

 

I’m not sure that I understand what you mean when you say, “aggregate CPE-based 
VPN routes with internet routes that interconnect the CPEs”. Could you 
elaborate?

 

Ron

 

 

From: Linda Dunbar  
Sent: Thursday, July 5, 2018 11:53 AM
To: Eric Rosen ; Ron Bonica ; 
bess@ietf.org
Subject: comments and suggestions to draft-rosen-bess-secure-l3vpn-01

 

Eric and Ron, 

 

We think that the method described in your draft is useful for CPE based EVPN, 
especially for SD-WAN between CPEs.

But, it misses some aspects to aggregate CPE-based VPN routes with internet 
routes that interconnect the CPEs. 

 

Question to you: Would you like to expand your draft to cover the scenario of 
aggregating CPE-based VPN routes with internet routes that interconnect the 
CPEs?

 

If yes, we think the following areas are needed: 

 

•For RR communication with CPE, this draft only mentioned IPSEC. Are 
there any reasons that TLS/DTLS are not a

Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

[UTTARO, JAMES]

Jeff,

Comments In-Line..

Thanks,
Jim Uttaro

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, July 06, 2018 8:16 PM
To: Ron Bonica 
Cc: bess@ietf.org; RTGWG ; Eric Rosen ; 
Robert Raszuk ; Linda Dunbar 
Subject: Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

There are also many companies using EVPN as the control plane.
It is important to find a “golden middle” where on one side we achieve 
interoperability but on another don’t hinder the innovation in that, fast 
growing space.
[Jim U>] Is this specific to inter-operability with secure-l3vpn-01 or intended 
as a general statement in re interoperability with the 2547 ?
Data planes are a jungle and would not be standardized any time soon.
However - an abstraction on top would be very useful.

Regards,
Jeff

On Jul 6, 2018, at 14:23, Ron Bonica 
mailto:rbon...@juniper.net>> wrote:
+1

Let’s follow up on this discussion in Montreal.

From: Linda Dunbar mailto:linda.dun...@huawei.com>>
Sent: Friday, July 6, 2018 4:33 PM
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>; 
Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Ron Bonica mailto:rbon...@juniper.net>>; RTGWG 
mailto:rt...@ietf.org>>; Eric Rosen 
mailto:ero...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Jess,

Great Action! There are much more than the Data modeling.
A lot to be done in Control Plane. Many SD-WAN deployment (ours included) use 
NHRP/DMVPN/DSPVN to manage routes via internet. But NHRP being developed 
decades ago (for ATM) just doesn’t scale to support Managed Overlay network of 
100s or 1000s CPEs.

Linda

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, July 06, 2018 3:20 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Ron Bonica mailto:rbon...@juniper.net>>; RTGWG 
mailto:rt...@ietf.org>>; Eric Rosen 
mailto:ero...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>; Linda Dunbar 
mailto:linda.dun...@huawei.com>>
Subject: Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Robert/Linda,

RTGWG chairs have been thinking of starting SD-WAN discussion in RTGWG.
Service data modeling(data modeling in general)is an obvious candidate (at ONUG 
we started, there’s some early effort, but IETF help is needed).
Control plane interworking is another interesting topic.
Please bring your ideas, I’m still working on agenda

Regards,
Jeff

On Jul 6, 2018, at 13:12, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Hi Linda,

What you are expressing is very clear and in fact happens today on any good 
SD-WAN controller.

But in the context of this discussion are you bringing it here to suggest that 
draft-rosen-bess-secure-l3vpn should have such functionality build in ?

Personally I don't think it really belongs in this draft as perfect sweet spot 
for it still IMHO resides on a SD-WAN controller. Pushing all that logic into 
BGP may be a bit excessive ...

Many thx,
R.


On Fri, Jul 6, 2018 at 9:32 PM, Linda Dunbar 
mailto:linda.dun...@huawei.com>> wrote:
Ron,

This is referring to a Managed Overlay WAN services with many CPEs (large scale 
SD-WAN) and where

-there are many CPEs at each location and multiple WAN ports on each CPE

-SD-WAN Controller needs to detour a path between Site -A-&  Site-B via 
another site (e.g. Site-C) for reasons like Performance, Regulatory,  or 
others. Instead of designating to specific CPE of the site-C.

It is preferable to partition CPEs to clusters, as shown in the figure below:

[cid:image001..png@01D41536.30DC7AC0]

Do I explain well? If not, can we talk face to face in Montreal?

Thanks, Linda Dunbar

From: Ron Bonica [mailto:rbon...@juniper.net<mailto:rbon...@juniper.net>]
Sent: Friday, July 06, 2018 1:25 PM
To: Linda Dunbar mailto:linda.dun...@huawei.com>>; 
Eric Rosen mailto:ero...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Hi Linda,

I’m not sure that I understand what you mean when you say, “aggregate CPE-based 
VPN routes with internet routes that interconnect the CPEs”. Could you 
elaborate?

Ron


From: Linda Dunbar mailto:linda..dun...@huawei..com>>
Sent: Thursday, July 5, 2018 11:53 AM
To: Eric Rosen mailto:ero...@juniper.net>>; Ron Bonica 
mailto:rbon...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Eric and Ron,

We think that the method described in your draft is useful for CPE based EVPN, 
especially for SD-WAN between CPEs.
But, it misses some aspects to aggregate CPE-based VPN routes with internet 
routes that inter

Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

[Jeff Tantsura]

There are also many companies using EVPN as the control plane.
It is important to find a “golden middle” where on one side we achieve 
interoperability but on another don’t hinder the innovation in that, fast 
growing space.
Data planes are a jungle and would not be standardized any time soon.
However - an abstraction on top would be very useful.

Regards,
Jeff

> On Jul 6, 2018, at 14:23, Ron Bonica  wrote:
> 
> +1
>  
> Let’s follow up on this discussion in Montreal.
>  
> From: Linda Dunbar  
> Sent: Friday, July 6, 2018 4:33 PM
> To: Jeff Tantsura ; Robert Raszuk 
> Cc: Ron Bonica ; RTGWG ; Eric Rosen 
> ; bess@ietf.org
> Subject: RE: [bess] comments and suggestions to 
> draft-rosen-bess-secure-l3vpn-01
>  
> Jess,
>  
> Great Action! There are much more than the Data modeling.
> A lot to be done in Control Plane. Many SD-WAN deployment (ours included) use 
> NHRP/DMVPN/DSPVN to manage routes via internet. But NHRP being developed 
> decades ago (for ATM) just doesn’t scale to support Managed Overlay network 
> of 100s or 1000s CPEs.
>  
> Linda
>  
> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeff Tantsura
> Sent: Friday, July 06, 2018 3:20 PM
> To: Robert Raszuk 
> Cc: Ron Bonica ; RTGWG ; Eric Rosen 
> ; bess@ietf.org; Linda Dunbar 
> Subject: Re: [bess] comments and suggestions to 
> draft-rosen-bess-secure-l3vpn-01
>  
> Robert/Linda,
>  
> RTGWG chairs have been thinking of starting SD-WAN discussion in RTGWG.
> Service data modeling(data modeling in general)is an obvious candidate (at 
> ONUG we started, there’s some early effort, but IETF help is needed).
> Control plane interworking is another interesting topic.
> Please bring your ideas, I’m still working on agenda
>  
> 
> Regards,
> Jeff
> 
> On Jul 6, 2018, at 13:12, Robert Raszuk  wrote:
> 
> Hi Linda,
>  
> What you are expressing is very clear and in fact happens today on any good 
> SD-WAN controller. 
>  
> But in the context of this discussion are you bringing it here to suggest 
> that draft-rosen-bess-secure-l3vpn should have such functionality build in ? 
>  
> Personally I don't think it really belongs in this draft as perfect sweet 
> spot for it still IMHO resides on a SD-WAN controller. Pushing all that logic 
> into BGP may be a bit excessive ...
>  
> Many thx,
> R.
>  
>  
> On Fri, Jul 6, 2018 at 9:32 PM, Linda Dunbar  wrote:
> Ron,
>  
> This is referring to a Managed Overlay WAN services with many CPEs (large 
> scale SD-WAN) and where
> -there are many CPEs at each location and multiple WAN ports on each 
> CPE
> 
> -SD-WAN Controller needs to detour a path between Site -A-&  Site-B 
> via another site (e.g. Site-C) for reasons like Performance, Regulatory,  or 
> others. Instead of designating to specific CPE of the site-C.
> 
>  
> It is preferable to partition CPEs to clusters, as shown in the figure below:
>  
> 
>  
> Do I explain well? If not, can we talk face to face in Montreal?
>  
> Thanks, Linda Dunbar
>  
> From: Ron Bonica [mailto:rbon...@juniper.net] 
> Sent: Friday, July 06, 2018 1:25 PM
> To: Linda Dunbar ; Eric Rosen ; 
> bess@ietf.org
> Subject: RE: comments and suggestions to draft-rosen-bess-secure-l3vpn-01
>  
> Hi Linda,
>  
> I’m not sure that I understand what you mean when you say, “aggregate 
> CPE-based VPN routes with internet routes that interconnect the CPEs”. Could 
> you elaborate?
>  
> Ron
>  
>  
> From: Linda Dunbar  
> Sent: Thursday, July 5, 2018 11:53 AM
> To: Eric Rosen ; Ron Bonica ; 
> bess@ietf.org
> Subject: comments and suggestions to draft-rosen-bess-secure-l3vpn-01
>  
> Eric and Ron,
>  
> We think that the method described in your draft is useful for CPE based 
> EVPN, especially for SD-WAN between CPEs.
> But, it misses some aspects to aggregate CPE-based VPN routes with internet 
> routes that interconnect the CPEs.
>  
> Question to you: Would you like to expand your draft to cover the scenario of 
> aggregating CPE-based VPN routes with internet routes that interconnect the 
> CPEs?
>  
> If yes, we think the following areas are needed:
>  
> •For RR communication with CPE, this draft only mentioned IPSEC. Are 
> there any reasons that TLS/DTLS are not added? 
> 
> •The draft assumes that C-PE “register” with the RR. But it doesn’t 
> say how. Should “NHRP” (modified version) be considered?
> 
> •It assumes that C-PE and RR are connected by IPsec tunnel.. With 
> zero touch provisioning, we need an automatic way to synchronize the IPSec SA 
> between C-PE and RR. The draft assume

Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

[Ron Bonica]

+1

Let’s follow up on this discussion in Montreal.

From: Linda Dunbar 
Sent: Friday, July 6, 2018 4:33 PM
To: Jeff Tantsura ; Robert Raszuk 
Cc: Ron Bonica ; RTGWG ; Eric Rosen 
; bess@ietf.org
Subject: RE: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Jess,

Great Action! There are much more than the Data modeling.
A lot to be done in Control Plane. Many SD-WAN deployment (ours included) use 
NHRP/DMVPN/DSPVN to manage routes via internet. But NHRP being developed 
decades ago (for ATM) just doesn’t scale to support Managed Overlay network of 
100s or 1000s CPEs.

Linda

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, July 06, 2018 3:20 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Ron Bonica mailto:rbon...@juniper.net>>; RTGWG 
mailto:rt...@ietf.org>>; Eric Rosen 
mailto:ero...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>; Linda Dunbar 
mailto:linda.dun...@huawei.com>>
Subject: Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Robert/Linda,

RTGWG chairs have been thinking of starting SD-WAN discussion in RTGWG.
Service data modeling(data modeling in general)is an obvious candidate (at ONUG 
we started, there’s some early effort, but IETF help is needed).
Control plane interworking is another interesting topic.
Please bring your ideas, I’m still working on agenda

Regards,
Jeff

On Jul 6, 2018, at 13:12, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Hi Linda,

What you are expressing is very clear and in fact happens today on any good 
SD-WAN controller.

But in the context of this discussion are you bringing it here to suggest that 
draft-rosen-bess-secure-l3vpn should have such functionality build in ?

Personally I don't think it really belongs in this draft as perfect sweet spot 
for it still IMHO resides on a SD-WAN controller. Pushing all that logic into 
BGP may be a bit excessive ...

Many thx,
R.


On Fri, Jul 6, 2018 at 9:32 PM, Linda Dunbar 
mailto:linda.dun...@huawei.com>> wrote:
Ron,

This is referring to a Managed Overlay WAN services with many CPEs (large scale 
SD-WAN) and where

-there are many CPEs at each location and multiple WAN ports on each CPE

-SD-WAN Controller needs to detour a path between Site -A-&  Site-B via 
another site (e.g. Site-C) for reasons like Performance, Regulatory,  or 
others. Instead of designating to specific CPE of the site-C.

It is preferable to partition CPEs to clusters, as shown in the figure below:

[cid:image001..png@01D41536.30DC7AC0]

Do I explain well? If not, can we talk face to face in Montreal?

Thanks, Linda Dunbar

From: Ron Bonica [mailto:rbon...@juniper.net<mailto:rbon...@juniper.net>]
Sent: Friday, July 06, 2018 1:25 PM
To: Linda Dunbar mailto:linda.dun...@huawei.com>>; 
Eric Rosen mailto:ero...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Hi Linda,

I’m not sure that I understand what you mean when you say, “aggregate CPE-based 
VPN routes with internet routes that interconnect the CPEs”. Could you 
elaborate?

Ron


From: Linda Dunbar mailto:linda..dun...@huawei.com>>
Sent: Thursday, July 5, 2018 11:53 AM
To: Eric Rosen mailto:ero...@juniper.net>>; Ron Bonica 
mailto:rbon...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Eric and Ron,

We think that the method described in your draft is useful for CPE based EVPN, 
especially for SD-WAN between CPEs.
But, it misses some aspects to aggregate CPE-based VPN routes with internet 
routes that interconnect the CPEs.

Question to you: Would you like to expand your draft to cover the scenario of 
aggregating CPE-based VPN routes with internet routes that interconnect the 
CPEs?

If yes, we think the following areas are needed:


•For RR communication with CPE, this draft only mentioned IPSEC. Are 
there any reasons that TLS/DTLS are not added?

•The draft assumes that C-PE “register” with the RR. But it doesn’t say 
how. Should “NHRP” (modified version) be considered?

•It assumes that C-PE and RR are connected by IPsec tunnel. With zero 
touch provisioning, we need an automatic way to synchronize the IPSec SA 
between C-PE and RR. The draft assumes:

•  A C-PE must also be provisioned with whatever additional information is 
needed in order to set up an IPsec SA with each of the red RRs

•IPsec requires periodic refreshment of the keys. How to synchronize 
the refreshment among multiple nodes?

•IPsec usually only send configuration parameters to two end points and 
let the two end points to negotiate the KEY. Now we assume that RR is 
responsible for creating the KEY for all end points. When one end point is 
confiscated, al

Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

[Linda Dunbar]

Jess,

Great Action! There are much more than the Data modeling.
A lot to be done in Control Plane. Many SD-WAN deployment (ours included) use 
NHRP/DMVPN/DSPVN to manage routes via internet. But NHRP being developed 
decades ago (for ATM) just doesn’t scale to support Managed Overlay network of 
100s or 1000s CPEs.

Linda

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, July 06, 2018 3:20 PM
To: Robert Raszuk 
Cc: Ron Bonica ; RTGWG ; Eric Rosen 
; bess@ietf.org; Linda Dunbar 
Subject: Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Robert/Linda,

RTGWG chairs have been thinking of starting SD-WAN discussion in RTGWG.
Service data modeling(data modeling in general)is an obvious candidate (at ONUG 
we started, there’s some early effort, but IETF help is needed).
Control plane interworking is another interesting topic.
Please bring your ideas, I’m still working on agenda

Regards,
Jeff

On Jul 6, 2018, at 13:12, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Hi Linda,

What you are expressing is very clear and in fact happens today on any good 
SD-WAN controller.

But in the context of this discussion are you bringing it here to suggest that 
draft-rosen-bess-secure-l3vpn should have such functionality build in ?

Personally I don't think it really belongs in this draft as perfect sweet spot 
for it still IMHO resides on a SD-WAN controller. Pushing all that logic into 
BGP may be a bit excessive ...

Many thx,
R.


On Fri, Jul 6, 2018 at 9:32 PM, Linda Dunbar 
mailto:linda.dun...@huawei.com>> wrote:
Ron,

This is referring to a Managed Overlay WAN services with many CPEs (large scale 
SD-WAN) and where

-there are many CPEs at each location and multiple WAN ports on each CPE

-SD-WAN Controller needs to detour a path between Site -A-&  Site-B via 
another site (e.g. Site-C) for reasons like Performance, Regulatory,  or 
others. Instead of designating to specific CPE of the site-C.

It is preferable to partition CPEs to clusters, as shown in the figure below:

[cid:image001..png@01D41536.30DC7AC0]

Do I explain well? If not, can we talk face to face in Montreal?

Thanks, Linda Dunbar

From: Ron Bonica [mailto:rbon...@juniper.net<mailto:rbon...@juniper.net>]
Sent: Friday, July 06, 2018 1:25 PM
To: Linda Dunbar mailto:linda.dun...@huawei.com>>; 
Eric Rosen mailto:ero...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Hi Linda,

I’m not sure that I understand what you mean when you say, “aggregate CPE-based 
VPN routes with internet routes that interconnect the CPEs”. Could you 
elaborate?

Ron


From: Linda Dunbar mailto:linda..dun...@huawei.com>>
Sent: Thursday, July 5, 2018 11:53 AM
To: Eric Rosen mailto:ero...@juniper.net>>; Ron Bonica 
mailto:rbon...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Eric and Ron,

We think that the method described in your draft is useful for CPE based EVPN, 
especially for SD-WAN between CPEs.
But, it misses some aspects to aggregate CPE-based VPN routes with internet 
routes that interconnect the CPEs.

Question to you: Would you like to expand your draft to cover the scenario of 
aggregating CPE-based VPN routes with internet routes that interconnect the 
CPEs?

If yes, we think the following areas are needed:


•For RR communication with CPE, this draft only mentioned IPSEC. Are 
there any reasons that TLS/DTLS are not added?

•The draft assumes that C-PE “register” with the RR. But it doesn’t say 
how. Should “NHRP” (modified version) be considered?

•It assumes that C-PE and RR are connected by IPsec tunnel. With zero 
touch provisioning, we need an automatic way to synchronize the IPSec SA 
between C-PE and RR. The draft assumes:

•  A C-PE must also be provisioned with whatever additional information is 
needed in order to set up an IPsec SA with each of the red RRs

•IPsec requires periodic refreshment of the keys. How to synchronize 
the refreshment among multiple nodes?

•IPsec usually only send configuration parameters to two end points and 
let the two end points to negotiate the KEY. Now we assume that RR is 
responsible for creating the KEY for all end points. When one end point is 
confiscated, all other connections are impacted.

If you are open to expand your draft to cover SD-WAN, we can help providing the 
sections to address the bullets mentioned above.

We have a draft analyzing the technological gaps when using SD-WAN to 
interconnect workloads & apps hosted in various locations: 
https://datatracker.ietf.org/doc/draft-dm-net2cloud-gap-analysis/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Ddm-2Dnet2cloud-2Dgap-2Da

Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

[Jeff Tantsura]

Robert/Linda,

RTGWG chairs have been thinking of starting SD-WAN discussion in RTGWG.
Service data modeling(data modeling in general)is an obvious candidate (at ONUG 
we started, there’s some early effort, but IETF help is needed).
Control plane interworking is another interesting topic.
Please bring your ideas, I’m still working on agenda


Regards,
Jeff

> On Jul 6, 2018, at 13:12, Robert Raszuk  wrote:
> 
> Hi Linda,
> 
> What you are expressing is very clear and in fact happens today on any good 
> SD-WAN controller. 
> 
> But in the context of this discussion are you bringing it here to suggest 
> that draft-rosen-bess-secure-l3vpn should have such functionality build in ? 
> 
> Personally I don't think it really belongs in this draft as perfect sweet 
> spot for it still IMHO resides on a SD-WAN controller. Pushing all that logic 
> into BGP may be a bit excessive ...
> 
> Many thx,
> R.
> 
> 
>> On Fri, Jul 6, 2018 at 9:32 PM, Linda Dunbar  wrote:
>> Ron,
>> 
>>  
>> 
>> This is referring to a Managed Overlay WAN services with many CPEs (large 
>> scale SD-WAN) and where
>> 
>> -there are many CPEs at each location and multiple WAN ports on each 
>> CPE
>> 
>> -SD-WAN Controller needs to detour a path between Site -A-&  Site-B 
>> via another site (e.g. Site-C) for reasons like Performance, Regulatory,  or 
>> others. Instead of designating to specific CPE of the site-C.
>> 
>>  
>> 
>> It is preferable to partition CPEs to clusters, as shown in the figure below:
>> 
>>  
>> 
>> 
>> 
>>  
>> 
>> Do I explain well? If not, can we talk face to face in Montreal?
>> 
>>  
>> 
>> Thanks, Linda Dunbar
>> 
>>  
>> 
>> From: Ron Bonica [mailto:rbon...@juniper.net] 
>> Sent: Friday, July 06, 2018 1:25 PM
>> To: Linda Dunbar ; Eric Rosen ; 
>> bess@ietf.org
>> Subject: RE: comments and suggestions to draft-rosen-bess-secure-l3vpn-01
>> 
>>  
>> 
>> Hi Linda,
>> 
>>  
>> 
>> I’m not sure that I understand what you mean when you say, “aggregate 
>> CPE-based VPN routes with internet routes that interconnect the CPEs”. Could 
>> you elaborate?
>> 
>>  
>> 
>> Ron
>> 
>>  
>> 
>>  
>> 
>> From: Linda Dunbar  
>> Sent: Thursday, July 5, 2018 11:53 AM
>> To: Eric Rosen ; Ron Bonica ; 
>> bess@ietf.org
>> Subject: comments and suggestions to draft-rosen-bess-secure-l3vpn-01
>> 
>>  
>> 
>> Eric and Ron,
>> 
>>  
>> 
>> We think that the method described in your draft is useful for CPE based 
>> EVPN, especially for SD-WAN between CPEs.
>> 
>> But, it misses some aspects to aggregate CPE-based VPN routes with internet 
>> routes that interconnect the CPEs.
>> 
>>  
>> 
>> Question to you: Would you like to expand your draft to cover the scenario 
>> of aggregating CPE-based VPN routes with internet routes that interconnect 
>> the CPEs?
>> 
>>  
>> 
>> If yes, we think the following areas are needed:
>> 
>>  
>> 
>> •For RR communication with CPE, this draft only mentioned IPSEC. Are 
>> there any reasons that TLS/DTLS are not added? 
>> 
>> •The draft assumes that C-PE “register” with the RR. But it doesn’t 
>> say how. Should “NHRP” (modified version) be considered?
>> 
>> •It assumes that C-PE and RR are connected by IPsec tunnel. With 
>> zero touch provisioning, we need an automatic way to synchronize the IPSec 
>> SA between C-PE and RR. The draft assumes:
>> 
>> p  A C-PE must also be provisioned with whatever additional information is 
>> needed in order to set up an IPsec SA with each of the red RRs
>> 
>> •IPsec requires periodic refreshment of the keys. How to synchronize 
>> the refreshment among multiple nodes?
>> 
>> •IPsec usually only send configuration parameters to two end points 
>> and let the two end points to negotiate the KEY. Now we assume that RR is 
>> responsible for creating the KEY for all end points. When one end point is 
>> confiscated, all other connections are impacted.
>> 
>>  
>> 
>> If you are open to expand your draft to cover SD-WAN, we can help providing 
>> the sections to address the bullets mentioned above.
>> 
>>  
>> 
>> We have a draft analyzing the technological gaps when using SD-WAN to 
>> interconnect workloads & apps hosted in various locations: 
>> https://datatracker.ietf.org/doc/draft-dm-net2cloud-gap-analysis/
>> 
>> Appreciate your comments and suggestions to our gap analysis.
>> 
>>  
>> 
>>  
>> 
>> Thanks, Linda Dunbar
>> 
>>  
>> 
>> 
>> ___
>> 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] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

[Linda Dunbar]

Eric and Ron,

We think that the method described in your draft is useful for CPE based EVPN, 
especially for SD-WAN between CPEs.
But, it misses some aspects to aggregate CPE-based VPN routes with internet 
routes that interconnect the CPEs.

Question to you: Would you like to expand your draft to cover the scenario of 
aggregating CPE-based VPN routes with internet routes that interconnect the 
CPEs?

If yes, we think the following areas are needed:


*For RR communication with CPE, this draft only mentioned IPSEC. Are 
there any reasons that TLS/DTLS are not added?

*The draft assumes that C-PE "register" with the RR. But it doesn't say 
how. Should "NHRP" (modified version) be considered?

*It assumes that C-PE and RR are connected by IPsec tunnel. With zero 
touch provisioning, we need an automatic way to synchronize the IPSec SA 
between C-PE and RR. The draft assumes:

p  A C-PE must also be provisioned with whatever additional information is 
needed in order to set up an IPsec SA with each of the red RRs

*IPsec requires periodic refreshment of the keys. How to synchronize 
the refreshment among multiple nodes?

*IPsec usually only send configuration parameters to two end points and 
let the two end points to negotiate the KEY. Now we assume that RR is 
responsible for creating the KEY for all end points. When one end point is 
confiscated, all other connections are impacted.

If you are open to expand your draft to cover SD-WAN, we can help providing the 
sections to address the bullets mentioned above.

We have a draft analyzing the technological gaps when using SD-WAN to 
interconnect workloads & apps hosted in various locations: 
https://datatracker.ietf.org/doc/draft-dm-net2cloud-gap-analysis/
Appreciate your comments and suggestions to our gap analysis.


Thanks, Linda Dunbar

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

Re: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop

[Ali Sajassi (sajassi)]

Eric, 

Please see my responses to your comments inline marked w/ "Ali>"

On 11/9/17, 9:42 AM, "BESS on behalf of Eric C Rosen"  wrote:

I have a number of comments on 
draft-sajassi-bess-evpn-mvpn-seamless-interop.

1. It seems that the proposal does not do correct ethernet emulation.  
Intra-subnet multicast only sometimes preserves MAC SA and IP TTL, 
sometimes not, depending upon the topology.  TTL handling for 
inter-subnet multicast seems inconsistent as well, depending upon the 
topology.  The proposal exposes the operator's internal network 
structure to the user, and will cause "LAN-only" applications to break.  
These concerns are acknowledged, then quickly dismissed based on wishful 
thinking.  (In my experience, wishful thinking doesn't work out very 
well in routing.)

Ali> EVPN doesn't provide LAN service per IEEE 802.1Q but rather an emulation 
of LAN service. This document defines what that emulation means wrt IP multicat 
traffic for intra-subnet & inter-subnet IP multicast traffic. I added section 
5.1 to expand on that. BTW, TTL handling for inter-subnet IP multicast traffic 
is done consistent!

2. In order to do inter-subnet multicast in EVPN, the proposal requires 
L3VPN/MVPN configuration on ALL the EVPN PEs.  This is required even 
when there is no need for MVPN/EVPN interworking. This is portrayed as a 
"low provisioning" solution!

Ali> Using MVPN constructs doesn't requires additional configuration on EVPN 
PEs beyond multicast configuration needed for IRB-mcast operation. 

3. The draft claims that the exact same control plane should be used for 
EVPN and MVPN, despite the fact that MVPN's control plane is unaware of 
certain information that is very important in EVPN (e.g., EVIs, 
TagIDs).  (This is largely responsible for point 1 above.) This is 
claimed to be a way of providing a "uniform solution".  As we examine 
the problems that arise, perhaps this will be seen as more a case of 
"pounding square pegs into round holes".  When interworking between two 
domains, generally one gets a more flexible and robust scheme by 
maintaining clean interfaces and having well-defined points of 
attachment, not by entangling the internal protocols of one domain with 
the internal protocols of the other.

Ali>  IP multicast described in the draft is done at the tenant's level 
(IP-VRF) and not BD level !! So, BD level info such as tagIDs are not relevant. 

4. The draft proposes to use the same tunnels for MVPN and EVPN, i.e., 
to have tunnels that traverse both the MVPN and the EVPN domains.  
Various "requirements" are stated that seem to require this solution.  
Somewhere along the line it was realized that this requirement cannot be 
met if MVPN and EVPN do not use the same tunnel types.  So for this very 
common scenario, a completely different solution is proposed, that (a) 
tries to keep the EVPN control plane out of the MVPN domain, and vice 
versa, and (b) uses different tunnels in the two domains.  Perhaps the 
"requirements" that suggest using a single cross-domain tunnel are not 
really requirements!  And why would we want different solutions for 
different deployment scenarios?  Yes, the solution needs to handle all 
the use cases, but we don't want to look at the use cases one at a time 
and design a different solution for each one.

Ali> There are SPDCs with MPLS underlay and there are SPDCs with VxLAN 
underlay. We need a solution that is optimum for both. Just the same way that 
we need both ASBR and GWs to optimize connectivity for inter-AS scenarios.

While the authors have realized that one cannot have cross-domain 
tunnels when EVPN uses VxLAN and MVPN uses MPLS, they do not seem to 
have acknowledged the multitude of other scenarios in which cross-domain 
tunnels cannot be used.  For instance, MVPN may be using mLDP, while 
EVPN is using IR.  Or MVPN may be using RSVP-TE P2MP while EVPN is using 
AR.  Etc., etc.  I suspect that "different tunnel types" will be the 
common case, especially when trying to interwork existing MVPN and EVPN 
deployments.

Ali> This will be captured in the next rev. and that's why the need for both GW 
and ASBRs.

The inability to use EVPN-specific tunnels also causes a number of 
specific problems when attempting to interwork with MVPN; these will be 
examined below.


5. A number of the draft's stated "requirements" seem to be entirely bogus.

a. In some cases, the "requirements" for optimality in one or another 
respect (e.g., routing, replication) are really only considerations that 
an operator should be able to trade off against other considerations.  
The real requirement is to be able to create a deployment scenario in 
which such optimality is achievable.  Other deployment 

Re: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop-01

[Ali Sajassi (sajassi)]

Hi Jingrong,

Thanks for the comments. Please see my responses inline.

From: BESS  on behalf of Xiejingrong 

Date: Tuesday, June 19, 2018 at 7:38 PM
To: "bess@ietf.org" , 
"draft-sajassi-bess-evpn-mvpn-seamless-inte...@ietf.org" 

Subject: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop-01

Hi folks,
I have some comments on draft-sajassi-bess-evpn-mvpn-seamless-interop-01:

(1)For section 9.2.2 where it stated “The MPLS label in the PMSI Tunnel 
Attribute MUST be the Virtual Network Identifier (VNI) associated with the 
customer MVPN.”,

I think the VNI need not being included in ‘MPLS Label’ field of PTA, because 
every IP-VRF has a static configuration of the VNI value.

We need to have the VNI set properly in the PTA so that the upstream PE can 
signal to downstream PEs what is the association of the multicast tunnel and 
VPN instance.



(2)Some terminologies are lacking, for example CO and SPDC. I think they 
are different things, and authors can make clear about them.
Included them in the terminology section. If there are more, let me know.


(3)Some references are lacking, for example [EVPN-IRB] in section 5, and 
[EVPN-IRB-MCAST] in section 9.
Added them to section 14.


(4)There are two nodes named ‘PE3’ repeatedly in Figure 1 and Figure 2.
Corrected them.


(5)For section 7.1 where it use ‘Intra-subnet/Intra-ES’, I think the 
‘Intra-subnet’ is confusing and conflicting with general concepts as used in 
section 5.
I changed it from “Intra-subnet/Intra-ES” to only “Intra-ES”.

Thanks
Jingrong

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

[bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop-01

[Xiejingrong]

Hi folks,
I have some comments on draft-sajassi-bess-evpn-mvpn-seamless-interop-01:

(1) For section 9.2.2 where it stated "The MPLS label in the PMSI Tunnel 
Attribute MUST be the Virtual Network Identifier (VNI) associated with the 
customer MVPN.",

I think the VNI need not being included in 'MPLS Label' field of PTA, because 
every IP-VRF has a static configuration of the VNI value.

(2) Some terminologies are lacking, for example CO and SPDC. I think they 
are different things, and authors can make clear about them.

(3) Some references are lacking, for example [EVPN-IRB] in section 5, and 
[EVPN-IRB-MCAST] in section 9.

(4) There are two nodes named 'PE3' repeatedly in Figure 1 and Figure 2..

(5) For section 7.1 where it use 'Intra-subnet/Intra-ES', I think the 
'Intra-subnet' is confusing and conflicting with general concepts as used in 
section 5.

Thanks
Jingrong

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

Re: [bess] Comments on draft-ietf-bess-mvpn-expl-track-03

[Xiejingrong]

Fully understood, and -06 version is ok to me.
Thanks for Eric's patient explanation.
Thanks for Stephane also.
In MVPN using BIER Segmented Scenario, ABR needs Per-flow's VpnLabels to do 
further forwarding sticking, so that we can not use a SPMSI (*,*, PTA 

Re: [bess] Comments on draft-ietf-bess-mvpn-expl-track-03

[Eric C Rosen]

Thanks for delving into the details here.  This part of the writeup is 
very confusing (for which I have no one to blame but myself); I've tried 
to clarify in the -06 revision.


On 1/18/2018 9:51 PM, Xiejingrong wrote:


Issue clarification:

According to chap 5.2 of this document:

In a [IngressPE--EgressABR--EgressPE] topology, IngressPE send a 
Wildcard S-PMSI(*,*) route with PTA(flag), whose NLRI is 
donated as  SPMSI(type<0/1/2>RD,*,*,IngressPE).


This SPMSI route will be relayed by EgressABR to EgressPE with PTA 
flag untouched.




The flags are required to be left untouched only if the PTA specifies 
"no tunnel info".


Then EgressPE will generate ONE LeafAD route with 
NLRI(type<0/1/2>RD,*,*,IngressPE,EgressPE) and RT, and 
N(N>=0) LeafAD routes with 
NLRI(type<16/17/18>RD,S,G,IngressPE,EgressPE) and RT.


Then according to chap 5.3  of this document:

EgressABR will only send a Leaf A-D route.

I guess, the said “a Leaf A-D route” should be the ONE of 
LeafAD(type<0/1/2RD,*,*,IngressPE,EgressABR) with RT.


Then how should EgressABR deal with the the N(N>=0) LeafAD routes with 
NLRI(type<16/17/18>RD,S,G,IngressPE,EgressPE) and RT ?


It is not clarified in RFC7524 either. See chap 7.1 of RFC7524, which 
only clarify LeafAD route with type<0/1/2>RD.


Should such LeafAD route with type<16/17/18>RD be accepted and 
installed by EgressABR ?


And then ‘relay’ back to IngressPE, and thus enable IngressPE explicit 
tracking inside the ingress “segmentation domain” ?




EgressABR originates Leaf A-D routes of its own if and when it knows 
that it has downstream receivers that are interested in receiving flows 
from IngressPE.  It may originate more than one Leaf A-D route if LIR-pF 
is set in the S-PMSI A-D route's PTA.



Question clarification:

(1)Should such LeafAD routes with type<16/17/18>RD be accepted and 
installed by EgressABR ? This draft does not describe this.




If such routes carry EgressABR's import RT, and if their NLRIs match the 
NLRI of an S-PMSI A-D route installed by EgressABR, the Leaf A-D routes 
will be accepted and installed by EgressABR.  They are also relayed 
upstream (after changing the RT), as described in section 5.3.


(2)If the said Leaf A-D routes (with RD type 16/17/18) be installed by 
EgressABR, then according to your answer, the Leaf A-D routes (with RT 
changed) will be ‘relay’ back to IngressPE. Right?  This draft does 
not describe this either.


(3)If the above two are correct, then We can use 

Re: [bess] Comments on draft-ietf-bess-mvpn-expl-track-03

[stephane.litkowski]

Hi,

Please find below my understanding of the text.


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Xiejingrong
Sent: Friday, January 19, 2018 03:51
To: Eric C Rosen; bess@ietf.org
Subject: Re: [bess] Comments on draft-ietf-bess-mvpn-expl-track-03

Issue clarification:
According to chap 5.2 of this document:
In a [IngressPE--EgressABR--EgressPE] topology, IngressPE send a Wildcard 
S-PMSI(*,*) route with PTA(flag<LIR+LIR-pF>), whose NLRI is donated as  
SPMSI(type<0/1/2>RD,*,*,IngressPE).
This SPMSI route will be relayed by EgressABR to EgressPE with PTA flag 
untouched.
Then EgressPE will generate ONE LeafAD route with 
NLRI(type<0/1/2>RD,*,*,IngressPE,EgressPE) and RT, and N(N>=0) 
LeafAD routes with NLRI(type<16/17/18>RD,S,G,IngressPE,EgressPE) and 
RT.

[SLI] Chap 5.2 does not deal with ASBR/ABR case, it defines the behavior of the 
egress node (the egress PE). Chap 5.3 does.


Then according to chap 5.3  of this document:
EgressABR will only send a Leaf A-D route.
I guess, the said "a Leaf A-D route" should be the ONE of 
LeafAD(type<0/1/2RD,*,*,IngressPE,EgressABR) with RT.

Then how should EgressABR deal with the the N(N>=0) LeafAD routes with 
NLRI(type<16/17/18>RD,S,G,IngressPE,EgressPE) and RT ?
It is not clarified in RFC7524 either. See chap 7.1 of RFC7524, which only 
clarify LeafAD route with type<0/1/2>RD.
Should such LeafAD route with type<16/17/18>RD be accepted and installed by 
EgressABR ?
And then 'relay' back to IngressPE, and thus enable IngressPE explicit tracking 
inside the ingress "segmentation domain" ?


Question clarification:

(1) Should such LeafAD routes with type<16/17/18>RD be accepted and 
installed by EgressABR ?

[SLI] If the egress node (EgressPE) originates Leaf A-D routes in a response to 
a LIR-pF, it uses the new RD types. As the SPMSI best route uses the ABR/ASBR 
address as a NH, the Leaf-AD route will use an ip-address based RT using the 
ABR/ASBR address as a base. When receiving the BGP Update containing the Leaf 
A-D, the ASBR/ABR will automatically import the route thanks to the RT.



(2) If the said Leaf A-D routes (with RD type 16/17/18) be installed by 
EgressABR, then according to your answer, the Leaf A-D routes (with RT changed) 
will be 'relay' back to IngressPE. Right?  This draft does not describe this 
either.

[SLI] Yes the Leaf A-D route is forwarded and the RT is changed on the fly to 
the IngressPE address-specific RT. I think this does not change compared to the 
existing procedures from RFC6514.



(3) If the above two are correct, then We can use PTA

Re: [bess] Comments on draft-ietf-bess-mvpn-expl-track-03

[Eric C Rosen]

I apologize for the delay in answering this message.

On 12/21/2017 4:22 AM, Xiejingrong wrote:


I have a comment on draft-ietf-bess-mvpn-expl-track-03.

The chap 5.3 of this document said:

Furthermore, if the PTA specifies "no tunnel info", the LIR and LIR-pF

flags in the PTA MUST be passed along unchanged.

   This will ensure that an egress ABR/ASBR only sends a Leaf A-D route

   in response to a "match for tracking" if it is on the path to an

   egress PE for the flow(s) identified in the corresponding S-PMSI A-D

   route.

The issue is as follow:

In a [IngressPE--EgressABR--EgressPE] topology, IngressPE send a 
Wildcard S-PMSI(*,*) route with PTA(flag), whose NLRI is 
donated as  SPMSI(type<0/1/2>RD,*,*,IngressPE). This SPMSI route will 
be relayed by EgressABR to EgressPE with PTA flag untouched. Then 
EgressPE will generate ONE LeafAD route with 
NLRI(type<0/1/2>RD,*,*,IngressPE,EgressPE) and RT and 
N(N>=0) LeafAD routes with 
NLRI(type<16/17/18>RD,S,G,IngressPE,EgressPE) and RT. All 
according to chap 5.2 of this document.


Then according to chap 5.3  of this document:

IngressABR will only send a Leaf A-D route, It should be the ONE of 
LeafAD(type<0/1/2RD,*,*,IngressPE,EgressABR) with RT.




In the example above, there is an "EgressABR" but not an "IngressABR".  
So I'm not completely sure that I understand your question.


Then how should IngressABR deal with the the N(N>=0) LeafAD routes 
with NLRI(type<16/17/18>RD,S,G,IngressPE,EgressPE) and RT ?


It is not clarified in RFC7524 either. See chap 7.1 of RFC7524, which 
only clarify LeafAD route with type<0/1/2>RD.


Should such LeafAD route with type<16/17/18>RD be accepted and 
installed by EgressABR, and then ‘relay’ back to IngressPE, and thus 
enable IngressPE explicit tracking inside the ingress “segmentation 
domain” ?




The intention is the following.  Suppose an egress ABR/ASBR satisfies 
the following two conditions:


1. It has installed an S-PMSI A-D route  with the following properties:

- its NLRI has wildcards for S and G,
- its NLRI specifies PE1 as the ingress PE,
- its PTA specifies "no tunnel info" and has LIR-pF set.

2. It has installed one or more Leaf A-D routes whose NLRI specifies 
(S,G) with PE1 as ingress PE


Then the ABR/ASBR should originate a Leaf A-D route (with RD type 
16/17/18) specifying (S,G) with ingress PE1.
The Leaf A-D route would be withdrawn when one of these conditions no 
longer holds.


Does this answer your question?


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