As co-author I support this document for WG adoption.
I’m not aware of any relevant IPR.
Thanks,
Senthil.
From: Jorge Rabadan (Nokia)
Sent: Wednesday, March 6, 2024 9:59 PM
To: Jeffrey (Zhaohui) Zhang ; 'BESS' ;
draft-sr-bess-evpn-dp...@ietf.org
Cc: idr@ietf. org ; 'bess-cha...@ietf.org'
As co-author, I support this document for WG adoption.
Not aware of any related undisclosed IPR.
This document specifies the use of D-PATH for EVPN routes used in ELAN and
ELINE services, it provides inter-domain visibility and prevents control plane
loops in an automatic way. There are
Hi Saumya,
Having a different RD for the MAC/IP Advertisement route and the IP A-D per EVI
route for the same ESI does not impose any issues. The RD should not be used in
the EVPN IP route resolution process. But note this is also the case for
Ethernet Aliasing.
As you can see in the route
John Scudder has entered the following ballot position for
draft-ietf-bess-evpn-irb-mcast-11: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
Saumya,
Thank you very much for reviewing the document and providing the comments.
Please see the detailed resolutions to your comments below.
Linda
From: Dikshit, Saumya
Sent: Sunday, March 3, 2024 5:14 PM
To: Linda Dunbar
mailto:linda.dun...@futurewei.com>>;
Hi,
This email begins a two-week WG adoption and IPR poll for
draft-sr-bess-evpn-dpath-04
(https://datatracker.ietf.org/doc/draft-sr-bess-evpn-dpath/).
Please review the draft and post any comments to the BESS working group list.
The IDR list is copied in this call because of the Domain
Hi Roman,
Thanks for your review and comments.
I will make some changes and post after the pre-IETF119 quiescence period is
over.
Please see zzh> below for some clarifications.
Juniper Business Use Only
-Original Message-
From: Roman Danyliw via Datatracker
Sent: Tuesday, March 5,
Hi Jorge,
I completely understand that IP AD per EVI route should carry the IP-VRF RD.
But with IP-aliasing, we are creating case where-in:
1. an attached ES is leveraged for both MAC-aliasing and IP-aliasing
(host routes) via MAC routes and /32 routes respectively
a. Both are
