[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 

Re: [bess] About draft-wang-bess-l3-accessible-evpn

[Linda Dunbar]

Wei,

You said
"we allocate one VNI for all customers in each MAN, and configure only one VRF 
on each PE, which can simplify the configuration work during deployment. On 
PEs,.."

Is the VNI for Customer A in MAN3 same as the VNI in MAN2 & MAN1?

You said "Only configure one VRF on each PE",  don't you need to configure the 
VRFs for all Customer A, B, C on each PE?

Linda Dunbar
On Tue, Mar 16, 2021 at 2:25 AM Wei Wang 
mailto:weiwan...@foxmail.com>> wrote:
Hi Gyan, Sergey, Patrice and Jorge,

In fact, we are considering the following scenario:
[cid:image001.png@01D71BFD.A03BABE0]
where Backbone is EVPN domain, and MAN1-3 are Layer-3 network. VNIs in MAN1-3 
are independently allocated, which may lead to the overlap of VNI in different 
customer sites.

If there are 3 customers who need cross domain networking: A, B, C.
In general, we allocate 3 VNIs for the 3 customers in each MAN, and configure 3 
VRFs on each PE to maintain the VPN routes of them.
In our solution, we allocate one VNI for all customers in each MAN, and 
configure only one VRF on each PE, which can simplify the configuration work 
during deployment. On PEs, the VRF can be divided into 3 sub-tables according 
to LSI information to maintain the VPN routes of customers.

To Gyan: in the two documents you mentioned, a device (Interworking PE / GW) is 
needed for routing conversion and redistribution, which is not needed in our 
solution.

Best Regards,
Wei
China Telecom

-- Original --
From: "Gyan Mishra" mailto:hayabusa...@gmail.com>>;
Date: Sun, Mar 14, 2021 10:18 AM
To: "Fomin, Sergey (Nokia - US/Mountain 
View)"mailto:sergey.fo...@nokia.com>>;
Cc: "Wei 
Wang"mailto:weiwan...@foxmail.com>>;"bess"mailto:bess@ietf.org>>;
Subject: Re: [bess] About draft-wang-bess-l3-accessible-evpn


Dear Authors

I am trying to understand the purpose of this document.

Is the goal for EVPN to be L3 accessible?

The way this has been done the past in a DC fabric environment using EVPN ESI 
single or all active multi home is from the DC fabric  from the Border leaf or 
Border spine that terminates the NVO3 overlay vxlan/vxlan-gpe/Geneve the DC 
core L3 box for DCI inter connect can act as a "fusion" router and terminate 
both tenant VRF and underlay peer and fuse the VRF overlay and global table 
underlay routing to provide access between overlay and underlay as well as 
external L3 reachability out of the fabric.  All the Type-2 Mac-IP and Type-5 
prefix can be converted imported as IPv4 AFI SAFI-1 so the Type-2 in SAFI-1 BGP 
RIB as host route and Type-5 shows as subnet prefix.

I am not sure if that is what you are trying to accomplish?


If you are trying to achieve EVPN to IPVPN interworking see draft below:

https://tools.ietf.org/html/draft-ietf-bess-evpn-ipvpn-interworking-02

DCI EVPN overlay

https://tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-10


Kind Regards

Gyan

On Fri, Mar 12, 2021 at 5:06 PM Fomin, Sergey (Nokia - US/Mountain View) 
mailto:sergey.fo...@nokia.com>> wrote:
Hi Wei,

This draft presents a peculiar way of bringing something similar to 
bridge-domain/bridge-table concepts into IP-VRFs..

One significant problem, in my opinion, is that you not only introduce a new 
dataplane dependency; but also propose to _redefine_ VXLAN-GPE header semantics 
(instead of just using it, or GENEVE). I would assume you have to go to nvo3 WG 
for the proposed VXLAN-GPE format changes (either with the full draft or 
splitting it into 2 parts (control & data plane)).

