[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-ccamp-mpls-graceful-shutdown-03.txt
adrian
the new error sub-code for the RSVP error-code "Routing
Problem" (24) [RSVP-TE] is:
9 (TBA) Local component link maintenance required
overlaps with the already defined Routing Problem
9 = MPLS label allocation failure [RFC3209]
this said if one does want to achieve certain consistency
it should be defined as a error value should be defined as
a sub-code of the Notify Error code (25)
7 = Local link maintenance required [RFC4736]
8 = Local node maintenance required [RFC4736]
thanks,
-d.
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel
> Sent: Monday, June 11, 2007 3:12 PM
> To: Zafar Ali; ccamp@ops.ietf.org
> Cc: 'Jean Philippe Vasseur'; 'Anca Zamfir';
> Jonathan.newton@cw.com; Brungard, Deborah A, ALABS
> Subject: Re: I-D
> ACTION:draft-ietf-ccamp-mpls-graceful-shutdown-03.txt
>
> Hi,
>
> The authors have indicated that this draft is complete and
> ready for WG last
> call.
>
> As is now our customary ritual, the chairs have done a
> pre-last call review.
> In this case, I am the lucky reviewer.
>
> Although the changes below are relatively minor in substance,
> they are many.
> I feel it would be helpful to reviewers in last call if you
> could provide an
> update with these issues fixed. As soon as I see it published we can
> initiate last call (subject to the Chicago meeting not
> getting in the way).
>
> Thanks,
> Adrian
>
> ===
> "GMPLS" in title, abstract, and first use in main text.
> Unfortunately, "GMPLS" is still not a recognised term in the
> wider IETF.
> You must, therefore, expand the acronym where it first occurs.
> ===
> Abstract line 1
> s/shutdown/Shutdown/
> ===
> Abstract para 1
> s/towards/toward/
> ===
> Abstract para 1
> s/addressing the planned/addressing planned/
> ===
> Abstract
> "These operations are equally
> applicable for both MPLS and its GMPLS extensions."
> If so, why have you named the document as you have.
> Wouldn't a better name have been:
> Graceful Shutdown in MPLS and Generalized MPLS Traffic
> Engineering Networks
> ===
> Conventions used in this document
> Section contains a reference to "[i]" that is not resolved.
> ===
> Contents table
> Formatting is scrappy
> ===
> 1. Terminology
> s/LSR - Label Switching Device./LSR - Label Switching Router./
> ===
> 1. Terminology
> "LSP - An MPLS Label Switched Path"
> What happened to GMPLS?
> ===
> 1. Terminology
> The definition for "Head-end or Ingress node:" is very hard
> to read and, I
> suspect, non-intuitive. Redefining "head-end" to mean
> "sometimes also a
> transit node" will really fry people's minds! If you need a
> term for a node
> that performs a specific function, I suggest that you create
> a new term
> rather than overloading an existing one.
> ===
> 1. Terminology
> "GMPLS - The term GMPLS is used in this document to refer to both
> classic MPLS, as well as the GMPLS extensions to MPLS."
> You mean LDP?
> ===
> 1. Terminology
> TE Link
> a. You need to provide an expansion of FA-LSP, and probably a
> reference
> b. Your definition has not caught all of the possible uses of
> a TE link
> (such
> as link bundles). Perhaps you want to use a generic definition?
> ===
> 2. Introduction
> "disable Traffic Engineering on a TE Link"
> This begs the question: what is traffic engineering?
> Are you disabling TE on the link, or are you disabling data
> traffic on the
> link?
> I think some work throughout the document to clarify the
> difference between:
> - the impact of disabling a link (viz. traffic cannot flow)
> and
> - disabling TE advertisement (viz. the link's capacity is
> withdrawn from the
> TED).
> The latter being the way to gracefully advertise the former.
> ===
> 2. Introduction para 1
> s/graceful reroute/gracefully reroute/
> ===
> 2. Introduction
> "The node initiating the graceful shutdown condition
> SHOULD delay the removal of the resources for forwarding, for
> some period determined by local policy."
> The point is not the delay. The point is the delay between
> disabling the
> resource in the control plane and removing the resource for
> forwarding.
> Can you clarify, please.
> ===
> 2. Introduction para 2
> s/allow control/allow the control/
> ===
> 2. Introduction para 2
> "Similarly, trigger for the graceful
> shutdown event is a local matter at the node initiating the
> graceful shutdown."
> a. Similarly to what?
> b. s/trigger/the trigger/
> ===
> 2. Introduction
> "traditional shutdown operation of an interface"
> I like this phrase.
> My family have been shutting down interfaces for generations. We use
> traditional techniques involving spun grass and a hand axe.
> ===
> 2. Introduction
> Last line
> s/node/nodes/
> ===
> Section 3.
> Formatting is broken.
> Indentation and bullets.
> ===
> Section 3 2nd requirement
> This reads a bit odd. Would it be better as:
>
> - Once an operator has initiated graceful shutdown of a network
> resource, no new TE LSPs may be set up that use the resource.
> Any signaling message for a new LSP that explicitly specifies the
> resource, or that would require the use of the resource due to
> local constraints, must be rejected as if the resource were
> unavailable.
>
> - It is desirable for new LSP setup attempts that would be rejected
> because of graceful shutdown of a resource (as described in the
> previous requirement) to avoid any attempt to use the resource by
> selecting an alternate route or other resources.
> ===
> Section 3
> " - It is required to reduce/eliminate traffic disruption on the
> LSP(s) using the network resources which are about to be
> shutdown."
> Is this the requirement, or is the requirement to give the
> ingress the
> opportunity to perform this function if policy and
> configuration require it,
> and if network resources allow?
> ===
> Section 3
> " - In order to make rerouting effective, it is required to
> communicate information about the TE resource under graceful
> shutdown."
> I know what you mean, but you have been terribly
> non-specific. Communicate
> what information from whom to whom?
> It is probably:
> - the fact that the resource is being shut down
> - from the node where the resource is located
> - to all other network nodes
> ===
> Page 4 (and several other places)
> Excessive page throws
> ===
> Section 4.1
> "Setup request for new LSPs over the TE resource being gracefully
> shutdown SHOULD be rejected using the existing mechanisms that
> are applied when the TE resource is not available."
> Are you sure that you don't want to reject the setup using
> one of your new
> error codes?
> ===
> Section 4.1.1
> The "local
> TE link maintenance required" error code is defined in [PATH-
> REOPT].
> s/local TE link/local link/
> In the whole of this section, and the rest of the document, please be
> careful to distinguish Error Codes and Error Values. In this
> case you are
> talking about an Error Value that is associated with the
> "Notify" Error
> Code. It is necessary to describe both fields.
> ===
> Section 4.1.1
> Suddenly you are abbreviating to "GS". I think that is inadvisable.
> ===
> General question.
> Would it help the ingress or PLR if the PathErr reporting
> imminent graceful
> shutdown included additional information such as the likely
> time of shutdown
> in the data plane, and the likely time of restart?
> We do have mechanisms for this function in RFC 4783.
> ===
> Section 4.1.1
> When a head-end LSR receives a Path Error (or Notify) message
> with sub-code "Local Maintenance on TE Link required Flag", it
> SHOULD immediately trigger a make-before-break procedure. A head-
> end node SHOULD avoid the IP address contained in the PathErr (or
> Notify message) when performing path computation for the new LSP.
> a. The name of the subcode continues to mutate :-)
> b. The first SHOULD is *entirely* a matter of local policy.
> It is a MAY.
> c. The second SHOULD is ambiguous as you haven't told us which
> IP address is contained in the PathErr. Since the Error Value is
> related to a TE Link, presumably it is the TE link IP address. But
> what if it is a node being shut down? What if it is only a lambda
> being shut down?
> Can you not use some more informative fields and reason codes
> as provided in draft-ietf-ccamp-crankback-06.txt or RFC4872?
> d. Please be consistent and use "Path Error" or "PathErr". I
> prefer the
> second.
> ===
> Section 4.1.1
> If the resource being gracefully shutdown is on the Path of the
> protecting LSP/ local detour, the branch node/ PLR reroutes the
> protecting LSP/ local detour just a head-end LSR would reroute
> any other LSP.
> Need to tidy up the text.
> But what are you saying? One LSP is the same as another, and
> reroute takes
> place from the head end. That is all.
> ===
> Section 4.1.2
> RSVP error-code "Routing Problem" (24) [RSVP-TE] is
> needed:
> 9 (TBA) Local component link maintenance required
> Why is this a subcode of Routing Problem, when you have used
> a subcode of
> Notify for the case of the whole TE link?
> More importantly, the use of Routing Problem is likely to
> cause us to run
> into questions about whether the upstream transit nodes will
> panic and tear
> the LSP or not. Using the Notify Error Code is a much safer approach.
> ===
> Section 4.1.2
> The head-end LSR MAY still use the IP address
> contained in the Path Error or Notify message in performing path
> computation for rerouting the LSP. This is because, this address
> is an IP address of the component link and the flag is an
> implicit indication that the TE link may still have capacity to
> admit new LSPs.
> If the IP address is the address of the component link being
> shut down, then
> it cannot be used in the new path. If, however, the address
> is the address
> of the link bundle, then it can still be used.
> ===
> Important
> I think you are missing an element of procedure that applies
> at the node
> doing shut down.
> please state clearly which addresses are placed in which fields when
> reporting graceful shutdown for a:
> - node
> - te link
> - component link
> - label resource
> ===
> Section 4.1.2
> However, if the ERO is computed such that it also
> provides details of the component link selection(s) along the
> Path, the component link selection with IP address contained in
> the Path Error or Notify message SHOULD be avoided.
> The use of "SHOULD" implies that there may be a good reason
> to continue to
> use the address. Please supply the text
> "MAY continue to use it in order to ...."
> ===
> Section 4.1.3
> Doesn't give enough information to the head end to avoid the
> problem node in
> its reroute computations.
> Perhaps you need to reorder your document to say that the IGP
> pieces happen
> first, and the shutdown node should wait to allow the IGP to
> converge before
> sending out PathErr and or Notify?
> ===
> Section 4.2.1
> Why not include also specifying Minimum LSP Bandwidth as
> greater than the
> available bandwidth and greater than the maximum LSP bandwidth?
> This goes further than "discouraging" the use of the TE link,
> it makes it
> impossible to use even for zero-bandwidth LSPs.
> I'm pretty sure this was discussed several times in the WG.
> ===
> Section 4.2.1
> Neighbors of the node where graceful shutdown procedure is in
> progress SHOULD continue to advertise the actual unreserved
> bandwidth of the TE links from the neighbors to that node,
> without any routing adjacency change.
> Doesn't this mean that the TE link is only shut down in one
> direction? So
> unidirectional LSPs would still try to use the link.
> ===
> Section 5
> I don't think you will get this past the Security ADs.
> What happens if graceful shutdown is:
> - spoofed
> - hidden (i.e. the signaling or routing is blocked)
> You have not mentioned the IGP security.
> it might be a good idea to include a reference to Luyuan's draft.
> ===
> Section 6
> You need to give IANA far clearer instructions than this.
> Please look at a recent RFC for an example.
> I suggest RFC 4873 section 9.5
> ===
> References
> Personally, I like references to RFCs to use the RFC numbers
> as this is far
> quicker to look up. But you don't have to make this change.
> ===
>
>
> ----- Original Message -----
> From: <Internet-Drafts@ietf.org>
> To: <i-d-announce@ietf.org>
> Cc: <ccamp@ops.ietf.org>
> Sent: Friday, June 08, 2007 8:50 PM
> Subject: I-D ACTION:draft-ietf-ccamp-mpls-graceful-shutdown-03.txt
>
>
> >A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Common Control and
> Measurement Plane
> > Working Group of the IETF.
> >
> > Title : Graceful Shutdown in GMPLS Traffic Engineering Networks
> > Author(s) : Z. Ali, et al.
> > Filename : draft-ietf-ccamp-mpls-graceful-shutdown-03.txt
> > Pages : 9
> > Date : 2007-6-8
> >
> > GMPLS-TE Graceful shutdown is a method for explicitly notifying
> > the nodes in a Traffic Engineering (TE) enabled network that the
> > TE capability on a link or on an entire Label Switching Router
> > (LSR) is going to be disabled. GMPLS-TE graceful shutdown
> > mechanisms are tailored towards addressing the planned outage in
> > the network.
> >
> > This document provides requirements and protocol mechanisms so as
> > to reduce/eliminate traffic disruption in the event of a planned
> > shutdown of a network resource. These operations are equally
> > applicable for both MPLS and its GMPLS extensions.
> >
> > A URL for this Internet-Draft is:
> >
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-grac
> eful-shutdown-03.txt
>
>
>
>