Subject: New revision of draft-ietf-ccamp-lsp-stitching

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 1 Mar 2007 13:58:27 -0000

Hi,

I appear to have taken over editing this I-D to prepare it for WG last call.

Here are my responses to my own review comments (yes, really!) that have 
been incorporated into the new revision just submitted.

Adrian

> ===
>
> idnits generates the following comments
>  * There are 96 instances of too long lines in the document, the longest
>    one being 1 character in excess of 72.

Indentation fixed.

>  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
>  - It seems as if not all pages are separated by form feeds - found 0 form
>    feeds but 22 pages

Form feeds inserted.

> ===
>
> The boilerplate will need to be updated for the new IETF Trust language.

Updated.

> ===
> Abstract.
>
> First paragraph is a good introduction.
> Second paragraph is fine and OK.
> But the Abstract also needs to say what the document is about!
> I suggest the addition of a new 2nd paragraph as follows...
>
>    This document describes extensions to the existing GMPLS signaling
>    protocol (RSVP-TE) to establish e2e LSPs from S-LSPs, and describes
>    how the LSPs can be managed using the GMPLS signaling and routing
>    protocols.

Test added.

> ===
>
> Acronyms
>
> Acronyms need to be expanded on their first use in the body of the 
> document regardless of whether they appear in the document title or in the 
> Abstract.
> I found...
> LSP
> GMPLS
> P2MP
> RRO

Changes made.

> ===
>
> Introduction
>
> The Introduction section is pretty lumpy. It seems to spend most of its 
> time talking about hierarchical LSPs, and only defines stitching in the 
> final paragraph.
>
> I suggest some re-ordering and a little editing as follows:
>
> New Section 1
>
>    A stitched Generalized Multiprotocol Label Switching (GMPLS) Traffic
>    Engineering (TE) Label Switched Path (LSP) is built from a set of
>    different LSP segments (S-LSPs) that are connected together in the
>    data plane in such a way that a single end-to-end LSP is realized in
>    the data plane.  In this document, we define the concept of LSP
>    stitching and detail the control plane mechanisms and procedures
>    (routing and signaling) to accomplish this.  Where applicable,
>    similarities and differences between LSP hierarchy [2] and LSP
>    stitching are highlighted.  Signaling extensions required for LSP
>    stitching are also described here.
>
>    It may be possible to configure a GMPLS node to switch the traffic
>    from an LSP for which it is the egress, to another LSP for which it
>    is the ingress, without requiring any signaling or routing extensions
>    whatsoever, and such that the operation is completely transparent to
>    other nodes.  This results in LSP stitching in the data plane, but
>    requires management intervention at the node where the stitching is
>    performed.  With the mechanism described in this document, the node
>    performing the stitching does not require configuration of the pair
>    of S-LSPs to be stitched together.  Also, LSP stitching as defined
>    here results in an end-to-end LSP both in the control and data
>    planes.

Done.

> Move the following paragraphs (unchanged) from Section 1 to the top of 
> Section 2.
>
>    LSP hierarchy ([2]) provides signaling and routing procedures so
>    that:
>
>    a.  A Hierarchical LSP (H-LSP) can be created.  Such an LSP created
>        in one layer can appear as a data link to LSPs in higher layers.
>        As such, one or more LSPs in a higher layer can traverse this
>        H-LSP as a single hop; we call this "nesting".
>
>    b.  An H-LSP may be managed and advertised (although this is not a
>        requirement) as a Traffic Engineering (TE) link.  Advertising an
>        H-LSP as a TE link allows other nodes in the TE domain in which
>        it is advertised to use this H-LSP in path computation.  If the
>        H-LSP TE link is advertised in the same instance of control plane
>        (TE domain) in which the H-LSP was provisioned, it is then
>        defined as a forwarding adjacency LSP (FA-LSP) and GMPLS nodes
>        can form a forwarding adjacency (FA) over this FA-LSP.  There is
>        usually no routing adjacency between end points of an FA.  An
>        H-LSP may also be advertised as a TE link in a different TE
>        domain.  In this case, the end points of the H-LSP are required
>        have a routing adjacency between them.
>
>    c.  RSVP signaling for LSP setup can occur between nodes that do not
>        have a routing adjacency.

