Re: [bess] VXLAN BGP EVPN Question

Looks like it has been submitted for publication!!

https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/22/

Ready to drain the queue of drafts with normative references!!

Kind Regards

Gyan

On Sat, Apr 24, 2021 at 3:03 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:

> Completely understood for a standards specifications with normative
> dependencies.
>
> I think we are close to seeing light at the end of the tunnel for the
> encap draft.
>
> Kind Regards
>
> Gyan
>
> On Sat, Apr 24, 2021 at 2:57 PM Jeff Tantsura <jefftant.ietf@gmail.com>
> wrote:
>
>> Gyan,
>>
>> Normative references have to be at least at the same level of maturity as
>> the document referring. Just common sense. While it often creates rather
>> complex dependencies, it is a healthy precaution.
>>
>> Regards,
>> Jeff
>>
>> On Apr 24, 2021, at 10:14, Gyan Mishra <hayabusagsm@gmail.com> wrote:
>>
>> 
>>
>>
>> That’s fabulous news that everyone has implemented!!
>>
>> Unfortunate on the red tape with the turn around to RFC.
>>
>> Kind Regards
>>
>> Gyan
>>
>>
>> On Sat, Apr 24, 2021 at 8:29 AM John E Drake <jdrake@juniper.net> wrote:
>>
>> Yes, and everyone has implemented it.  Unfortunately, it had an
>>> inadvertent normative reference to the tunnel encapsulation attribute and
>>> hence has been in the RFC Editor queue for over three years.
>>>
>>>
>>>
>>> Yours Irrespectively,
>>>
>>>
>>>
>>> John
>>>
>>>
>>>
>>>
>>>
>>> Juniper Business Use Only
>>>
>>> *From:* Gyan Mishra <hayabusagsm@gmail.com>
>>> *Sent:* Friday, April 23, 2021 6:21 PM
>>> *To:* Ali Sajassi (sajassi) <sajassi@cisco.com>; BESS <bess@ietf.org>;
>>> Jeff Tantsura <jefftant.ietf@gmail.com>; John E Drake <
>>> jdrake@juniper.net>; Rabadan, Jorge (Nokia - US/Mountain View) <
>>> jorge.rabadan@nokia.com>
>>> *Subject:* Fwd: [bess] VXLAN BGP EVPN Question
>>>
>>>
>>>
>>> *[External Email. Be cautious of content]*
>>>
>>>
>>>
>>>
>>>
>>> Authors
>>>
>>>
>>>
>>> Do we know if this draft will progress to RFC?
>>>
>>>
>>>
>>> https://tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-10
>>> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-10__;!!NEt6yMaO-gk!Vg9pxTtcOdgw7cYL_Ze1TyY-pXZUmyMf3uJyvPslpcQNVpijlvjvRwzvkEMMBHM$>
>>>
>>>
>>>
>>>
>>>
>>> This is a very useful draft for intra DC multi pod NVO3 solutions with
>>> multiple vendors.
>>>
>>>
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>> Gyan
>>>
>>>
>>>
>>>
>>>
>>> ---------- Forwarded message ---------
>>> From: *Rabadan, Jorge (Nokia - US/Mountain View)* <
>>> jorge.rabadan@nokia.com>
>>> Date: Fri, Apr 24, 2020 at 3:07 AM
>>> Subject: Re: [bess] VXLAN BGP EVPN Question
>>> To: Gyan Mishra <hayabusagsm@gmail.com>, Jeff Tantsura <
>>> jefftant.ietf@gmail.com>
>>> CC: BESS <bess@ietf.org>
>>>
>>>
>>>
>>> Hi Gyan,
>>>
>>>
>>>
>>> If I may, note that:
>>>
>>>
>>> https://tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-10#section-4.6
>>> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-10*section-4.6__;Iw!!NEt6yMaO-gk!Vg9pxTtcOdgw7cYL_Ze1TyY-pXZUmyMf3uJyvPslpcQNVpijlvjvRwzvfKkPzi4$>
>>>
>>>
>>>
>>> Also provides vxlan segmentation, and while the description is based on
>>> DCI, you can perfectly use it for inter-pod connectivity.
>>>
>>>
>>>
>>> Thanks.
>>>
>>> Jorge
>>>
>>>
>>>
>>> *From: *BESS <bess-bounces@ietf.org> on behalf of Gyan Mishra <
>>> hayabusagsm@gmail.com>
>>> *Date: *Friday, April 24, 2020 at 5:21 AM
>>> *To: *Jeff Tantsura <jefftant.ietf@gmail.com>
>>> *Cc: *BESS <bess@ietf.org>
>>> *Subject: *Re: [bess] VXLAN BGP EVPN Question
>>>
>>>
>>>
>>>
>>>
>>> Hi Jeff
>>>
>>>
>>>
>>> Yes - Cisco has a draft for multi site for use cases capability of inter
>>> pod or inter site segmented path between desperate POD fabrics intra DC or
>>> as DCI option inter DC without MPLS.  The segmentation localizes BUM
>>> traffic and has border gateway DF election for BUM traffic that is
>>> segmented stitched between PODs as I mentioned similar to inter-as L3 vpn
>>> opt b.  There is a extra load as you said on the BGW border gateway
>>> performing the network vtep dencap from leaf and then again encap towards
>>> the egress border gateway.  Due to that extra load on the border gateway
>>> it’s not recommended to have spine function on BGW thus an extra layer for
>>> multi site to be scalable.  Definitely requires proprietary asic and not
>>> merchant silicon or white box solution.  The BUM traffic is much reduced as
>>> you stated from multi fabric connected super spine or single fabric spine
>>> that contains all leafs.  That decoupling sounds like incongruent control
>>> and data plane with Mac only Type 2 routes which would result in more BUM
>>> traffic  but it sounds like that maybe trade off of conversation learning
>>> only active flows versus entire data center wide Mac VRF being learned
>>> everywhere.  I wonder if their is an option to have that real decoupling of
>>> EVPN control plane and vxlan data plane overlay that does not impact
>>> convergence but adds stability and only active flow Type 2 Mac learner
>>> across the fabric.
>>>
>>>
>>>
>>> https://datatracker.ietf.org/doc/draft-sharma-multi-site-evpn/
>>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-sharma-multi-site-evpn/__;!!NEt6yMaO-gk!Vg9pxTtcOdgw7cYL_Ze1TyY-pXZUmyMf3uJyvPslpcQNVpijlvjvRwzvPV5PoSI$>
>>>
>>>
>>>
>>> Kind regards
>>>
>>>
>>>
>>> Gyan
>>>
>>>
>>>
>>> On Thu, Apr 23, 2020 at 6:04 PM Jeff Tantsura <jefftant.ietf@gmail.com>
>>> wrote:
>>>
>>> Gyan,
>>>
>>>
>>>
>>> "Multi site” is not really an IETF terminology, this is a solution
>>> implement by NX-OS, there’s a draft though. Its main functionality is to
>>> localize VxLAN tunnels and provide segmented path vs end2end full mesh of
>>> VxLAN tunnels (participating in the same EVI). We are talking HER here.
>>>
>>> The feature is heavily HW dependent as it requires BUM re-encapsulation
>>> at the boundaries (leaf1->BGW1-BGW2->leaf2..n). So good luck seeing it soon
>>> on low end silicon.
>>>
>>> It doesn’t eliminate BUM traffic but significantly reduces the span of
>>> “broadcast domain” and reduces the need for large flood domains (modern HW
>>> gives you ~512 large flood groups, obviously depending on HW)
>>>
>>>
>>>
>>> Wrt your question about Mac conversation learning - this is an
>>> implementation issue, nothing in EVPN specifications precludes you of doing
>>> so, moreover in the implementation I was designing (in my previous life) we
>>> indeed decoupled data plane learning from control plane advertisement so
>>> control plane was aware of “Active” flows.  Needless to say - this creates
>>>  an additional layer of complexity and all kinds of funky states in the
>>> system ;-).
>>>
>>>
>>>
>>> Hope this helps
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Jeff
>>>
>>> On Apr 23, 2020, 8:30 AM -0700, Gyan Mishra <hayabusagsm@gmail.com>,
>>> wrote:
>>>
>>>
>>>
>>>
>>>
>>> Slight clarification with the arp traffic.  What I meant was broadcast
>>> traffic translated into BUM traffic with the EVPN architecture is there any
>>> way to reduce the amount of BUM traffic with a data center design
>>> requirement with vlan anywhere sprawl with 1000s of type 2 Mac mobility
>>> routes being learned between all the leaf VTEPs.
>>>
>>>
>>>
>>> The elimination of broadcast is a tremendous gain and with broadcast
>>> suppression of multicast that does help but it would be nice to not have
>>> such massive Mac tables type 2 route churn chatter with a conversation
>>> learning where only active flows are are in the type 2 rib.
>>>
>>>
>>>
>>> Kind regards
>>>
>>>
>>>
>>> Gyan
>>>
>>>
>>>
>>> On Wed, Apr 22, 2020 at 6:47 PM Gyan Mishra <hayabusagsm@gmail.com>
>>> wrote:
>>>
>>>
>>>
>>> In the description of the vxlan BGP evpn scenario has a typo on the
>>> multisite feature segmented LSP inter pod with the RT auto rewrite which is
>>> similar to MPLS inter-as option b not a.
>>>
>>>
>>>
>>> Kind regards
>>>
>>>
>>>
>>> Gyan
>>>
>>>
>>>
>>> On Wed, Apr 22, 2020 at 5:57 PM Gyan Mishra <hayabusagsm@gmail.com>
>>> wrote:
>>>
>>>
>>>
>>> All
>>>
>>>
>>>
>>> Had a question related to vxlan BGP EVPN architecture specifications
>>> defined in BGP EVPN NVO3 overlay RFC 8365 and VXLAN data plane RFC 7348.
>>>
>>>
>>>
>>> In a Data Center environment where you have a multiple PODs individual
>>> fabrics per POD connected via a super spine extension using a Multi site
>>> feature doing auto rewrite of RTs to stitch the NVE tunnel between pods
>>> similar to inter-as option A.
>>>
>>>
>>>
>>> So in this scenario where you have vlan sprawl everywhere with L2 and L3
>>> VNIs everywhere as if it were a a single L2 domain.  The topology is a
>>> typical vxlan spine leaf topology where the L3 leafs are the TOR switch so
>>> very small physical  L2 fault domain. So I was wondering if with the vxlan
>>> architecture if this feature below is possible or if their is a way to do
>>> so in the current specification.
>>>
>>>
>>>
>>> Cisco use to have a DC product called “fabric path” which was based on
>>> conversation learning.
>>>
>>>
>>>
>>> Is there any way with existing vxlan BGP evpn specification or maybe
>>> future enhancement to have a Mac conversation learning capability so that
>>> only the active mac’s that are part of a conversations flow are the mac
>>> that are flooded throughout the vxlan fabric.  That would really help
>>> tremendously with arp storms so if new arp entries are generated locally on
>>> a leaf they are not flooded through the fabric unless their are active
>>> flows between leafs.
>>>
>>>
>>>
>>> Also is there a way to filter type 2 Mac mobility routes between leaf
>>> switches at the control plane level based on remote vtep or maybe other
>>> parameters..  That would also reduce arp storms BUM traffic.
>>>
>>>
>>>
>>> Kind regards
>>>
>>>
>>>
>>> Gyan
>>>
>>> --
>>>
>>> Gyan  Mishra
>>>
>>> Network Engineering & Technology
>>>
>>> Verizon
>>>
>>> Silver Spring, MD 20904
>>>
>>> Phone: 301 502-1347
>>>
>>> Email: gyan.s.mishra@verizon.com
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Gyan  Mishra
>>>
>>> Network Engineering & Technology
>>>
>>> Verizon
>>>
>>> Silver Spring, MD 20904
>>>
>>> Phone: 301 502-1347
>>>
>>> Email: gyan.s.mishra@verizon.com
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Gyan  Mishra
>>>
>>> Network Engineering & Technology
>>>
>>> Verizon
>>>
>>> Silver Spring, MD 20904
>>>
>>> Phone: 301 502-1347
>>>
>>> Email: gyan.s.mishra@verizon.com
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> BESS mailing list
>>> BESS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/bess
>>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!Vg9pxTtcOdgw7cYL_Ze1TyY-pXZUmyMf3uJyvPslpcQNVpijlvjvRwzvzScD_hE$>
>>>
>>> --
>>>
>>> Gyan  Mishra
>>>
>>> Network Engineering & Technology
>>>
>>> Verizon
>>>
>>> Silver Spring, MD 20904
>>>
>>> Phone: 301 502-1347
>>>
>>> Email: gyan.s.mishra@verizon.com
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>
>>> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Vg9pxTtcOdgw7cYL_Ze1TyY-pXZUmyMf3uJyvPslpcQNVpijlvjvRwzvJ9vmSpU$>
>>> <~WRD0000.jpg>
>>> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Vg9pxTtcOdgw7cYL_Ze1TyY-pXZUmyMf3uJyvPslpcQNVpijlvjvRwzvJ9vmSpU$>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions Architect *
>>>
>>> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>>>
>>> *M 301 502-1347*
>>>
>>>
>>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>>
>>
>>
>> *M 301 502-1347*
>>
>> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
>
>
> *M 301 502-1347*
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*