[bess] Re: Fwd: I-D Action: draft-ietf-bess-v4-v6-pe-all-safi-01.txt

; reference was found in the text > > > > == Unused Reference: 'RFC6074' is defined on line 2085, but no explicit > > reference was found in the text > > > > == Unused Reference: 'RFC6513' is defined on line 2091, but no explicit &g

[bess] Fwd: I-D Action: draft-ietf-bess-v4-v6-pe-all-safi-01.txt

ented prior to WGLC. Thank you Gyan -- Forwarded message - From: Date: Mon, Jul 29, 2024 at 2:11 AM Subject: [bess] I-D Action: draft-ietf-bess-v4-v6-pe-all-safi-01.txt To: Cc: Internet-Draft draft-ietf-bess-v4-v6-pe-all-safi-01.txt is now available. It is a work item of the B

[bess] Re: Fw: New Version Notification for draft-xie-bess-evpn-extension-evn6-00.txt

BGP Only DC over L3 core the same concept can be applied here for your use case over public Internet and can use secure EVPN. https://datatracker.ietf.org/doc/draft-sajassi-bess-secure-evpn/ Kind Regards Gyan On Sat, Jul 27, 2024 at 1:35 AM Gyan Mishra wrote: > Hi Chongfeng > > To

[bess] Re: Fw: New Version Notification for draft-xie-bess-evpn-extension-evn6-00.txt

the other side does not have to be aware and can blindly forward the packets. So the situation use case is interesting but I think corner case. Kind Regards Gyan On Fri, Jul 26, 2024 at 11:59 PM Gyan Mishra wrote: > > Hi Chongfeng > > This is a very intriguing solution. > >

[bess] Re: Fw: New Version Notification for draft-xie-bess-evpn-extension-evn6-00.txt

Hi Chongfeng This is a very intriguing solution. The use case for this solution is EVPN L2 stretch over the internet or disparate IP networks that could be in the same OAD admin domain and have IP connectivity between disparate PEs but do not have the availability to natively extend the EVPN con

[bess] Re: [Idr] Re: Do we need yet another link bandwidth community?

All I think has been a great effort by all authors involved over many years in trying to encode link bandwidth to be carried in BGP for weighted UCMP load balancing. Many thanks to all the authors on your work! Here is some history on all of these drafts below and my take on possible path forwar

[bess] Re: Initial agenda for BESS

Thank you! Gyan On Mon, Jul 22, 2024 at 1:31 PM Matthew Bocci (Nokia) < matthew.bo...@nokia.com> wrote: > Hi Gyan > > > > That should be fine. > > > > Matthew > > > > *From: *Gyan Mishra > *Date: *Thursday, 18 July 2024 at 08:11 > *To:

[bess] Re: Initial agenda for BESS

Hi Mankamana I would like to request if you move me to the end of the agenda. Thank you Gyan On Sat, Jul 13, 2024 at 9:14 PM Mankamana Mishra (mankamis) wrote: > All, > > https://datatracker.ietf.org/doc/agenda-120-bess/ > > > > please unicast if something missed in agenda. > > > > Mankaman

[bess] IETF 120 time slot request

Hi Mankamana I would like to request a 5 minute time slot for updates on this draft on testing updates and plan for initiate WGLC this fall. Also plans for interoperability testing this work at EANTC labs at MPLS World Congress next year as well as on the agenda officially to present this work a

Re: [bess] Mail regarding draft-ietf-bess-rfc7432bis

the EVPN corresponding route type. There have been a lot of EVPN route types added since RFC 7432. RFC 9469 lists all the EVPN route types in section 4.1. Hope that helps Kind Regards *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* On

Re: [bess] Adoption call: draft-zhao-pim-evpn-multicast-yang in pim

Support adoption. I see the yang model has RT 6-8 but wondering why RT-3 IMET was not included. Kind Regards <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* On Thu, Jan 4, 2024 at 5:40 PM Michael M

