Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt

[Robert Raszuk <[e-mail]>]

Ahmed,

 > May be I understood the source of confusion regarding paths
> The draft does not require modifications to existing prefix
> advertisements rules or implementations. All the draft is saying is that
> if a prefix satisfies the conditions for attaching and advertising "rL"
> and the prefix is being advertised, then rPE attaches "rL" as an
> optional attribute.

To the best of my knowledge today we do not have a defined attribute in 
BGP to carry MPLS labels. If you are proposing a solution which does not 
have corresponding encoding in the protocol you intend to use I think 
you are going a wrong way.

> Regarding diverging to implementation details, I am not prepared to
> discuss any implementation details, at least at this point in time, and
> I will refrain from commenting on any of them.

That's neat :) While you may claim that everything is an implementation 
detail I think you should not be stating as an advantage of your 
proposal the following:

"   o  Very scalable:
        o No router has to copy the routing table of another router"

> AB2: As mentioned at the beginning of the email, the draft never
> indicated that it requires changes to BGP prefix advertisement rules or
> implementations. All the draft is saying that "rL" can be attached to
> advertised prefixes if the PE can and is willing to act as a repair PE

Than your solution is broken. You must at min enable best external to 
cover the case where the VPN chooses by local preference or med 
different exit point as best path. If you do not enable best external or 
add-paths your repair paths will not get advertised.

>> Anyhow to realize your scheme even if we solve major issues a network
>> wide upgrade of participating routers is mandatory.
>>
> AB2: This is incorrect. The scheme can be incrementally deployed few
> routers at a time. For example, one iPE, one rP and two ePEs.

That was correct. Pls notice what I said: "participating routers". Do 
you expect iPE, rP and two ePEs all be from the same vendor and same OS 
branch supporting your feature ???

> AB2: The draft never claimed that it works in all scenarios (and no
> document should be making this claim). But for this particular scenario,
> can you provide more clarification ?

I am afraid this is an implementation detail how you organize the packet 
switching after termination of the IP tunnel.

Rgs,
R.