Subject: Re: [Idr] Discussions about RT-Constrain //RE: IETF-78 IDR minutes

From: [email-masked]
Date: Tue, 7 Sep 2010 00:51:36 +0800

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

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 06 Sep 2010 20:05:18 +0200

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
> [email-masked] https://www.ietf.org/mailman/listinfo/idr
>

---

From: Jie Dong <[email-masked]>
Date: Tue, 07 Sep 2010 11:22:46 +0800

Hi Robert,

> fact I think what you are planning to do does make sense.

So you agree in this scenario our proposed solution will solve the problem
of receiving undesired vpn routes, right?

> optimization to the optimization.

IMO, the goal of RT-constrain is to control distribution of VPN routes only
to where needed, and now we know that in some scenarios this goal cannot be
achieved with current RT-constrain. Thus this draft is a solution to the
existing problem.

>From your statements, my feeling is that you think deployment of
RT-constrain has little value to operators, is this your intention? As I
know, the amount of VPN routes is much larger than that of public IP routes,
thus avoid advertising and processing of undesired VPN routes would be very
important.

> them ?

In my understanding of RFC4684, this "cheap operation" is one of the
objectives that RT-constrain intends to resolve. Even if this drop operation
on receiver side is "cheap" as you said, from the view of the sender,
RT-constrain also aims to avoid advertising and propagation of unnecessary
VPN routes. 

> Or are you under impression that all PEs would need to store

With smart implementations, some of the PEs do not need to store these
unnecessary routes. But some other routers (RR, ASBR) have to maintain all
the received routes. So implementation optimization cannot solve this
problem completely. 

Best regards,
Jie

> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Jie Dong <[email-masked]>
Date: Tue, 07 Sep 2010 11:56:25 +0800

Hi Robert,

Some further thoughts...

Avoiding propagation and processing of unnecessary VPN routes is one
important aspect. In addition, what we concern more is: with current
RT-constrain mechanism [RFC4684] which uses one AFI/SAFI for all kinds of
VPN services (including L3VPN, L2VPN, L1VPN, MVPN, and potential
xxxVPNs...), configuration/deployment of one type VPN may affect other
deployed VPNs in the network. 

As I said in my previous mail, such impact among different types VPNs can be
more serious with more and more types of VPNs deployed in the network, and
coexistence of static configured RT and automatic generated RT makes the RT
collision among different types of VPNs much easier to occur, and it would
become more and more difficult in planning and management of different types
of VPNs when RT-constrain is deployed. 

RTs used in one type of VPN SHOULD be independent with any other types of
VPNs. Thus it's straightforward and reasonable for RT-constrain to separate
RT membership information of different AFI/SAFIs, which is what we proposed
in our draft
(http://tools.ietf.org/html/draft-dong-idr-vpn-route-constrain-01.txt).

Best regards,
Jie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Robert Raszuk
> Sent: Tuesday, September 07, 2010 2:05 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Idr] Discussions about RT-Constrain //RE: IETF-78 IDR
minutes

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 07 Sep 2010 11:03:59 +0200

Hi Jie,

I think very careful RT allocation planning is needed in each 
multi-service network and this is regardless of rt-constrain use or not.

If you expect RT collisions to happen then I don't think prepending 
AFI/SAFI to an RT will be of any help.

You would be much better to propose modifications to the RT format 
itself to accomodate service encoding as part of it's value. Then 
automatically any protocol which uses RTs will inherit it.

But I don't think this is practically sound required, but clearly you 
have a different opinion. And I don't think AFI/SAFI+RT that much is 
needed. Providers usually already have their own ways to divide RT 
spaces among their services today just playing with available 8 octets.

If you think 8 octets is not enough maybe proposing 9 or 10 would 
address your concern of overlapping RTs for various types of VPNs.

 > RTs used in one type of VPN SHOULD be independent with any other
 > types of VPNs.

That would not generally not be a good practice. Perhaps for few 
migrations cases, but clearly not for long term deployment plan.

