headers
Jie Dong | 1 Sep 2010 04:29
Favicon

Re: IETF-78 IDR minutes

Hi all, 

Some supplements for discussion of draft-dong-idr-vpn-route-constrain-01.txt
in the meeting: 

1. Answers to Robert's first question:

One PE (say PE1) can connect to two or more VPN sites, some of them support
IPv4, and some others support IPv6, or both v4 and v6, thus PE1 would
establish BGP session for both VPNv4 and VPNv6. Then peers can advertise
both VPNv4 and VPNv6 routes to PE1. 

In this scenario, if the same RT is used for both VPNv4 and VPNv6, based on
current RT-Constrain, the peers cannot tell which kind of route is requested
by PE1, thus they may send undesired VPN routes to it. For some VPNs the
amount of undesired routes can be large.

2. Reply to Robert's second question (configuring different RTs to solve the
problem)

Based on normal BGP procedures, using the same RT for different AFI/SAFIs is
permitted, as routes of different AFI/SAFIs would be processed
independently. But using the same RT along with current RT-Constrain can
cause the problem of receiving undesired VPN routes. Thus we just try to
make RT-Constrain compliant with normal BGP.

Any further comments on draft-dong-idr-vpn-route-constrain-01 are welcome.

Best regards,
Jie
(Continue reading)

Permalink | Reply | 10 comments |
headers
Robert Raszuk | 1 Sep 2010 07:53
Picon
Favicon

Re: IETF-78 IDR minutes

Hi Jie,

Let me clarify ...

> Thus we just try to make RT-Constrain compliant with normal BGP.

Let me observe that RT-Constrain as documented in RFC 4684 is very 
complaint with normal BGP (modulo your definition of "normal BGP").

It needs to be pointed out that vast majority of customers would
have valid requirement for congruent IPv4 and IPv6 topologies. So using 
the same value for those VPNs is not only possible, but also highly 
encouraged. Authors of RFC4684 looked at route-target as marker 
identifying a customer VPN of any address family.

For possible migrations scenarios yes PE would be receiving both v4 and 
v6 VPN routes if the same RT is configured on both address families. If 
this turns to be an issue for some VPNs using during migration or even 
long term configuration of different RT values solves the issue.

So I really do not think that we need to incorporate any protocol 
modifications here.

Many thx,
R.
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
(Continue reading)

Permalink | Reply | 9 comments |
headers
Jie Dong | 1 Sep 2010 09:35
Favicon

Discussions about RT-Constrain //RE: IETF-78 IDR minutes

Hi Robert,

Thanks for your prompt reply.

Yes, I have been pointing out that using the same RT for VPNv4 and VPNv6
should be encouraged. But this should not be restricted to congruent
topologies. For management simplicity and less configuration of different
RTs, using the same RT for non-congruent topologies of the same customer can
also be preferred. The most common scenario is customer's migration from
IPv4 to IPv6, and not all the sites need to migrate to IPv6 at once. 

As described in the draft, using different RT is one alternative solution,
but requires more configurations and in some scenarios will meet the problem
of difficulty in planning and management. Details are specified in section
6.2.1 of draft-dong-idr-vpn-route-constrain-01.

In addition, some VPN mechanisms propose generating RTs automatically, which
would makes planning and management of unique RT more difficult, and can
result in the same RT used by different VPN services. This draft is trying
to facilitate the deployment of new VPN services and avoid potential
problems.

Further discussions are always welcome. We especially solicit comments and
feedbacks on this from ISPs who has deployed or plans to deploy RT-Constrain
in their networks.

Many thanks.

Best Regards,
Jie
(Continue reading)

Permalink | Reply | 8 comments |
headers
Susan Hares | 1 Sep 2010 11:48

2 week LC for adoption of draft-dong-idr-fsm-subcode-01 as wG document

This is to start a 2 week period of considering the adoption of draft-dong-idr-fsm-subcode-01 as a WG document.

 

Please respond to this email by 9/15/2010.

 

Sue and John

 

-------------------------------------

We would like to ask for adoption of draft-dong-idr-fsm-subcode-01 as a WG document.

 

The URL is: http://tools.ietf.org/html/draft-dong-idr-fsm-subcode-01

 

Best Regards,
Jie & Mach

 

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 6 comments |
headers
Xu Xiaohu | 2 Sep 2010 09:59
Favicon

Re: 2 week LC for adoption of draft-dong-idr-fsm-subcode-01 as wGdocument

xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40" xmlns:ns0="http://schemas.microsoft.com/office/2004/12/omml">

Support the adoption.

 

Xiaohu

 

发件人: idr-bounces <at> ietf.org [mailto:idr-bounces <at> ietf.org] 代表 Susan Hares
发送时间: 2010年9月1日 17:49
收件人: idr <at> ietf.org
主题: [Idr] 2 week LC for adoption of draft-dong-idr-fsm-subcode-01 as wGdocument

 

This is to start a 2 week period of considering the adoption of draft-dong-idr-fsm-subcode-01 as a WG document.

 

Please respond to this email by 9/15/2010.

 

Sue and John

 

-------------------------------------

We would like to ask for adoption of draft-dong-idr-fsm-subcode-01 as a WG document.

 

The URL is: http://tools.ietf.org/html/draft-dong-idr-fsm-subcode-01

 

Best Regards,
Jie & Mach

 

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
Ananth Suryanarayana | 2 Sep 2010 10:53
Picon
Favicon

Re: 2 week LC for adoption of draft-dong-idr-fsm-subcode-01 as wG document

I support.

Regards,
Ananth

