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

[Wenhu Lu <[e-mail]>]

Hi Greg,
My answers inline with [luw].

________________________________
From: Greg Mirsky [mailto:[e-mail]]
Sent: Monday, March 01, 2010 1:56 PM
To: Wenhu Lu
Cc: Sriganesh Kini; [e-mail]
Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Hi Wenhu,
the RFC 5443 does not explicitly specify when the real IGP cost must be advertised.
[luw] It does, see section 2, third paragraph. Basically when an IGP discovers a new neighbor, it has to update its PDU to reflect the change, either the real cost or poisoned cost.
  Even more, the RFC explicitly discusses configurable delay timer to allow IGP-LDP synchronization and refers to then ongoing LDP End-of-Lib work as better trigger condition (top paragraph on p.3).
[luw] The dealy timer is well understood and already widely used. It is a temporarily workaround of the (not ready yet) End-of-Lib event. I don't see how this would help addressing the broadcast network cases.
 All said, I don't see the problem with the RFC 5443. It allows enough freedom for developers to demonstrate their ingenuity and good judgment.

[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

Regards,
Greg

On Mon, Mar 1, 2010 at 1:21 PM, Wenhu Lu <wenhu.lu<http://wenhu.lu>@ericsson.com<http://ericsson.com>> wrote:
Hi Greg,
The point is that the original (RFC5443) method cannot be used to handle the broadcast network cases.
Do you agree with that?

Thanks,
-wenhu

________________________________
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Greg Mirsky
Sent: Monday, March 01, 2010 12:52 PM
To: Sriganesh Kini
Cc: [e-mail]<mailto:[e-mail]>

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

Hi Sri,
in my view, the problem you're addressing in this document is implementation specific. You're proposing alternative implementation, which requires SPF modification.

Regards,
Greg

On Mon, Mar 1, 2010 at 12:14 PM, Sriganesh Kini <[e-mail]<mailto:[e-mail]>> wrote:
Greg, see inline @ [Sri]


- Sri



________________________________
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Greg Mirsky
Sent: Monday, March 01, 2010 10:53 AM
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Dear Authors,
I've following questions to the document:

 *
was it reviewed/discussed by OSPF and ISIS WGs;
[Sri ] It was presented at OSPF WG in IETF-75
 *
how not advertising connection to a broadcast network is better then advertising it with maximum cost
[Sri ] See section 1 of the draft that explains issues that arise due to advertising it with maximum cost. Not advertising connection to the broadcast network solves those issues.
 *
if the answer to the previous question "Because former considers LDP state", then why not amend second interpretation of the [LDP-IGP-SYNC] with that improvement
[Sri ] The problem with the second interpretation of the draft is described in the last para of section 1. Amending it with LDP state does not help. A's next-hop (towards PE2) would point to B immediately when IGP converges. Consider the timeline when B has not yet advertised a label to A for the prefix PE2. Then A does not have a LSP path to PE2 and would blackhole packets.
 *
I find "will not" in the following sentence at the end of Section 1 to assertive: "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." May I suggest to change it to "may not".
[Sri ] This hinges on a clear definition of operational. The definition we are using is that it is operational (for PE2) when B has advertised a label (for PE2) to A. In this case "will not" is applicable. We can add a clarifying statement in the draft.

Regards,
Greg

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.

On Sat, Feb 27, 2010 at 4:10 AM, Loa Andersson <[e-mail]<mailto:[e-mail]>> wrote:
All,


this is to start a mpls working group last call on
draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Please sen your comments to the mpls working group mailing
list ([e-mail]<mailto:[e-mail]>).

The working group last call end eob March 12.

/Loa
--


Loa Andersson                         email: [e-mail]<mailto:[e-mail]>
Sr Strategy and Standards Manager            [e-mail]<mailto:[e-mail]>
Ericsson Inc                          phone: [phone]
                                            [phone]
_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls