Re: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection

[Robert Raszuk <[e-mail]>]

Vinod,

That puts an interesting challenge to AF independent code which in most 
BGP implementations is BGP best path calculation. Moreover as each peer 
by design will signal different set of RTs you are essentially proposing 
a best path per peer. If I recall correctly even your add-path can not 
provide today different selection criteria on set of eligible paths for 
groups of peers.

For one AF this should work very differently then for the other. Also it 
should work differently on RR then on ASBR.

With this in mind I think we need to first wait to evaluate the new RTC 
draft then if that passes any further then IETF submission front end we 
could come back to discuss draft-vinod in it's -00 or -01 versions.

Rgs,
R.

> When you explained how draft-vinod is to work I assumed and took as
> obvious that you are calling for modification to how RTC works today for
> AFI/SAFIs draft-vinod would be applicable for.
>
> Yes that's correct, we are calling for modification to the present RTC implementation. This was answered since when we were speaking about the RR specific RT, which can be signalled via RTC - In this case, the RR is to only announce the best path for a given prefix and this different to the present behaviour of RTC and will need to be modified.
>
> Someone asked if you are going to issue a new RTC spec to address this,
> but that AFAIK was never answered.
>
> Yes that is correct.
>
> Regards
>
> Vinod Joseph
> Professional Services - Service Provider Europe
> Juniper Networks
> M: [phone]
> E: [e-mail]
>
>
>
>
> -----Original Message-----
> From: Robert Raszuk [mailto:[e-mail]]
> Sent: 12 June 2011 19:44
> To: Vinod Joseph
> Cc: Jakob Heitz; [e-mail]; [e-mail]; Thareja, Gaurav; Amit Khopkar; [e-mail]; [e-mail]
> Subject: Re: [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection
>
> Hi Vinod,
>
> Bruno interpretation is correct your is I am afraid wrong even to your
> own implementation of RTC.
>
> RTC does not modify best path calculation. For VPN in the even there
> would be overlapping VPNv4 nets different RD per VRF solves the problem
> of different path with different RT being selected as overall best and
> dropped by RTC. Perhaps operators may speak if they are using different
> RDs in case there would be two different VPNv4 paths for the same net or
> not today with RTC.
>
> When you explained how draft-vinod is to work I assumed and took as
> obvious that you are calling for modification to how RTC works today for
> AFI/SAFIs draft-vinod would be applicable for.
>
> Someone asked if you are going to issue a new RTC spec to address this,
> but that AFAIK was never answered.
>
>   >  Let me also re-iterate that a BGP speaker does not need to have a
>   >  "RT" configured, if it does not intend to add an extended community
>   >  to any of its announced prefixes, but will have the ability to use RT
>   >  constrain to indicate a list of RTs it is interested in.
>
> You contradicting yourself. In order to use RTC for signaling on the
> interested set of RTs those I am afraid need to be configured.
>
>   >  words, only ASBRs may have Route Targets configured, and all PE may
>   >  just use RTC to indicate preferences in a list of given ASBRs.
>
> RTC is not a cristal ball. When we wrote it we were thinking about
> adding some magic to it, but since it would even further delay review
> and release of the spec we concluded that we will leave it for later
> time ;-). Perhaps the time is now !
>
> Cheers,
> R.
>
>> Yes it has been Jacob.
>>
>> The proposal uses ADD-PATH in combination with RTC - Therefore if a
>> PE signals interest in a given RT (ASBRs), the RR will use ADD-PATH
>> in order to make sure that NO best path calculation is used to
>> tie-break between multiple paths within the same RT and in effect
>> announce all or "N" paths (that can be configured on a per
>> Peer/Peer-Group) basis to the PE.
>>
>> Let me also re-iterate that a BGP speaker does not need to have a
>> "RT" configured, if it does not intend to add an extended community
>> to any of its announced prefixes, but will have the ability to use RT
>> constrain to indicate a list of RTs it is interested in. In other
>> words, only ASBRs may have Route Targets configured, and all PE may
>> just use RTC to indicate preferences in a list of given ASBRs.
>>
>> Regards
>>
>> Vinod Joseph Professional Services - Service Provider Europe Juniper
>> Networks
>>   M: [phone] E: [e-mail]
>>
>>
>>
>> -----Original Message----- From: Jakob Heitz
>> [mailto:[e-mail]] Sent: 12 June 2011 17:43 To:
>> [e-mail] Cc: Vinod Joseph;
>> [e-mail]; [e-mail]; Thareja, Gaurav; Amit Khopkar;
>> [e-mail]; [e-mail] Subject: Re:
>> [Idr] Comments ondraft-vinod-lavallee-bgp-optimal-route-reflection
>>
>> Has this been answered?
>>
>> -- Jakob Heitz.
>>
>>
>> On Jun 8, 2011, at 6:33 AM,
>> "[e-mail]"<[e-mail]>
>> wrote:
>>
>>> Thanks for the feedback.
>>>
>>> Regarding RTC behavior, I don't agree of your interpretation of the
>>> way it works, you said : "There is no best path calculation when
>>> using RT constrain. The RR just picks the number of paths that
>>> match a given RT and advertise this to the PE." Maybe I'm wrong,
>>> but I hope Robert will correct us as he is one of people who
>>> defined RTC :) For me, RTC doesn't change anything to the way BGP
>>> is globally working. RTC was designed to work for VPNs (first IPv4
>>> but now it can be used for all VPN types). RTC is just a way to
>>> signal an interrest for a BGP speaker for a specific set of VPN
>>> prefixes matching some RTs (with end to end possibility to
>>> propagate it). This signalling will lead for the peer who received
>>> the RT NLRI to install a per peer ORF. And imo that's all. So if
>>> you take this case (VPN) :
>>>
>>> PE1 imports RT1 in VRF1 and peers with RR1 (enabling RTC between
>>> them) PE1 signals his interrest for RT1 using RT AFI/SAFI to RR1.
>>>
>>> RR1 owns VPN routes and has the followings : RD1:X/Y label z Path 1
>>> ->   NH1 (IGP cost 10), LP100, ASPATH empty, RT1 Path 2  ->   NH2
>>> (IGP cost 5), LP100, ASPATH empty, RT2
>>>
>>> RD2:A/B label C Path 1  ->   NH1 (IGP cost 10), LP100, ASPATH empty,
>>> RT1
>>>
>>> RD3:A/B label D Path 2  ->   NH2 (IGP cost 5), LP100, ASPATH empty,
>>> RT1
>>>
>>> RR1 still compute best path per VPN prefix (in your case it will be
>>> IPv4 but it doesn't really matter). RD1:X/Y label z ->   Path2 is
>>> best RD2:A/B label C ->   Path1 RD3:A/B label D ->   Path2 Then RR1
>>> will advertise these best path to the peers, especially PE1, but it
>>> has an ORF for PE1 which match only RT1, so only RD2:A/B and
>>> RD3:A/B will be sent, RD1:X/Y will not because it doesn't have the
>>> community.
>>>
>>>
>>> What I mean by this, is that if you consider your case (IPv4), you
>>> will have this :
>>>
>>> PE1 is interrested by ASBR1 and ASBR2 routes, ASBR1 routes marked
>>> with RT1 and ASBR2 marked with RT2. PE1 will signal his interrested
>>> for RT1 and RT2.
>>>
>>> RR1 owns all IPv4 path from ASBRs, if we consider only one prefix
>>> X/Y received from all the ASBRs, we have this : X/Y Path 1  ->
>>> NH=ASBR1 (IGP cost a), LP 100, ASPATH a, RT1 Path 2  ->   NH=ASBR2
>>> (IGP cost b), LP 100, ASPATH b, RT2 Path 3  ->   NH=ASBR3 (IGP cost
>>> c), LP 100, ASPATH c, RT3 ... Path x  ->   NH=ASBRx (IGP cost x), LP
>>> 100, ASPATH x, RTx
>>>
>>> RR1 receives PE1 RT-NLRI and installs ORF for RT1/RT2 on the PE1
>>> peer. RR1 selects best path for all prefixes, and so for X/Y, it
>>> will choose one path, the best for him, based on his own criteria.
>>> So if it selects for example Path3 as best, no path will be
>>> exported to PE1 :(
>>>
>>> All, pls correct me if I'm wrong.
>>>
>>>
>>> Thanks,
>>>
>>
>
>