Re: [bess] WG Adoption and IPR poll for draft-sajassi-bess-evpn-ip-aliasing-09

I support adoption. Thanks Gyan On Wed, Nov 29, 2023 at 6:12 PM Suresh Pasupula (surpasup) wrote: > I support the adoption of this document as a WG draft and I am not aware > of any undisclosed IPR. > > > Thanks > Suresh > > > On 11/13/23, 5:50 AM, "Jeffrey (Zhaohui) Zhang"

[bess] draft-burdet-bess-evpn-fast-reroute - Review

Dear Authors I reviewed the EVPN FRR draft and it is well written. There is a tremendous amount of detail in this draft and wonder if it should be easier to split into different drafts that focus on different underlays or technologies. My understanding from reading the draft is that this draft u

Re: [bess] Please send slot request for IETF 118

Mankamana I would like to request 10 minute slot for the updated combined draft. *draft-ietf-bess-v4-v6-pe-all-safi (Standards Track)* Thanks Gyan On Mon, Oct 9, 2023 at 4:39 PM Mankamana Mishra (mankamis) wrote: > All, > > Primary agenda has been posted. Please send me slot request for BESS

Re: [bess] draft-boutros-bess-elan-services-over-sr review

. Cheers, Gyan On Mon, Oct 9, 2023 at 11:16 PM Gyan Mishra wrote: > > Dear authors > > Slight correction on SRv6 uSID service sid. > > So the F3216 uSID format 32 bit block with 16 bit uSID entry in the uSID > carrier, you can have different types or “service sid” which comes

Re: [bess] draft-boutros-bess-elan-services-over-sr review

limit of ideas for SRv6 uSID forwarding plane service sid use case extensibility and SRv6 endpoint instantiation and what you want to encode into the service sid field. Kind Regards Gyan On Mon, Oct 9, 2023 at 10:52 PM Gyan Mishra wrote: > > Dear authors > > I would like to

[bess] draft-boutros-bess-elan-services-over-sr review

Dear authors I would like to provide some feedback on this draft follow up from the presentation given at IETF 117. After reviewing this draft it seems this draft is trying apply the concept of “service sid” to both SR-MPLS and SRv6 uSID forwarding planes. Interesting idea. This draft seems to o

Re: [bess] WG adoption and IPR poll for draft-trr-bess-bgp-srv6-args-02

I reviewed the draft and it’s important updates to RFC 9252 to support SRV6 BGP service overlay to support SRv6 SID ARG field for endpoint behaviors that require it namely with EVPN RT-1 and RT-3. I support WG adoption. Thanks Gyan On Thu, Sep 28, 2023 at 10:50 AM Matthew Bocci (Nokia) < matt

Re: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

I support WG adoption. Thanks Gyan On Thu, Oct 5, 2023 at 6:45 AM Matthew Bocci (Nokia) < matthew.bo...@nokia.com> wrote: > WG > > > > This email starts a one-week WG adoption poll for > draft-ietf-bess-bgp-sdwan-uasge-16 [1] > > > > A little bit of history: A previous version was adopted, comp

Re: [bess] Appointment of additional WG Chair

m. > > > > Thanks > > > > Andrew Alston > > Routing Area Director > > > > Internal All Employees > ___ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > -- <http://w

Re: [bess] IETF 117 BESS - IPv6 Only PE Design & IPv4 Only PE Design ALL SAFI Supported

support this merge. > > Thanks, > Ketan > > > On Thu, Jul 27, 2023 at 5:32 PM Gyan Mishra wrote: > >> Dear BESS WG, >> >> *From my presentation today discussion on "merging" of drafts I would >> like to poll the BESS WG on merging of the two draft

[bess] IETF 117 BESS - IPv6 Only PE Design & IPv4 Only PE Design ALL SAFI Supported

