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

Hi Robert,

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

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

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

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.

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

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

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

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

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

> 
> 
> > 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@ietf.org https://www.ietf.org/mailman/listinfo/idr
> >
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr