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

[Robert Raszuk <[e-mail]>]

Joel, Paul

I am looking at the version -01 and can't find any encoding how are you
proposing to send multiple vpnv4/v6 paths each with different next hop
and a different VPN labels.

Can you clarify ?

And operationally this is common request for SPs providing same RD
across VPN type of configurations or in few scenarios of inter-as
topologies.

Cheers,
R.

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

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