dense these days
https://tools.ietf.org/html/rfc6513 MVPN
https://tools.ietf.org/html/rfc6514 MVPN
https://tools.ietf.org/html/rfc6037. Rosen PIM GRE
https://tools.ietf.org/html/rfc4875 P2MP TE
Sent from my iPhone
> On Sep 28, 2019, at 11:58 AM, Gyan Mishra wrote:
>
> BESS WG / All
0904
United States
Phone: 301 502-1347
Email: gyan.s.mis...@verizon.com
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
Sent from my iPhone
> On Sep 21, 2019, at 9:04 AM, Sudhin Jacob
> wrote:
>
> Dear All,
>
> We have floated a draft for benchmarking EVPN-VPWS services.
d (s,g,rpt) prune mechanisms, not for source discovery purpose.
>
> MVPN/MSDP SA interoperation for the "rpt-spt" mode is outside of the scope
> of this document. In the rest of the document, the "spt-only" mode is
> assumed.
>
>
>
>
>
> Regards,
>
>
ited States
Phone: 301 502-1347
Email: gyan.s.mis...@verizon.com
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
Sent from my iPhone
> On Sep 4, 2019, at 7:20 PM, IETF Secretariat
> wrote:
>
>
> The BESS WG has placed draft-snr-bess-evpn-loop-protect in state
> Call For
/us/support/docs/ip/multicast/200512-Configure-mVPN-Profiles-within-Cisco-IOS.html
Thank you
Gyan Mishra
Verizon Communications
Cell 301 502-1347
Sent from my iPhone___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
Sent from my iPhone
> On Sep 29, 2019, at 11:44 PM, Sudhin Jacob wrote:
>
> Hi Gyan,
>
> Thank you very much for the comments. I will get back in a day or two.
>
> Regards,
> Sudhin
Thank you
Gyan
>
>
> Juniper Business Use Only
> From: Gyan Mis
hich is the gap filled by this
feature. Without this feature if the administrative domain is contained by the
same customer performing full mesh msdp peering between in a customer VPN is a
non technical issue so other then having different administrative scope for the
CEs within the same
,
Gyan S. Mishra
IT Network Engineering & Technology
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-1347
Email: gyan.s.mis...@verizon.com
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
Thank you
Gyan S. Mi
Pike FDC1 3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-1347
Email: gyan.s.mis...@verizon.com
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
Sent from my iPhone
> On Sep 19, 2019, at 9:17 AM, Nagaraj, Kiran (Nokia - US/Mountain View)
> wrote:
>
> I support th
3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-1347
Email: gyan.s.mis...@verizon.com
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERTSent from my iPhone
> On Sep 2, 2019, at 11:10 AM, Rabadan, Jorge (Nokia - US/Mountain View)
> wrote:
>
> As a co-author I suppo
3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-1347
Email: gyan.s.mis...@verizon.com
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
Sent from my iPhone
> On Sep 10, 2019, at 3:26 PM, Neeraj Malhotra wrote:
>
>
> Hi,
>
> Support adoption.
>
>
Thank you Sudhin
Sent from my iPhone
> On Oct 1, 2019, at 12:48 AM, Sudhin Jacob wrote:
>
> Hi Gyan,
>
> Kindly find the answers inline. Appreciate your feedback.
>
> Regards,
> Sudhin
>
> Juniper Business Use Only
> From: Gyan Mishra
> Sent:
t; Thanks
> Mankamana
>
>
> From: BESS on behalf of Gyan Mishra
>
> Date: Saturday, September 28, 2019 at 8:59 AM
> To: "bess@ietf.org"
> Subject: [bess] RFC or Draft that lists all standards track rfc’s of all mvpn
> profiles
>
> BESS WG / All
>
&
permanently
on the shared tree.
Regards,
Gyan S. Mishra
IT Network Engineering & Technology
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-1347
Email: gyan.s.mis...@verizon.com
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-
; customer 2
>
[Gyan] Understood. Thanks Jeff
> Jeffrey
>
> From: Gyan Mishra
> Sent: Tuesday, October 1, 2019 4:02 PM
> To: Jeffrey (Zhaohui) Zhang
> Cc: bess@ietf.org
> Subject: Re: [bess] RFC or Draft that lists all standards track rfc’s of all
> m
so help with vendor interoperability.
> Jeffrey
>
> From: BESS On Behalf Of Gyan Mishra
> Sent: Saturday, September 28, 2019 2:06 PM
> To: Gyan Mishra ; bess@ietf.org
> Subject: Re: [bess] RFC or Draft that lists all standards track rfc’s of all
> mvpn profiles
>
>
Mankamana
What would be the use case for use of leave group 32 bit sequence number usage?
As you mentioned their maybe some vendors that have implemented and if they did
what is the use case?
So the 32 bit field would only be present if the vendor uses it and would not
for those that
Support
Thank you
Gyan Mishra
IT Network Engineering & Technology
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-1347
Email: gyan.s.mis...@verizon.com
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
Sent fro
Sorry to talk implementation on or off list but from a pure net-net vpn VTI
tunnel mode perspective using DMVPN that scales pretty well to 100’s of user
sites homing to a pair of mGRE DMVPN head ends which I have deployed. I have
not done any with over a 1000 on a pair but that’s a lot even
gt; IETF’s protocols work well. (p.s. DMVPN or DSVPN is not IETF standard, they
> both use vendors extended version of NHRP). Hope to discuss with you more.
>
> For example,
>
>
>
>
> Looking for more comments,
>
> Linda
>
>
> From: Gyan Mis
Hi Stephanie
+ 6MAN & Spring
I was thinking about the BGP capability exchange between address families
concept from a 6MAN and operations perspective treating the next hop as a pure
ubiquitous transport carrying v4 and v6 NLRI and the significance and
advantages from a deployment
e, in addition to setting the next-hop at the
>>> ASBR there needs to be a way to specify the particular label also.
>>>
>>>
>>>
>>> Otherwise just using any dynamic label will not work.
>>>
>>>
>>>
>>> Thanks,
>>>
With option b since the LSP is segmented into 3 segments
Left side Rx to R1 -ibgp
Middle R1 to R2 - ebgp vpnv4
Right side R2 to R3 - ibgp
So for the LSP to be segmented in opt b for it to work properly what is
required is either next-hop-self on the ibgp peer so the rewrite happens
forcing the
IP value such as below. I realize this probably isn't a common
> configuration.
>
> route-map NH permit 10
> match ip address prefix-list ONE
> set ip next-hop x.x.x.x
>
> route-policy NH
> if destination in (1.1.1.1/32) then
> set next-hop x.x.x.x
>
> On
I fully support the draft. The draft is well written and covers all the
critical points of multiprotocol BGP where the IPv6 next hop can carry IPv4
NLRI.
Thank you
Gyan S. Mishra
IT Network Engineering & Technology
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver
y and
> authentication methods (AH or ESP).
>
> As the result, the number of messages to maintain IPsec key among a group of
> nodes is much less.
>
> For example,
>
>
>
> Linda
>
> From: Gyan Mishra
> Sent: Saturday, November 16, 2019 3:13 PM
> To: Linda Dunb
; U-SID benefits from all the advantages SRH provides while adding a
>> > higher density of SIDs thus allowing stricter path control.
>> >
>> > Regards,
>> > Greg
>> >
>> > On Fri, Oct 4, 2019 at 10:02 PM Gyan Mishra
>
In-line
Good idea agreed that’s a good way to go using uSID along with SR-MPLS.
I am going to set that up in my lab all 3 in parallel overlays SR-MPLS, uSID
and SRv6. That may not be a bad idea having the architecture in parallel I
wonder and using SRv6 when you don’t have MTU constraints
Hi Robert
In-line question
Sent from my iPhone
> On Oct 3, 2019, at 11:01 AM, Robert Raszuk wrote:
>
> Hi Linda,
>
> Nope. Nodes except egress have any reason to look at VPN label. That label
> has only local significance on egress.
>
> Thx,
> R.
Robert
From an operator perspective
of
the label stack but now with RFC 4797 with GRE you add extra 24 GRE/IP
bytes and with UDP/MPLS 8 bytes.
> Thx,
> R.
>
> On Fri, Oct 4, 2019 at 1:03 AM Gyan Mishra wrote:
>
>>
>> Hi Robert
>>
>> In-line question
>>
>> Sent from my iPhone
>>
I support adoption as well as there are implementations of SRv6 bgp L3 VPN
services per link below Nanog publication.
https://pc.nanog.org/static/published/meetings/NANOG71/1445/20171005_Dawra_Segment_Routing_Ipv6_v1.pdf
Regards
Gyan Mishra
IT Network Engineering & Technology
Ver
Bess,
What is the benefit of SRv6 over SR-MPLS for greenfield deployments or existing
mpls deployments.
Regards,
Gyan Mishra
IT Network Engineering & Technology
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-
In line to Robert and any of the other co-authors on my comment
Sent from my iPhone
> On Oct 4, 2019, at 1:27 AM, Gyan Mishra wrote:
>
> Hi Robert
>
> in-line responses
>
> Thank you
>
> Gyan
>
>> On Thu, Oct 3, 2019 at 7:29 PM Robert Raszuk wrote:
&g
In line possible answers
Sent from my iPhone
> On Oct 4, 2019, at 8:22 PM, Gyan Mishra wrote:
>
>
> Bess,
>
> What is the benefit of SRv6 over SR-MPLS for greenfield deployments or
> existing mpls deployments.
>
I think I answered my own question but please chi
> hypervisor managed by server admins
> >
> > In any decent network or for that matter even in my lab this is all 100%
> automated. You run one template and execute it. Ansible works pretty well,
> but there are other choices too.
> >
> > Many thx,
> > R.
> >
also the NVE residing in the hypervisor.
>
> That’s usually the reference here.
>
>
>
> My two cents..
>
> Thx
>
> Jorge
>
>
>
> *From: *BESS on behalf of "UTTARO, JAMES" <
> ju1...@att.com>
> *Date: *Wednesday, March 4, 2020 at 4:57 PM
quality at this point.
>
> Btw ,,, no need for VXLAN nor BGP to the host. The proposed above
> alternative were well thought out and turned to work ways far more
> efficient and practical if you zoom into details.
>
> Best,
> Robert.
>
>
> On Tue, Mar 3, 2020 a
maximizing stability.
Kind regards,
Gyan
--
Gyan Mishra
Network Engineering & Technology
Verizon
Silver Spring, MD 20904
Phone: 301 502-1347
Email: gyan.s.mis...@verizon.com
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mai
supports it.
It does seem there would be a lot of customers wanting this fabric
extension to hypervisor capabilities for MH load balancing- and very
surprising that it does not exist.
https://tools.ietf.org/html/rfc8365#section-7
Kind regards
Gyan Mishra
Verizon
Cell 301 502-1347
On Wed, Mar 4
> This poll for adoption closes on Wednesday 11th March 2020.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-gmsm-bess-evpn-bfd/
>
>
>
>
>
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.i
late and execute it. Ansible works pretty well,
> but there are other choices too.
>
> Many thx,
> R.
>
>
Good point as most networks these days have orchestration built into the
solution. Agreed.
>
>
> On Tue, Mar 3, 2020 at 1:00 AM Gyan Mishra wrote:
>
>>
d as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll for adoption closes on 18th Feb 2020.
>
>
>
> Regards,
>
> Stephane and Matthew
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-wsv-bess-extended-evpn-optimized-ir/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dwsv-2Dbess-2Dextended-2Devpn-2Doptimized-2Dir_=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=s7ZzB4JbPv3nYuoSx5Gy8Q=T2V6NlWDOa-h0yqE2sJnAuAD8ab9LVClxX9Do5SXglg=ORfJfU_4k4JZyIAPnAEvPznq3_ZTmuNFoBbbNkGgG7A=>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
--
Gyan Mishra
Network Engineering & Technology
Verizon
Silver Spring, MD 20904
Phone: 301 502-1347
Email: gyan.s.mis...@verizon.com
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
;
> [1] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
> [2] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
In-line comment
On Wed, Jan 8, 2020 at 5:15 PM Leonard Giuliano wrote:
>
>
> On Wed, 8 Jan 2020, Gyan Mishra wrote:
>
>
>
> | Gyan> Source discovery is only necessary with ASM not SSM. With SSM
> the receiver is "source" aware so does not require any d
uent reach
ability to the SSM multicast sources ; you now have solved the SSM gap
mentioned related to LHR network based source discovery. I don’t think
their is a draft on this but I think it’s a worthwhile I-D.
>
> Jeffrey
>
> -Original Message-
> From: Lenny Giuliano
> S
hor or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
>
>
>
>
> This poll for adoption closes on *** 20th January 2020 ***
>
>
>
>
>
>
>
> Regards
ntations of the modified protocol
> described in this draft.
>
> Thank you,
>
> Matthew
>
>
>
> [1] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
>
> ___
> BESS mailing list
> BES
Hi Jeffrey & Mankamana
Just following up on my comments and if you had any questions.
Kind Regards
Gyan
On Thu, Jan 9, 2020 at 7:22 PM Gyan Mishra wrote:
>
> In-line comments
>
> On Wed, Jan 8, 2020 at 1:48 PM Jeffrey (Zhaohui) Zhang
> wrote:
>
>> Hi Gyan,
>&g
tocol
> described in this draft.
>
> Thank you,
>
> Matthew
>
>
>
> [1] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
>
> ___
> BESS mailing list
> BESS@ietf.org
&g
1] https://datatracker.ietf.org/doc/draft-zzhang-bess-bgp-multicast
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-zzhang-bess-bgp-multicast=02%7C01%7Carkadiy.gulko%40refinitiv.com%7Ca55ef10e648140186c4308d792b2cfe1%7C71ad2f6261e244fc9e8
On Thu, Jan 9, 2020 at 1:30 PM Jeffrey (Zhaohui) Zhang
wrote:
> Please see zzh> below.
>
>
>
> *From:* Gyan Mishra
> *Sent:* Thursday, January 9, 2020 1:25 PM
> *To:* Jeffrey (Zhaohui) Zhang
> *Cc:* Lenny Giuliano ; bess-cha...@ietf.org;
> bess@ietf.org
In-line comments
On Wed, Jan 8, 2020 at 1:48 PM Jeffrey (Zhaohui) Zhang
wrote:
> Hi Gyan,
>
>
>
> Please see zzh3> below. I trimmed some text.
>
>
>
> *From:* Gyan Mishra
> *Sent:* Wednesday, January 8, 2020 2:50 AM
> *To:* Jeffrey (Zhaohui) Zhang
> *C
Support.
Gyan
On Mon, Jan 6, 2020 at 1:25 PM Mankamana Mishra (mankamis) <
manka...@cisco.com> wrote:
> Support.
>
>
>
> *From: *BESS on behalf of "Bocci, Matthew (Nokia
> - GB)"
> *Date: *Monday, January 6, 2020 at 9:54 AM
> *To: *"bess@ietf.org"
> *Subject: *[bess] WG Last Call and
Support.
Regards,
Gyan
On Mon, Jan 6, 2020 at 3:43 PM Jeffrey (Zhaohui) Zhang wrote:
> Support as co-author.
>
>
>
> Not aware of undisclosed IPR relevant to this draft.
>
>
>
> Thanks!
>
> Jeffrey
>
>
>
> *From:* BESS *On Behalf Of *
> slitkows.i...@gmail.com
> *Sent:* Monday, January 6,
for customers as a value
added service.
See forwarded below as well - inline comments.
Kind regards,
Gyan
On Mon, Jan 6, 2020 at 8:09 PM Jeffrey (Zhaohui) Zhang
wrote:
> Hi Gyan,
>
>
>
> Please see zzh> below.
>
>
>
> *From:* Gyan Mishra
> *Sent:
Hi Jeffery
Pleas see in line Gyan>
On Tue, Jan 7, 2020 at 9:49 AM Jeffrey (Zhaohui) Zhang
wrote:
> Hi Gyan,
>
>
>
> Please see zzh> below.
>
>
>
> *From:* Gyan Mishra
> *Sent:* Tuesday, January 7, 2020 12:39 AM
> *To:* Jeffrey (Zhaohui) Zhang
>
er things that need consideration in such case,
> e.g. host asic table scalability). Please look @
> https://datatracker.ietf.org/doc/draft-ietf-rift-rift/ If you need more
> info/code, more than happy to talk out of band
>
> thanks
>
> -- tony
>
> On Thu, Mar 5, 2020 at 2:04
; BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
--
Gyan Mishra
Network Engineering & Technology
Verizon
Silver Spring, MD 20904
Phone: 301 502-1347
Email: gyan.s.mis...@verizon.com
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
that concept apply to SRv6 in the brown field mixed environment.
Kind regards
Gyan
On Sat, Mar 14, 2020 at 2:55 PM Gyan Mishra wrote:
>
> Eduard
>
> I have some similar questions related to BE L3 VPN
>
> Dear BESS authors of SRv6 services draft Q:
>
> My understanding is
well as other capabilities you
don’t get without SR-TE.
If it’s true that SR-TE will not be added to SRv6 then that makes SR-MPLS
more attractive then SRv6.
Gyan
On Sat, Mar 14, 2020 at 3:05 PM Gyan Mishra wrote:
>
>
> BESS authors of services draft,
>
> A follow on question.
&
t; Please let me know if you want some slot for this session*. We would be
> finalizing Agenda 4/21 so please send me request before that. *
>
>
>
> Mankamana
> _______
> BESS mailing list
> BESS@ietf.org
> https://www.ietf
d finding cornercases, not the way RIFT WG is
> run ;-)
>
> I'll ping you 1:1 otherwise ;-)
>
> thanks
>
> --- tony
>
> On Mon, Mar 9, 2020 at 9:15 PM Gyan Mishra wrote:
>
>> Hi Tony
>>
>> I am actually a member of RIFT, as the WG charter description
&g
,
>
>
>
> In-line, please.
>
> Thanks,
>
> Jorge
>
>
>
> *From: *Gyan Mishra
> *Date: *Thursday, March 26, 2020 at 8:50 AM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" >
> *Cc: *BESS , "UTTARO, JAMES"
> *Subject: *Re: [
rworking-02
>
>
>
> Thx
>
> Jorge
>
>
>
> *From: *BESS on behalf of Gyan Mishra <
> hayabusa...@gmail.com>
> *Date: *Wednesday, March 25, 2020 at 6:38 AM
> *To: *BESS
> *Subject: *[bess] vxlan evpn and L3 vpn interworking standard
>
>
>
iple signaling domains i.e EVPN<->L3VPN<->EVPN...
> I would be interested in your use cases..*
>
>
>
> *Thanks,*
>
> * Jim Uttaro*
>
>
>
> *From:* BESS *On Behalf Of * Gyan Mishra
> *Sent:* Wednesday, March 25, 2020 1:37 AM
> *To:* B
91fedc%7C1%7C0%7C637206355463932513=LtBJOxohSHjupWERqW88kUik96QA8iKzaucSLxh6rSU%3D=0>
> describes examples of using BGP UPDATE messages to achieve the SDWAN
> Application Based Segmentation, assuming that the applications are
> assigned with unique IP addresses.
>
> In the Figure below, the following BGP Updates can be advertised to ensure
> that Payment Application only communicates with the Payment Gateway:
>
>
>
>
>
> BGP UPDATE #1 from C-PE2 to RR for the RED P2P topology (only propagated
> to Payment GW node:
>
> -MP-NLRI Path Attribute:
>
>- 30.1.1.x/24
>
> -Tunnel Encap Path Attribute
>
>- IPsec Attributes for PaymentGW ->C-PE2
>
>
>
> BGP UPDATE #2 from C-PE2 to RR for the routes to be reached by Purple:
>
> -MP-NLRI Path Attribute:
>
>- 10.1.x.x
> - 12.4.x.x
>
> -TunnelEncap Path Attribute:
>
>- Any node to C-PE2
>
>
>
>
>
> Your feedback is greatly appreciated.
>
>
>
> Thank you very much.
>
>
>
> Linda Dunbar
> --
>
> *External Email:** Please use caution when opening links and attachments
> / **Courriel externe:** Soyez prudent avec les liens et documents joints *
> --
>
> *External Email:** Please use caution when opening links and attachments
> / **Courriel externe:** Soyez prudent avec les liens et documents joints *
>
> ___
> Idr mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr=02%7C01%7Clinda.dunbar%40futurewei.com%7Ce72069277dec49a5666a08d7cfcddf3f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637206355463932513=eqN85C344P7RxfO%2FBxoVZ0zNgGBsAcH%2F623Ye6TYHhs%3D=0>
>
> ___
> Idr mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
--
Gyan Mishra
Network Engineering & Technology
Verizon
Silver Spring, MD 20904
Phone: 301 502-1347
Email: gyan.s.mis...@verizon.com
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
es not bring
> any benefits other then few bits savings in the packet header as compared
> with say IPv4 transport. Contrary it costs a lot of complexity in the
> control plane and forwarding planes of the network elements.
>
> Thx,
> R.
>
>
>
> On Tue, Mar 31, 2020 at
we wanted to illustrate an example where
> PE1 and PE2 belong to the same domain, no ip-lookups in between. For that,
> you need to connect PE1 and PE2 by a tunnel that can cross different ASNs,
> and BGP-LU can do that.
>
>
>
> Hope it helps.
>
> Thanks.
>
> Jorg
Dear BESS,
Does anyone know if this draft has been picked up in another draft or is on its
way to become standardized. Please provide data tracker if so.
This is a much needed feature for operators for DC for mpls core connectivity
DCI extension.
n, split-horizon,
> mass withdraw and aliasing/backup procedures as any Ethernet Segment.
>
>
>
> Thanks.
>
> Jorge
>
>
>
> *From: *Gyan Mishra
> *Date: *Monday, April 27, 2020 at 1:50 AM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" >
> *
ols.ietf.org.
The IETF Secretariat
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect & SME*
*Data Center Planning | Common Core | Development & Engineering Lab
ServicesGlobal Technology Services | ITNUC*
*O 240 970-6287M 301 502-134713101 Columbia Pi
failover to cell audio.
Kind regards
Gyan
On Tue, Apr 28, 2020 at 2:16 PM John Scudder wrote:
> Hi Gyan,
>
> On Apr 28, 2020, at 12:32 PM, Gyan Mishra wrote:
>
> Sorry for the audio issues I had during the call. My apologies.
>
>
> Just BTW, I am about 99% sure your proble
al 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 ,
> wrote:
>
>
>
> Slight clarification with the arp traffic. What I meant was broadcast
> traffic tr
CI, you can perfectly use it for inter-pod connectivity.
>
>
>
> Thanks.
>
> Jorge
>
>
>
> *From: *BESS on behalf of Gyan Mishra <
> hayabusa...@gmail.com>
> *Date: *Friday, April 24, 2020 at 5:21 AM
> *To: *Jeff Tantsura
> *Cc: *BESS
> *Sub
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 wrote:
>
> All
>
> Had a ques
are are in the type 2 rib.
Kind regards
Gyan
On Wed, Apr 22, 2020 at 6:47 PM Gyan Mishra 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.
>
bilities when you eliminate the IPv4 peer.
Please provide any comments and feedback as well as any issues you see with
this idea of IPv4 peer elimination with carrying all v4 and v6 NLRI over
IPV6 peer.
Kind regards
Gyan Mishra
Verizon
Cell 301 502-1347
-- Forwarded message -
Fro
t; any extra flooding.
>
>
>
> Thanks.
>
> Jorge
>
>
>
> *From: *Gyan Mishra
> *Date: *Saturday, April 25, 2020 at 8:45 AM
> *To: *"Lukas Krattiger (lkrattig)" , "
> saja...@cisco.com"
> *Cc: *BESS , Jeff Tantsura ,
> "Rabadan, Jorge
load sharing between all the leaf
to spine node links. Are their any other tweaks necessary maybe based on
L2 VNI even odd numbering distribution between leaf to spine links.
Kind regards
Gyan
On Sun, Apr 26, 2020 at 7:50 PM Gyan Mishra wrote:
>
> Jorge
>
> In the BGP EVPN NVO RFC
wn for a leaf,
> it must be somewhere beyond the GW. Finally, the draft also allows you to
> use an I-ES for multihoming and have all-active to two or more GWs.
>
> Note that this draft has multiple implementations, and the only reason why
> is not an RFC yet is due to a normative re
ges
> that have been introduced.
>
>
>
>
>
> Thanks,
>
>
>
> Stephane & Matthew
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-igmp-mld-proxy
>
>
> ___
> BESS mailing li
t any design objective.
Comments welcome.
Kind Regards
Gyan
On Sat, Oct 10, 2020 at 3:26 PM Gyan Mishra wrote:
>
> Dear TEAS, PCE, IDR, LSR, BESS, BIER Spring Working Groups,
>
> I have noticed that after reviewing many drafts across many WGs it seems
> in the industry that the l
ought I would bring
up to the WG as an important discussion point.
Lots of food for thought. Welcome all comments as well as concerns related
to this topic.
Kind Regards,
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*M 301 502-134713101 Columbia Pike *Silver Spr
closed in conformance with IETF rules.
>
>
>
>
>
>
>
> We are also polling for any existing implementation as per [2].
>
>
>
>
>
>
> Thank you,
>
>
> Stephane & Matthew
>
>
>
>
>
> [1]
>
> https://datatracker.ietf.org/d
To: Hayabusanew
-- Forwarded message -
From:
Date: Sat, Aug 22, 2020 at 2:20 AM
Subject: [E] New Version Notification for
draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-03.txt
To: Jeff Tantsura , Gyan Mishra <
gyan.s.mis...@verizon.com>, Mankamana Mishra
A new version
:
Date: Sun, Jul 12, 2020 at 5:37 AM
Subject: [E] New Version Notification for
draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-01.txt
To: Gyan S. Mishra
A new version of I-D, draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-01.txt
has been successfully submitted by Gyan Mishra and posted to the
IETF
rnet-drafts/
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/li
hor on 4364 and drove a lot of the details of what we
> wrote.
>
> Two points in closing:
> - If someone can show that we break something, we will have to fix it.
> - If the chairs want to run this point past IDR and BESS explicitly, that
> would be fine.
>
> Hope this he
ised the point. Obviously, some of the authors know a bit about BGP, and
> Eric was a lead author on 4364 and drove a lot of the details of what we
> wrote.
>
> Two points in closing:
> - If someone can show that we break something, we will have to fix it.
> - If the chairs want to run this point past IDR and BESS explicitly, that
> would be fine.
>
> Hope this helps.
>
> Best,
> Adrian
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
> ___
> Idr mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
A new version of I-D, draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-02.txt
has been successfully submitted by Gyan MIshra and posted to the
IETF repository.
Name: draft-mishra-bess-ipv4nlri-ipv6nh-use-cases
Revision: 02
Title: IPv4 NLRI with IPv6 Next Hop Use Cases
Document dat
Hi Adrian
Just checking if you had a chance to look at my comments on the draft.
Kind Regards
Gyan
On Wed, Jun 10, 2020 at 2:55 PM Gyan Mishra wrote:
> Hi Adrian & Authors
>
> I support the draft and the problems it is trying to address with SR-TR
> steering over multiple AS
/datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
>
> [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
t;
>
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-aggregation-label/
>
> [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mai
w confusion, risk
> destabilising the network? Should it use a different code point to be
> distinguishable?
>
> Gyan> Completely agree. I agree negative impact if any exist. See my
> comments above. As BGP has the ability to compartmentalize SAFI,
> codepoints and p
New Version Notification for
draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-07.txt
To: Hayabusanew
-- Forwarded message -
From:
Date: Thu, Nov 19, 2020 at 2:54 AM
Subject: [E] New Version Notification for
draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-07.txt
To: Gyan Mishra , Mankamana Mish
Forwarded message -
From:
Date: Mon, Nov 2, 2020 at 12:36 AM
Subject: [E] New Version Notification for
draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-06.txt
To: Mankamana Mishra , Jeff Tantsura <
jefftant.i...@gmail.com>, Gyan Mishra
A new version of I-D, draft-mishra-bes
gt; If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll for adoption closes on 15th December 2020.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
> [1]
> https://datatrac
[1] https://datatracker.ietf.org/doc/draft-mohanty-bess-weighted-hrw/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-mohanty-bess-weighted-hrw/__;!!BhdT!w5xhP0Zmgt8Mvf7pa1FdZaljAMAQXuOx6dPzL8TMMbjSnyZV1L6-Dd5FJaw$>
>
>
>
>
>
>
> ___
gt;
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll for adoption closes on 15th December 2020.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-skr-bess-evpn-redundant-mcast-source/
>
>
>
>
>
>
>
>
>
>
>
> 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
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
tps://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
> ___
> BESS mailing
1 - 100 of 239 matches
Mail list logo