Additionally, I would like to see more text on the motivation of the proposed 
solution. In the abstract you make a point that "This draft ... proposes a new 
solution which can simplify the deployment of layer-3 accessible EVPN service." 
-> this simplicity is not obvious at all, and one may argue that this solution 
is more complex compared to the existing ones (such as draft 
inter-subnet-forwarding with multiple IP-VRFs)

--
Sergey

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Wei Wang
Sent: Friday, March 12, 2021 12:14 AM
To: linda.dunbar 
mailto:linda.dun...@futurewei.com>>; jorge.rabadan 

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with DISCUSS and COMMENT)

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

Hi Éric,

Thanks for this, it is very useful. Please see my comments in-line with [jorge].
We just published a revision, addressing yours and all the comments received in 
all the reviews.

Thanks again!
Jorge

From: Éric Vyncke via Datatracker 
Date: Thursday, January 21, 2021 at 3:13 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-proxy-arp...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Bocci, Matthew (Nokia - 
GB) , Bocci, Matthew (Nokia - GB) 
, jeanmichel.com...@orange.com 

Subject: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with 
DISCUSS and COMMENT)
Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-proxy-arp-nd-11: Discuss

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


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


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



--
DISCUSS:
--

Thank you for the work put into this document. This system could indeed be very
useful but I am afraid that this is a very complex system especially for IPv6
NDP.

Minor regret in the shepherd write-up as the WG summary did not include any
comment on the WG consensus.

Thanks to Jean-Michel Combes for its Internet directorate review at:
https://datatracker.ietf.org/doc/review-ietf-bess-evpn-proxy-arp-nd-11-intdir-telechat-combes-2021-01-20/
as Jean-Michel added some important comments, please review them as well as I
support them especially those around DAD that should be a blocking DISCUSS
point.

I also second Erik Kline's DISCUSS points.

Question to the authors and BESS WG chairs: was this document submitted to a
6MAN/V6OPS WGs review ? This is where all IPv6 experts live :-)

Please find below some blocking DISCUSS points, some non-blocking COMMENT
points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

Would RFC 8929 be enough to solve the problem ?
[jorge] I found RFC8929 an interesting reading, thanks for the reference. 
However, unless I’m missing something the use-case is very different.
It seems RFC8929 tries to reduce broadcast domains by using MLSNs where each 
link is its own broadcast domain. In EVPN BDs, the idea is reduce the control 
plane Broadcast/Multicast flooding among PEs of the same BD by replacing them 
with BGP EVPN routes. For ARP/ND, this basically means we learn at the ingress 
PE by snooping ARP/NAs and advertise the entries in EVPN MAC/IP routes so that 
the egress PE learns ARP/ND entries, and can reply to its local 
ARP-Requests/NS. Also in RFC8929, even for the bridging proxy, it seems that 
the proxy appears as an IPv6 host on the backbone, which is not the case in 
this document. Another difference is that the proxy in RFC8929 uses only ND 
messages to register bindings and in our document, we also use static entries 
and EVPN messages (in addition to snooped ARP and NA messages).
Please let me know if you see it otherwise.


-- Section 3 --
"A Proxy-ARP/ND implementation MAY support all those sub-functions or only a
subset of them.", I am afraid that it is mandatory that the reply and
duplicate-ip must be coupled: either both of them are active or none of them
are active else the system allows for duplicate IP addresses.
[jorge] the new text is as follows, let me know if it is okay. Note that the 
duplicate ip detection on the PEs is new in this document, and we didn’t want 
to make it mandatory we allow backwards compatibility with RFC7432 EVPN PEs 
that do proxy-ARP/ND.

   A Proxy-ARP/ND implementation MUST at least support the Learning,
   Reply and Maintenance sub-functions.  The following sections describe
   each individual sub-function.



-- Section 3.1 --
"A Proxy-ARP/ND implementation SHOULD support static, dynamic and EVPN-learned
entries." why not a MUST ? Or at least for dynamic & EVPN-learned ? or at least
one ?
[jorge] new text is as follows, let me know if it is ok:

   A Proxy-ARP/ND implementation in an EVPN BD MUST support dynamic and

   EVPN-learned entries, and SHOULD support static entries.



