Subject: [mpls] draft-newton-mpls-te-dynamic-overbooking-00.txt

From: "Newton, Jonathan" <[email-masked]>
Date: Tue, 29 Jul 2008 11:41:02 +0100

Hi all,

We have a draft that defines an implementation model that allows a
Traffic Engineered network to dynamically alter link booking factors
during failure events.  The rationale is to allow an operator to adopt
different optimisation schemes depending upon the current failure state
of the network.

http://www.ietf.org/internet-drafts/draft-newton-mpls-te-dynamic-overboo
king-00.txt

This was presented on Monday and we received some good feedback during
the session, but would appreciate further comment from the list.

The intention is to ask for adoption as a WG document. The status was
going to be BCP, but the chairs have recommended that it is more
appropriate to Informational status. 

Cheers,
~Jon.

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: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 29 Jul 2008 13:45:06 +0100

Hi Jon,

Comments from a quick skim of the draft.

I think it would be helpful to synchronize section 3.1 with RFC3209 and the 
recent work in the MPLS and CCAMP WGs on:
- draft-ietf-mpls-soft-preemption
- draft-berger-mpls-gmpls-lsp-reroute
- draft-ietf-mpls-3209-patherr
- draft-ietf-ccamp-mpls-graceful-shutdown
At the moment the section is hard to parse because of inconsistencies (for 
example, how does a head end receive a PathTear?).

Although your immediate requirement is for MPLS-TE, I would prefer that your 
solution was applicable also to GMPLS. In this context, when you say that an 
LSP fault can be detected through control plane failure, I am quite worried 
that you are limiting your applicability to a specific subset of MPLS-TE and 
entirely ruling out GMPLS.

In section 3.3 you need to clarify setup and holding priorities.

Section 4.2.1 says that "all LSPs will be torn down." This seems to be in 
conflict with the subsequent discussion of FRR. The section also says that a 
PathErr will be used to report the use of FRR to the head end - please note 
that this behavior is a SHOULD in RFC4090 and that delivery of PathErr is 
not guaranteed.

Your procedure needs to consider the time for IGP convergence. At the 
moment, you say that the error may be notified by the IGP, in which case the 
new path computation (please don't call it CSPF :-) will know about the 
failed link. But in the case of fault propagation through RSVP-TE simply 
invoking path computation will not be enough unless the IGP has already 
converged (unlikely). So you need to be able to invoke path computation 
either later or with an explicit exclusion. Now, from where do you get the 
information about which link failed? RFC2205 defines the Error-Spec as 
containing "The IP address of the node in which the error was detected." 
which does not necessarily tell you the interface that has failed (although 
implementations *could* use the interface address of the failed interface at 
the reporting node). I suspect that to properly perform exclusions (there 
may be node failures or link failures) you should look at the IF_ID 
Error-Spec object defined in RFC3473. You might also look at the work for 
error reporting in RFC4920.

Some work needed, I think, before it is appropriate to bring this to WG 
status.

Cheers,
Adrian
----- Original Message ----- 
From: "Newton, Jonathan" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, July 29, 2008 11:41 AM
Subject: [mpls] draft-newton-mpls-te-dynamic-overbooking-00.txt

Hi all,

Cheers,
~Jon.

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

--------------------------------------------------------------------------------