Hi Authors, WG, # Gunter Van de Velde, RTG AD, comments for draft-ietf-bess-vpls-multihoming-07
# line numbers are rendered from the idnits tool found at https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bess-vpls-multihoming-07.txt # Many thanks to Matthew Bocci for the Shepher write-up # I found thsi document written well. Many thanks for making this an enjoyable read # Can the list of authors and associated affiliations and email addresses be verified? # When running idnits the following message is displayed. Can authors confirm that no content was submitted from before 10 Nov 2028? alternative can Shepherd confirm that authors were contacted to grant rights, and if not confirmed add the pre-RFC5378 disclaimer as mentioned in the displayed idnits message: " -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) " # The document updates RFC 4761 by defining additional Control Flags in the Layer2 Info Extended Community. RFC 8614 subsequently updated the semantics of the Control Flags field defined in RFC 4761. Please analyze whether RFC 8614 should be referenced normatively and whether the document should also list RFC 8614 in the Updates header. # COMMENTS #========= 149 the base VPLS instance that has non-zero VE block offset, VE block GV> The text speaks about 'base VPLS instance' in multiple places, but does not specify what exactkly is a base VPLS instance. Is there a something different as a base vpls instance? if so, should it be said that this is out of scope of this document? 157 A Multi-homed (MH) site is uniquely identified by a CE-ID. Sites are GV> would it make sense to explicit say something about the scope of CE-ID uniqueness? It is not per PE but unique among the set of participating BGP PE's i suspect. 326 PE1 has two VPLS sites, CE1 and CE4. If both CE1 and CE4 327 connectivity to PE1 is down, remote PEs can choose based on D bit in 328 VE NLRI not to send multicast traffic to PE1 as there are no VPLS 329 sites reachable via PE1. If CE4 was not assigned a unique CE-ID, GV> Can a reference to this D bit be inserted? 356 NLRIs. In order to simplify the explanation of these algorithms, we 357 will use a number of variables derived from fields in the VPLS 358 advertisement. These variables are: RD, SITE-ID, VBO, DOM, ACS, PREF 359 and PE-ID. The notation ADV -> <RD, SITE-ID, VBO, DOM, ACS, PREF, 360 PE-ID> means that from a received VPLS advertisement ADV, the 361 respective variables were derived. The following sections describe GV> Can a reference to the VPLS advertisement and the relevant attributes be provided. Maybe it was mentioned earler already, however for clarity it may help a reader of teh document to cross correlate the exact specifics. 378 document. Figure 4 shows the position of the new 'D' and 'F' flags. GV> Earlier in the document this was called the D bit, here the D flag. Can the naming of the field within the document be made consistent. 384 |D|Z|F|Z|Z|Z|C|S| (Z = MUST Be Zero) GV> Can the usual disclaimer be added that these bits must be set zero when transmitted and must ignored when received? 400 forwarder must set the F bit and a non-designated forwarder must GV> i suggest using consistent naming for F bit vs F flag within the document Kind Regards, Gunter Van de Velde Routing Area Director
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
