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

[Wenhu Lu <[e-mail]>]

Hi Greg,
You're welcome.

________________________________
From: Greg Mirsky [mailto:[e-mail]]
Sent: Tuesday, March 02, 2010 2:49 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,
thank you for clarifying your point. Though I'd argue, that if provider is interested in IGP/LDP synchronization, then this "IGP ASAP" might not be as strict. That is why I'd suggest to make cut-edge definition step optional.
[luw] I see what you're saying. The difficulty is that the handling of the two cases (cut-edge and non-cut-edge) is different,
one is to break the connectivity by not advertising the adj (non-cut-edge) so as to discourage the traffic,
the other (cut-edge) is not to break it. Therefore you still have to know the interface's cut-edge property.
You may argue to use the same method (break the connectivity) for the cut-edge case. But this will hold the IGP and LDP
traffic from recovery for a prolonged peorid of time which is hardly acceptable, expecially when there is a solution.

Calculating the cut-edge property is not difficult. It doesn't change the dijkstra algorithm. It's a byproduct of the routing
table updates, probably just one line of code.
Regards,
-wenhu

Regards,
Greg

On Tue, Mar 2, 2010 at 2:40 PM, Wenhu Lu <wenhu.lu<http://wenhu.lu>@ericsson.com<http://ericsson.com>> wrote:
Hi Greg,
The idea is that for cut-edge interface, you don't have backup LSPs.
So when the primary LSP is down, the traffic loss starts.
There is no need to delay the recovery of the IGP routes.
In fact, we want IGP routes recover as soon as possible.

Regards,
-wenhu

________________________________
From: Greg Mirsky [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Tuesday, March 02, 2010 2:29 PM

To: Wenhu Lu
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Hi Wenhu,
though the node still has to determine whether interface is or is not the cut-edge. Right? What is the benefit of not doing LDP/IGP sync for cut-edge interface?

Regards,
Greg

On Tue, Mar 2, 2010 at 2:23 PM, Wenhu Lu <wenhu.lu<http://wenhu.lu>@ericsson.com<http://ericsson.com>> wrote:
Hi Greg,
Basically, if a link is a cut-edge, we don't even bother to perform LDP/IGP sync on that link.
Regards,
-wenhu

________________________________
From: Greg Mirsky [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Tuesday, March 02, 2010 2:15 PM

To: Wenhu Lu
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Hi Wenhu,
we all have our own preferences and understanding of "simple".

Regards,
Greg

On Tue, Mar 2, 2010 at 1:33 PM, Wenhu Lu <wenhu.lu<http://wenhu.lu>@ericsson.com<http://ericsson.com>> wrote:
Hi Greg,
If a link is a cut-edge, we don't do anything (I mean changing LSA, or wait on an LDP timer).
Just follow regular IGP procedure. Simple enough, right?
Thanks,
-wenhu

________________________________
From: Greg Mirsky [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Tuesday, March 02, 2010 12:34 PM

To: Wenhu Lu
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Hi Wenhu,
I don't see my suggestion as "different method". I view your work as having two parts:

 *   definition of cut-edge broadcast IGP interface
 *   advertisement of Stub Link in RTR LSA (OSPF case, IS-IS identical) instead of Transit Link until the LDP converges

If you agree that my understanding of your work is correct, then I can step to my question: How critical to benefit of your work definition of cut-edge status? I don't see it as critical but as optimization for IP convergence. Thus is my suggestion, to make cut-edge definition step in IGP-LDP convergence on a broadcast segment optional.

Regards,
Greg

On Tue, Mar 2, 2010 at 12:24 PM, Wenhu Lu <wenhu.lu<http://wenhu.lu>@ericsson.com<http://ericsson.com>> wrote:
Hi Greg,
I don't quite understand your question. Were you proposing a different method to handle the "cut-edge"?
Would you elaborate a bit ?
Thanks,
-wenhu

________________________________
From: Greg Mirsky [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Monday, March 01, 2010 5:55 PM

To: Wenhu Lu
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Hi Wenhu,
if "cut-edge" is optimization, why not just propose to advertise link to broadcast network as stub until LDP has converged? That would not require the change in SPF and will work.

Regards,
Greg

On Mon, Mar 1, 2010 at 5:49 PM, Wenhu Lu <wenhu.lu<http://wenhu.lu>@ericsson.com<http://ericsson.com>> wrote:
Hi Greg,
Glad we finally converged.
A few more inline.

________________________________
From: Greg Mirsky [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Monday, March 01, 2010 5:02 PM

To: Wenhu Lu
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

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?
[luw] Yes, that's correct. Our method works in both "cut-edge" and "non-cut-edge" scenarios.
Regards,
-wenhu

Regards,
Greg

On Mon, Mar 1, 2010 at 4:33 PM, Wenhu Lu <wenhu.lu<http://wenhu.lu>@ericsson.com<http://ericsson.com>> wrote:
Hi Greg,
Inline.

________________________________
From: Greg Mirsky [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Monday, March 01, 2010 4:28 PM

To: Wenhu Lu
Cc: [e-mail]<mailto:[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 <wenhu.lu<http://wenhu.lu>@ericsson.com<http://ericsson.com>> 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]<mailto:[e-mail]>]
Sent: Monday, March 01, 2010 3:32 PM
To: Wenhu Lu
Cc: [e-mail]<mailto:[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