Subject: [bess] Fwd: VXLAN BGP EVPN Question

From: Gyan Mishra <[email-masked]>
Date: Fri, 23 Apr 2021 18:21:14 -0400

Authors

Do we know if this draft will progress to RFC?

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

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) <[email-masked]>
Date: Fri, Apr 24, 2020 at 3:07 AM
Subject: Re: [bess] VXLAN BGP EVPN Question
To: Gyan Mishra <[email-masked]>, Jeff Tantsura <
[email-masked]>
CC: BESS <[email-masked]>

Hi Gyan,

If I may, note that:

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

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 <[email-masked]> on behalf of Gyan Mishra <
[email-masked]>
*Date: *Friday, April 24, 2020 at 5:21 AM
*To: *Jeff Tantsura <[email-masked]>
*Cc: *BESS <[email-masked]>
*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/

Kind regards

Gyan

On Thu, Apr 23, 2020 at 6:04 PM Jeff Tantsura <[email-masked]>
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 <[email-masked]>, 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 <[email-masked]> 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 <[email-masked]> 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: [email-masked]

--

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

--

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

_______________________________________________
BESS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bess

-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: John E Drake <[email-masked]>
Date: Sat, 24 Apr 2021 12:29:32 +0000

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 <[email-masked]>
Sent: Friday, April 23, 2021 6:21 PM
To: Ali Sajassi (sajassi) <[email-masked]>; BESS <[email-masked]>; Jeff Tantsura <[email-masked]>; John E Drake <[email-masked]>; Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>
Subject: Fwd: [bess] VXLAN BGP EVPN Question

[External Email. Be cautious of content]

Authors

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) <[email-masked]<mailto:[email-masked]>>
Date: Fri, Apr 24, 2020 at 3:07 AM
Subject: Re: [bess] VXLAN BGP EVPN Question
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>, Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
CC: BESS <[email-masked]<mailto:[email-masked]>>

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 <[email-masked]<mailto:[email-masked]>> on behalf of Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Date: Friday, April 24, 2020 at 5:21 AM
To: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Cc: BESS <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>>, 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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: [email-masked]<mailto:[email-masked]>

--
Gyan  Mishra
Network Engineering & Technology
Verizon
Silver Spring, MD 20904
Phone: 301 502-1347
Email: [email-masked]<mailto:[email-masked]>

--
Gyan  Mishra
Network Engineering & Technology
Verizon
Silver Spring, MD 20904
Phone: 301 502-1347
Email: [email-masked]<mailto:[email-masked]>

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
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: [email-masked]<mailto:[email-masked]>

--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Vg9pxTtcOdgw7cYL_Ze1TyY-pXZUmyMf3uJyvPslpcQNVpijlvjvRwzvJ9vmSpU$>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 24 Apr 2021 13:13:53 -0400

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 <[email-masked]> 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
>
>
>
>
>
> *From:* Gyan Mishra <[email-masked]>
> *Sent:* Friday, April 23, 2021 6:21 PM
> *To:* Ali Sajassi (sajassi) <[email-masked]>; BESS <[email-masked]>;
> Jeff Tantsura <[email-masked]>; John E Drake <[email-masked]>;
> Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>
> *Subject:* Fwd: [bess] VXLAN BGP EVPN Question
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Authors
>
>
>
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-10__;!!NEt6yMaO-gk!Vg9pxTtcOdgw7cYL_Ze1TyY-pXZUmyMf3uJyvPslpcQNVpijlvjvRwzvkEMMBHM$>
>
>
>
>
>
> From: *Rabadan, Jorge (Nokia - US/Mountain View)* <[email-masked]
> >
> <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$>
>
>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-sharma-multi-site-evpn/__;!!NEt6yMaO-gk!Vg9pxTtcOdgw7cYL_Ze1TyY-pXZUmyMf3uJyvPslpcQNVpijlvjvRwzvPV5PoSI$>
>
>
>
> Kind regards
>
>
>
> Gyan
>
>
>
> 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.
>
>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!Vg9pxTtcOdgw7cYL_Ze1TyY-pXZUmyMf3uJyvPslpcQNVpijlvjvRwzvzScD_hE$>
>
> --
>
> Gyan  Mishra
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Vg9pxTtcOdgw7cYL_Ze1TyY-pXZUmyMf3uJyvPslpcQNVpijlvjvRwzvJ9vmSpU$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 24 Apr 2021 18:20:01 +0000

There are a number of drafts that were waiting years on the IDR tunnel Encap draft – they will all be published together in this cluster:

https://www.rfc-editor.org/cluster_info.php?cid=C349

Thanks,
Acee

From: BESS <[email-masked]> on behalf of Gyan Mishra <[email-masked]>
Date: Saturday, April 24, 2021 at 1:14 PM
To: John E Drake <[email-masked]>
Cc: Jeff Tantsura <[email-masked]>, "Ali Sajassi (sajassi)" <[email-masked]>, "Rabadan, Jorge (Nokia - US)" <[email-masked]>, BESS <[email-masked]>
Subject: Re: [bess] VXLAN BGP EVPN Question

Kind Regards

Gyan

On Sat, Apr 24, 2021 at 8:29 AM John E Drake <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>>
Sent: Friday, April 23, 2021 6:21 PM
To: Ali Sajassi (sajassi) <[email-masked]<mailto:[email-masked]>>; BESS <[email-masked]<mailto:[email-masked]>>; Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; John E Drake <[email-masked]<mailto:[email-masked]>>; Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>
Subject: Fwd: [bess] VXLAN BGP EVPN Question

Authors

Thanks

Gyan

---------- Forwarded message ---------
From: Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>
Date: Fri, Apr 24, 2020 at 3:07 AM
Subject: Re: [bess] VXLAN BGP EVPN Question
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>, Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
CC: BESS <[email-masked]<mailto:[email-masked]>>

Hi Gyan,

If I may, note that:

Thanks.
Jorge

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.

Kind regards

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

Kind regards

Gyan

Kind regards

Gyan

All

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.

Kind regards

Gyan

--

Gyan Mishra

M 301 502-1347

--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 24 Apr 2021 14:55:51 -0400

Thanks Acee!!

Gyan

On Sat, Apr 24, 2021 at 2:20 PM Acee Lindem (acee) <[email-masked]> wrote:

> There are a number of drafts that were waiting years on the IDR tunnel
> Encap draft – they will all be published together in this cluster:
>
>
>
> *Date: *Saturday, April 24, 2021 at 1:14 PM
> *To: *John E Drake <[email-masked]>
> *Cc: *Jeff Tantsura <[email-masked]>, "Ali Sajassi (sajassi)" <
> [email-masked]>, "Rabadan, Jorge (Nokia - US)" <[email-masked]>,
> BESS <[email-masked]>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 24 Apr 2021 11:57:43 -0700

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 <[email-masked]> wrote:
> 
> 
> 
>> To: Gyan Mishra <[email-masked]>, Jeff Tantsura <[email-masked]>
>> CC: BESS <[email-masked]>
>> 
>>  
>> 
>> Hi Gyan,
>> 
>>  
>> 
>> If I may, note that:
>> 
>> To: Jeff Tantsura <[email-masked]>
>> Cc: BESS <[email-masked]>
>> On Thu, Apr 23, 2020 at 6:04 PM Jeff Tantsura <[email-masked]> wrote:
>> 
>> Gyan,
>> 
>>  
>> 
>> Email [email-masked]
>> M 301 502-1347
>> 
>>  
>> 
> -- 
> 
> 
> Gyan Mishra
> Email [email-masked]
> M 301 502-1347
> 
>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 24 Apr 2021 15:03:49 -0400

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 <[email-masked]>
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
>
>> From: *Rabadan, Jorge (Nokia - US/Mountain View)* <
>> [email-masked]>
>> 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.
>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 24 Apr 2021 18:30:07 -0400

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 <[email-masked]> wrote:

> I think we are close to seeing light at the end of the tunnel for the
> encap draft.
>
> Kind Regards
>
> Gyan
>
>>> Jeff Tantsura <[email-masked]>; John E Drake <
>>> [email-masked]>; Rabadan, Jorge (Nokia - US/Mountain View) <
>>> [email-masked]>

*Gyan Mishra*

*M 301 502-1347*