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

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> 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]]
> *Sent:* Monday, March 01, 2010 5:55 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,
> 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 <[e-mail]> wrote:
>
>>  Hi Greg,
>> Glad we finally converged.
>> A few more inline.
>>
>>  ------------------------------
>>  *From:* Greg Mirsky [mailto:[e-mail]]
>> *Sent:* Monday, March 01, 2010 5:02 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,
>>
>> 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 <[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
>>>>
>>>
>>>
>>
>