On January 5, 2022 at 12:12:14 PM, Sriram, Kotikalapudi wrote: Sriram: Hi! > [KS/AA]: That is interesting. We did already enhance the Role descriptions > [KS/AA]: as follows to add the import policy verbiage (to the already > [KS/AA]: existing export policy) in Sec. 2 of v-19 to be uploaded: Route leaks are created by the (incorrect) advertisement of routes. Defining egress rules is then in line with the subject of this document. OTOH, ingress rules are not. Also, the ingress behavior is tied in the draft to the OTC attribute (and not directly to the role). The result is that the updated text is not consistent with the behavior already defined elsewhere. For example, using the Provider role: > Old text: ... > Provider: MAY propagate any available route to a Customer. > ... > New text: ... > Provider: May propagate any available route to a Customer. May > accept routes originated by the Customer or its Customers; all > other routes from the Customer must not be accepted. [Besides loosing the normative language...] A strict interpretation of the text (routes originated by a Customer can be accepted) is in contradiction with this text in §4: 1. If a route with the OTC Attribute is received from a Customer or RS-Client, then it is a route leak and MUST be considered ineligible (see Section 1.1). Note that this text doesn't talk about the origin, but it qualifies the policy based on the OTC attribute. All this is to say that the expected ingress behavior, which depends on the OTC attribute, is already defined elsewhere and there's no need to change the role definition. Thanks! Alvaro. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
