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

["Adrian Farrel" <adrian@olddog.co.uk>]

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