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

[Greg Mirsky <[e-mail]>]

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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>