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

[Ahmed Bashandy <[e-mail]>]

It looks like I am going to re-iterate some of the statements that you
seem to avoid (I don't know why)

See replies inline. Look for AB4

Thanks

-----Original Message-----
From: Robert Raszuk [mailto:[e-mail]] Sent: Saturday, July 21,
2012 10:28 AM
To: Ahmed Bashandy (bashandy)
Cc: [e-mail] List; [e-mail]; Maciek Konstantynowicz (mkonstan)
Subject: Re: [Idr] Fwd: New Version Notification for
draft-bashandy-bgp-frr-vector-label-00.txt

Hi Ahmed,

Since you seem to be skipping answering some questions in your replies
let me ask (well repeat) one question at a time.

Question:

How are you going to propagate any information in iBGP from repair PEs
to ingress PEs considering that overall best path for this prefix is
advertised by some other protected PE ?

AB4: Quotation from the first reply (AB:) "The behavior explained in
this document requires the support for multipath". More explicit
statement: how to satisfy the multipath requirement is deliberately left
out of the draft.

Are you mandating that your solution is deployable only with use of one
of the following techniques:

- add-paths on rPEs, RRs & iPEs
- best-external on rPEs + add-paths on RRs & iPEs
- best-external on rPEs + diverse-path on RRs
- full mesh of iPEs & rPEs with best external

AB4: No. The draft does NOT mandate particular multipath technique(s).
This is a question that is already answered. Here is a quotation from
the previous email (AB3:) "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."

(I am skipping cluster external option on RRs as in the control plane
only RRs which are randomly located this may be a bit difficult to
provision).

Scenario clarification:

I am talking about case where pPE chooses the best path based on local
preference or MED.

The only comment I found related to the above is in the introduction:

    In modern networks, it is not uncommon to have a prefix reachable
    via multiple edge routers. One example is the best external path
    [8].

The reason for such fundamental question is that architectures which do
not require at the service level participation of ingress routers and
repair routers in the protection may be chosen over the one which does
(your proposal).

AB4: So all these questions are alluding to a comparison:) A more direct
question, like what Susan asked, would have been easier to answer. IMHO
comparison with other techniques is more befitting an informational draft.

For the participation of iPE and rPE, I have a comment and a request
- BGP-PIC edge is a deployed solution that requires iPE participation.
So it seems like other factors, such as scalability, transparency to
operators, and simplified provisioning and management, are as important
in deployment decisions
- For rPE participation, I would be very happy if you point me to a
paper/draft/implemented/deployed or about to be implemented/deployed
BGP-FRR technique (that rely on local failure detection and traffic
re-routing when an ePE fails) that does not require the participation of
rPE. That would also help with Susan's request.

Rgs,
R.