pot versus being broken out into separate drafts added complexity Thank you <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Please send slot request for BESS IETF 117

ist > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption poll for draft-wang-bess-sbfd-discriminator

or adoption closes on May 31th > > > > Regards, > > Matthew and Stephane > > > > [1] https://datatracker.ietf.org/doc/draft-wang-bess-sbfd-discriminator/ > ___ > BESS mailing list > BESS@ietf.org > https://www

Re: [bess] WG adoption for draft-brissette-bess-evpn-vpws-seamless

or adoption closes on June 7th. > > > > Regards, > > Matthew and Stephane > > > > [1] > https://datatracker.ietf.org/doc/draft-brissette-bess-evpn-vpws-seamless/ > _______ > BESS mailing list > BESS@ietf.org > https

Re: [bess] WG Adoption and IPR poll for draft-sajassi-bess-secure-evpn-06

h IETF rules. > > > > This poll for adoption closes on June 9th 2023 > > > > Regards, > > Matthew and Stephane > > > > [1] https://datatracker.ietf.org/doc/html/draft-sajassi-bess-secure-evpn > > > _______ >

Re: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis

/rfc8584.html#section-2.2.1 > > > > Thanks, > > --Satya > > > > *From: *BESS on behalf of Jorge Rabadan (Nokia) < > jorge.raba...@nokia.com> > *Date: *Friday, March 3, 2023 at 11:06 PM > *To: *Gyan Mishra > *Cc: *mdodge , bess@ietf.org > *Subject: *Re

Re: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis

es type 1 and Preference type 2. HRW is not obsoleting the modulo-based > or anything like that. The three algorithms are widely used in networks, > and while the default one has limitations, it is simple and works out in > many networks. > > > > Thank you! > > Jorge &

Re: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis

t; [image: signature_3305758272] > > +972-526175734 > > mdo...@drivenets.com > > follow us on Linkedin <https://www.linkedin.com/company/drivenets> > > www.drivenets.com > > [image: DriveNets Network Cloud] > <https://get.drivenets.com/mwc-2023-schedule-a-me

[bess] IETF 116 10 minute time slot request for IPv4-Only PE Design All SAFI & IPv6-Only PE Design All SAFI

y-pe-design-all-safi/ Thank you <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Suggestion on v4-only/v6-only drafts

ed review of the >> content/proposals. >> >> Thanks, >> Ketan >> >> ___ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >> > -- <http://www.verizon.com/>

Re: [bess] Suggestion on v4-only/v6-only drafts

heard?) > (2) all other informational/BCP material could be combined in a single > draft (perhaps the existing BESS WG draft) > > IMHO, that would facilitate an appropriate focussed review of the > content/proposals. > > Thanks, > Ketan > > -- <http://www.ver

Re: [bess] Please send me presentation slot request for IETF 115

/www.ietf.org/mailman/listinfo/bess > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption poll and IPR poll for draft-sajassi-bess-evpn-ac-aware-bundling

nformance with IETF rules. > > > > This poll for adoption closes on October 24th 2022. > > > > Regards, > > Matthew and Stephane > > > > > > [1] > https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-ac-aware-bundling/ > > > _____

Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-bgp-sdwan-usage-05

> > > > > [1] draft-ietf-bess-bgp-sdwan-usage-05 > <https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-sdwan-usage> > > > > > > > ___ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > -- <http://

