Hi Alvaro Responses In-line
I think the document needs to clearly state that the role priority by itself does not have an import policy that is automatically configured. The import policy is based on OTC Attribute. The document should also clearly state that Role priority must be used in conjunction with OTC attribute. I think this is being implied but needs to be clear that role priority must be used with OTC attribute for route leak detection and prevention. Also in order for the route leak detection and prevention to work correctly, the role priority cannot have an automatic inbound policy and must depend on the dynamic signaling nature of OTC path attribute to signal route leak. Kind Regards Gyan On Wed, Jan 5, 2022 at 4:33 PM Alvaro Retana <aretana.i...@gmail.com> wrote: > 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. Gyan> Agreed > > > OTOH, ingress rules are not. Also, the ingress behavior is tied in > the draft to the OTC attribute (and not directly to the role). > Gyan> Agreed > > The result is that the updated text is not consistent with the > behavior already defined elsewhere. For example, using the Provider > role: > Gyan> Good point > > > > > 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). > Gyan> Very Good point. OTC attribute must be used for the route leak detection dynamic import policy. > > Note that this text doesn't talk about the origin, but it qualifies > the policy based on the OTC attribute. > Gyan> Agreed > > > 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. > Gyan> Completely agree > > Thanks! > > Alvaro. > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art