[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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".
===
----- Original Message ----- From: <Internet-Drafts@ietf.org> 
To: <i-d-announce@ietf.org>
Cc: <ccamp@ops.ietf.org>
Sent: Tuesday, November 21, 2006 3:50 PM
Subject: I-D ACTION:draft-ietf-ccamp-rsvp-te-exclude-route-06.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 : 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
i-d-announce-request@ietf.org 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:
mailserv@ietf.org.
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.