Re: [bess] [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR

ation >> 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

[bess] Rtgdir last call review of draft-ietf-bess-evpn-vpws-fxc-07

Reviewer: Gyan Mishra Review result: Ready This specification specifies a important optimization for operators using VPWS EVPN for scalability of millions of P2P AC provisioning using a VPWS EVPN Flexible Cross connect service which multiplexes multiple attachment circuits across different

Re: [bess] [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR

tf.org/doc/draft-ietf-idr-sr-p2mp-policy/> > > > > Jeffrey Zhang has joined as co-author. > > Work is undergoing in the author group > > To help align it to other work. > > > > It will be WG LC in IDR and BESS. > > > > Cheers, Sue > > >

[bess] IETF 114 time slot update

Hi Mankamana and chairs One additional draft added below. I have already requested a 10 minute time slot for the following drafts: IPv6-Only PE design - updates on development work on this draft https://datatracker.ietf.org/doc/draft-ietf-bess-ipv6-only-pe-design/ IPV6 Only PE design All SAFI

Re: [bess] FW: WG adoption call for draft-chen-idr-bier-te-path-04.txt (6/22/2022 to 7/6/2022

) Does this mechanism correctly integrates into > > a) the BIER architecture (draft-ietf-bier-te-arch) and > > b) Multicast VPNs (BESS)? > > > > 3) Will this technology aid the deployment of > > Bier multicast forwarding in operational networks? > > > > Cheers, Sue >

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-redundant-mcast-source

tephane & Matthew > > > > > > [1] > > https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-redundant-mcast-source/ > > [2] > > > > https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw > > > ___ > BESS mailing list > BESS@ietf.or

[bess] IETF 114 time slot

design All SAFI - Introduction https://datatracker.ietf.org/doc/draft-mishra-bess-ipv6-only-pe-design-all-safi/ IPv4 Only PE design - Introduction https://datatracker.ietf.org/doc/draft-mishra-bess-ipv4-only-pe-design/ Thank you Gyan -- <http://www.verizon.com/> *Gyan Mishra* *N

Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

yan, > > > > Please see zzh4> below. > > > > > > Juniper Business Use Only > > *From:* Gyan Mishra > *Sent:* Saturday, May 21, 2022 2:05 AM > *To:* Jeffrey (Zhaohui) Zhang > *Cc:* BESS ; Bidgoli, Hooman (Nokia - CA/Ottawa) < > hooman.bidg...@nokia.com>;

Re: [bess] [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR

cast https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-00 BGP Multicast Controller https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-09#section-3.1.1 Kind Regards Gyan On Mon, May 30, 2022 at 9:56 AM Gyan Mishra wrote: > I agree with S

Re: [bess] [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR

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. > ___ > Pals mailing list > p...@ietf.org > https://www.ietf.org/mailman/listinfo/pals > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Enhancing lsp ping (in extension to draft-ietf-bess-evpn-lsp-ping)

n few places in the doc, else we can add a > section to call it out. > > Regards, > Saumya. > > Get Outlook for Android <https://aka.ms/ghei36> > > ------ > *From:* Gyan Mishra > *Sent:* Friday, 20 May 2022, 19:58 > *To:* Dikshit, Sau

Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

Hi Jeffrey Pleas see Gyan4> Kind Regards On Fri, May 20, 2022 at 10:59 AM Jeffrey (Zhaohui) Zhang wrote: > Hi Gyan, > > > > Please see zzh3> below. > > > > > > Juniper Business Use Only > > *From:* Gyan Mishra > *Sent:* Thursday, May 12, 2022

Re: [bess] Enhancing lsp ping (in extension to draft-ietf-bess-evpn-lsp-ping)

mode > > - DP only check > > Please feel free to add. If this can be generalized for any solution > (EVPN, L3VPN, L2VPN->VPLS/VPWS) provisioned over MPLS fabric. > > Thanks > > Saumya. > > > > > > *From:* Dikshit, Saumya > *Sent:* Monday, O

Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

ontainers versus encoding as defined in SR policy draft? https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-17 Jeffrey > > > > > > Juniper Business Use Only > > *From:* Gyan Mishra > *Sent:* Thursday, April 28, 2022 12:19 AM > *

Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

Hi Jeffrey Please see Gyan2> On Tue, Apr 12, 2022 at 11:02 AM Jeffrey (Zhaohui) Zhang wrote: > Hi Gyan, > > > > Please see zzh2> below. > > > > > > Juniper Business Use Only > > *From:* Gyan Mishra > *Sent:* Friday, April 8, 2022 8:48 PM > *T

Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

Hi Jeffrey Please see Gyan> On Tue, Apr 5, 2022 at 7:38 PM Jeffrey (Zhaohui) Zhang wrote: > Hi Gyan, > > > > Please see zzh> below for my view. > > > > > > Juniper Business Use Only > > *From:* Gyan Mishra > *Sent:* Tuesday, March 29, 2022

Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

or those implementing this > > technology and those deploying the technology? > > > > 4) Do you think this multicast technology is a good > > Place to start for P2MP policy advertisement via BGP? > > > > Zzh> Both ways are good place to start. We just need to figure out how to > proceed with the two proposals. > > > > 5) Do you think this SR P2MP policies should not be advertised > > via BGP? > > > > Zzh> I do think BGP signaling for SR P2MP is appropriate. We just need to > discuss the two ways and figure out how to proceed. The authors have > discussed before though we have not reached consensus. > > Zzh> Thanks! > > Zzh> Jeffrey > > > > Cheers, Susan Hares > ___ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess

Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

