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

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> 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:* [e-mail] [mailto:[e-mail]] *On Behalf Of
> *Greg Mirsky
> *Sent:* Monday, March 01, 2010 12:52 PM
> *To:* Sriganesh Kini
> *Cc:* [e-mail]
>
> *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 <
> [e-mail]> wrote:
>
>>  Greg, see inline @ [Sri]
>>
>>
>> - Sri
>>
>>
>>  ------------------------------
>> *From:* [e-mail] [mailto:[e-mail]] *On Behalf
>> Of *Greg Mirsky
>> *Sent:* Monday, March 01, 2010 10:53 AM
>> *To:* [e-mail]
>> *Subject:* Re: [mpls] working group last call on
>> draft-ietf-mpls-ldp-igp-sync-bcast-00.txt
>>
>>  Dear Authors,
>> I've following questions to the document:
>>
>>    - 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 <[e-mail]> 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 ([e-mail]).
>>>
>>> The working group last call end eob March 12.
>>>
>>> /Loa
>>> --
>>>
>>>
>>> Loa Andersson                         email: [e-mail]
>>> Sr Strategy and Standards Manager            [e-mail]
>>> Ericsson Inc                          phone: [phone]
>>>                                             [phone]
>>> _______________________________________________
>>> mpls mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>
>>
>