The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] Re: Last Call: 'Graceful Restart Mechanism for BGP withMPLS' to Proposed Standard
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" <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
Cc: <mpls@ietf.org>
Sent: Tuesday, February 22, 2005 2:37
PM
Subject: Last Call: 'Graceful Restart Mechanism
for BGP with MPLS' to Proposed Standard > 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 > iesg@ietf.org or ietf@ietf.org 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 > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
|
|