Hi Menachem, Thanks for your review and comments. Please see zzh> below.
Juniper Business Use Only -----Original Message----- From: Menachem Dodge via Datatracker <[email protected]> Sent: Sunday, July 2, 2023 4:58 AM To: [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: Opsdir last call review of draft-ietf-bess-mvpn-evpn-aggregation-label-10 [External Email. Be cautious of content] Reviewer: Menachem Dodge Review result: Has Nits 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. Zzh> Fixed. 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 Zzh> Fixed. 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: zzh> Fixed. 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." Zzh> What it tries to say is: Zzh> a) a central entity breaks a few label spaces into disjoint blocks and assign those blocks to PEs Zzh> b) it also allocates some labels from the DCB, one for each of those label spaces Zzh> I tweaked the entire paragraph slightly and it now reads: 3. A central entity assigns disjoint label blocks from a few context-specific label spaces to each PE, and allocates labels from the DCB to identify those context-specific label spaces. A PE independently allocates a label for a segmented S-PMSI from its assigned label block, and advertises the label along with the context-identifying label. Zzh> Please let me know if this works. I will post the revision after the quiescence period is over. Zzh> Thanks. Zzh> Jeffrey Thank you kindly. Best Regards, Menachem Dodge _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
