[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
New revision of draft-ietf-ccamp-lsp-stitching
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.
===