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

From: Greg Mirsky <[email-masked]>
Date: Mon, 1 Mar 2010 10:53:07 -0800

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

   - was it reviewed/discussed by OSPF and ISIS WGs;
   - how not advertising connection to a broadcast network is better then
   advertising it with maximum cost
   - 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
   - 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".

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 <[email-masked]> 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 ([email-masked]).
>
> The working group last call end eob March 12.
>
> /Loa
> --
>
>
> Loa Andersson                         email: [email-masked]
> Sr Strategy and Standards Manager            [email-masked]
> Ericsson Inc                          phone: +46 10 717 52 13
>                                             +46 767 72 92 13
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: <[email-masked]>
Date: Mon, 1 Mar 2010 19:59:25 +0000

Greg,

On 01/03/2010 18:53, "Greg Mirsky" <[email-masked]> 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

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

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 1 Mar 2010 15:14:41 -0500

Greg, see inline @ [Sri]

- Sri

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

Dear Authors,

 *   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 <[email-masked]<mailto:[email-masked]>> wrote:
All,

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

/Loa
--

Loa Andersson                         email: [email-masked]<mailto:[email-masked]>
Sr Strategy and Standards Manager            [email-masked]<mailto:[email-masked]>
Ericsson Inc                          phone: +46 10 717 52 13
                                            +46 767 72 92 13
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 1 Mar 2010 12:27:21 -0800

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

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 1 Mar 2010 12:52:11 -0800

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 <[email-masked]
> wrote:

