Reviewer: Henning Rogge
Review result: Has Nits
Hi,
the RTGDIR asked me to do a review on draft-ietf-bess-evpn-igmp-mld-proxy
(which is currently in revision 12).
I do not follow the BESS WG (I mostly work with mesh routing protocols), but I
am familiar with the issue of "linklocal protocols" (l
Hi Authors,
Recently, we are preparing to use the L3VPN yang model, we check it with the
yang-validator at https://yangcatalog.org/yangvalidator,
and found the following errors:
Pyang Validation
/var/yang/tmp/yangvalidator/yangvalidator-v2-workdir-TwlCIaOZ/ietf-bgp-l3...@2018-04-17.yang:508:
er
Hello Jorge,
Sorry for belated reply… IETF week and some holidays were on the path...
The -14 revision has vastly improved the document and has addressed the
majority of my points. There are anyway still one open blocking DISCUSS point
and three COMMENT points (but feel free to ignore them).
S
Hi Matt,
I would submit the changes which I had mentioned in below email. Some of the
open questions not addressed in this version. Would wait to hear back from you.
Mankamana
From: Mankamana Mishra (mankamis)
Date: Tuesday, September 7, 2021 at 6:03 AM
To: Matt Joras , gen-...@ietf.org
Cc: be
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
Title : IGMP and MLD Proxy for EVPN
Authors : Ali Sajassi
Samir Thoria
Hi Henning,
Thanks for comment. Please find inline comments.
From: Henning Rogge via Datatracker
Date: Tuesday, September 14, 2021 at 12:51 AM
To: rtg-...@ietf.org
Cc: bess@ietf.org ,
draft-ietf-bess-evpn-igmp-mld-proxy@ietf.org
, last-c...@ietf.org
Subject: Rtgdir last call review of dr
Hi Brian,
Thanks for comment. Please find inline comment. Waiting on some more review
comments before publish the next version of document.
AI from this comment :
* Add reference to RFC6513, RFC6514 in terminology section
* Define (S,G), (*,G) in terminology section
Mankamana
From: Br
Hi Satya,
That is part of the optional procedure to provide backwards compatibility. An
implementation would likely to have configuration controlling whether this
procedure is used or not.
For the origination of per-region I-PMSI routes, whether it is for the purpose
of backwards compatibility
Hi Gorry,
Thank you for your comments. I missed it hence the late response. Sorry about
that.
Please see zzh> below.
-Original Message-
From: Gorry Fairhurst via Datatracker
Sent: Monday, August 30, 2021 5:59 AM
To: tsv-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-evpn-bum-procedure
Hi Scott,
In the example of "5.3. Backward Compatibility", seems that it is already in
the following format?
" if you want to X then do these steps
1
2
3
"
---
Specifically, section 5.3 has the following text:
The above procedures assume that all PEs are upgra
Hi Jeffrey,
Thanks for your reply.
It makes perfect sense.
Am I to assume that the same reasoning applies to Inter-as MVPN as well since
EVPN BUM procedures is based significantly on MVPN procedures?
Best Regards,
--Satya
From: "Jeffrey (Zhaohui) Zhang"
Date: Tuesday, September 14, 2021 at 12
Hello All,
Getting back on this topic with a text update proposal for sec 5 and 6 of the
draft.
The objective of this change is to clarify the use of the SHOULD that is used
in this text.
OLD/CURRENT
When providing best-effort connectivity to the egress PE, the ingress
PE encapsulates th
12 matches
Mail list logo
