Hi, A few comments on the draft.
> A policy definition contains a list the upstream and peering I think 'of' is missing, but still the paragraph is not easy to parse. > 2. If there is no specific definition for the relationship, the > ASX:Default policy; When you say ASX:Defaul, are you referring to the "The default behaviour for a neighbour, if the relationship is not explicitly described in the policy" mentioned before? To avoid ambiguity you may want to introduce this notation there. > 3. Validating an AS-Cone > If the validated cache does not contain the referenced object, > then the validation moves on to the next downstream ASN; Meaning routes originated by this ASN will be rejected (or a filter won't contain these routes)? Better to be explicit about this. > 2. If there is a reference to another AS-Cone, the validating > process should recursively process all the entries in that > AS-Cone first, with the same principles contained in this > list. Here is a question. As I understand, the policy definition object is intended to allow a customer to indicate to the upstream which AS-Cone to use (and which prefixes to expect). The customer controls this policy. However, the reference to an AS-Cone in another AS-Cone seems to be done at will of a provider, based on some static decision, rather than the analysis of a corresponding policy definition. Do you think that can lead to inconsistencies? Thanks, Andrei
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