If you separate unicast from multicast the latter may have not work too 
well as it depends on unicast for it's RPF check. If you separate v4 
from v6 and sites that have a dual stack routing congruency requirement 
will just double the advertisement of RTs.

Cheers,
R.

---

From: Jie Dong <[email-masked]>
Date: Wed, 08 Sep 2010 15:20:46 +0800

Hi Robert, 

> multi-service network and this is regardless of rt-constrain use or not.

Can't agree. Without RT-constrain, PEs can always receive undesired VPN
routes regardless of careful RT allocation, that is the problem RT-constrain
intends to solve. Thus RT-constrain SHOULD work correctly regardless of
careful RT allocation use or not. 

RT allocation management in each type of VPN service is needed, but among
different VPN services which should even be unaware of each other, IMO such
restriction on RT assignment is unreasonable and may bring extra complexity
and burden to operators. For example, if in one type of VPN, RT is
automatically generated, SHOULD other types of VPN services try to adjust
their RT assignments to avoid the collision? 

RT is firstly used for VPNv4 and then generalized to other types of VPNs.
When only VPNv4 is deployed, allocation of RT is not restricted by any other
service. This is also true for networks which deploy L2VPN only. If one
network needs to deploy both or even more types of VPNs, why should the
operators be limited with additional restrictions?

> automatically any protocol which uses RTs will inherit it.

Since AFI/SAFI can already separate different kinds of services, RT itself
does not need to contain this information, and that's why multi-service
network can work correctly without RT-constrain when RT collision happens.
The problem of current RT-constrain is that the update messages of current
RT membership NLRI does not carry sufficient information of services'
AFI/SAFI, which impairs the effect of RT-constrain.

> spaces among their services today just playing with available 8 octets.

Maybe we need comments from SPs about this dividing RT space approach. Is
this what they really want, does this increase their management complexity?
According to BGP, overlapping of RTs for different types of VPNs will not
bring any problem.

> address your concern of overlapping RTs for various types of VPNs.

That's not what we proposed. :) 

> migrations cases, but clearly not for long term deployment plan.

The migration period could be long :) And if migration cases permit this
use, long term deployment may also use it.

> will just double the advertisement of RTs.

In multicast one may use SAFI 2 for RPF check, and compared with the amount
of undesired routes, double advertisement of RTs is more than acceptable.
Though the relationship between unicast & multicast, IPv4 & IPv6 are not
quite relevant to our discussion of RT assignment.

Best regards,
Jie

> > As I said in my previous mail, such impact among different types VPNs
can
> be

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 08 Sep 2010 15:44:57 +0200

Hi Jim,

> Comments In-Line..

Excellent comments, but a bit not for the question at hand. What you are 
essentially saying is that rt-constrain deployment has no real benefit.

This thread is/was about making rt-constrain more atomic to 
differentiate RT values between various services or not.

In any case while we are at it let me address some of your points below.

> - RT-Constrain takes away the ability to realize new services. A number
> of "stitching" based services whereby SP content "SP routes" need to be
> stitched into a customer's VPN regardless of whether or not that SP
> Content VPN is configured on a given PE.

That is incorrect. RT-constrain does not take away any ability described 
above. Without RT-constrain if given VPN is not configured on PE the 
routes will be dropped, with rt-constrain they will not be sent from RR 
to such PE.

Central stitching like we have discussed in the past would add to the SP 
routes given customer's VPN RT values so those will be accepted at 
participating PEs automatically.

> - Intra-AS RT constrain assumes that VPNs are not distributed evenly
> across an AS. This means that the intra-AS iBGP topology will be
> optimized.. Assume US with east and west coast clusters defined. Using
> the assumption in the draft, VPNs are generally localized to a given
> region so the east and west coast clusters would have a mutually
> exclusive set of routes.. This is not real..My experience is that
> companies do not create limited VPN topologies..

I agree. Those intra-as RR distributions are only possible for local VPN 
sites .. for example state's local offices etc ...

> - Inter-AS RT constrain assumes that RT assignment is done the same way
> across all ASes under an administrative domain.. Cannot assume this. As
> companies are bought/sold etc... we have had to stitch together VPNs for
> a given customer across AS domains.

