Subject: I-D ACTION:draft-ietf-ccamp-rsvp-te-exclude-route-06.txt

From: [email-masked]
Date: Tue, 21 Nov 2006 10:50:01 -0500

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		: Exclude Routes - Extension to RSVP-TE
	Author(s)	: A. Farrel, et al.
	Filename	: draft-ietf-ccamp-rsvp-te-exclude-route-06.txt
	Pages		: 26
	Date		: 2006-11-21
	
The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP
   Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized
   Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation
   Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow
   abstract nodes and resources to be explicitly included in a path
   setup, but not to be explicitly excluded.

   In some networks where precise explicit paths are not computed at the
   head end it may be useful to specify and signal abstract nodes and
   resources that are to be explicitly excluded from routes. These
   exclusions may apply to the whole path, or to parts of a path between
   two abstract nodes specified in an explicit path. How Shared Risk
   Link Groups (SLRGs) can be excluded is also specified in this
   document.

   This document specifies ways to communicate route exclusions during
   path setup using RSVP-TE.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ccamp-rsvp-te-exclude-route-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 21 Nov 2006 16:59:11 -0000

Hi,

FYI this revision is an update after GenArt review and some comments from 
the AD.

The changes are as follows:

Adrian
===
Section 1.
ADD
   For example, route exclusion could be used in the case where two
   non-overlapping Label Switched Paths (LSPs) are required. In this
   case, one option might be to set up one path and collect its route
   using route recording, and then to exclude the routers on that first
   path from the setup for the second path. Another option might be to
   set up two parallel backbones, dual home the provider edge (PE)
   routers to both backbones, and then exclude the local router on
   backbone A the first time that you set up an LSP (to a particular
   distant PE), and exclude the local router on backbone B the second
   time that you set up an LSP.
NOTE
   Idea for text from Ross answering Eric's questions about usage.
===
Section 1.1
OLD
   This document does not preclude a route exclusion from listing
   arbitrary nodes or network elements to avoid. The intent is,
   however, to indicate only the minimal number of subobjects to be
   avoided. For instance it may be necessary to signal only the  SRLGs
   (or Shared Risk Groups) to avoid.
NEW
   This document does not preclude a route exclusion from listing
   arbitrary nodes or network elements to avoid. The intent is,
   however, to indicate only the minimal number of subobjects to be
   explicitly avoided. For instance it may be necessary to signal only
   the  SRLGs (or Shared Risk Groups) to avoid. That is, the route
   exclusion is not intended to define the actual route by listing all
   of the choices to exclude at each hop, but rather to constrain the
   normal route selection process where loose hops or abstract nodes
   are to be expanded by listing certain elements to be avoided.
NOTE
   This additional text to answer Eric's questions about usage.
===
Section 1
OLD
   This document introduces an ERO subobject to indicate an SRLG to be
   signaled in either of the two exclusion methods described above and
   this document does not assume or preclude any other usage for this
   subobject. This subobject might also be appropriate for use within
   Explicit Routes or Record Routes, but this is outside the scope of
   this document.
NEW
   This document introduces a subobject to indicate an SRLG to be
   signaled in either of the two exclusion methods described above. This
   document does not assume or preclude any other usage for this
   subobject. This subobject might also be appropriate for use within an
   Explicit Route object (ERO) or Record Route object (RRO), but this is
   outside the scope of this document.
NOTE
   The issue raised was that the subobject could not both be an ERO
   subobject and not be defined for use in an ERO.
===
Section 2
OLD
   The identifier of a SRLG is defined as a 32 bit quantity in
   [RFC4202]. An SRLG ERO subobject is introduced such that it can be
   used in the exclusion methods as described in the following sections.
   This document does not assume or preclude any other usage for this
   subobject. This subobject might also be appropriate for use within
   Explicit Routes or Record Routes, but this is outside the scope of
   this document.
NEW
   The identifier of a SRLG is defined as a 32 bit quantity in
   [RFC4202]. An SRLG subobject is introduced such that it can be used
   in the exclusion methods as described in the following sections.
   This document does not assume or preclude any other usage for this
   subobject. This subobject might also be appropriate for use within
   Explicit Route object (ERO) or Record Route object (RRO), but this is
   outside the scope of this document.
NOTE
   As before.
===
Section 2.1
OLD
2.1  SRLG ERO Subobject

   The format of the ERO and its subobjects are defined in [RFC3209].
   The new SRLG ERO subobject is defined by this document as follows.
NEW
2.1  SRLG Subobject

   The new SRLG subobject is defined by this document as follows. Its
   format is modeled on the ERO subobjects defined in [RFC3209].
NOTE
   As before.
===
Section 3.1
OLD
     The contents of an EXCLUDE_ROUTE object are a series of variable-
     length data items called subobjects. This specification adapts ERO
     subojbects as defined in [RFC3209], [RFC3473], and [RFC3477] for
     use in route exclusions. The SRLG ERO subobject as defined in
     Section 2 of this document and its processing within ERO have not
     been defined before. The SRLG ERO subobject is defined here for use
     with route exclusions.
