1 Mar 2010 22:24
Re: working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt
Sriganesh Kini <sriganesh.kini <at> ericsson.com>
2010-03-01 21:24:15 GMT
2010-03-01 21:24:15 GMT
In your "how I'd do that" proposal, if B is advertising the real cost before the "obviously lagging behind LDP" has setup the LSP path to PE2, then traffic loss occurs as explained in RFC 5443.
Regarding "the same lagging behind exists in the proposed schema", the solution proposed in draft-ietf-mpls-ldp-igp-sync-bcast is designed to address the lagging condition and ensure there is no loss due to the lagging.
Regarding "I personally don't see strong enough benefits. Existing listed in the document interpretations permit implementations that are not worse than described new method". Both section 1 and 3 in the draft provide use-cases and solutions to prove those statements incorrect. It will be useful if you can give detailed explanations why you believe otherwise.
Implementation experience has shown that change in the IGP is straightforward.
From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of Greg MirskyBen,
Sent: Monday, March 01, 2010 12:27 PM
To: benjamin.niven-jenkins <at> bt.com
Cc: mpls <at> ietf.org
Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt
I'm not familiar with the particular implementation of trigger to change cost in LSA thus everything further is my speculation a'la "how I'd do that".
Firstly, B advertises high cost (perhaps maxCost/2). When all IGP adjacencies been formed (perhaps forming adjacencies with DR and BDR on the Broadcast segment is sufficient condition), B advertises the real cost in its LSA. That is when IGP really converges since A switches the best route to PE2 from C to B. Will LDP lag behind? Obviously. But the same laging behind exists in the proposed schema. I personally don't see strong enough benefits. Existing, listed in the document, interpretations permit implementations that are not worse then described new method. Considering risk of changing SPF to determine "cut-edge" status ...
GregOn Mon, Mar 1, 2010 at 11:59 AM, <benjamin.niven-jenkins <at> bt.com> wrote:Greg,I still don't understand...
On 01/03/2010 18:53, "Greg Mirsky" <gregimirsky <at> gmail.com> wrote:
> PS. RE: Question #2 from Ben. Cost to PE2 through B is 2, while through C-D it
> is 3. Thus B will be selected as NHR from A to PE2. Note, that the stated
> problem exists only if a better path is coming up on the broadcast segment.
The draft states:
In Figure 1 when
B's link to the broadcast network comes up, it advertises a high cost
to the broadcast network. After IGP has converged but the LDP peeringA-B is not yet operational, A will have B as the nexthop for PE2 andwill not have a LDP LSP path to PE2. VPN traffic from PE1 to PE2 will
be dropped at A.
Let's say "high cost" = 10 and "normal cost" = 1.
B will bring up its broadcast link and advertise it with a high cost of 10.
PE1-A-B-PE2 will have a cost of 11. PE1-A-C-D-PE2 will have a cost of 3.
After IGP convergence PE1-A-B-PE2 will still have a cost of 11, will it not?
_______________________________________________ mpls mailing list mpls <at> ietf.org https://www.ietf.org/mailman/listinfo/mpls