Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt

Adam,

	I am uncomfortable turning over route distribution to a protocol. IMO the risk for a L3VPN network with sites that are geographically spread does not warrant the gain. I would suggest the working group tee this up with the IRS2 team as a use case.

Jim Uttaro

-----Original Message-----
From: Vitkovský Adam [mailto:adam.vitkovsky@swan.sk] 
Sent: Monday, June 23, 2014 10:15 AM
To: UTTARO, JAMES; 'Dongjie (Jimmy)'; 'idr@ietf.org'
Subject: RE: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt

James,
Think of the filters between inter-as-RRs and PEs for example used to limit the exposure of MNCs prefixes versus the local corporations prefixes to other regions. These could be replaced by the RT-C not requiring "manual" maintenance. 
But I agree that the risk of discontinuous VPNs based on some arbitrary topology between RRs is an unacceptable burden for full blown RT-C deployment, though my understanding is that this could only happen in hierarchical RR topologies.
However I see no need to alleviate the number of iBGP sessions between intra-as-RRs with yet another level of hierarchy. 

adam
> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of UTTARO, JAMES
> Sent: Monday, June 23, 2014 1:24 PM
> To: 'Dongjie (Jimmy)'; 'idr@ietf.org'
> Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-
> rr-00.txt
> 
> Jie,
> 
> 	I still do not understand the architecture of hierarcacal RRs for the
> VPNV4 AF. As evidenced by your diagram and associated text probably not a
> good idea.  Regardless of that here are my thoughts, concerns and the where
> RT-C may have utility.
> 
> RT-C Premise..
> 
> The reason articulated in the original RT-C draft was based on the notion that
> VPNs would be highly localized in nature and where there associated routing
> state could also be contained in a sub-graph of the topology. My experience
> is that this is not the case. The major advertisers of routing state are big
> organizations that have footprint spanning multiple continents across the
> globe.
> 
> A benefit of RT-C may be to limit the amount of routing state sent to a PE
> when a soft refresh, VRF add or re-boot occurs. The savings here is CPU
> cycles, ease of HOL blocking for those implementations that do not
> discriminate between routes incrementally added and a new VRF and
> reducing reboot time.
> 
> For these limited benefits full blown RT-C is not something I would deploy as
> I risk fate sharing, disconnected VPNs ( Based on Topology ), etc... For all of
> the business needs competing for cycles/windows it is difficult to understand
> the cost/benefit..
> 
> SDN Control
> 
>  RT-C like filter deployed from an SDN controller may be the way to go. As the
> RR/Route Server topology can easily scale to millions of routes we can focus
> our energy on reducing the flood of routing state to an individual PE,
> between providers or even between RRs although the last one holds little
> interest for me.
> 
> Jim Uttaro
> 
> -----Original Message-----
> From: Dongjie (Jimmy) [mailto:jie.dong@huawei.com]
> Sent: Sunday, June 22, 2014 10:42 PM
> To: UTTARO, JAMES; 'idr@ietf.org'
> Subject: RE: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-
> 00.txt
> 
> Hi Jim,
> 
> Here is the example I previously sent to the list:
> 
> PE1---RR2
>          \
>           \
> PE2-       RR1
>     \     /
>      \   /
>       RR3
>      /
>     /
> PE3-
> 
> RR1 is level-1 RR, and RR2 and RR3 are level-2 RRs.
> 
> 1. All the PEs advertise RTC route of RT-X to their connecting RRs.
> 2. RR2 and RR3 select the best RTC route, add their cluster_id to the
> cluster_list and advertise the RTC route to RR1 respectively.
> 3. RR1 selects one RTC route as best (let's say RTC route from RR2), adds its
> cluster_id into the cluster_list and advertises it to RR2 and RR3.
> 4. Then RR2 would receive the RTC route from RR1 with its own cluster_id in
> the cluster_list and will drop this RTC route.
> 5. As a result, RR2 will not advertise VPN routes with RT-X to RR1.
> 
> For a network with hierarchical RR, RTC can also be useful to control the VPN
> routes being distributed only to PEs which have the corresponding customers
> connected.
> 
> I'm not quite clear about your comments about RTC and SDN controller, do
> you mean RTC mechanism can be used to distribute routes to SDN
> controller? I'd agree that is another possible use case of RTC.
> 
> Best regards,
> Jie
> 
> > -----Original Message-----
> > From: UTTARO, JAMES [mailto:ju1738@att.com]
> > Sent: Saturday, June 21, 2014 3:02 AM
> > To: Dongjie (Jimmy); 'idr@ietf.org'
> > Subject: RE: New Version Notification for
> > draft-dong-idr-rtc-hierarchical-rr-00.txt
> >
> > Why? A picture would be quite useful here. I am struggling to
> > understand a hierarcacal design that then needs RT-C?? Maybe if the
> > VPNs are highly localized.. BTW isn't RT-C a good candidate to off net to an
> SDN controller?
> > IMO that should be the future.
> >
> > Jim Uttaro
> >
> > -----Original Message-----
> > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy)
> > Sent: Thursday, June 19, 2014 10:55 PM
> > To: idr@ietf.org
> > Subject: [Idr] FW: New Version Notification for
> > draft-dong-idr-rtc-hierarchical-rr-00.txt
> >
> > Hi all,
> >
> > This is a short draft to make RTC applicable in hierarchical RR scenario.
> >
> > Comments are welcome.
> >
> > Best regards,
> > Jie
> >
> > > -----Original Message-----
> > >
> > > A new version of I-D, draft-dong-idr-rtc-hierarchical-rr-00.txt
> > > has been successfully submitted by Jie Dong and posted to the IETF
> repository.
> > >
> > > Name:		draft-dong-idr-rtc-hierarchical-rr
> > > Revision:	00
> > > Title:		Extensions to RT-Constrain in Hierarchical Route
> Reflection
> > > Scenarios
> > > Document date:	2014-06-19
> > > Group:		Individual Submission
> > > Pages:		5
> > > URL:
> > > http://www.ietf.org/internet-drafts/draft-dong-idr-rtc-hierarchical-
> > > rr
> > > -00.txt
> > > Status:
> > > https://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/
> > > Htmlized:
> > > http://tools.ietf.org/html/draft-dong-idr-rtc-hierarchical-rr-00
> > >
> > >
> > > Abstract:
> > >    The Route Target (RT) Constrain mechanism specified in RFC 4684 is
> > >    used to build a route distribution graph in order to restrict the
> > >    propagation of Virtual Private Network (VPN) routes.  In network
> > >    scenarios where hierarchical route reflection (RR) is used, the
> > >    existing RT-Constrain mechanism cannot build a correct route
> > >    distribution graph.  This document refines the route distribution
> > >    rules of RT-Constrain to address the hierarchical RR scenarios.
> > >
> > >
> > >
> > >
> > >
> > > Please note that it may take a couple of minutes from the time of
> > > submission until the htmlized version and diff are available at
> tools.ietf.org.
> > >
> > > The IETF Secretariat
> >
> > _______________________________________________
> > 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