[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
Hi Adrian / Lou,
With respect to the comments on the mechanism to trigger the ingress LSP
to perform a make-before-break, the draft already references 4736 for
definition of the required pathErr codes.
I have only had a quick look over 4920, but I would suggest that there
should not be overlap with crankback for a couple of reasons:
1/To me, crankback is targeted at LSP setup time rather than in-service
LSPs (stand to be corrected here!).
2/The ingress LSR seems to need to request the crankback information,
making this a much more involved implementation and requiring advanced
configuration at the ingress node.
With respect to Soft-preemption: Whilst I can clearly see the overlap,
to me there are some reasons why it may not be appropriate to combine
these in any way:
1/ We would want the ingress element to be aware of, in order to log,
the reason for the MBB request and soft-preemption only has a single
'soft preemption desired' flag.
2/ In the case of graceful shutdown, the actual removal of the resource
has not yet occurred and it may be up to operator discretion whether to
continue with the resource removal in the case that LSPs remain. In the
case of soft-preemption, the event has already occurred (the pre-empting
LSP is already admitted).
Cheers,
~Jon.
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel
> Sent: 27 February 2008 12:10
> To: Lou Berger
> Cc: ccamp@ops.ietf.org
> Subject: Re: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
>
> Lou,
>
> What you say about "triggered make-before-break" is interesting.
> We should also look at the overlap between this work and RFC
> 4736 and RFC 4920.
>
> Adrian
> ----- Original Message -----
> From: "Lou Berger" <lberger@labn.net>
> To: "Adrian Farrel" <adrian@olddog.co.uk>
> Cc: <ccamp@ops.ietf.org>
> Sent: Tuesday, February 26, 2008 9:13 PM
> Subject: Re: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
>
>
> > Here are some last call comments on this draft:
> >
> > - Opening/general comment:
> > "Category: Informational" and
> > "Conventions used in this document
> >
> > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
> > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
> > "OPTIONAL" in this document are to be interpreted as described in
> > RFC-2119 [RFC2119]"
> >
> > Given this is NOT a standards track document, the use of RFC2119
> > style directives is misleading and should not be used.
> >
> > - Section 2, a nit:
> > "temporarily or definitely".
> >
> > I think you mean indefinitely.
> >
> > - Section 3:
> > "- If the resource being shutdown is a last resort, it can be
> > used. Time or decision for removal of the resource being shutdown
> > is based on a local decision at the node initiating the graceful
> > shutdown procedure. "
> >
> > "Last resort" should be defined in technical terms. Also it's not
> > clear how this requirement is being met by the draft.
> >
> > - Section 4.2:
> > "The Graceful Shutdown
> > mechanism outlined in the following section, uses PathErr and
> > where available, Notify message, in order to achieve this
> > requirement. These mechanisms apply to both existing and new
> > LSPs."
> >
> > This comment really applies to the whole section. This section
> > seems to be quite a bit more than what you'd expect to find in
> > an informational document. I think this comment given the next
> > comment:
> >
> > From a high-level perspective, it seems to me what's trying to
> > accomplish in this section is to trigger MBB based on a
> > management plane directive to gracefully shutdown a
> > resource/link/node. Given this, it seems that this objective
> > is the same as that which soft-preemption provides, and that it
> > doesn't really make sense to have two documents (which just so
> > happen to be going through last call at the same time) that
> > provide the identical functionality. As this document is
> > targeted as an informational document, perhaps it would be best
> > to replace all of 4.2 with a recommendation to use soft
> > preemption signaling procedures to support graceful shutdown.
> >
> > Given this comment - I'll skip detailed comments on 4.2...
> >
> > Lou
> >
> > At 06:06 AM 2/13/2008, Adrian Farrel wrote:
> >>Hi,
> >>
> >>The authors of this draft have been indicating that they
> thought it was
> >>complete for some time. They have now updated the document
> to fix various
> >>formatting nits and minor issues raised in the working group.
> >>
> >>Therefore, this email marks the start of a working group
> last call on
> >>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gr
aceful-shutdown-05.txt
> >>This is positioned to be an Informational RFC.
> >>
> >>The last call will end on Wednesday 5th March at 12 noon
> GMT. Please send
> >>your comments to the list.
> >>
> >>Thanks,
> >>Adrian
> >>
> >>
> >>
> >
> >
> >
>
>
>
>
This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/
The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies.
Cable and Wireless plc
Registered in England and Wales.Company Number 238525
Registered office: 7th Floor, The Point, 37 North Wharf Road, London W2 1LA