Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt

[Enke Chen <[e-mail]>]

Hi, Joel:

Joel M. Halpern wrote:

> Enke, I have real trouble with your characterization of your draft.
> You claim it is simple and elegant.
> From where I sit, it introduces a new identifier that must be shared 
> between the routers.  That identifier has to be assigned and managed 
> by the advertising router in such a way that it is unique for each 
> path that needs advertised (under all possible circumstances).  But it 
> has to be used by the receiver no matter how the sender has chosen to 
> allocate / create it.  As such, if the two happen to have the same 
> implementation view they may find it simple.  But it is quite 
> dependent upon that implementation.


I am not sure what you meant by  "same implementation view, and 
dependent upon a particular implementation".  In the add-path proposal, 
the advertiser is responsible for allocating  the identifier suitable 
for a particular application, and the receiver needs to use the (prefix, 
path-identifier) to identify a path to be replaced.  I believe that part 
is clear in the proposal, but if it is not, we'll need to make it clear.

> While our draft makes use of information that was already being 
> exchanged to provide the necessary disambiguation.  I would argue that 
> such is in fact both simpler and more elegant.
>
> At the same time, your claim of greater flexibility is in fact not 
> backed up by need.  We previously had support for advertising paths 
> with different attributes but the same NLRI and the same next-hop.  In 
> discussion with folks we realized that there was no actual use case 
> where you need the differentiation.  Either the advertiser is in the 
> path (next-hop self) in which case preserving the paths does not add 
> information, even for the route oscillation case, or the advertiser is 
> preserving the next-hop information in which case the next hops 
> provide the needed differentiation.  Thus, using the next-hop as an 
> added differentiator provides exactly the flexibility needed by the 
> problem, and is much simpler, more amenable to variations in 
> implementations strategies, and more robust.


I keep hearing that (prefix, nexthop) as the key to identify a path, and 
here you also mentioned "using the next-hop as an added differentiator". 
For several applications I cited, (prefix, nexthop) is actually not the 
right one. Considering the case in which the route reflector would 
advertising all the routes (simulating full-mesh).  It is actually the 
(prefix, router-id) that would identify a path instead of the prefix itself.

As the issue of how to identify a path is so fundamental to a solution,  
I hope that it can be clarified before we dive into other details.

Regards,

-- Enke

>
> Yours,
> Joel M. Halpern
>
> At 03:45 AM 8/23/2006, Enke Chen wrote:
>
>> Hi, Manav:
>>
>> Manav Bhatia wrote:
>>
>>> Hi Enke,
>>>
>>>>
>>>> The add-path draft introduces a path identifier so that a path from 
>>>> a neighbor can be identified by (prefix, path identifier), and the 
>>>> implicit replacement/withdraw behavior (and thus the update 
>>>> efficiency) in BGP is maintained. The path identifier can be a 
>>>> neighbor-AS, or a router-id, or an opaque number suitable for a 
>>>> particular application.
>>>>
>>>> It is not clear to me how the implicit replacement/withdraw can be 
>>>> achieved with your proposal.
>>>
>>>
>>>
>>> Simple. You look at the prefix and the nexthop to perform implicit 
>>> withdraw as this tuple would always be uniquely learnt from each BGP 
>>> speaker.
>>
>>
>>
>> Sorry I do not follow you, and I went back to your draft and got more 
>> confused. As you stated here, as well as in the draft,  a path  is 
>> identified by  (prefix , nexthop-address) in your proposal.  Then how 
>> can a path identified by (prefix, neighbor-As), or (prefix, 
>> router-id), or (prefix, opaque-number) be implicitly 
>> replaced/withdrawn by a mechanism that identifies a path by (prefix, 
>> nexthop-address)?
>>
>> Regarding the need for identifying a path by (prefix, neighbor_AS) or 
>> (prefix, route-id),  I am not sure if you have read the companion 
>> draft of add-path (draft-walton-bgp-route-oscillation-stop-01.txt), 
>> which has expired unfortunately, but is still readily available on 
>> the Internet, for example:
>>
>>
>> http://ietfreport.isoc.org/idref/draft-walton-bgp-route-oscillation-stop-01.txt 
>>
>>
>> Two approaches are presented in the draft to address the ibgp route 
>> oscillation:
>>
>>     1) advertise the available paths (equivalent to full ibgp mesh): 
>> in this case a path is identified by (prefix, router-id).
>>     2) advertise the (neighboring-AS based) group bestpaths: in this 
>> case a path is identified by (prefix, neighboring-AS).
>>
>> They have different scaling properties, and a provider may choose to 
>> deploy one or another. In both cases, however, the nexthop addresses 
>> of the multiple paths being advertised would most likely be different.
>>
>> Since we are comparing the drafts, I think it is fair to ask this 
>> question:
>>
>>    As the add-path draft has existed for a long time, and the spec is 
>> pretty simple, complete, fairly elegant (sure, relatively), I am 
>> wondering if you have spotted certain issues with it that can not be 
>> fixed, or if the solution proposed failed to address a particular 
>> problem that requires multiple paths?
>>
>> -- Enke
>>
>>
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/idr
>

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr