Extended communities cannot represent an equivalent of AS4:AS4 in a form that
standard communities can do with AS2:AS2, extended communities define a
container for 6 bytes of payload total regardless of interpretation.
Right, but the case where in XX:YY YY is also an AS number is much less common
than the case where XX is an AS number but YY is just a small integer.
For a particular use case that can be implemented with a small number
having a specific meaning - yes, but for a more generic use case in a
form of "AS this do not advertise to AS that", whete "this" and "that"
are both AS4s, it is not possible. From the practical point of view, if
a new path attribute is defined, it should be generic enough to cover
all use cases reasonably known at present time. Otherwise it will be yet
another short term hack that will result in problems later.
(If anyone has any data on RFC 5668 support out in the wild that would be
useful.)
Pretty much any implementation.
Not sure what you mean here.
5668 is a form of an extended community, yes, it does have a specific
subtype which will need to be implemented to correctly present the value
of the extended community via user interface. Extended communities as
such are implemented and deployed widely, even for plain IPv4 and IPv6
address families - some examples below, including the AS4 based 5668.
Any practical implementation that has support for L3VPNs will support
extended communities.
It is still the same extended community, just with a different interpretation.
Unless I'm mistaken, as a user you can't interact with extended communities
unless the BGP implementation knows about the kind of extended community that
you're dealing with. So if a router doesn't implement RFC 5668 there's no way
for me to use the RFC 5668 communities.
It is specific to how a particular implementation presents it to user
interface and routing policy language. On the wire, except of the
specific subtype, the encoding is the same, and it is an agreement
between the parties to interpret it in a particular way. There are
various types of extended communities used in the field, a few examples
from live view of RIPE collectors:
extcomm final RT:65165:132167 (Route Target) (type 0/2) (Two-Octet AS
Specific Extended Community)
extcomm final RT:65171:132203 (Route Target) (type 0/2) (Two-Octet AS
Specific Extended Community)
extcomm final RT:65204:222220000 (Route Target) (type 0/2) (Two-Octet AS
Specific Extended Community)
extcomm final RT:65205:222220000 (Route Target) (type 0/2) (Two-Octet AS
Specific Extended Community)
extcomm final RT:65207:222220000 (Route Target) (type 0/2) (Two-Octet AS
Specific Extended Community)
extcomm final RT:0:197580 (Route Target) (type 0/2) (Two-Octet AS
Specific Extended Community)
extcomm final RT:0:197999 (Route Target) (type 0/2) (Two-Octet AS
Specific Extended Community)
extcomm final RT:0:198477 (Route Target) (type 0/2) (Two-Octet AS
Specific Extended Community)
extcomm final RT:0:199399 (Route Target) (type 0/2) (Two-Octet AS
Specific Extended Community)
extcomm final RT:843:105 (Route Target) (type 2/2) (4-Octet AS Specific
Extended Community)
extcomm final RT:843:106 (Route Target) (type 2/2) (4-Octet AS Specific
Extended Community)
extcomm final RT:843:300 (Route Target) (type 2/2) (4-Octet AS Specific
Extended Community)
extcomm final RT:843:301 (Route Target) (type 2/2) (4-Octet AS Specific
Extended Community)
extcomm final RT:843:60143 (Route Target) (type 2/2) (4-Octet AS
Specific Extended Community)
extcomm final OSPF-RT:000000000501 (OSPF Route Type) (type 3/6) (Opaque
Extended Community)
extcomm final OSPF-RT:0:1234736768 (OSPF Route Type) (type 0/6)
(Two-Octet AS Specific Extended Community)
extcomm final RO:0:198570 (Route Origin) (type 0/3) (Two-Octet AS
Specific Extended Community)
extcomm final RO:1027:1 (Route Origin) (type 2/3) (4-Octet AS Specific
Extended Community)
extcomm final RO:11896:10000 (Route Origin) (type 2/3) (4-Octet AS
Specific Extended Community)
some hacks (remapping and AS4 marker, both reuse standard communities, and both
are ugly).
I'm interested in those hacks. Maybe they're ugly but at least we can start
using them today, and when the router vendors implement the hacks they'll show
up as AS:nn as usual without any chicken/egg or boil the ocean issues.
The remapping one is based on reusing an available AS2 number to mean a
specific AS4 number. Ingress policy matches the incoming AS4 and tags
the route with a new AS2 based standard or extendedc community. This is
a risk for conflicts though.
AS4 marker one is based on splitting the 32 bit value part into two 16
bit parts and carrying them as two standard or extended communities
together. The risk here is that an AS4 split into two may result in a
conflict with a legitimate AS2 value, therefore additional "marker"
community is needed, and an implementation needs to allow for matching
of all three of the elements in order to consider it for a correct match
of the mapped community.
Both are prone to errors and conflicts - please do not use them, instead
ask your vendors to implement the correct native AS4 solutions. That is
not a huge price to pay to get an unambiguous solution to a problem that
is real and urgent.
Ignas
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
