Re: [bess] Opsdir last call review of draft-ietf-bess-mvpn-evpn-aggregation-label-10

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Menachem,

Thanks for your review and comments.
Please see zzh> below.


Juniper Business Use Only
-----Original Message-----
From: Menachem Dodge via Datatracker <[e-mail]>
Sent: Sunday, July 2, 2023 4:58 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
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