NEW
     The contents of an EXCLUDE_ROUTE object are a series of variable-
     length data items called subobjects. This specification adapts ERO
     subojbects as defined in [RFC3209], [RFC3473], and [RFC3477] for
     use in route exclusions. The SRLG subobject as defined in Section 2
     of this document has not been defined before. The SRLG subobject is
     defined here for use with route exclusions.
NOTE
   As before.
===
Section 3.1.5
OLD
   The Attribute octet is not present. The rest of the fields are as
   defined in the "SRLG ERO Subobject" section of this document.
NEW
   The Attribute octet is not present. The rest of the fields are as
   defined in the "SRLG Subobject" section of this document.
NOTE
   As before.
===
Section 8
Major rewrite of the IANA section since it had been misunderstood
===
Section 3.2
ADD
   A node receiving a Path message carrying an XRO MAY reject the
   message if the XRO is too large or complicated for the local
   implementation or as governed by local policy. In this case, the
   node MUST send a PathErr message with the error code "Routing Error"
   and error value "XRO Too Complex". An ingress LSR receiving this
   error code/value combination MAY reduce the complexity of the XRO or
   route around the node that rejected the XRO.
NOTE
   This addresses Eric's request to be able to "opt out".
===
Section 4.2
ADD
   A node MAY reject a Path message if the EXRS is too large or
   complicated for the local implementation or as governed by local
   policy. In this case, the node MUST send a PathErr message with the
   error code "Routing Error" and error value "EXRS Too Complex". An
   ingress LSR receiving this error code/value combination MAY reduce
   the complexity of the EXRS or route around the node that rejected
   the EXRS.
NOTE
   This addresses Eric's request to be able to "opt out".
===
Section 3.2
OLD
   3. The subobjects in the ERO and XRO MUST NOT contradict each other.
      If a Path message is received that contains contradicting ERO and
      XRO subobjects, then:
NEW
   3. The subobjects in the ERO and XRO SHOULD NOT contradict each
      other. If a Path message is received that contains contradicting
      ERO and XRO subobjects, then:
===
Section 3.1
OLD
   The concept of loose or strict hops has no meaning in route
   exclusion. The L bit, defined for ERO subobjects in [RFC3209], is
   reused here to indicate that an abstract node MUST be avoided (value
   0) or SHOULD be avoided (value 1).
NEW
   The concept of loose or strict hops has no meaning in route
   exclusion. The L bit, defined for ERO subobjects in [RFC3209], is
   reused here to indicate that an abstract node MUST be excluded (value
   0) or SHOULD be avoided (value 1). The distinction is that the path
   of an LSP must not traverse an abstract node listed in the XRO with
   the L bit clear, but may traverse one with the L bit set. A node
   responsible for routing an LSP (for example, for expanding a loose
   hop) should attempt to minimize the number of abstract nodes listed
   in the XRO with the L bit set that are traversed by the LSP according
   to local policy. A node generating XRO subobjects with the L bit set
   must be prepared to accept an LSP that traverses one, some, or all of
   the corresponding abstract nodes.
NOTE
   Address Eric's request for more detail on MUST/SHOULD avoid.
===
Section 6
OLD
   2. The EXRS MAY be supported. If supported, the same restrictions
      as for the XRO apply.
NEW
   2. The EXRS MAY be supported. If supported, the same restrictions
      as for the XRO apply. If not supported, an EXRS encountered
      during normal ERO processing MUST be rejected as an unknown
      ERO subobject as described in Section 4.2. Note that a node
      SHOULD NOT parse ahead into an ERO, and if it does, MUST NOT
      reject the ERO if it discovers an EXRS that applies to another
      node.
NOTE
   Eric requested clarification on how a non-supporting node behaves.
===
Section 7
OLD
   The new exclude route object poses no security exposures over and
   above [RFC3209] and [RFC3473]. Note that any security concerns that
   exist with Explicit Routes should be considered with regard to route
   exclusions.
NEW
   Security considerations for MPLS-TE and GMPLS signaling are covered
   in [RFC3209] and [RFC3473]. This document does not introduce any new
   messages or any substantive new processing, and so those security
   considerations continue to apply.

   Note that any security concerns that exist with explicit routes
   should be considered with regard to route exclusions. For example,
   some administrative boundaries may consider explicit routes to be
   security violations and may strip EROs from the Path messages that
   they process. In this case, the XRO should also be considered for
   removal from the Path message.

   It is possible that an arbitrarily complex XRO or EXRS sequence could
   be introduced as a form of denial of service attack since its
   presence will  potentially cause additional processing at each node
   on the path of the LSP. It should be noted that such an attack
   assumes that an otherwise trusted LSR (i.e., one that has been
   authenticated by its neighbors) is misbehaving. A node that receives
   an XRO or EXRS sequence that it considers too complex according to
   its local policy may respond with a PathErr message carrying the
   error code "Routing Error" and error value "XRO Too Complex" or "EXRS
   Too Complex".
===