Subject: [GROW] Comments Request draft-cheng-grow-va-auto-extensions-00

From: [email-masked]
Date: Thu, 27 Oct 2011 09:08:09 +0800

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. 

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. 

Your thoughts and comments are welcome. 

Best regards 
Li Cheng
-------------------------------------------------------
Grow mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/grow

--------------------------------------------------------
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.

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 27 Oct 2011 02:21:33 +0000

Hi Li Cheng,

Please see my comments inline.

发件人: [email-masked] [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2011年10月27日 9:08
收件人: [email-masked]
主题: [GROW] Comments Request draft-cheng-grow-va-auto-extensions-00

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<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.

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

Best regards

Li Cheng

---

From: [email-masked]
Date: Sun, 30 Oct 2011 15:08:17 +0800

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,

Hi all, 

 
[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

[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

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.