Subject: Updated version of draft-ietf-ccamp-gmpls-rsvp-te-call

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 12 Aug 2006 15:37:39 +0100

Hi,

We have just submitted an updated version of 
draft-ietf-ccamp-gmpls-rsvp-te-call.

These changes result from:
- WG chair review by Deborah
- extensive post WG last call discussions on the CCAMP list.

Note that we polled the MPLS WG via the mailing list on the use of the 
previously reserved bits in the Session object and received no comments.

Changes are:

==
Throughout...
Minor punctuation changes
==
Throughout
s/LINK CAPABILITY/LINK_CAPABILITY/
==
Abstract
s/connection/Connection/ (twice)
==
Section 2
s/connection/Connection/ (four times)
==
Section 2
OLD
A Call may be associated with zero, one more Connections,
NEW
A Call may be associated with zero, one, or more than one Connection,
==
Section 4.2
Use period not colon before list.
==
Section 3.3
s/Call Segments capabilities/Call Segment capabilities/
==
Section 4.3
OLD
   It is useful for the ingress node of an LSP to know the link
   capabilities of the link between the network and the egress node.
   This information may allow the ingress node to tailor its LSP request
   to fit those capabilities and to better utilize network resources
   with regard to those capabilities.

   In particular, this may be used to achieve end-to-end spectral
   routing attribute negotiation for signal quality negotiation (such as
   BER) in photonic environments where network edges are signal
   regeneration capable. Similarly, it may be used to provide end-to-end
   spatial routing attribute negotiation in multi-area routing
   environments, in particular, when TE links have been bundled based on
   technology specific attributes.

  Call setup may provide a suitable mechanism to exchange information
  for this purpose, although several other possibilities exist.
NEW
   In an overlay model, it is useful for the ingress node of an LSP to
   know the link capabilities of the link between the network and the
   remote overlay network. In the language of [RFC4208], the ingress
   node can make use of information about the link between the egress
   network node (NN) and the remote edge node (EN). We call this link
   the egress network link. This information may allow the ingress node
   to tailor its LSP request to fit those capabilities and to better
   utilize network resources with regard to those capabilities.

   For example, this might be used in transparent optical networks to
   supply information on lambda availability on egress network links,
   or, where the egress NN is capable of signal regeneration, it might
   provide a mechanism for negotiating signal quality attributes (such
   as bit error rate). Similarly, in multi-domain routing environments
   it could be used to provide end-to-end selection of component links
   (i.e., spatial attribute negotiation) where TE links have been
   bundled based on technology specific attributes.

   In some circumstances, the Traffic Engineering Database (TED) may
   contain sufficient information for decisions to be made about which
   egress network link to use. In other circumstances, the TED might not
   contain this information and Call setup may provide a suitable
   mechanism to exchange information for this purpose. The
   Call-responder may use the Call parameters to select a subset of the
   available egress network links between the egress NN and the remote
   EN, and may report these links and their capabilities on the Call
   response so that the Call-initiator may select a suitable link.

   The sections that follow indicate the cases where the TED may be
   used, and those where Call parameter exchange may be appropriate.
==
Section 4.3.1
OLD
   In this case, there may be no need to distribute additional link
   capability information over and above the information distributed by
   the TE and GMPLS extensions to the IGP. Further, it is possible that
   future extensions to these IGPs will allow the distribution of more
   detailed information including optical impairments.
NEW
   In this case the ingress (and correspondingly the egress) lie within
   the network and there may be no need to distribute additional link
   capability information over and above the information distributed by
   the TE and GMPLS extensions to the IGP. Further, it is possible that
   future extensions to these IGPs will allow the distribution of more
   detailed information including optical impairments.
==
Section 4.3.2
OLD
   In this case, edge link information may not be visible within the
   core network, nor (and specifically) at other edge nodes. This may
   prevent an ingress from requesting suitable LSP characteristics to
   ensure successful LSP setup.

   Various solutions to this problem exist including the definition of
   static TE links (that is, not advertised by a routing protocol)
   between the core network and the edge nodes. Nevertheless, special
   procedures may be necessary to advertise edge TE link information to
   the edge nodes outside of the network without advertising the
   information specific to the contents of the network.

   In the future, when the requirements are understood on the
   information that needs to be supported, TE extensions to EGPs may be
   defined that provide this function.
