The MPLS WG Archive

["Adrian Farrel" <afarrel@movaz.com>]

Yakov,

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

How about...

While an LSR is in the process of restarting it may also receive
other label management messages.  These SHOULD be handled
according to the following rules.

- A Label Withdraw should be matched against the table.  If a
  match is found, the entry should be deleted from the table and
  a Label Withdraw propagated upstream according to the
  protocol options in operation at the LSR.  If no match is found
  the Label Withdraw should be silently dropped.
- A Label Release should be matched against the table.  If no
  match is found, or a match is found and the entry is marked as
  stale the Label Release should be silently dropped.  If a match
  is made and the entry is not stale, processing should continue
  accoding to the normal Label Release procedures on the LSR.
- A Label Abort message should not match any entry in the table
  since the procedures in this draft apply to Downstream Unsolicited
  operation only.

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

As described in section 6.1.1, if the label carried in a Label Mapping
message received during restart processing is not an Implicit NULL,
the LSR searches its MPLS forwarding table for an entry with the
outgoing label equal to the label carried in the message, and the
next hop equal to one of the addresses (next hops) received in one
of the Address messages from the peer.

In order that the address can be properly validated, the restarted
LSR must have an up-to-date list of addresses.  This could be
achieved by the restarting LSR saving previously received addresses
to non-volatile storage and retrieving them during restart, but this
does not protect against address changes while the restarted LSR
is off-line.

As a result it should be noted that the adjacent LSRs SHOULD all
re-send all of their current addresses to the restarted LSR as part of
session re-initialization and before re-sending any label-related
messages.  The restart timers described in this draft should be
factored to include this exchange of addresses.

Note that there is no need to parse the preserved MPLS forwarding
table for enries made invalid by the absence of an address on the
restarted session.  Such entries will still be stale when restart is
complete and will be discarded then.

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

I believe it is.  I'm sure the WG chairs will comment.

Regards,
Adrian