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

["Stephane Litkowski (slitkows)" <[e-mail]>]

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.


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 ?

"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



"