RT format is well defined. As long as it contains bgp_rtr_id in the form 
of public IPv4 address or registered AS number there should be no need 
for RT remapping for any inter-as service.

> - Currently there is no way to "know" if RT constrain is working or
> not.. The network management to support RT Constrain would need to
> determine if a VPN distribute tree was built correctly by interrogating
> each leaf to determine if the VPN distribution tree was created
> correctly..

Hmmm interesting comment ...

> - The draft in its current form requires changes to the BGP
> specification to accommodate RT-Constrain.. Differences in BGP behavior
> for different AFs is not desirable as ops/main/tech support need to
> support these variations.

I am not sure I understand this point. Could you perhaps elaborate more?

> - There is no difference made in the draft the refers to the difference
> between an RR and a leaf node.. Therefore even though a leaf "PE" should
> always send all of its routes the RR will still sent RT constrain
> messages requesting routes for RTs of interest.. Creates unneeded
> processing on the PE..

That is incorrect. Rfc4684 says:

    The default route target can be used to indicate to a peer the
    willingness to receive all VPN route advertisements such as, for
    instance, the case of a route reflector speaking to one of its PE
    router clients.

Many thx,
R.

> - The actual effect on the performance of PEs needs to be quantified..
> - How to rollout RT Constrain across all of the PEs in an AS domain..
>
> I do not believe the limited benefits of RT Constrain at this point
> justify turning over route dissemination to a mechanism that we do not
> even have the tools to understand if it is working correctly..
>
> Jim Uttaro

---

From: "UTTARO, JAMES (ATTLABS)" <[email-masked]>
Date: Wed, 8 Sep 2010 08:48:12 -0400

Comments In-Line..

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jie Dong
Sent: Wednesday, September 08, 2010 3:21 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] Discussions about RT-Constrain //RE: IETF-78 IDR
minutes

Hi Robert, 

routes regardless of careful RT allocation, that is the problem
RT-constrain
[Jim U>] Do not agree with this. 

Jim Uttaro

RT allocation management in each type of VPN service is needed, but
among
different VPN services which should even be unaware of each other, IMO
such
restriction on RT assignment is unreasonable and may bring extra
complexity
and burden to operators. For example, if in one type of VPN, RT is
automatically generated, SHOULD other types of VPN services try to
adjust
their RT assignments to avoid the collision? 

RT is firstly used for VPNv4 and then generalized to other types of
VPNs.
When only VPNv4 is deployed, allocation of RT is not restricted by any
other
service. This is also true for networks which deploy L2VPN only. If one
network needs to deploy both or even more types of VPNs, why should the
operators be limited with additional restrictions?

> automatically any protocol which uses RTs will inherit it.

Since AFI/SAFI can already separate different kinds of services, RT
itself
does not need to contain this information, and that's why multi-service
network can work correctly without RT-constrain when RT collision
happens.
The problem of current RT-constrain is that the update messages of
current
RT membership NLRI does not carry sufficient information of services'
AFI/SAFI, which impairs the effect of RT-constrain.

> spaces among their services today just playing with available 8
octets.

Maybe we need comments from SPs about this dividing RT space approach.
Is
this what they really want, does this increase their management
complexity?
According to BGP, overlapping of RTs for different types of VPNs will
not
bring any problem.

> will just double the advertisement of RTs.

In multicast one may use SAFI 2 for RPF check, and compared with the
amount
of undesired routes, double advertisement of RTs is more than
acceptable.
Though the relationship between unicast & multicast, IPv4 & IPv6 are not
quite relevant to our discussion of RT assignment.

Best regards,
Jie

> > RT-constrain mechanism [RFC4684] which uses one AFI/SAFI for all
kinds
of
can
> be
> > more serious with more and more types of VPNs deployed in the
network,
> and
> > coexistence of static configured RT and automatic generated RT makes
the
> RT
> > become more and more difficult in planning and management of
different
> types
types
> of
> >> of routes which are desired. The fact that it allows limit the
amount
of
> >> 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

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr