Hi Xiaohu, I have read the -00 version of va-auto before I wrote the extension draft.
According to the VA routes, I still think it’s necessary for these routes to be tagged specifically. I have some questions as following. 1. As the tagging routers are configured with “VP range” instead of “VP list”, how could these routers identify the VP routes? 2. You mentioned that in consideration of the VP route flap event, “VP tag” approach should be given up. However, if the routes couldn’t identify the VP routes, what operation will they implement according to the scenario of the VP routes withdrawn? Furthermore, the suggestion in our draft is not the same with the -00 version. Our opinion is that the VP route tag should be used in conjunction with the suppress tag. According to the popular prefixes, as our draft is an extension to the existing mechanism, we just provided a flexible approach for popular prefixes auto- configuration. We just mentioned a list which operators could use to specify the prefixes need to be FIB installed specially. Best Regards Li Cheng Hi Li Cheng, Please see my comments inline. Hi all, We’ve submitted a draft for the extensions of VA-auto mechanism, below is the link: http://tools.ietf.org/id/draft-cheng-grow-va-auto-extensions-00.txt This draft specifies VA auto-configuration extension operation, which includes the following two aspects: 1. VP routes are tagged specifically with a “should-install tag”. Consequently, in the scenario where all VP routes for a given VP are withdrawn, routers (include tagging routers and non-tagging routers) could detect the withdrawn VP immediately, and then implement the proper operation. [Xiaohu] The “VP route tag” approach had ever been mentioned in the -00 version of VA-auto (see section 4.1). However, after serious consideration, we decided to give up this approach in the latter versions since the approach will cause the risk of repeatedly adding and removing the sub-prefixes within a given VP in the event of that VP route flap. Well 2. A popular prefixes list is configured on the tagging routers. This list could be consisted of high volume prefixes, policy-based prefixes and static list prefixes. Customer prefixes mentioned in exiting mechanism could be considered as one kind of policy-based prefixes. Tagging routers should not tag routes whose prefix falls within this list. [Xiaohu] The similar idea was also mentioned in the -00 version of VA-auto (see section 3.1.1). However, since how to identify the popular prefixes and policy-based prefixes is a local matter and much flexible(e.g, automatically or manually, prefix-based or peer-based), we decided not to specify it in the latter version and thus the operators have flexibility to choose the approach which is most suitable for them. Xiaohu Your thoughts and comments are welcome. Best regards Li Cheng -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
