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:[email protected]] Sent: Saturday, July 21, 2012 10:28 AM To: Ahmed Bashandy (bashandy) Cc: [email protected] List; [email protected]; 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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
