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
"
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