>  Greg, see inline @ [Sri]
>
>
> - Sri
>
>
>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Greg Mirsky
> *Sent:* Monday, March 01, 2010 10:53 AM
> *To:* [email-masked]
> *Subject:* Re: [mpls] working group last call on
>    [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.
>    [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
>    [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
>

---

From: Wenhu Lu <[email-masked]>
Date: Mon, 1 Mar 2010 16:21:47 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Monday, March 01, 2010 12:52 PM
To: Sriganesh Kini
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Greg, see inline @ [Sri]

- Sri

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

Dear Authors,

 *
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

/Loa
--

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 1 Mar 2010 16:24:15 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Monday, March 01, 2010 12:27 PM
To: [email-masked]
Cc: [email-masked]
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, <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

The draft states:
  In Figure 1 when

Ben

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 1 Mar 2010 13:55:58 -0800

Hi Wenhu,
the RFC 5443 does not explicitly specify when the real IGP cost must be
advertised. 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). 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.

Regards,
Greg

On Mon, Mar 1, 2010 at 1:21 PM, Wenhu Lu <[email-masked]> wrote:

> *Sent:* Monday, March 01, 2010 12:52 PM
> *To:* Sriganesh Kini
> *Cc:* [email-masked]
>
> 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 <
> [email-masked]> wrote:
>
>>  Greg, see inline @ [Sri]
>>
>>
>> - Sri
>>
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
>> Of *Greg Mirsky
>>    [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.
>>

---

From: <[email-masked]>
Date: Mon, 1 Mar 2010 22:10:00 +0000

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 [[email-masked]]
Sent: 01 March 2010 21:24
To: Greg Mirsky; Niven-jenkins,B,Ben,DMK5 R
Cc: [email-masked]
Subject: RE: [mpls] working group last call on  draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Greg,

- Sri

Ben,

Regards,
Greg

The draft states:
  In Figure 1 when

Ben

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 1 Mar 2010 14:58:40 -0800

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, <[email-masked]> wrote:

> 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.
>
> Subject: RE: [mpls] working group last call on
> 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.
>
> Subject: Re: [mpls] working group last call on
> C-D it

---

From: Wenhu Lu <[email-masked]>
Date: Mon, 1 Mar 2010 18:14:16 -0500

Hi Greg,
My answers inline with [luw].

________________________________
From: Greg Mirsky [mailto:[email-masked]]
Sent: Monday, March 01, 2010 1:56 PM
To: Wenhu Lu
Cc: Sriganesh Kini; [email-masked]
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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Greg Mirsky
Sent: Monday, March 01, 2010 12:52 PM
To: Sriganesh Kini
Cc: [email-masked]<mailto:[email-masked]>

Hi Sri,

Regards,
Greg

- Sri

Dear Authors,

 *

Regards,
Greg

/Loa
--

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 1 Mar 2010 15:31:51 -0800

Hi Wenhu,
I've snipped text to leave only your question for further discussion.

> "A" wants the traffic continues to flow through the backup path
> "PE1-A-C-D-PE2" for a while, so that it gains
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

---

From: Wenhu Lu <[email-masked]>
Date: Mon, 1 Mar 2010 19:15:25 -0500

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:[email-masked]]
Sent: Monday, March 01, 2010 3:32 PM
To: Wenhu Lu
Cc: [email-masked]
Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Hi Wenhu,

                          |
                          |    +---+           +---+

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

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 1 Mar 2010 16:27:53 -0800

Hi Wenhu,
I think that you are overlooking the fact that B advertises at LSInfinity
its ALL links, including to PE2 in your diagram. 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 <[email-masked]> 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 !
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Monday, March 01, 2010 3:32 PM
> *To:* Wenhu Lu
> *Cc:* [email-masked]
>
> 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
>

---

From: Wenhu Lu <[email-masked]>
Date: Mon, 1 Mar 2010 19:33:48 -0500

Hi Greg,
Inline.

________________________________
From: Greg Mirsky [mailto:[email-masked]]
Sent: Monday, March 01, 2010 4:28 PM
To: Wenhu Lu
Cc: [email-masked]
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".

Regards,
-wenhu

________________________________
From: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, March 01, 2010 3:32 PM
To: Wenhu Lu
Cc: [email-masked]<mailto:[email-masked]>

Hi Wenhu,

                          |
                          |    +---+           +---+

Regards,
-wenhu

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 1 Mar 2010 17:01:47 -0800

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 <[email-masked]> wrote:

> *Sent:* Monday, March 01, 2010 4:28 PM
>
> *To:* Wenhu Lu
> *Cc:* [email-masked]
> its ALL links, including to PE2 in your diagram.
> 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
>

---

From: Wenhu Lu <[email-masked]>
Date: Mon, 1 Mar 2010 20:49:53 -0500

Hi Greg,
Glad we finally converged.
A few more inline.

________________________________
From: Greg Mirsky [mailto:[email-masked]]
Sent: Monday, March 01, 2010 5:02 PM
To: Wenhu Lu
Cc: [email-masked]
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.

To: Wenhu Lu

Hi Wenhu,

Best regards,
-wenhu

Regards,
Greg

Regards,
-wenhu

Hi Wenhu,

                          |
                          |    +---+           +---+

Regards,
-wenhu

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 1 Mar 2010 17:55:07 -0800

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 <[email-masked]> wrote:

> *Sent:* Monday, March 01, 2010 5:02 PM
>
> *To:* Wenhu Lu
> *Cc:* [email-masked]
> 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?

---

From: Wenhu Lu <[email-masked]>
Date: Tue, 2 Mar 2010 15:24:27 -0500

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:[email-masked]]
Sent: Monday, March 01, 2010 5:55 PM
To: Wenhu Lu
Cc: [email-masked]
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.

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Best regards,
-wenhu

Regards,
Greg

Regards,
-wenhu

Hi Wenhu,

                          |
                          |    +---+           +---+

Regards,
-wenhu

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 2 Mar 2010 12:33:47 -0800

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 <[email-masked]> wrote:

> *Sent:* Monday, March 01, 2010 5:55 PM
>
> *To:* Wenhu Lu
> *Cc:* [email-masked]

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 2 Mar 2010 16:05:57 -0500

If link is advertised as stub, LDP session will not come up when the link is a cut-edge. This is due to SPF not installing routes to the loopback address of the other node (which is typically the address to which LDP session is established) and this is due to failure of the bi-directional check in SPF.

- Sri

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Tuesday, March 02, 2010 12:34 PM
To: Wenhu Lu
Cc: [email-masked]
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

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Best regards,
-wenhu

Regards,
Greg

Regards,
-wenhu

Hi Wenhu,

                          |
                          |    +---+           +---+

Regards,
-wenhu

Regards,
Greg

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 2 Mar 2010 16:06:26 -0500

- Sri

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Best regards,
-wenhu

Regards,
Greg

Regards,
-wenhu

Hi Wenhu,

                          |
                          |    +---+           +---+

Regards,
-wenhu

Regards,
Greg

---

From: Wenhu Lu <[email-masked]>
Date: Tue, 2 Mar 2010 16:33:25 -0500

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

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Best regards,
-wenhu

Regards,
Greg

Regards,
-wenhu

Hi Wenhu,

                          |
                          |    +---+           +---+

Regards,
-wenhu

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 2 Mar 2010 14:10:19 -0800

Hi Sri,
according to my understanding of your work and based on RFC 2328 Section
12.4.1 your Router LSA (I'm more comfortable with OSPF as IGP example) will
have Link Type 3 "Link to Stub network" with network address as Link ID
until the LDP convergence presumably is achieved. Only then the Router LSA
will be re-originated with Link Type 2 "Link to Transit network" and address
of the DR as Link ID.  (In case of p2p link, as you've suggested in the
document, Type 2 Link will be updated with Type 1 after LDP converges). Is
my understanding of implementation of your proposal in OSPF is correct?

Regards,
Greg

On Tue, Mar 2, 2010 at 1:06 PM, Sriganesh Kini
<[email-masked]>wrote:

>  If link is advertised as stub, LDP session will not come up when the link
> is a cut-edge. This is due to SPF not installing routes to the loopback
> address of the other node (which is typically the address to which LDP
> session is established) and this is due to failure of the bi-directional
> check in SPF.
>
>
> - Sri
>
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 2 Mar 2010 14:15:18 -0800

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 <[email-masked]> wrote:

> *Sent:* Tuesday, March 02, 2010 12:34 PM
>
> *To:* Wenhu Lu
> *Cc:* [email-masked]
>>>   On Mon, Mar 1, 2010 at 4:33 PM, Wenhu Lu <[email-masked]>wrote:
>>>
>>>>  Hi Greg,
>>>> Inline.
>>>>
>>>> I think that you are overlooking the fact that B advertises at
>>>> LSInfinity its ALL links, including to PE2 in your diagram.
>>>>  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
>>>>> 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

---

From: Wenhu Lu <[email-masked]>
Date: Tue, 2 Mar 2010 17:19:39 -0500

Hi Greg,
Inline.

________________________________
From: Greg Mirsky [mailto:[email-masked]]
Sent: Tuesday, March 02, 2010 2:10 PM
To: Sriganesh Kini
Cc: Wenhu Lu; [email-masked]
Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Hi Sri,
according to my understanding of your work and based on RFC 2328 Section 12.4.1 your Router LSA (I'm more comfortable with OSPF as IGP example) will have Link Type 3 "Link to Stub network" with network address as Link ID until the LDP convergence presumably is achieved. Only then the Router LSA will be re-originated with Link Type 2 "Link to Transit network" and address of the DR as Link ID.  (In case of p2p link, as you've suggested in the document, Type 2 Link will be updated with Type 1 after LDP converges). Is my understanding of implementation of your proposal in OSPF is correct?
[luw] If the link is a non-cut-edge, yes, we do as you described.
If it's a cut-edge, no, we must not do anything special.
Regards,
-wenhu

Regards,
Greg

On Tue, Mar 2, 2010 at 1:06 PM, Sriganesh Kini <[email-masked]<mailto:[email-masked]>> wrote:
If link is advertised as stub, LDP session will not come up when the link is a cut-edge. This is due to SPF not installing routes to the loopback address of the other node (which is typically the address to which LDP session is established) and this is due to failure of the bi-directional check in SPF.

- Sri

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Best regards,
-wenhu

Regards,
Greg

Regards,
-wenhu

Hi Wenhu,

                          |
                          |    +---+           +---+

Regards,
-wenhu

Regards,
Greg

---

From: Wenhu Lu <[email-masked]>
Date: Tue, 2 Mar 2010 17:23:19 -0500

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:[email-masked]]
Sent: Tuesday, March 02, 2010 2:15 PM
To: Wenhu Lu
Cc: [email-masked]
Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Hi Wenhu,

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

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Best regards,
-wenhu

Regards,
Greg

Regards,
-wenhu

Hi Wenhu,

                          |
                          |    +---+           +---+

Regards,
-wenhu

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 2 Mar 2010 14:28:53 -0800

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 <[email-masked]> wrote:

> *Sent:* Tuesday, March 02, 2010 2:15 PM
>
> *To:* Wenhu Lu
> *Cc:* [email-masked]
>> 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 Mon, Mar 1, 2010 at 4:15 PM, Wenhu Lu <[email-masked]>wrote:
>>>>>
>>>>>>  Hi Greg,

---

From: Wenhu Lu <[email-masked]>
Date: Tue, 2 Mar 2010 17:40:20 -0500

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:[email-masked]]
Sent: Tuesday, March 02, 2010 2:29 PM
To: Wenhu Lu
Cc: [email-masked]
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

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Best regards,
-wenhu

