Hi Authors,
Please find below my last review of draft-ietf-bess-evpn-ipvpn-interworking-12. Introduction: s/that the end to end tenant/that the end-to-end tenant Section 4: b. Bullet 2: I would clarify that <DOMAIN-ID:ISF_SAFI_TYPE> to be added is the one associated with the received path. The third bullet provides an example and we should make the normative statement more clear IMO. g. I would rephrase: s/"A received D-PATH attribute is considered malformed if it"/ "A received D-PATH attribute MUST be considered malformed if it" s/"A domain segment is considered as malformed in ..."/"A domain segment MUST be considered as malformed in ..."/ s/"The D-PATH attribute MUST be at least 8 octets in length or it is malformed." /"The D-PATH attribute length is less than 8 bytes". g. 5. What is the procedure if multiple D-PATH attribute are present ? g. 6. The written statement requires update of code for all other address-families (even outside context of gateway PE). Is it realistic ? Section 5.2: When gateway PE receives a route from iBGP and re-advertises to iBGP, do you consider that it's doing route-reflection and should apply the RR procedures related to OriginatorID and cluster list attributes ? It should probably be clarified if it's the case or not. Bullet 5. Have we considered how it works in case of ADD-PATH being used in advertising domain ? Section 8. 1 d) s/ ISAF SAFI-y/ ISF SAFI-y Brgds, Stephane
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
