Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

[Greg Mirsky <[e-mail]>]

Hi Ben,
both RFC 5443 and the draft-ietf-mpls-ldp-igp-sync-bcast-00 refer to the LDP
End-of-Lib as the trigger to advertise the real IGP cost. Thus, I don't see
sufficient benefit in not advertising link in the RTR LSA vs advertising it
with maximum cost (I'd consider max/2 for the same reason as RFC mentioned
for IS-IS). Proposed in the draft-ietf-mpls-ldp-igp-sync-bcast-00 method
does bring some optimization if compared to "interpretation #2" as it
applies staged LSA origination to "cut-edge" IGP interfaces only (though
that comes at the cost of extra SPF run). But that is not directly related
to the stated motivation of this work. The proposed "cut-edge" does not by
itself address issue of IGP-LDP synchronization during convergence but LDP
End-of-Lib does.

Regards,
Greg

On Mon, Mar 1, 2010 at 2:10 PM, <[e-mail]> wrote:

> I might be missing something but...
>
> While not being specific about when an LSR should advertise the true link
> cost RFC5443 does state "when LDP is not "fully operational" (see below) on
> a given link, the IGP will advertise the link with maximum cost to avoid any
> transit traffic over it".
>
> This implies to me that an LSR first advertises the link with maximum cost.
> Then waits for the LDP session to become "fully operational" and only then
> advertises the link's true cost.
>
> I believe draft-ietf-mpls-ldp-igp-sync-bcast-00 attempts to clarify that
> behaviour when used with broadcast links.
>
> If implementers have experienced difficulty interpreting RFC5443 (as
> draft-ietf-mpls-ldp-igp-sync-bcast-00 implies they have) then clarifying the
> expected behaviour is IMO a worthwhile activity.
>
> However, what neither RF5443 not draft-ietf-mpls-ldp-igp-sync-bcast-00
> contain IMO is a clear statement of the order that an LSR should perform
> each step. I think that would be a valuable addition to at least
> draft-ietf-mpls-ldp-igp-sync-bcast-00. As an addition to my original
> question #2 in my LC comments I would like to add the comment that the
> paragraph (Page 4, final paragraph of Section 1) needs updating to indicate
> when the draft assumes the LSR B advertises the link's true cost and why
> that would be before its LDP adjacencies are considered "fully operational".
>
> Ben
>
> P.S. looking at draft-ietf-mpls-ldp-igp-sync-bcast-00 I notice it does not
> explicitly update RFC5443, however if its intention is to further clarify
> how RFC5443 should be applied to broadcast links then I think it should be
> an update to RFC5443.
>
> ________________________________________
> From: Sriganesh Kini [[e-mail]]
> Sent: 01 March 2010 21:24
> To: Greg Mirsky; Niven-jenkins,B,Ben,DMK5 R
> Cc: [e-mail]
> Subject: RE: [mpls] working group last call on
>  draft-ietf-mpls-ldp-igp-sync-bcast-00.txt
>
> Greg,
>
> 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.
>
> - Sri
>
>
>
> ________________________________
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Greg Mirsky
> Sent: Monday, March 01, 2010 12:27 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [mpls] working group last call on
> draft-ietf-mpls-ldp-igp-sync-bcast-00.txt
>
> Ben,
> 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 ...
>
> Regards,
> Greg
>
> On Mon, Mar 1, 2010 at 11:59 AM, <[e-mail]<mailto:
> [e-mail]>> wrote:
> Greg,
>
>
> On 01/03/2010 18:53, "Greg Mirsky" <[e-mail]<mailto:
> [e-mail]>> 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.
>
> I still don't understand...
>
> 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 peering
>  A-B is not yet operational, A will have B as the nexthop for PE2 and
>  will 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?
>
> Ben
>
>
>
>