Regards,
Greg

Regards,
-wenhu

Hi Wenhu,

                          |
                          |    +---+           +---+

Regards,
-wenhu

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 2 Mar 2010 14:48:51 -0800

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.

Regards,
Greg

On Tue, Mar 2, 2010 at 2:40 PM, Wenhu Lu <[email-masked]> wrote:

> *Sent:* Tuesday, March 02, 2010 2:29 PM
>
> *To:* Wenhu Lu
> *Cc:* [email-masked]
>>>>> 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
>>>>>>> "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 !

---

From: Wenhu Lu <[email-masked]>
Date: Tue, 2 Mar 2010 18:41:55 -0500

Hi Greg,
You're welcome.

________________________________
From: Greg Mirsky [mailto:[email-masked]]
Sent: Tuesday, March 02, 2010 2:49 PM
To: Wenhu Lu
Cc: [email-masked]
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,

Regards,
-wenhu

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Best regards,
-wenhu

Regards,
Greg

Regards,
-wenhu

Hi Wenhu,

                          |
                          |    +---+           +---+

Regards,
-wenhu

Regards,
Greg

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 2 Mar 2010 19:22:12 -0500

Cut-edge step cannot be optional. As I explained in another email when the link is a cut-edge, LDP session does not come up until connectivity is advertised by both routers connected to the cut-edge.

