Re: [bess] draft-ietf-bess-mvpn-evpn-aggregation-label-05 shepherd's review

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

Hi, Stephane,

Thanks you so much for your review!

Please see zzh> below (I skipped all those that will be fixed as you pointed out).

From: Stephane Litkowski (slitkows) <[e-mail]>
Sent: Monday, April 12, 2021 5:56 AM
To: [e-mail]
Cc: [e-mail]
Subject: draft-ietf-bess-mvpn-evpn-aggregation-label-05 shepherd's review

[External Email. Be cautious of content]

Hi,

Here is my review of the document:

Section 2.2:
s/the DCB MUST not intersect/the DCB MUST NOT intersect/

I don’t fully understand the purpose of the second part of the sentence :

“or those routers MUST be
   considered as part of the "domain".”

I think the DCB must not intersect with any other label block (common, or dynamic), otherwise there will be some issues.
That’s different from SRGB where each node could have a different one. This should be highlighted I think.

Zzh> The complete text is:


   If these PEs share other common

   label blocks (e.g.  SRGB) with other routers, the DCB MUST not

   intersect with those common label blocks or those routers MUST be

   considered as part of the "domain".

Zzh> The DCB can actually be part of a SRGB that is a common block on all routers (then each DCB label will take place of a SID from the SRGB), but we don’t want to simply say that DCB is part of a common SRGB.
Zzh> The PEs can be considered to be in a domain of themselves (separate from the SR domain when all routers use a “common” SRGB – where all those SRGBs are the same) for the purpose of defining “Domain-common Label Block”. Let’s say there are 10 PEs and the DCB is [1000, 2000]. On those 10 PEs the [1000,2000] can’t be used for other purposes, but on internal P-routers, that [1000, 2000] can be used for other purposes and there is no need to set aside that block on those P-routers. In other words, the DCB does not have to, and better not to be part of the SRGB or some other common label blocks of for a larger set of routers. That’s what we try to say – either DCB does not intersect with for example SRGB (red text), or all the routers involved in the SRGB will have be considered as part of the domain for the DCB (purple text).
Zzh> Indeed it’s a bit convoluted, but hopefully now you see what we wanted to say. I’ll try to think of better wording – suggestions are appreciated.

Section 3.2:

“If PE Distiguisher…, they must be allocated” => should this be a MUST be ? Previous sentence is using normative language

“When a PE receives an x-PMSI…, it programs its…” => It should be :”it MUST program”

“The receiving PE then programs…” => It should be “Then, the receiving PE MUST program…”

“A PE MUST ignore a received route” => what do you mean by ignore ? drop the update received ?

zzh> I meant treat as if it was not received from MVPN/EVPN procedure point of view. I did not consider “dropping” it (such that it won’t be further propagated if this router is in the propagation path to more PEs). While I think it is fine if it is dropped because other PEs are supposed to ignore it as well, it may make debugging more difficult because you’d see it advertised by its peer yet kept not on this router.

Zzh> Yes we’ll add a security section 😊 Somehow we missed it.
Zzh> It is always a headache section to me though . Do you have any suggestions or foresee any security concerns?
Zzh> Will share an update once we get all done.
Zzh> Thanks.
Zzh> Jeffrey

“the label in the PTA … is treated as” => MUST be treated as

s/must be followed/MUST be followed


IANA considerations:
Could you rewrite slightly the text with more formal allocation requests (the content is here, it is just the way it is expressed that sounds weird to me). You can reuse the code points from the early allocation:

Example:
“IANA is requested to allocate the followings:

  *   Bit 47 (DCB-Bit) in the “Additional PMSI Tunnel Attribute Flags”  registry



     Bit         Name                             Reference

     ----        --------------                   -------------

     47          DCB-bit                          This document





  *   Sub-type 0x08 from the “Transitive Opaque Extended Community Sub-Types” registry and associated to the “Context Label Space ID Extended Community”


     Bit         Name                                              Reference

     ----        --------------                                    -------------

     0x08        Context Label Space ID Extended Community         This document








Please add a security considerations section

Please update the references of drafts that have become RFCs now.

Here are the list of nits related to references:


  Checking references for intended status: Proposed Standard

  ----------------------------------------------------------------------------



     (See RFCs 3967 and 4897 for information about using normative references

     to lower-maturity documents in RFCs)



  == Missing Reference: 'RFC 8279' is mentioned on line 152, but not defined



  == Missing Reference: 'BIER-MVPN' is mentioned on line 155, but not defined



  == Missing Reference: 'BIER-EVPN' is mentioned on line 155, but not defined



  == Missing Reference: 'RFC 6514' is mentioned on line 235, but not defined



  == Missing Reference: 'EVPN-BUM' is mentioned on line 294, but not defined



  == Unused Reference: 'I-D.ietf-bess-evpn-bum-procedure-updates' is defined

     on line 580, but no explicit reference was found in the text



  == Outdated reference: draft-ietf-bier-mvpn has been published as RFC 8556



  == Outdated reference: draft-ietf-spring-segment-routing has been published

     as RFC 8402



“



Juniper Business Use Only