[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Chair review of draft-ietf-ccamp-lsp-stitching-04.txt
Hi,
As promised, I have done a review of this I-D to help the authors prepare it
for WG last call. In my opinion, the draft is in pretty good shape, but
there are a few minor issues.
If the authors can submit a new version to address these comments, we can
take the I-D forward.
Thanks,
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.
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
===
The boilerplate will need to be updated for the new IETF Trust language.
===
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.
===
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
===
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.
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.
===
Section 3.2
It might be useful to include a reference to RFC4726 to give some context
for inter-domain uses of stitching.
===
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.
===
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"
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]
===