Subject: wg last call draft-ietf-mpls-ldp-restart-02.txt

From: Loa Andersson <[email-masked]>
Date: Thu, 20 Jun 2002 10:01:55 +0200

This message initiates a two week WG last call on:

Graceful Restart Mechanism for LDP

       <draft-ietf-mpls-ldp-restart-02.txt>

Please send your comments to the mailing list.

This wg last call ends July 5, 2002 at 2400 GMT.

/Loa

-- 
Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office          +46 8 5270 2000
Office direct   +46 8 5270 5038
Mobile          +46 70 848 5038
Email           [email-masked]
WWW             www.utfors.se

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 20 Jun 2002 11:16:37 -0400

Since this draft has an explicit dependency on draft-ietf-mpls-ldp-ft-03.txt,
and since draft-ietf-mpls-ldp-ft-03.txt is also ready for last call, can I
suggest that the last calls proceed in parallel?

Thanks,
Adrian
----- Original Message -----
From: "Loa Andersson" <[email-masked]>
To: "mpls wg" <[email-masked]>
Cc: "Scott Bradner" <[email-masked]>; "George Swallow" <[email-masked]>;
"Yakov Rekhter" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, June 20, 2002 4:01 AM
Subject: wg last call draft-ietf-mpls-ldp-restart-02.txt

---

From: George Swallow <[email-masked]>
Date: Thu, 20 Jun 2002 11:49:35 -0400

> suggest that the last calls proceed in parallel?

Yes.  This officially begins a two week WG last call on:

    Fault Tolerance for LDP and CR-LDP

     <draft-ietf-mpls-ldp-ft-03.txt>

George & Loa
==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 21 Jun 2002 00:47:42 -0400

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 
   this draft applies only to DU.  Currently this is 
   tucked away in para 3 of section 6.

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

3. It would be helpful to add some text to cover processing
   of other messages while an LSR is in the process of 
   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 
   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.

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

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

6. Section 6 states that there is an assumption that IP
   forwarding state is preserved in parallel to MPLS 
   forwarding state.  I looked hard for a reference to this
   in the text and only found the case of the restarting 
   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.

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

Hope this is of some help.
Regards,
Adrian

---

From: Yakov Rekhter <[email-masked]>
Date: Sun, 23 Jun 2002 08:55:06 -0700

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

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

>    Mapping message" is a "newly received Mapping message"?

Done (as you suggested).

>    to normal Release procedures on local node.

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

>    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

not sure.

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 27 Jun 2002 00:21:48 -0400

Yakov,

> >    of other messages while an LSR is in the process of=20
> >    Withdraw should match in table, delete from table and=20

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.

> >    need to be exchanged before the downstream node starts=20

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

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

Regards,
Adrian