Hi Ketan Responses in-line On Thu, Mar 17, 2022 at 1:15 PM Ketan Talaulikar wrote: > Hi Gyan, > > Please check inline below for responses. > > > On Wed, Mar 16, 2022 at 8:08 PM Gyan Mishra wrote: > >> >> Hi Ketan >> >> I reviewed the updated s

Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

t at IETF-111. It was on >>> the agenda in the “if time allows” section. I assume time did NOT allow >>> because I don’t see mention of it in the minutes. (I did find the slides, >>> slides 3 and 4 summarize the critique, >>> https://da

Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

this scenario, RRs are always >> required to support it if we want to get it right. >> If "RR peers" means other PEs, it is the expected result that PEs don't >> support the new capability will not receive the new kind of UPDATE >> messages. So the dropping

Re: [bess] Please send me slot request for IETF 113 (BESS is only remote )

t; > > > > > Mankamana > ___ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitec

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-mh-split-horizon

ke the necessary edits to make the > text consistent with that, as part of this WGLC. > > > > Thanks! > > Jorge > > > > *From: *Gyan Mishra > *Date: *Tuesday, February 15, 2022 at 8:37 PM > *To: *Rabadan, Jorge (Nokia - US/Sunnyvale) > *Cc: *Anoop Ghanwani , BESS

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-mh-split-horizon

e be MPLSoGRE RFC 4023 and all other NVO tunnels are Non MPLS based. Many Thanks Gyan On Thu, Feb 10, 2022 at 4:10 PM Gyan Mishra wrote: > > I support publication. > > Thanks > > Gyan > > On Sat, Feb 5, 2022 at 1:41 AM Rabadan, Jorge (Nokia - US/Sunnyvale) < &

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

sure that the >> BGP >> service information (including associated SRv6 SID) advertised via BGP >> sessions >> are limited to peers within this trusted SR domain." This is related to >> (from >> RFC8402): "Therefore, by default, the explicit rou

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

: > Gyan, > > MPLS is never sent in SAFI 1. > > Thx, > R. > > On Sun, Feb 13, 2022 at 5:47 AM Gyan Mishra wrote: > >> Hi Robert >> >> On Sat, Feb 12, 2022 at 4:23 PM Robert Raszuk wrote: >> >>> Gyan, >>> >>> Section 5.3 and 5.4

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

However I am for providing overlay reachability over global IPv6 Internet > to interconnect customer sites. But routing within those sites should not > be traversing Internet routers and using SAFI 1. > > Rgs, > Robert. > > -- <http://www.verizon.com/> *Gyan Mi

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

Hi Andrew On Sat, Feb 12, 2022 at 9:41 PM Gyan Mishra wrote: > Hi Andrew, > > On Sat, Feb 12, 2022 at 5:13 PM Andrew - IETF > wrote: > >> Hi Gyan, >> >> >> >> A few clarifications on your clarifications – see responses inline: >> >> RFC8

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

t the SID’s are exposed (albeit as addresses) – which still leads > to the problem of the fact that this seems to rely on perfect bgp filtering > in combination with perfect border filtering, and a failure in either that > could have catastrophic consequences. > > Gyan> As e

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

g, we really do need to find a way to clarify it, if its not > a misunderstanding, then we need to find a way to rectify it for security > purposes and to bring it in-line with RFC8402. > > Gyan> Understood. We can update the verbiage to make it crystal clear. > > T

Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

surface to >> include the customer's networks too. >> >> Not only does an operator have to ensure that BGP leaks never occur, they >> have >> to then ensure that at no point can there be any filter lapses at any >> border >> node, and be able to guarantee the security of every device, server and >> machine >> within the domain in order for a secure posture to be maintained. Simply >> saying >> that precautions should be taken to make sure that route leak don't >> occur, when >> the consequences of doing so are a: severe and b: hard to recover from >> seems to >> not really cover it. In addition, it seems that the blast radius from a >> missing >> ACL seems much larger if it allows injections. >> >> >> -- >> COMMENT: >> -- >> >> I'm still reviewing the document, but wanted to get an initial ballot in, >> so >> that we could start discussing it. Hopefully someone can help my >> understand how >> this doesn't expand the consequences of a BGP leak. >> >> >> ___ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-mh-split-horizon

it-horizon/ > > [2] > https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw > > > > ___ > 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 * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

f-recovery-03 - Fast Recovery for EVPN DF > Election > <https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/> > > [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 * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Query/comments on draft-ietf-bess-evpn-lsp-ping-05

t; > I can a Spin-out a rev-0 for a new draft. Let me know your thoughts. > > > > Regards, > > Saumya. > > > > *From:* Gyan Mishra [mailto:hayabusa...@gmail.com] > *Sent:* Wednesday, October 13, 2021 8:41 PM > *To:* Parag Jain (paragj) > *Cc:* BESS ; Dikshit,

Re: [bess] Query/comments on draft-ietf-bess-evpn-lsp-ping-05

te: *Thursday, September 2, 2021 at 1:42 PM > > > > [sending the queries in a different email with changed subject line] > > > > Hello Authors of draft-ietf-bess-evpn-lsp-ping draft, > > > > I have following queries regarding this draft: > > > > >>>> Do we intend-to-us

Re: [bess] Genart last call review of draft-ietf-bess-evpn-optimized-ir-09

with [jorge]. > > > > Please check them out. > > > > Thanks again, > > Jorge > > > > *From: *Gyan Mishra via Datatracker > *Date: *Saturday, October 2, 2021 at 8:09 PM > *To: *gen-...@ietf.org > *Cc: *bess@ietf.org , > draft-ietf-bess-evpn-optimiz

[bess] Genart last call review of draft-ietf-bess-evpn-optimized-ir-09

Reviewer: Gyan Mishra Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For

Re: [bess] WG adoption poll and IPR poll for draft-mohanty-bess-ebgp-dmz-03 [1].

for adoption closes on September 21st 2021. > > > > Regards, > > Matthew and Stephane > > > > > > [1] https://datatracker.ietf.org/doc/draft-mohanty-bess-ebgp-dmz-03/ > > > > > ___ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailm

Re: [bess] Implementation poll for draft-ietf-bess-evpn-lsp-ping-05

cosyeO0PYZjTGA5JLyFmli44UwE5yg$> > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > <https://urldefense.com/v3/__ftp:/ftp.ietf.org/internet-drafts/__;!!NEt6yMaO-gk!RoQdN1xrngG7wEPSC6AqHesQtzGvBMP82cosyeO0PYZjTGA5JLyFmli4trDqUTY$> > > > __

Re: [bess] [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

ices-07) > > > > *[External Email. Be cautious of content]* > > > > Hi All, > > > > As per this draft, this is how resolution must work. > > > > 1)For Non Intent service Route: > > if BGP next hop is not reachable return. > > Resolve SRv6 Service S

Re: [bess] NVO3 VXLAN Source port entropy

in v4, in linux kernel since 2016), stay tuned. > This is mostly relevant to DC domain and while host based still a very > important improvement. > > Cheers, > Jeff > > On Jul 14, 2021, at 18:21, Gyan Mishra wrote: > >  > > All > > I think I figured out how “s