"Upon receiving traffic from the CE... the PE will activate the IP->MAC and
advertise it in EVPN" it is unspecified how many bindings can be advertised in
the case of multiple static MAC for one IP... only one or all ?
[jorge] good point, thx, changed it to:

Only in that case, the PE will activate the IP->MAC and advertise

   only that IP and MAC in an EVPN MAC/IP Advertisement route.



-- Section 3.2 --
Why not flooding to all other PEs the ARP/NS with unknown options ? It would be
safer.

[bess] I-D Action: draft-ietf-bess-evpn-proxy-arp-nd-12.txt

[internet-drafts]

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

Title   : Operational Aspects of Proxy-ARP/ND in Ethernet 
Virtual Private Networks
Authors : Jorge Rabadan
  Senthil Sathappan
  Kiran Nagaraj
  Greg Hankins
  Thomas King
Filename: draft-ietf-bess-evpn-proxy-arp-nd-12.txt
Pages   : 26
Date: 2021-03-18

Abstract:
   This document describes the Ethernet Virtual Private Networks (EVPN)
   Proxy-ARP/ND function, augmented by the capability of the ARP/ND
   Extended Community.  From that perspective this document updates the
   EVPN specification to provide more comprehensive documentation of the
   operation of the Proxy-ARP/ND function.  The EVPN Proxy-ARP/ND
   function and the ARP/ND Extended Community help operators of Internet
   Exchange Points, Data Centers, and other networks deal with IPv4 and
   IPv6 address resolution issues associated with large Broadcast
   Domains by reducing and even suppressing the flooding produced by
   address resolution in the EVPN network.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-proxy-arp-nd/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-evpn-proxy-arp-nd-12
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-proxy-arp-nd-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-proxy-arp-nd-12


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Re: [bess] About draft-wang-bess-l3-accessible-evpn

[Wei Wang]

Hi Gyan,


Thanks for your reply. Please see in-line [WW].


Best Regards,
Wei
-- Original --
From:   
 "Gyan Mishra"  
  
https://tools.ietf.org/html/draft-ietf-bess-evpn-ipvpn-interworking-02


DCI EVPN overlay 


https://tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-10




Kind Regards 


Gyan


On Fri, Mar 12, 2021 at 5:06 PM Fomin, Sergey (Nokia - US/Mountain View) 
https://datatracker.ietf.org/doc/html/draft-wang-bess-l3-accessible-evpn-04#section-6.1
 
  

 
  
Question 2, from Jorge Rabadan. "The ESI shouldn't be used to distinguish the 
route-type 5, it is mainly used for multi-homing purpose"
 
  
Answer: Currently, we are considering using two methods to identify the routes 
that associated different LSI:
 
  
   Method 1: Ethernet Tag ID, which is similar with its 
usage in layer 2 vlan environment.
 
  
   Method 2: Newly defined ESI type(type 6)
 
  

 
  
  We think both methods are approachable:
 
  
  Method 1 requires also the update of  
https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement-11(Ethernet
 Tag ID is set to 0 for route type 5), may arises some confuse with its 
original defintion.
 
  
  Method 2 requires the extension of ESI type (as described in:  
https://datatracker.ietf.org/doc/html/draft-wang-bess-l3-accessible-evpn-04#section-6.2).
 The original purpose of ESI (mulit-homing) can also be preserved.
 
 
  

 
  
  I hope the above explanations help.
 
  
  Comments and questions are always welcome.
 
  

 
  
Best Regards,
 
  
Wei
 
  
China Telecom
 
 
 
 ___
 BESS mailing list
 BESS@ietf.org
 https://www.ietf.org/mailman/listinfo/bess
 

-- 




Gyan Mishra

Network Solutions Architect 

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD












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

-- 




Gyan Mishra

Network Solutions Architect 

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD















Wei Wang
China Telecom___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess