Last Call Review of draft-ietf-bess-mvpn-evpn-aggregation-label-10
review-ietf-bess-mvpn-evpn-aggregation-label-10-opsdir-lc-dodge-2023-07-02-00
Request | Review of | draft-ietf-bess-mvpn-evpn-aggregation-label |
---|---|---|
Requested revision | No specific revision (document currently at 14) | |
Type | Last Call Review | |
Team | Ops Directorate (opsdir) | |
Deadline | 2023-07-12 | |
Requested | 2023-06-28 | |
Authors | Zhaohui (Jeffrey) Zhang , Eric C. Rosen , Wen Lin , Zhenbin Li , IJsbrand Wijnands | |
I-D last updated | 2023-07-02 | |
Completed reviews |
Secdir Last Call review of -10
by Robert Sparks
(diff)
Opsdir Last Call review of -10 by Menachem Dodge (diff) Genart Last Call review of -10 by Russ Housley (diff) Rtgdir Last Call review of -08 by Tony Przygienda (diff) |
|
Assignment | Reviewer | Menachem Dodge |
State | Completed | |
Request | Last Call review on draft-ietf-bess-mvpn-evpn-aggregation-label by Ops Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/ops-dir/odGdR2Xs9nszjA4XIb7_WHPPYkw | |
Reviewed revision | 10 (document currently at 14) | |
Result | Has nits | |
Completed | 2023-07-02 |
review-ietf-bess-mvpn-evpn-aggregation-label-10-opsdir-lc-dodge-2023-07-02-00
Hello, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. The document is well written. Summary: For MVPN and EVPN networks where P2MP or MP2MP tunnels are used to carry traffic, the ingress routers allocate an upstream label for each VPN or for each BD. This can lead to the egress routers needing to keep track of large numbers of labels that can be greatly reduced if the association between a label and a VPN or BD is made by provisioning, so that all ingress routers assign the same label to a particular VPN or BD. The document is for the standards track. Nits ==== 1. Section 2.2, 5th paragraph - missing word: OLD --> However, that is not necessary as the labels used by PEs for the purposes defined in this document will only rise to the top of the label stack when traffic arrives the PEs. SUGGEST --> However, that is not necessary as the labels used by PEs for the purposes defined in this document will only rise to the top of the label stack when traffic arrives at the PEs. 2. Section 2.2, Last Paragraph - sentence not clear: OLD --> Allocating a label from the DCB or from those a few context-specific label spaces and communicating them to all PEs is not different from allocating VNIs, and is feasible in today's networks since controllers are used more and more widely SUGGEST --> Allocating a label from the DCB or from a context-specific label space and communicating them to all PEs is not different from allocating VNIs, and is feasible in today's networks since controllers are used more and more widely 3. Section 2.2.3, first sentence: OLD --> In summary, labels can be allocated and advertised the following ways: SUGGEST --> In summary, labels can be allocated and advertised in the following ways: 4. Section 2.2.3, point 3 - sentence is unclear. "A central authority assigns disjoint label blocks from those a few context-specific label spaces to each PE, and allocate labels from the DCB to identify the context-specific label spaces." Thank you kindly. Best Regards, Menachem Dodge