Done, resulting in a shorter Section 1, and a longer Section 2.

> ===
>
> Section 3.2
>
> It might be useful to include a reference to RFC4726 to give some context 
> for inter-domain uses of stitching.

Added in 2nd paragraph.

> ===
>
> Security considerations
>
> I don't think we will get away with what is currently written :-(
> The killer is:
>    Mechanisms described in [6] should be
>    re-examined and may need to be altered to define new security
>    associations based on receiver's IP address instead of the sending
>    and receiving interfaces.
>
> I think that if you say that the re-examination is needed, you must do it. 
> You need to satisfy yourself as to whether any changes (beyond those 
> expressed in RFC4206) are needed.
>
> My view is that you should be able to echo the text of RFC4206 without 
> needing anything further. This is because the relationship between the 
> end-points of the S-LSP is the same as that between the end points of the 
> H-LSP in RFC4206. The precedent for remote signaling adjacencies has 
> already been established, and you are not defining anything new.

Security section re-written as follows:

   From a security point of view, the changes introduced in this
   document model the changes introduced by [2].  That is, the control
   interface over which RSVP messages are sent or received need not be
   the same as the data interface which the message identifies for
   switching traffic.  But the capability for this function was
   introduced in [4] to support the concept of out-of-fiber control
   channels, so there is nothing new in this concept for signaling or
   security.

   The application of this facility means that the "sending interface"
   or "receiving interface" may change as routing changes.  So, these
   interfaces cannot be used to establish security association between
   neighbors, and security associations MUST be bound to the
   communicating neighbors themselves.

   [6] provides a solution to this issue: in Section 2.1, under "Key
   Identifier", an IP address is a valid identifier for the sending (and
   by analogy, receiving) interface.  Since RSVP messages for a given
   LSP are sent to an IP address that identifies the next/previous hop
   for the LSP, one can replace all occurrences of 'sending [receiving]
   interface' with 'receiver's [sender's] IP address' (respectively).
   For example, in Section 4, third paragraph, instead of:

      "Each sender SHOULD have distinct security associations (and keys)
       per secured sending interface (or LIH).  ...  At the sender,
       security association selection is based on the interface through
       which the message is sent."

   it should read:

      "Each sender SHOULD have distinct security associations (and keys)
       per secured receiver's IP address. ...  At the sender, security
       association selection is based on the IP address to which the
       message is sent."

   Thus the mechanisms of [6] can be used unchanged to establish
   security associations between control plane neighbors.

   This document allows the IP destination address of Path and PathTear
   messages to be the IP address of a nexthop node (receiver's address)
   instead of the RSVP session destination address.  This means that the
   use of the IPsec Authentication Header (AH) (ruled out in [6] because
   RSVP messages were encapsulated in IP packets addressed to the
   ultimate destination of the Path or PathTear messages) is now
   perfectly applicable, and standard IPsec procedures can be used to
   secure the message exchanges.

   An analysis of GMPLS security issues can be found in [16].

> ===
>
> IANA considerations
>
> It would be helpful to name the sub-registries to help IANA get these 
> allocations right.
>
> In section 7.1 the registry is "RSVP TE Parameters" (not the registry 
> quoted in section 7) and the sub-registry is "Attributes Flags"
>
> In section 7.2 the registry is "Resource ReSerVation Protocol (RSVP) 
> Parameters" and the sub-registry is "Error Codes and Globally-Defined 
> Error Value Sub-Codes"

Done.

> It is also helpful to supply the precise text you would like added to the 
> registry.
>
> For section 7.1:
>
>                                       Path      Resv      RRO
> Bit   Name                             message   message   sub-object 
> Reference
> ----  -------------------------------  --------  --------  ----------  ---------
> 5     LSP stitching desired bit        Yes       No        Yes 
> [This doc]
>
>
> For section 7.2:
>
>  24  Routing Problem                             [RFC3209]
>
>        23 = Stitching unsupported  [This doc]

Done.

> ===