[bess] Review of draft-ietf-bess-evpn-ipvpn-interworking-12

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

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