-- 
On Wed, Sep 01, 2010 at 05:48:51AM -0400, Susan Hares wrote:
>    This is to start a 2 week period of considering the adoption of
>    draft-dong-idr-fsm-subcode-01 as a WG document.
> 
>     
> 
>    Please respond to this email by 9/15/2010.
> 
>     
> 
>    Sue and John
> 
>     
> 
>    -------------------------------------
> 
>    We would like to ask for adoption of draft-dong-idr-fsm-subcode-01 as a WG
>    document.
> 
>     
> 
>    The URL is: [1]http://tools.ietf.org/html/draft-dong-idr-fsm-subcode-01
> 
>     
> 
>    Best Regards,
>    Jie & Mach
> 
>     
> 
> References
> 
>    Visible links
>    1. http://tools.ietf.org/html/draft-dong-idr-fsm-subcode-01

> _______________________________________________
> Idr mailing list
> Idr <at> ietf.org
> https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
Mach Chen | 3 Sep 2010 02:44
Favicon

Re: 2 week LC for adoption of draft-dong-idr-fsm-subcode-01 as wGdocument

Support

Best regards,
Mach

--------------------------------------------------
From: "Susan Hares" <skh <at> ndzh.com>
Sent: Wednesday, September 01, 2010 5:48 PM
To: <idr <at> ietf.org>
Subject: [Idr] 2 week LC for adoption of draft-dong-idr-fsm-subcode-01 as 
wGdocument

> This is to start a 2 week period of considering the adoption of
> draft-dong-idr-fsm-subcode-01 as a WG document.
>
>
>
> Please respond to this email by 9/15/2010.
>
>
>
> Sue and John
>
>
>
> -------------------------------------
>
>
>
> We would like to ask for adoption of draft-dong-idr-fsm-subcode-01 as a WG
> document.
>
>
>
> The URL is:  <http://tools.ietf.org/html/draft-dong-idr-fsm-subcode-01>
> http://tools.ietf.org/html/draft-dong-idr-fsm-subcode-01
>
>
>
> Best Regards,
> Jie & Mach
>
>
>
>

> _______________________________________________
> Idr mailing list
> Idr <at> ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> 
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
Paul Jakma | 6 Sep 2010 05:31

Re: 2 week LC for adoption of draft-dong-idr-fsm-subcode-01 as wG document

On Wed, 1 Sep 2010, Susan Hares wrote:

> 
> This is to start a 2 week period of considering the adoption of
> draft-dong-idr-fsm-subcode-01 as a WG document.

Support.

regards,
--

-- 
Paul Jakma	paul <at> jakma.org	Key ID: 64A2FF6A
Fortune:
Let's _not_ bring that into this thread, OK?

 	- Al Viro on linux-kernel
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
lizhenqiang | 6 Sep 2010 18:51

Re: Discussions about RT-Constrain //RE: IETF-78 IDR minutes

Hi Robert and Jie,

I am Zhenqiang Li from China Mobile. I think this draft is useful. We are now planning the IPv6 migration
scheme. During the migration period, some sites of a specific service will introduce IPv6 first. These
IPv6-enabled sites (still support IPv4) need to communicate with other sites belonging to this specific
service, including both IPv6-enabled and IPv4-only sites. Because they are parts of one service, we want
them to be in one VPN. Thus we give the IPv6 route the same RT as the IPv4 route of this service. By using the
proposed scheme in this draft, we can control the IPv6 route distribution within the IPv6-enabled sites.
This is also helpful to limit the potential impact of IPv6 introduction.

Best Regards,
Zhenqiang Li
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 7 comments |
headers
Robert Raszuk | 6 Sep 2010 20:05
Picon
Favicon

Re: Discussions about RT-Constrain //RE: IETF-78 IDR minutes

Hello Zhenqiang,

Many thx for your email. I have no doubt about your deployment case. In 
fact I think what you are planning to do does make sense.

But let's do not forget about the overall picture. RT-constrain's 
primary objective was to help automate inter-as VPNs. Later we have 
observed that it may also help to allow to store on RRs only those set 
of routes which are desired. The fact that it allows limit the amount of 
automated inbound filtering on the PEs is more or less the over all 
positive side effect :)

So RT-constrain in itself is an optimization. This draft would be an 
optimization to the optimization.

Reg the impact of IPv6 introduction how many VPN IPv6 routes are you 
concerned with ? Note that there are production IPv4 deployments with 
over 1 million IPv4 routes today and without rt-constrain deployed at all.

Are you concerned with the need to drop unnecessary routes on inbound RR 
-> PE (which is a very cheap operation) on those PEs which do not need 
them ? Or are you under impression that all PEs would need to store 
those routes even if those would not be needed .. the latter would be 
very easy to address without any protocol changes by your favorite BGP 
implementation.

Many thx,
R.

> Hi Robert and Jie,
>
> I am Zhenqiang Li from China Mobile. I think this draft is useful. We
> are now planning the IPv6 migration scheme. During the migration
> period, some sites of a specific service will introduce IPv6 first.
> These IPv6-enabled sites (still support IPv4) need to communicate
> with other sites belonging to this specific service, including both
> IPv6-enabled and IPv4-only sites. Because they are parts of one
> service, we want them to be in one VPN. Thus we give the IPv6 route
> the same RT as the IPv4 route of this service. By using the proposed
> scheme in this draft, we can control the IPv6 route distribution
> within the IPv6-enabled sites. This is also helpful to limit the
> potential impact of IPv6 introduction.
>
> Best Regards, Zhenqiang Li
> _______________________________________________ Idr mailing list
> Idr <at> ietf.org https://www.ietf.org/mailman/listinfo/idr
>

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 6 comments |

Gmane