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

[Greg Mirsky <[e-mail]>]

Hi Wenhu,
yes, I stay corrected. The RFC 5443 states that only affected link to be
maxed. In case of the whole node coming up it will be applied to all node
links and thus work for any iIGP interface type. If only one link, then IGP
convergence over the broadcast interface might precede LDP. But then, if
link B-PE2 is up, B's interface to the broadcast segment is not the
"cut-edge" because alternative path PE2-D-C exists. Would you agree?

Regards,
Greg

On Mon, Mar 1, 2010 at 4:33 PM, Wenhu Lu <[e-mail]> wrote:

>  Hi Greg,
> Inline.
>
>  ------------------------------
> *From:* Greg Mirsky [mailto:[e-mail]]
> *Sent:* Monday, March 01, 2010 4:28 PM
>
> *To:* Wenhu Lu
> *Cc:* [e-mail]
> *Subject:* Re: [mpls] working group last call on
> draft-ietf-mpls-ldp-igp-sync-bcast-00.txt
>
>  Hi Wenhu,
>
> I think that you are overlooking the fact that B advertises at LSInfinity
> its ALL links, including to PE2 in your diagram.
> [luw] No, not all links, but only the affected link.
> Please double check RFC5443 section 2, third paragraph, quoted below:
> In detail: 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.
>
> Best regards,
> -wenhu
>
>
>
>  Thus, as I understand OSPF, there's no way A will select B for its path
> to PE2. Yes, you've found another way "to slice the cake" but, as I've
> mentioned, the main issue is when to advertise the real IGP cost being
> handled by both documents identically.
>
> Regards,
> Greg
>
> On Mon, Mar 1, 2010 at 4:15 PM, Wenhu Lu <[e-mail]> wrote:
>
>>  Hi Greg,
>> "I don't think that A has or can to do anything." - that's exactly my
>> point. i.e. A cannot manipulate its cost to favor C or B.
>> Now B can't either !
>> If you increase B's cost (to the LAN) to LSInfinity, it still doesn't
>> change A's decision.
>> "A->B->PE2" is still shorter than "A->C->D->PE2".
>>
>> The traffic thus will be directed to B, hence the traffic loss.
>>
>> Regards,
>> -wenhu
>>
>>  ------------------------------
>>  *From:* Greg Mirsky [mailto:[e-mail]]
>> *Sent:* Monday, March 01, 2010 3:32 PM
>> *To:* Wenhu Lu
>> *Cc:* [e-mail]
>>
>> *Subject:* Re: [mpls] working group last call on
>> draft-ietf-mpls-ldp-igp-sync-bcast-00.txt
>>
>>   Hi Wenhu,
>> I've snipped text to leave only your question for further discussion.
>>
>>
>>>
>>> [luw] Let me ask a simple question. In the following diagram, let's
>>> assume the link cost is 10 everywhere.
>>>
>>>                           |
>>>                           |    +---+           +---+
>>>                           |----| B |-----------|PE2|
>>>                           |    +---+           +---+
>>>         +---+    +---+    |                      |
>>>         |PE1|----| A |----|                      |
>>>         +---+    +---+    |                      |
>>>                           |    +---+    +---+    |
>>>                           |----| C |----| D |----+
>>>                           |    +---+    +---+
>>>
>>>  Originally the primary LSP from PE1 to PE2 is "PE1-A-B-PE2". The backup
>>> LSP is "PE1-A-C-D-PE2".
>>> Now after B's link to the broadcast network (that connects A, B, and C)
>>> restores to UP from being DOWN,
>>> "A" wants the traffic continues to flow through the backup path
>>> "PE1-A-C-D-PE2" for a while, so that it gains
>>> time to recover the primary LSP(s).
>>> With the RFC5443 method, could you let me know what "A" should do to keep
>>> traffic from flowing through "B"?
>>>
>>> Regards,
>>> -wenhu
>>>
>>>
>> I don't think that A has or can to do anything. Per RFC 5443, as well as
>> per your work, it is responsibility of up-and-coming node to try not to
>> disturb existing topology. The node B can, per RFC 5443, advertise its link
>> to the broadcast network (DR in OSPF) with LSInfinity (I'd prefer divide it
>> in half but that's me). The real problem, and RFC 5443 clearly acknowledges
>> this, is when the node B can advertise the real IGP cost (irrespective of
>> type of its IGP interface). Yes, the delay timer is a workaround and sort of
>> a "black magic". The LDP End-of-Lib, as both documents point out, is better
>> and more appropriate trigger.
>>
>> Regards,
>> Greg
>>
>
>