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

[Greg Mirsky <[e-mail]>]

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