The behavior is by design different depending on whether the link is a cut-edge or not. To summarize:
1. When link is NOT a cut-edge, advertising the link in the LSA MUST be delayed until LDP becomes operational
2. When link is a cut-edge, advertising the link in the LSA is necessary for LDP session to even come up.

- Sri

Hi Wenhu,

Regards,
Greg

Regards,
-wenhu

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Regards,
Greg

To: Wenhu Lu

Hi Wenhu,

Best regards,
-wenhu

Regards,
Greg

Regards,
-wenhu

Hi Wenhu,

                          |
                          |    +---+           +---+

Regards,
-wenhu

Regards,
Greg

---

From: Wenhu Lu <[email-masked]>
Date: Tue, 2 Mar 2010 20:40:20 -0500

Hi Ben,
Please find my comment inline. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 01, 2010 11:59 AM
To: [email-masked]; [email-masked]
Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Greg,

On 01/03/2010 18:53, "Greg Mirsky" <[email-masked]> 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.

The draft states:
   In Figure 1 when

[luw] The "high cost 10" is B's incoming (from A's viewpoint) interface cost.
It will not be used. The cost from A-B-PE2 therefore is 2.
Regards,
-wenhu

Ben

---

From: Wenhu Lu <[email-masked]>
Date: Tue, 2 Mar 2010 20:40:55 -0500

Hi Ben,
Please see inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 01, 2010 2:10 PM
To: Sriganesh Kini; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

[luw] The draft does not use the poison method (bumping up link cost). It instead does the following:
1. If an affected broadcast interface is cut-edge, do nothing special. Follow regular
   IGP protocol precedure;
2. If it is not cut-edge, the affected router (owner of the affected interface) will delay
   advertising its link to the pseudo node (of the broadcast network), until the LDP session
   become fully operational.

