Subject: RE: I-D ACTION:draft-ietf-ccamp-mpls-graceful-shutdown-03.txt

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Sat, 7 Jul 2007 15:44:25 +0200

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Monday, June 11, 2007 3:12 PM
> To: Zafar Ali; [email-masked]
> Cc: 'Jean Philippe Vasseur'; 'Anca Zamfir'; 
> [email-masked]; 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: <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> 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
> 
> 
> 
>