NEW
   In this case the ingress (and correspondingly the egress) lie outside
   the network. Edge link information may not be visible within the
   core network, nor (and specifically) at other edge nodes. This may
   prevent an ingress from requesting suitable LSP characteristics to
   ensure successful LSP setup.

   Various solutions to this problem exist, including the definition of
   static TE links (that is, not advertised by a routing protocol)
   between the NNs and ENs. Nevertheless, special procedures may be
   necessary to advertise to the edge nodes outside of the network
   information about egress network links without also advertising the
   information specific to the contents of the network.

   In the future, when the requirements on the information that needs to
   be supported are better understood, TE extensions to EGPs may be
   defined that provide this function, and new rules for leaking TE
   information between routing instances may be used.
==
Section 4.3.3
OLD
   When IGP and EGP solutions are not available at the UNI, there is
   still a requirement to have, at the local edge nodes, the knowledge
   of the remote edge link capabilities.

   The Call setup procedure provides an opportunity to discover edge
   link capabilities of remote edge nodes before LSP setup is attempted.
   The LINK CAPABILITY object is defined to allow this information to be
   exchanged. The information that is included in this object is similar
   to that distributed by GMPLS-capable IGPs (see [RFC4202]).
NEW
   When IGP and EGP solutions are not available at the User-to-Network
   Interface (UNI), there is still a requirement to have, at the local
   edge nodes, the knowledge of the remote edge link capabilities.

   The Call setup procedure provides an opportunity to discover edge
   link capabilities of remote edge nodes before LSP setup is attempted.

   - The Call-responder can return information on one or more egress
     network links. The Call-reponder could return a full list of the
     available links with information about the link capabilities, or it
     could filter the list to return information about only those links
     which might be appropriate to support the Connections needed by the
     Call. To do this second option, the Call-responder must determine
     such appropriate links from information carried in the Call request
     including destination of the Call, and the level of service
     (bandwidth, protection, etc.) required.

   - On receiving a Call response, the Call-initiator must determine
     paths for the Connections (LSPs) that it will set up. The way that
     it does this is out of scope for this document since it is an
     implementation-specific, algorithmic process. However, it can take
     as input the information about the available egress network links
     as supplied in the Call response.

   The LINK_CAPABILITY object is defined to allow this information to be
   exchanged. The information that is included in this object is similar
   to that distributed by GMPLS-capable IGPs (see [RFC4202]).
==
Section 5.1
s/connection/Connection/ (twice)
==
Section 5.2
s/connection/Connection/ (three times)
==
Section 5.2.2
s/connection/Connection/
==
Section 5.3
Use period not colon before list.
==
Section 5.3
OLD
   The LINK CAPABILITY object is introduced to support link capability
   exchange during Call setup and MAY be included in a Notify message
   used for Call setup. This optional object includes the bundled link
   local capabilities of the Call initiating node (or terminating node)
   indicated by the source address of the Notify message.
NEW
   The LINK_CAPABILITY object is introduced to support link capability
   exchange during Call setup and MAY be included in a Notify message
   used for Call setup. This optional object includes the link local
   capabilities of a link joining the Call-initiating node (or
   Call-terminating node) to the network. The specific node is indicated
   by the source address of the Notify message.

   The link reported can be a single link or can be a bundled link
   [RFC4201].
==
Section 5.3
OLD
   - Type 1: the link local IPv4 address (numbered bundle) using the
     format defined in [RFC3209]
   - Type 2: the link local IPv6 address (numbered bundle) using the
     format defined in [RFC3209]
   - Type 4: the link local identifier (unnumbered links and bundles)
     using the format defined in [RFC3477]
   - Type 64: the Maximum Reservable Bandwidth corresponding to this
     bundle (see [RFC4201])
   - Type 65: the interface switching capability descriptor (see
     [RFC4202]) corresponding to this bundle (see also [RFC4201]).
