Subject: [mpls] Last Call: 'Graceful Restart Mechanism for BGP with MPLS' to Proposed Standard

From: The IESG <[email-masked]>
Date: Tue, 22 Feb 2005 09:37:47 -0500

The IESG has received a request from the Multiprotocol Label Switching WG to 
consider the following document:

- 'Graceful Restart Mechanism for BGP with MPLS '
   <draft-ietf-mpls-bgp-mpls-restart-04.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2005-03-21.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mpls-bgp-mpls-restart-04.txt

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 24 Feb 2005 18:41:09 -0000

Hi,

I am a little surprised that this I-D is in IETF last call when it is so heavily dependent on another I-D (draft-ietf-idr-restart) that is only in "Publication Requested" state. Should this I-D advance beyond IETF last call and the dependent processes change we might be in a pickle.

(OTOH, I am not clear why draft-ietf-idr-restart has been in its current state for 12 months)

Regards,
Adrian

===
Might have been nice to de-nit this before issuing last call.
===
I think your page throws are misplaced wrt the page numbers.
===
My understanding is that the Abstract should not contain citations.
===
Section 1
   In the case where a Label Switching Router (LSR) could preserve its
   MPLS forwarding state across restart of its control plane, and
   specifically its BGP component, and BGP is used to carry MPLS labels
   (e.g., as specified in [RFC3107]), it may be desirable not to perturb
   the LSPs going through that LSR (and specifically, the LSPs
   established by BGP)
ADD
   after failure of or restart of the BGP component of the control plane.
===
Section 1
OLD
   In this document, we describe a mechanism that
   allows to accomplish this goal.
NEW
   In this document, we describe a mechanism that
   allows this goal to be accomplished.
===
Section 1
   The mechanism described in this document is applicable to all LSRs,
   both those with the ability to preserve forwarding state during BGP
   restart and those without (although the latter need to implement only
   a subset of the mechanism described in this document).  Supporting a
   subset of the mechanism described here by the LSRs that can not
   preserve their MPLS forwarding state across the restart would not
   reduce the negative impact on MPLS traffic caused by their control
   plane restart, but it would minimize the impact if their neighbor(s)
   are capable of preserving the forwarding state across the restart of
   their control plane and implement the mechanism described here.  The
   subset includes all the procedures described in this document, except
   the procedures in Sections 4.1, 4.2, 4.3, 5, and 6.
Section 6 describes procedures at the LSR adjacent to the restarting LSR. This paragraph implies that "the LSRs that can not preserve their MPLS forwarding state across restart" do not have to support the procedures in section 6. This seems like a disconnect.
===
Section 2
OLD
   to create new <FEC -> label> bindings after restart, while temporary
   maintaining MPLS forwarding state corresponds to both the bindings
NEW
   to create new <FEC -> label> bindings after restart, while temporarily
                                                                      ^^^
   maintaining MPLS forwarding state corresponding to both the bindings
===                                               ^^^
Section 4
OLD
   Procedures in this section applies when a restarting LSR is able to
NEW
   Procedures in this section apply when a restarting LSR is able to
                                  ^
=== 
Section 4.3
OLD
   not allocate label for that route.
NEW
   not allocate a label for that route.
                ^
===
Section 5
OLD
   restart, while temporary maintaining MPLS forwarding state
NEW
   restart, while temporarily maintaining MPLS forwarding state
                          ^^
===
Section 5
OLD
   The procedures described in this section requires that for the use by
NEW
   The procedures described in this section require that for the use by
                                                   ^
===
Section 5
   The LSR MAY retain the forwarding state
   even a bit longer (the amount of extra time MAY be controlled by
   configuration on the LSR), as to allow the neighbors to receive and
   process the routes that have been advertised by the LSR. After that,
   the LSR MAY delete the MPLS forwarding state that it preserved across
   the restart.
What do you mean "MAY delete". You mean that deletion is optional and an implementation would normally continue to retain this state?
===
Section 6
   To minimize the potential mis-routing caused by the label change,
   when creating a new <label, FEC> binding the LSR SHOULD pick up the
   least recently used label. Once an LSR releases a label, the LSR
   SHALL NOT re-use this label for advertising a <label, FEC> binding to
   a neighbor that supports graceful restart for at least the Restart
   Time, as advertised by the neighbor to the LSR.
1. The "SHOULD pick up the least recently used label" seems extreme to
   me. It is surely enough to use any label that has not been used for
   at least the Restart Time.
2. "Once an LSR releases a label, the LSR SHALL NOT..." 
   Are we to assume that this applies to *ANY* label release (as the
   text implies) or only to labels released during restart processing?
   I think the former, and it would be very helpful (important) to stress
   this at this point in the text.
===
Section 8
OLD
   In addition, the mechanism described here renders LSRs that implement
   it to additional denial-of-service attacks as follows:
NEW
   In addition, the mechanism described here renders LSRs that implement
   it vulnerable to additional denial-of-service attacks as follows:
      ^^^^^^^^^^^
===
Section 12
   [1] "Graceful Restart Mechanism for BGP", draft-ietf-idr-
   restart-01.txt
This has moved on one or two revisions. Suggest you strike the version number.

----- Original Message ----- 
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, February 22, 2005 2:37 PM
Subject: Last Call: 'Graceful Restart Mechanism for BGP with MPLS' to Proposed Standard 

> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
> 
>

---

From: Bill Fenner <[email-masked]>
Date: Thu, 24 Feb 2005 15:22:11 -0800

Ouch.  I only count 8 months, but you're right, this kind of delay
is unacceptable.

Much of the delay is because we refused to progress any idr documents
until the base spec was done; now that the base spec is done I need to
get cracking on helping things to progress.

  Bill