Hi Wes, > I note that this is still listing the requested IANA extended community as > non-transitive, but has removed the explicit prohibition to sending this > community to an eBGP peer based on my prior feedback. Is that going to work, > or does the community need to be redefined as transitive as well? > > Also, if we're going to allow it to be used in eBGP in even a limited > fashion, I think that we do need some text that covers this transitive vs > intransitive distinction in a bit more detail. For example, when I > recommended that we not explicitly prohibit sending this community on an > eBGP session, I also said that it should default to non-transitive for eBGP > in order to prevent misconfigurations from causing validation info of > questionable origin from moving between ASNs. In other words, it should be a > configurable option, but we want to express that the preference is to have > people do their own RPKI validation at their ASBR rather than relying on an > upstream and to limit propagation of this information since it's of > questionable accuracy and trust. We may also want to say that the receiving > peer must be explicitly configured to accept the extended community, and by > default it should drop any instance of the validation community on eBGP. Not > sure if we need to explicitly state that peers that don't understand/support > the community should silently ignore it, since I'm pretty sure that's > default behavior.
Yes, making the extended community non-transitive, but allowing it to be exchanged across ebgp sessions helps this. > > Updating the deleted text from the original document might give us something > like this: > Since the extended community is primarily intended to provide a method to > carry prefix validation information within an ASN, it SHOULD be a > non-transitive attribute, but there are some applications where it may be > necessary for it to transit between ASNs. In order to limit the propagation > of this information outside of the originating ASN, it MUST NOT be attached > by default while advertising routes to EBGP peers, even if the session is > configured to send other communities. It MAY be explicitly configured to be > sent between eBGP peers. Additionally, if it is present in an UPDATE message > received from an EBGP peer, by default the router MUST remove the origin > validation state extended community before parsing rest of the message. The > router MAY be explicitly configured to allow the origin validation state > from an eBGP peer to be accepted, but this is not recommended unless there > is an existing trust relationship between the ASNs (such as upstream ISP and > customer). Any ASN that learns validation information from an eBGP peer via > this community MUST NOT pass that community beyond routers in its own ASN. Thanks! I am fine with adding this text. Will wait for a few if others want to chime in... - Pradosh _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
