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

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> 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]]
> *Sent:* Tuesday, March 02, 2010 2:29 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,
> 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 <[e-mail]> 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]]
>> *Sent:* Tuesday, March 02, 2010 2:15 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,
>> we all have our own preferences and understanding of "simple".
>>
>> Regards,
>> Greg
>>
>> On Tue, Mar 2, 2010 at 1:33 PM, Wenhu Lu <[e-mail]> 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]]
>>> *Sent:* Tuesday, March 02, 2010 12:34 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 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>