in 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
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
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"
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
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
.
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
is the 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
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
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) <
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,
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
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
ersus 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
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
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
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
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
>
>
> _______
>
/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
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!
>
> J
mage: 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-meeting
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
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/>
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
/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
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/
>
>
> _____
>
>
>
> [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://www.v
>> 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 s
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
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
>
>
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
) 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
>
ne & 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.org
>
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
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>;
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 wi
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
t in 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
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
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
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
> *
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
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
hnology 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
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
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://datatra
red 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 the new routes sent to these PEs is not a
>&g
gt;
>
>
>
> Mankamana
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
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
able 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) <
&
P
>> 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 routing information MUST
>
:
> 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
owever 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 Mishra*
*Ne
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
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
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
o
>> 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
rizon/
>
> [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
overy-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
>
> 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,
day, 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-use/call-out
gt;
>
> 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-optimized-ir@ietf.org &
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 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
5JLyFmli44UwE5yg$>
>
>
> 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$>
>
>
>
-srv6-services-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
ort 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
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
, it
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 *
*M
ed previously, 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,
>
>
oute"
>>
>>
>>
>> Section 7
>>
>>
>>
>> - spurious 'g'.
>>
>>
>>
>> - missing period under the second sub-bullet of point 'f'.
>>
>>
>>
>>
>>
>> On Mon, May 31, 2021 at 12:31 AM
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, 20
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
Please 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.verizo
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/
>
>
>
>
>
>
>
>
> __
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
t;>
>>> This feature has multiple-vendor implementations and has been deployed
>>> by several customers in their networks.
>>>
>>>
>>>
>>> Best Regards,
>>>
>>> --Satya
>>> ___
>>> BESS mailing list
>>&
nal scale.
>
> 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 Gy
ommunity 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,
>&g
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)
>
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
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
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-
> >
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 Mi
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
t;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 not be SR-specific,
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 a
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:
>
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 just my slopp
s, 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 reviewer fo
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 implicitly
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
>>>
>>>
>>> [NM]: clarified in section 4.
>>>
>>>
>>>
>>> - [BGP-LINK-BW] advertises the bandwidth in unit of bytes (not bits!)
>>> per second. Could the unit of the new EVPN Link Bandwidth extended
>>> community
eBGP tie to the core comes Up. Problem solved.
Kind Regards
Gyan
On Fri, May 14, 2021 at 7:02 PM Gyan Mishra wrote:
>
> Hi Adrian
>
> I believe what John is describing is a valid failure scenario where one of
> the GWs is no longer a valid gateway because it’s eBGP peering t
>
>
> Yes, that’s understood, but I was positing a case where just because GW1
> can reach GW2 stably, and just because GW1 can reach X stably, it does not
> imply GW2 can reach X.
>
> —John
>
> ___
> BESS mailing list
> BESS@i
Hi Jeffrey
I am all set with the draft technical Q as this draft fills an important
gap for operators, I believe is in excellent shape ready for publication.
Thank you
Gyan
On Tue, May 11, 2021 at 11:08 AM Gyan Mishra wrote:
>
> Thanks Jeffrey for the explaining section 14 and your
gt;
> Otherwise, RFC6514 rules apply: MSDP accepts/rejects SAs based on it's
> peer-RPF rules and MVPN uses BGP selection rules to determine the best
> route.
>
> Hope this answers your questions,
>
> -Lenny
>
> On Tue, 11 May 2021, Gyan Mishra wrote:
>
> |
> | Thanks
om a Shared C-Tree to a Source C-Tree" in RFC 6514).
>
> Thanks.
>
> Jeffrey
>
> -Original Message-
> From: Gyan Mishra
> Sent: Friday, May 7, 2021 12:55 PM
> To: Jeffrey (Zhaohui) Zhang
> Cc: Lenny Giuliano ; Qin Wu ; bess
> ; draft-ietf-bess-mvpn-msdp-sa-intero
g more clarifications will pull in more and more
> concepts/procedures like a chain reaction, so I'd rather avoid that.
>
> Zzh3> Thanks.
>
> Zzh3> Jeffrey
>
>
>
> [Qin3]: I think the confusing issue comes from " It MUST NOT
>
Reviewer: Gyan Mishra
Review result: Not Ready
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 more
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/
>
>
>
>
> ___
> 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
1 - 100 of 239 matches
Mail list logo
