version.
>
>
>
> https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-14.html
>
>
>
> Thanks & Regards,
>
> Reshma Das
>
>
>
> Juniper Business Use Only
>
> *From: *Anoop Ghanwani
> *Date: *Monday, July 28, 2025 at 1:20 PM
> *To: *
I support the progression of this doc for publication as RFC.
I have a couple of terminology questions and an editorial nit.
Questions:
The doc starts out by saying this allows one to perform unequal cost load
balancing. Would it be more precise to say WECMP (which is the term used
in the rest
It looks like "in the future" really means "subsequently (in the rest of
the document)" rather than "in the figure".
On Wed, Jul 2, 2025 at 6:35 AM Madison Church
wrote:
> Hi Gunter,
>
> We are unable to verify this erratum that the submitter marked as
> editorial, so we changed the Type to “Tec
I had a couple of minor editorial nits on this. I sent them offline to
Linda and she suggested I send them to the list.
SDWAN is normally written SD-WAN.
C-PE is not defined.
We are missing an expansion/reference for NHRP, and also expansion for
DMVPN/DSVPN. I wonder if we can have better refe
use of the ethernet option TLV in
> all cases.
>
>
>
> Thanks.
>
> Jorge
>
>
>
> *From: *Anoop Ghanwani
> *Date: *Sunday, December 18, 2022 at 3:49 AM
> *To: *Boutros, Sami
> *Cc: *Boutros, Sami , UTTARO, JAMES <
> ju1...@att.com>, Jorge Ra
dures used by EVPN
MPLS.
On Sat, Dec 17, 2022 at 6:33 PM Anoop Ghanwani
wrote:
> Sami,
>
> Why is it recommended to carry the TLV if local bias is in use? (I
> understand the need for it if we're not using local bias.)
>
> Anoop
>
> On Sat, Dec 17, 2022 at 2:
n this, may be you can propose something.
>
>
>
> It is quite clear to me and to the authors, and I hope to everyone else,
> how the TLV can be used for SH as a mechanism similar to local bias, as
> well it can be used when ETREE support is needed.
>
>
>
> Thanks,
>
ultihoming is in use. But this is not necessary or even
valuable if Local Bias is in use.
On Wed, Jul 13, 2022 at 12:12 AM Anoop Ghanwani
wrote:
> Hi Sami,
>
> Thanks for updating the doc.
>
> Regarding this:
> >>>
>
> I find this statement confusing
>
>
Hi Sami,
Thanks for updating the doc.
Regarding this:
>>>
I find this statement confusing
While "local-bias" MUST be supported along with GENEVE encapsulation,
the use of the Ethernet option-TLV is RECOMMENDED to follow the same
procedures used by EVPN MPLS.
I'm not sure how i
I had only editorial comments on this one, and they all appear to be
fixed.
https://mailarchive.ietf.org/arch/msg/bess/3u6z_CaCS886H0yh4ebbILj37s4/
Thanks,
Anoop
On Thu, Jun 23, 2022 at 8:34 AM wrote:
> Hi Gyan, Anoop,
>
>
>
> As you commented during the WGLC, could you please confirm that this
a critical misalignment in the figure !
>
>
>
> I have moved the whole description section up into the encoding/extcomm as
> descriptive text of the fields themselves. Nice catch, thank you !
>
>
>
> Regards,
>
> Luc André
>
>
>
> Luc André Burdet |
I support the publication of the draft as an RFC.
Below are some minor editorial comments.
Anoop
==
Multiple sections
Probably better to replace all uses of Ethernet Segment with ES rather than
use them at random.
Section 1
Expand first use of "SID".
will keeo following
->
will keep followi
I support publication of the document as an RFC. However, I think there
are some editorial nits that need to be addressed (see below).
Anoop
==
Abstract
performed via a simple signaling between the recovered PE
and each PEs in the multi-homing group.
->
performed via simple signaling betwee
sset) <
pbris...@cisco.com> wrote:
> Anoop,
>
>
>
> Which specifics haven’t we answer?
>
>
>
> Regards,
>
> Patrice Brissette, Principal Engineer
>
> Cisco Systems
>
>
>
> *http://e-vpn.io <http://e-vpn.io>*
>
> *http://go2.cis
confirm that you are fine with the changes proposed by Luc, so
> we can move the draft forward to next steps ?
>
>
>
> Thanks !
>
>
>
>
>
> *From:* Anoop Ghanwani
> *Sent:* lundi 5 juillet 2021 21:39
> *To:* Luc André Burdet
> *Cc:* slitkows.i...@gmail.com
I had a couple of comments that I would appreciate a response on.
https://mailarchive.ietf.org/arch/msg/bess/hMvrFYS1LkUPekW1p86Culd3NJY/
On Tue, Oct 19, 2021 at 8:42 AM Bocci, Matthew (Nokia - GB) <
matthew.bo...@nokia.com> wrote:
> WG
>
>
>
> I believe there is consensus to publish this documen
I support the publication of this draft. I have the following comments
and suggested edits.
--
Technical comments
Section 4.1
I find this statement confusing
While "local-bias" MUST be supported along with GENEVE encapsulation,
the use of the Ethernet option-TLV is RECOMMENDED to follow
Sorry, sent to the wrong thread. Will resend to the correct one.
On Mon, Sep 27, 2021 at 11:02 PM wrote:
> Hi,
>
>
>
> This email starts a two-week working group last call for
> draft-ietf-bess-evpn-vpws-fxc [1]
>
>
>
> Please review the draft and send any comments to the BESS list. Also, plea
I support the publication of this draft. I have the following comments
and suggested edits.
--
Technical comments
Section 4.1
I find this statement confusing
While "local-bias" MUST be supported along with GENEVE encapsulation,
the use of the Ethernet option-TLV is RECOMMENDED to follow
gt; Regards,
>
> Luc André
>
>
>
> Luc André Burdet | Cisco | laburdet.i...@gmail.com | Tel: +1 613 254
> 4814
>
>
>
>
>
> *From: *BESS on behalf of Anoop Ghanwani <
> an...@alumni.duke.edu>
> *Date: *Tuesday, June 1, 2021 at 19:23
> *To: *"sli
>
> Other people may come with different solution in the future if needed be.
>
>
>
> Regards,
>
> Patrice Brissette, Principal Engineer
>
> Cisco Systems
>
>
>
> *http://e-vpn.io <http://e-vpn.io>*
>
> *http://go2.cisco.com/evpn <http://go
My only concern with the time sync approach is that it imposes the
requirement for some kind of time sync protocol (either ntp or ptp). From
what I understand, running these in the data center is not that common.
On Fri, Jun 4, 2021 at 2:19 AM wrote:
> Hi WG,
>
>
>
> Just as a reminder, draft-i
I support publication of this document. The following are my comments.
==
Abstract
- I think it would be better to list the RFC rather than say "EVPN
standard", since EVPN standard is an evolving term.
- "support of port-active" -> "support for port-active"
- The last line of the abstract shoul
The security considerations section is empty. Is it possible to have that
updated before the WGLC?
I will try to review and provide more detailed comments.
On Mon, Jan 18, 2021 at 12:58 AM wrote:
> This email starts a two-week working group last call for
> draft-ietf-bess-evpn-irb-extended-mob
There are also a couple of idnits, one of them being a missing reference
for GENEVE.
On Sat, Sep 5, 2020 at 11:18 AM Anoop Ghanwani
wrote:
> Reading the doc, I found several editorial nits. I'm half way through and
> these are the comments. If there is interest in addressing t
Reading the doc, I found several editorial nits. I'm half way through and
these are the comments. If there is interest in addressing them, I will
send comments on the remainder.
throughout
- document uses route type, Route Type, route type-, RT-.
Would be good if it consistently used RT- no
Linda,
The draft references RFC 3948 which already covers this.
https://tools.ietf.org/html/rfc3948#section-3.2
Anoop
On Tue, Jul 28, 2020 at 4:17 PM Linda Dunbar
wrote:
> Ali,
>
>
>
> Thank you very much for the explanation.
>
>
>
> IPsec ESP Transport mode header is :
>
>
>
> Do you need IPs
favorite order for receiving, and every sender is required to implement all
options. Further, if a systems vendor has silicon from multiple vendors,
their
own control plane may be forced to operate differently.
On Sat, Jul 18, 2020 at 11:40 PM Anoop Ghanwani
wrote:
> I have reviewed the doc
I have reviewed the doc and have the following comments.
Anoop
==
authors:
Jorge is listed as working at Juniper but with a Nokia address. :)
Throughout the document:
Mixed use of GENEVE and Geneve.
Suggest making it consistent (should be Geneve per the Geneve draft).
There are also several occu
I'm OK with the changes mentioned below (remove the field and require RR to
accept both lengths).
I think RR accepting both lengths should be a SHOULD rather than a MUST (it
would be more accommodative of implementations), but I could probably live
with the MUST.
Anoop
On Thu, Apr 23, 2020 at 1:
." -> "The PE that has the highest hash..."
"one per-bandwidth..." -> "one per bandwidth..."
- pg 14
"[WEIGHTED-HRW] document describes..." -> "[WEIGHTED-HRW] describes..."
- pg 16
"PE_CE" -> "PE-CE"
There appear
I decided to look at the draft and will send my mostly editorial comments
in a day or so. Sorry for the delay.
But what I find really surprising is that the draft made it through WGLC
without IANA considerations or security considerations sections. I thought
those were mandatory. I haven't been
send it across. We are going to make changes about editorial
> comment right after WGLC and post updated version.
>
>
>
> Thanks
>
> Mankamana
>
>
>
>
>
> *From: *Anoop Ghanwani
> *Date: *Saturday, June 29, 2019 at 1:04 AM
> *To: *"stephane.litko
I support the publication of the document as an RFC.
I have several editorial comments and I'll send them in a Word document
markup to the authors.
If the mailing list accepts attachments, I'd be happy to post it here as
well.
Thanks,
Anoop
On Mon, Jun 17, 2019 at 1:53 AM wrote:
> Hello Worki
Message-
> From: BESS on behalf of "Satya Mohanty (satyamoh)"
>
> Date: Friday, December 7, 2018 at 6:09 PM
> To: Anoop Ghanwani , "bess@ietf.org"
> Subject: Re: [bess] Last Call:
> (Framework for EVPN
> Designated Forwarder Election Extensibility)
t;
>> Kind regards,
>> Greg
>>
>> On Wed, Dec 19, 2018 at 5:19 AM Reshad Rahman (rrahman)
>> wrote:
>>>
>>> +1 to Anoop's comments. I've made similar comment to Greg privately, and
>>> Anoop's proposed text clears things up.
nd End Station
> are used interchangeably.
>
> If my understanding of the proposed update is correct, I'd be glad to use it
> (adding RFC 8365 as Informational reference). Should note that in the draft
> we never used "End Station". Perhaps the last sentence is not
I would change the introduction to the following to mention the use of
VXLAN by BGP EVPN.
Thanks,
Anoop
==
"Virtual eXtensible Local Area Network" (VXLAN) [RFC7348] provides
an encapsulation scheme that allows building an overlay network by
decoupling the address space of the attached v
I have reviewed the doc and I have mostly editorial comments.
Thanks,
Anoop
==
Throughout
VLAN Bundle, VLAN bundle, VLAN-Bundle, VLAN-bundle -- make consistent
VLAN Aware Bundle, VLAN-aware bundle, VLAN-Aware Bundle -- make consistent
bridge table, Bridge Table -- make consistent (also add defi
all the DC MAC addresses in the control/management plane is
> usually the case when the NVEs reside in hypervisors. Refer to
> [EVPN-Overlays] section 7.”
>
>
>
> Thank you.
>
> Jorge
>
>
>
> *From: * on behalf of Anoop Ghanwani <
> an...@alumni.duke.edu>
&g
t;addresses and/or the Unknown MAC route are advertised into a given
>
>DC. As an example, when all the DC MAC addresses are learned in the
>
>control/management plane, it may be appropriate to advertise only the
>
>Unknown MAC route.
>
>
>
> Is it not en
e.
>
>
>
> Is it not enough?
>
>
>
> Thank you.
>
> Jorge
>
>
>
> *From: *BESS on behalf of Anoop Ghanwani <
> an...@alumni.duke.edu>
> *Date: *Tuesday, January 23, 2018 at 1:47 AM
> *To: *"bess@ietf.org"
> *Subject: *Re: [bess]
I have a question about the following paragraph in this draft:
>>>
The solution specified in this document uses the 'Unknown MAC' route
which is advertised into a given DC by each of the DC's GWs. This
route is a regular EVPN MAC/IP Advertisement route in which the MAC
Address Length
hat this draft has already gone through
> the WG LC.
>
> Cheers,
> Ali
>
> From: on behalf of Anoop Ghanwani <
> an...@alumni.duke.edu>
> Date: Wednesday, July 19, 2017 at 9:11 AM
> To: Cisco Employee
> Cc: "bess@ietf.org" , "n...@ietf.org"
&
ed onto a single MAC-VRF (in case of VLAN-aware bundle service).
>>>
Anoop
On Wed, Jul 19, 2017 at 12:14 AM, Ali Sajassi (sajassi)
wrote:
>
> From: BESS on behalf of Anoop Ghanwani <
> an...@alumni.duke.edu>
> Date: Tuesday, July 18, 2017 at 10:39 PM
> To: "
This is what the draft says about bundled service:
https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-08#section-4
>>>
8) When a 802.1Q interface is used between a CE and a PE, each of the
VLAN ID (VID) on that interface can be mapped onto a bridge table
(for upto 4094 such bridge tabl
46 matches
Mail list logo