Re: [bess] NVO3 VXLAN Source port entropy

ilar analogous to IPv6 flow label RFC 6437 5-tuple header hash input key to hash function stateless mode flow label uniform load balancing. Kind Regards Gyan On Wed, Jul 14, 2021 at 6:11 PM Gyan Mishra wrote: > > Dear BESS Experts > > ?? On NVO3 VXLAN overlay encapsulation > > My

[bess] NVO3 VXLAN Source port entropy

is RECOMMENDED that the value be in the dynamic/private port range 49152-65535 [RFC6335 <https://datatracker.ietf.org/doc/html/rfc6335>]. Kind Regards Gyan -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com *

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

viously, we are actually originating it at the AS > boundary. > > > > BTW, the cumulative link-bandwidth feature first went in XR in 6.1.1. We > can incorporate that in the addendum as well get the similar information > from other vendors. > > > > Thanks, > >

Re: [bess] WGLC, IPR and implementation poll on draft-ietf-bess-evpn-mh-pa-02

EVI route" >> >> >> >> Section 7 >> >> >> >> - spurious 'g'. >> >> >> >> - missing period under the second sub-bullet of point 'f'. >> >> >> >> >> >> On Mon,

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

every hop traversed. > > The alternative with add-path and potentially path explosion (not to talk > about operational complexity of add-path and bugs in the implementations) > is a rather unattractive solution for DC fabrics. > > Cheers, > Jeff > > On Fri, Jul 2, 2021 at

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

TH. > > > > Best Regards, > > --Satya > > > > > > *From: *"UTTARO, JAMES" > *Date: *Wednesday, May 26, 2021 at 5:38 AM > *To: *Gyan Mishra , Robert Raszuk < > rob...@raszuk.net> > *Cc: *Jeff Tantsura , Arie Vayner < > ar...@vayne

Re: [bess] Please send slot request for IETF 111

se do not change the > subject, last IETF I had missed few reply due to subject change ☺ > > > > Mankamana > ___ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > -- <http://www.verizon.

Re: [bess] WG POLL: Moving forward draft-ietf-bess-evpn-fast-df-recovery by dropping "Handshake" option

opening a poll starting today and ending on 18th June to > gather feedbacks. > > > > Thanks, > > > > Stephane > > > > https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/ > > > > > > > > >

Re: [bess] I-D Action: draft-ietf-bess-evpn-geneve-02.txt

tf.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 * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

gt; >>> >>> This feature has multiple-vendor implementations and has been deployed >>> by several customers in their networks. >>> >>> >>> >>> Best Regards, >>> >>> --Satya >>> ___ >>> BESS mailing list

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

cale. > > I support this draft. > > Cheers, > Robert > > PS. Also keep in mind that for handling elephant flows there are bunch of > TE like solutions in place which can be used which in turn give you very > fine control. > > On Tue, May 25, 2021 at 9:23 AM Gyan M

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

unity has been implemented by Cisco and deployed by >> >> our customers for several years. >> >> Polarization of flows in multipath is a well known problem, but it hasn't >> deterred >> >> people from using it. >> >> >> >> Regards, &

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

ws in multipath is a well known problem, but it hasn't > deterred > > people from using it. > > > > Regards, > > Jakob. > > > > *From:* BESS *On Behalf Of * Gyan Mishra > *Sent:* Tuesday, May 25, 2021 12:24 AM > *To:* Satya Mohanty (satyamoh) &g

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

is feature has multiple-vendor implementations and has been deployed by > several customers in their networks. > > > > Best Regards, > > --Satya > ___ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listin

Re: [bess] [Last-Call] Genart last call review of draft-ietf-bess-datacenter-gateway-10

Sorry, attached. Thanks Gyan On Wed, May 19, 2021 at 5:03 AM Adrian Farrel wrote: > Hi Gyan, > > Thanks for the work. > > > Attached is a txt version -gsm update of version 10 > > No attachment received. > > Best, > Adrian > > -- <http://www.verizo

Re: [bess] [Last-Call] Genart last call review of draft-ietf-bess-datacenter-gateway-10

net, maybe that should be mentioned. Kind Regards Gyan On Tue, May 18, 2021 at 4:49 PM John E Drake wrote: > Excellent, thanks so much for your help on this. > > Yours Irrespectively, > > John > > > Juniper Business Use Only > > > -Original Message-

Re: [bess] [Last-Call] Genart last call review of draft-ietf-bess-datacenter-gateway-10

d thank you all for the following > discussion. I have entered a No Objection ballot for this document based on > the current status of the discussion. > > Lars > > > > On 2021-4-29, at 8:46, Gyan Mishra via Datatracker > wrote: > > > > Reviewer: Gyan Mishra

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-mvpn-msdp-sa-interoperation-06: (with DISCUSS and COMMENT)

nt is only about IPv4 and not a single word is written about > IPv6. > > > ___ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

d in a BGP UPDATE >message for one of the address families for which [RFC8669] has a >defined behavior, namely BGP IPv4/IPv6 Labeled Unicast [RFC4760] > [RFC8277]. If included in a BGP UPDATE for any other address family, >it MUST be ignored. > > IOW, even though the overall mechanism could

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

that the ingress and egress domains now called “sites” not domains do not have to be SR enabled. Kind Regards Gyan On Mon, May 17, 2021 at 5:04 PM Gyan Mishra wrote: > Hi John > > I agree with your comments that the scenario I mentioned is covered in > Section 3 and agree as

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

Hi John I agree with your comments that the scenario I mentioned is covered in Section 3 and agree as well on the RFC 2119 keyword usage scrub. In-line On Mon, May 17, 2021 at 3:55 PM John Scudder wrote: > Hi Gyan, > > > On May 17, 2021, at 1:50 PM, Gyan Mishra wrote: >

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

onstructs each advertisement listing only the correct set of > gateways in the tunnel attribute > > > > The key question is the one I’ve highlighted: how does GW1 come to know > GW2’s internally-reachable prefixes? I didn’t notice any of this in the > spec. Maybe it was jus

Re: [bess] [Last-Call] Genart last call review of draft-ietf-bess-datacenter-gateway-10

uthors, would you please respond to Gyan's review? > > Thanks, > Lars > > > > On 2021-4-29, at 8:46, Gyan Mishra via Datatracker > wrote: > > > > Reviewer: Gyan Mishra > > Review result: Not Ready > > > > I am the assigned Gen-ART r

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

nnect-05 Kind Regards Gyan On Sat, May 15, 2021 at 12:35 AM Gyan Mishra wrote: > > Adrian & Authors please correct me if I misspeak the way I read the draft. > > I did not see in the draft stating explicitly how the internal DC GW > routes are advertised which I believe i

Re: [bess] John Scudder's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

SAFI 1, 128, 129. Kind Regards Gyan On Fri, May 14, 2021 at 10:45 PM Gyan Mishra wrote: > Hi Adrian > > I may have missed this in the draft but the solution for this failover > scenario is if each GW can only advertise itself, which I think that is > stated in section 3 then GW1

  1   2   3   >