NEW
   - Type 1: the link local IPv4 address of a link or a numbered bundle
     using the format defined in [RFC3209]
   - Type 2: the link local IPv6 address of a link or a numbered bundle
     using the format defined in [RFC3209]
   - Type 4: the link local identifier of an unnumbered link or bundle
     using the format defined in [RFC3477]
   - Type 64: the Maximum Reservable Bandwidth corresponding to this
     link or bundle (see [RFC4201])
   - Type 65: the interface switching capability descriptor (see
     [RFC4202]) corresponding to this link or bundle (see also
     [RFC4201]).
==
Section 5.3
OLD
   This object MAY also be used to exchange more than one bundled link
   capability. In this case, the following ordering MUST be followed:
   one identifier subobject (Type 1, 2 or 4) MUST be inserted before any
   capability subobject (Type 64 or 65) to which it refers.
NEW
   A single instance of this object MAY be used to exchange capability
   information relating to more than one link or bundled link. In this
   case, the following ordering MUST be used:
   - each link MUST be identified by an identifier subobject (Type 1, 2
     or 4)
   - capability subobjects (Type 64 or 65, and future subobjects) MUST
     be placed after the identifier subobject for the link or bundle to
     which they refer.

   Multiple instances of the LINK_CAPABILITY object within the same
   Notify message are not supported by this specification. In the event
   that a Notify message contains multiple LINK_CAPABILITY objects, the
   receiver SHOULD process the first one as normal and SHOULD ignore
   subsequent instances of the object.
==
Section 5.4.1
s/ATTIBUTE/ATTRIBUTE/
==
Section 5.5
OLD
   The format and the contents of the ADMIN_STATUS object are both
   dictated by [RFC3473] in favor of [RFC3471]. The new "C" bit is added
   as shown below.
NEW
   [RFC3473] indicates that the format and contents of the ADMIN_STATUS
   object are as defined in [RFC3471]. The new "C" bit is added for Call
   control as shown below.
==
Section 6.1
s/connection/Connection/
==
Section 6.1 bullet two
s/a further Connection/another Connection/
==
Section 6.2
Use period not colon before list.
==
Section 6.2 bullet one
s/call terminating/Call-terminating/
==
Section 6.2 bullet two
s/value is assigning/value in assigning/
==
Section 6.2 bullet three
s/call initiating/Call-initiating/
==
Section 6.6.1
s/RFC3743/RFC3473/
==
Section 6.6.3 3rd para
Alignment fixed
s/at least the five/at least five/
==
Section 6.7
s/call/Call/
s/connection/Connection/  (twice)
s/link failures, and the addition/link failures, or the addition/
==
Section 7.3.1
s/call/Call/
==
Section 9.1
OLD
   Note, additionally, that the process of Call establishment
   independent of LSP setup may be used to apply an extra level of
   authentication and policy to hop-by-hop LSP setup.
NEW
   Note, additionally, that the process of independent Call
   establishment, where the Call is set up separately from the LSPs, may
   be used to apply an extra level of authentication and policy for the
   end-to-end LSPs above that which is available with Call-less,
   hop-by-hop LSP setup.
==
Section 9.1
s/Insect/IPsec/
==
Section 9.1
ADD
   The frequency of Call establishment is application dependent and hard
   to generalize. Key exchange for Call-related message exchanges is
   therefore something that should be configured or arranged dynamically
   in different deployments according to the advice in [RFC4107]. Note
   that the remote RSVP-TE signaling relationship between Call endpoints
   is no different from the signaling relationship between LSRs that
   establish an LSP. That is, the LSRs are not necessarily IP-adjacent
   in the control plane in either case. Thus key exchange should be
   regarded as a remote procedure, not a single hop procedure. There are
   several procedures for automatic remote exchange of keys, and IKE
   [RFC2409] is particularly suggested in [RFC3473].
==
Section 11.
Updated acknowledgements
==
Section 12.1
Added RFC 2709
==
Section 12.2
Added RFC 4107
==
Section 13
Updated Arthi's coordinates
==

Regards,
Adrian and Dimitri

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Thu, 17 Aug 2006 13:32:34 -0500

Bill and Ross,

This draft has been through CCAMP WG last call and has been updated to
my satisfaction. All changes were in response to LC comments and my
nits.

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-
01.txt

Please take it on its next step to being an RFC.

Thanks everyone,
Deborah