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

[Ahmed Bashandy <[e-mail]>]

Robert,
See comments inline. This time look for "AB3:"

Thanks

Ahmed

On 7/19/2012 11:39 PM, Robert Raszuk wrote:
> 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.
AB3: You are rushing things too fast:) We're still discussing the idea.
The syntax of the new attribute will come at later versions. I hope you
do not think that the whole solution is wrong just because I did not put
the syntax of the attribute in the first version.
>
>> 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"
AB3: So either I diverge into implementations or blindly accept what
should be kept in the draft and what should not. If I were to suggest
the above modification, I would make a it more scientific by taking a
closer  look at the draft and trying to corroborate the suggestion by
finding one or more deployment scenarios where one router needs to copy
the routing table of another.
>
>> 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. 
AB3: No it is not. You do not have a full understanding of the draft
> 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.
AB3: I am not sure why you insist on pushing path selection and
advertisement down the throat of the draft. The conditions for
advertising "rL" are clear. What you just suggested is one way to
satisfy the conditions in a certain scenario. BGP-PIC edge and PE-CE
link protection are other scenarios where the conditions of advertising
"rL" are satisfied without best external or add-path.
>
>>> 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".
AB3: IMHO, if a network has thousands of routers, it is hard to label
updating 4 routers as "network wide"
>
> Do you expect iPE, rP and two ePEs all be from the same vendor and
> same OS branch supporting your feature ???
AB3: Ah. So now we're taking the discussion of implementation details to
the level of feature release and router sales:)
>> 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.
AB3: Excellent, so I see an agreement to avoid implementation details:).
>
> Rgs,
> R.
>