Bringing this up to the WG list to get the feedback. The discussion is
about the usage of the BGP extended communities as defined for OSPFv2
versus the definition of the new one in the context of the OSPFv3 PE-CE.
- draft-ietf-l3vpn-ospfv3-pece-05 defines a new OSPFv3 Route Extended
Communities Attribute, which carries the exact same information as the
original OSPF ext. communities defined in RFC4577.
- given that most vendors that will implement
draft-ietf-l3vpn-ospfv3-pece-05 have already implemented RFC4577,
reusing the communities defined there would make sense.
- from the operational perspective people are familiar with the original
OSPF communities from the VPNv4 deployments, so they would appreciate
the familiarity with those.
- in the last WG meeting an argument has been used that the route-types
encoding in 4.4 of draft-ietf-l3vpn-ospfv3-pece-05 does not match the
one defined for OSPFv2 in 4.2.6. of RFC4577. The Route Type filed in
OSPF Route Type Extended Communities Attribute as defined in RFC4577 has
enough space to use the encoding as defined in
draft-ietf-l3vpn-ospfv3-pece-05 and there would be no collision. An
alternative is to use the route-types as defined for OSPFv2
(intra/inter/external/nssa) that match OSPFv3 route-types anyway - there
is no need to carry the LSA type in this context.
- draft-ietf-l3vpn-ospfv3-pece-05 uses the IPv6 Address Specific BGP
Extended Community Attribute (RFC5701) that was defined specifically to
carry the IPv6 address. Not sure if it's usage as a placeholder for
opaque data was the intention of RFC570 as such.
- other protocols are reusing the originally defined communities in IPv6
VPN context.
thanks,
Peter
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