[luw] accepted.

[luw] That paragraph explains the limitation of the RFC5443 over the broadcast network.

Regards,
-wenhu

Ben

Greg,

- Sri

Ben,

Regards,
Greg

The draft states:
  In Figure 1 when

Ben

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 3 Mar 2010 07:40:28 +0100 (CET)

On Tue, 2 Mar 2010, Sriganesh Kini wrote:

> Cut-edge step cannot be optional. As I explained in another email when 
> the link is a cut-edge, LDP session does not come up until connectivity 
> is advertised by both routers connected to the cut-edge.

Let me just state that I've actually run into this in a live network where 
ISIS LDP/IGP sync never completed because the router got both paths cut 
off and thus didn't have any other connectivity when one of the links then 
came up.

We nowadays configure it with 60 second holdtime so if LDP hasn't come up 
then bring the link into action anyway.

I don't know what would work best, one way would be to run LDP both 
between loopbacks and on the link addresses, or have some kind of fallback 
mechanism where it tries both. In the end of course we want to go back to 
running it between the loopbacks for the failover scenario.

Also, it would be really really nice if the link in question could 
actually get high cost at both ends, but virtue of just influence from one 
router. I know this requires a change in the IGPs, it would be really nice 
to be able to raise the cost of a link bidirectionally and if this could 
be influenced by configuring just a single router (or having a mechanism 
like LDP/IGP sync trigger this behaviour). It would also be less of a 
hammer than setting isis-overload to remove traffic. Is there a common 
forum for ISIS and OSPF where this could be brought up?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 3 Mar 2010 02:08:34 -0500

Thanks Mikael for sharing your real-world experience. Pls see inline @ [Sri] 

- Sri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: Tuesday, March 02, 2010 10:40 PM
To: [email-masked]
Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

On Tue, 2 Mar 2010, Sriganesh Kini wrote:

> the link is a cut-edge, LDP session does not come up until 
> connectivity is advertised by both routers connected to the cut-edge.

Let me just state that I've actually run into this in a live network where ISIS LDP/IGP sync never completed because the router got both paths cut off and thus didn't have any other connectivity when one of the links then came up.

We nowadays configure it with 60 second holdtime so if LDP hasn't come up then bring the link into action anyway.

[Sri] It is useful to have this kind of fallback since at least IP connectivity would be restored and debugging may get easier. Curious if link was a p2p or multi-access.

I don't know what would work best, one way would be to run LDP both between loopbacks and on the link addresses, or have some kind of fallback mechanism where it tries both. In the end of course we want to go back to running it between the loopbacks for the failover scenario.

Also, it would be really really nice if the link in question could actually get high cost at both ends, but virtue of just influence from one router. I know this requires a change in the IGPs, it would be really nice to be able to raise the cost of a link bidirectionally and if this could be influenced by configuring just a single router (or having a mechanism like LDP/IGP sync trigger this behaviour). It would also be less of a hammer than setting isis-overload to remove traffic. Is there a common forum for ISIS and OSPF where this could be brought up?

[Sri] For a p2p link that is typically what should happen (if RFC5443 is implemented correctly). For multi-access links see the draft section 1 that explains what problems would occur.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 3 Mar 2010 08:35:37 +0100 (CET)

On Wed, 3 Mar 2010, Sriganesh Kini wrote:

> [Sri] For a p2p link that is typically what should happen (if RFC5443 is 
> implemented correctly). For multi-access links see the draft section 1 
> that explains what problems would occur.

This is mainly HDLC/PPP links over POS, or (ten)GE links configured with 
ISIS point-to-point.

When we set cost at one end, this only affects cost one way which is what 
I would like to change so that it would be bidirectional.

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 3 Mar 2010 03:12:20 -0500

Inline @ [Sri] 

- Sri

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Tuesday, March 02, 2010 11:36 PM
To: Sriganesh Kini
Cc: [email-masked]
Subject: RE: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

On Wed, 3 Mar 2010, Sriganesh Kini wrote:

> [Sri] For a p2p link that is typically what should happen (if RFC5443 
> is implemented correctly). For multi-access links see the draft 
> section 1 that explains what problems would occur.

This is mainly HDLC/PPP links over POS, or (ten)GE links configured with ISIS point-to-point.

When we set cost at one end, this only affects cost one way which is what I would like to change so that it would be bidirectional.

[Sri] This problem should not happen if RFC5443 is implemented correctly. Typically both ends of a p2p link will have IGP come up simultaneously but until LDP is established, both routers should be advertising max cost. 

However what might be happening is that the link may be declared up by physical layer at different times. This is typically true of p2p GiGE links if they are going through an intermediate switch & is also true of POS links going over certain types of L1 switches. Each end of the router may detect physical link up but due to the intermediate link between switches being down the IGP (& LDP) adjacency would not come up. After a certain timeout the link (stub) would be advertised with actual cost. Now later if the physical link comes up end-to-end between the two routers, IGP metric must be again changed back to max cost (on both sides) if RFC5443 is interpreted correctly. If this is done then there should be no issue, but there is potential to not get this right and could explain problems that you experienced.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 3 Mar 2010 09:18:58 +0100 (CET)

On Wed, 3 Mar 2010, Sriganesh Kini wrote:

> [Sri] This problem should not happen if RFC5443 is implemented 
> correctly. Typically both ends of a p2p link will have IGP come up 
> simultaneously but until LDP is established, both routers should be 
> advertising max cost.

This is only true if both ends are running LDP/IGP sync.

What I would like is the ability for each end of the link to need to be 
able to declare a high metric regardless of what the other end thinks.

This would mean only one end needs to actually have LDP IGP sync 
implemented, it also means when doing maintenance on a router instead of 
declaring isis-overload we could do "max-metric" on all interfaces which 
would still mean the router is eligable for transit if there is no other 
path, which isis-overload doesn't allow.

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 3 Mar 2010 03:43:58 -0500

Inline @ [Sri] 

- Sri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: Wednesday, March 03, 2010 12:19 AM
To: [email-masked]
Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

[Sri] If both ends are not capable of LDP/IGP Sync it seems like a misconfig (or lack of a config knob)

What I would like is the ability for each end of the link to need to be able to declare a high metric regardless of what the other end thinks.

This would mean only one end needs to actually have LDP IGP sync implemented, it also means when doing maintenance on a router instead of declaring isis-overload we could do "max-metric" on all interfaces which would still mean the router is eligable for transit if there is no other path, which isis-overload doesn't allow.

[Sri] If the goal is to achieve overload-bit like behavior with the exception of allowing transit traffic through the router when no other path is available, then it can be achieved with "max-metric all-interfaces" on one router even though this results in each link being uni-directionally at max-cost. This is because during SPF computation, to transit the router, it will have to go through one link in the direction that it is advertised with max-cost.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 3 Mar 2010 10:47:00 +0100 (CET)

> misconfig (or lack of a config knob)

Correct, but still valid (would mean LDP/IGP sync would work even if only 
one end of the link had it implemented.

> [Sri] If the goal is to achieve overload-bit like behavior with the 
> exception of allowing transit traffic through the router when no other 
> path is available, then it can be achieved with "max-metric 
> all-interfaces" on one router even though this results in each link 
> being uni-directionally at max-cost. This is because during SPF 
> computation, to transit the router, it will have to go through one link 
> in the direction that it is advertised with max-cost.

That doesn't solve directly connected interfaces in HSRP/VRRP type 
redundancy scenarios.

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 3 Mar 2010 04:57:11 -0500

Inline @ [Sri] 

- Sri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: Wednesday, March 03, 2010 1:47 AM
To: [email-masked]
Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

> misconfig (or lack of a config knob)

Correct, but still valid (would mean LDP/IGP sync would work even if only one end of the link had it implemented.

[Sri] If the draft is used instead of RFC5443 then it would work.

> computation, to transit the router, it will have to go through one 
> link in the direction that it is advertised with max-cost.

That doesn't solve directly connected interfaces in HSRP/VRRP type redundancy scenarios.

[Sri] If you can explain with a figure it will help