The MPLS WG Archive

[Yakov Rekhter <yakov@juniper.net>]

Adrian,

> Hi,
> I have some comments which are mainly requests for clarification to be =
> added to the draft.  I'm sorry to raise them at this late stage, but =
> better now than even later...
> 
> 1. It would be nice if you made it clear up front that=20
>    this draft applies only to DU.  Currently this is=20
>    tucked away in para 3 of section 6.

Done (the text is moved to both the Abstract and the Movitation
sections.

> 2. In the first line of 6.1.1 could you say that "the
>    Mapping message" is a "newly received Mapping message"?

Done (as you suggested).

> 3. It would be helpful to add some text to cover processing
>    of other messages while an LSR is in the process of=20
>    restarting: in particular Withdraw and Release.  Although
>    this is pretty obvious, I believe you run the risk of
>    failure to interop correctly unless you spell it out: viz.
>    Withdraw should match in table, delete from table and=20
>    send Withdraw upstream as required
>    Release should match in table, if entry is stale should
>    ignore, if entry is not stale should process according
>    to normal Release procedures on local node.

please proposed the text, and I'll add it to the draft.

> 4. It would be nice if you exposed that all Address messages
>    need to be exchanged before the downstream node starts=20
>    resending Mapping messages.  Section 6.1.1 is based on the
>    assumption that these messages have been received.

please propose the text and I'll add it to the draft.

> 5. Is it normal procedure to give suggested values for all
>    timers in drafts?

not sure.

> 6. Section 6 states that there is an assumption that IP
>    forwarding state is preserved in parallel to MPLS=20
>    forwarding state.  I looked hard for a reference to this
>    in the text and only found the case of the restarting=20
>    Egress LSR needing to look up the next hop of a FEC if
>    it is also configured to generate a non-null, unique
>    label for such a FEC.  Further this only applies if the
>    FEC is of the type that has its next hop determined
>    through the IP forwarding table.
>    This seems much weaker than the statement in section 6.

I clarified this in Section 6.

> As a general question, has anyone done any analysis of how long it would =
> take to redistribute all of the addresses and labels on a router in a =
> large network?  In other words, what is a reasonable bound for the =
> Recovery Time?  (Note that the neighbors can't start re-using labels =
> until the Recovery Time is complete.)

Among other things, it depends on the processing power of the control plane.

Yakov.