Mailing List Archive

Hi!

Somewhat stupid question: while experimenting with rpki, I found that
while rfc8097 declares origin validation state as extended community
(0x4300:0.0.0.0:N in juniper configuration terms), Juniper documentation
uses standard communities 0x4300:N for this purpose:

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/bgp-origin-as-validation.html

Junos OS supports the following well-known extended communities for
route validation:

origin-validation-state-valid
origin-validation-state-invalid
origin-validation-state-unknown

[...]

set policy-options community origin-validation-state-invalid members 0x4300:2
set policy-options community origin-validation-state-unknown members 0x4300:1
set policy-options community origin-validation-state-valid members 0x4300:0

Of course, these communities are not translated to extended ones and
sent as standard 17152:N ones.

One more interesting thing: when I configure RPKI communities manually:

set policy-options community origin_invalid members 0x4300:0.0.0.0:2
set policy-options community origin_unknown members 0x4300:0.0.0.0:1
set policy-options community origin_valid members 0x4300:0.0.0.0:0

and use them to announce validation information to other routers,
these communities displayed either as 'unknown iana opaque':

Communities: unknown iana opaque 0x4300:0x0:0x2

(junos 17.3R3-S3.3 and 18.3R1-S2.1) or even as just 'unknown iana 4300'
(15.1R6).

Question: is it just a bit outdated documentaton and I shall follow
RFC and use extended communities, or there are some other reasons
to use standard ones ?

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp