Hi Jeff, [Sorry about the delayed response]
> In addition to the energetic discussion about the terminology for the three > states of the community, I'd also like to suggest that the origin of the > validation may be relevant. The cache protocol gives a data source for the > validation and that source probably should be represented within this > community. This also argues that it may be reasonable to have multiple > instances of this community - or that the representation of the data source > should be a bit-vector. > > I also wonder if "color" would need to go into a community such as this one. > Since the current purpose of "color" is unclear, it's hard to know one way > or the other. > > The above has impact on the suggested changes to the BGP decision process. > For example, an operator may prefer that RPKI validation have precedence > over IRR validation. Similarly, "color" may impact it. The original thought process was that all the above you have listed are local policy matter. E.g. the data source (RPKI or IRR) would be taken as a local policy hint to prefer one vs. the other... Same with color etc. Ultimately, it's only the path state that gets disseminated in IBGP and the corresponding decision process change is defined in the draft. But I see where you are going: if border router A fetches the origin validation database from RPKI and another border router B fetches the origin validation database from IRR, the third router receiving IBGP updates may want to know the source to be able to make a better decision. However this use case is extremely rare; do we really want to go there? - Pradosh _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
