[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Working Group Last Call Comments on draft-ietf-ccamp-gmpls-mln-extensions-03.txt
Hi,
I have mainly editorial issues, but a few deeper quesitons mixed in...
Adrian
===
Please update to use the new IPR boilerplate. You should get agreement
from all Authors before doing this. It would also be worth consulting
the Contributors (although I don't know whether the boilerplate applies
to them or not).
===
idnits
Please run idnits.
Currently this shows one page too long, and loads of lines too long.
This latter problem is caused by incorrect indentation.
There are also numerous issues with references.
===
Document heading
I think this needs...
Updates RFC 3473, RFC 4201, RFC 4203, RFC 4874, RFC 4974
===
Abstract
There are requirements for the support of networks comprising LSRs
with different data plane switching layers controlled by a single
s/with/participating in/
===
Introduction
A GMPLS
switching type (PSC, TDM, etc.) describes the ability of a node to
forward data of a particular data plane technology, and uniquely
identifies a control plane region. LSP Regions are defined in
[RFC4206].
Are these deliberately different terms?
- control plane region
- LSP region
If possible (and if they mean the same thing) can you clarify that they
are the same, and then use only one term through out the I-D.
If you retain "LSP Region" please expand the acronym here as it is the
first use.
===
Introduction
A network comprising transport nodes with
s/with/participating in/
different data plane switching layers controlled by a single GMPLS
===
Introduction
The applicability of GMPLS to multiple switching technologies
provides the unified control and operations for both LSP provisioning
d/the/
s/LSP/Label Switched Path (LSP)/ (unless expanded as above)
===
Introduction
and recovery. This document covers the elements of a single GMPLS
control plane instance controlling multiple layers within a given TE
domain. A TE domain is defined as group of LSRs that enforces a
s/enforces/enforce/
===
common TE policy. A CP instance can serve one, two or more layers.
I don't think you have defined "CP"
===
2. Summary of the Requirements and Evaluation
As identified in [MLN-EVAL] most of MLN/MRN requirements rely on
d/of/
mechanisms and procedures that are outside the scope of the GMPLS
protocols, and thus do not require any GMPLS protocol extensions.
They rely on local procedures and policies, and on specific TE
mechanisms and algorithms, which are outside the scope of GMPLS
protocols.
There is a lot of duplication in this paragraph. Can we have...
As identified in [MLN-EVAL], most MLN/MRN requirements rely on
mechanisms and procedures (such as local procedures and policies, or
specific TE mechanisms and algorithms) that are outside the scope of
the GMPLS protocols, and thus do not require any GMPLS protocol
extensions.
===
2. Summary of the Requirements and Evaluation
Bullet list
s/extension/extensions/ (x4)
===
2. Summary of the Requirements and Evaluation
o GMPLS signaling extension for constrained multi-region signaling
(SC inclusion/exclusion). See Section 3.2.1 of [MLN-EVAL].
This is the first use of "SC".
===
2. Summary of the Requirements and Evaluation
OLD
The first three requirements are addressed in Sections 3, 4 and 5,
respectively, of this document.
NEW
The first three requirements are addressed in Sections 3, 4, and 5 of
this document, respectively.
===
2. Summary of the Requirements and Evaluation
Companion documents address GMPLS OAM aspects that have been
identified in [MLN-EVAL].
Hmmm. I smell a wriggle!
Can you cite those companion documents and list those aspects?
===
3. Interface adaptation capability descriptor (IACD)
Capitalise heading, please.
===
3. Interface adaptation capability descriptor (IACD)
In the MRN context, nodes supporting more than one switching
capability on at least one interface are called Hybrid nodes.
-- You can give a citation for the definition of this term
-- This sentence is unclear...
Does it say that there is at least one interface on the node
that supports more than one SwCap? Or does it say that the node
supports more than one SwCap, and that the node has at least one
interface?
===
3. Interface adaptation capability descriptor (IACD)
Hybrid
nodes contain at least two distinct switching elements that are
interconnected by "internal links" to provide adaptation between the
supported switching capabilities. These "internal links" have finite
capacities and must be taken into account when computing the path of
a multi-region TE-LSP.
As worded, this paragrpah seems to make some strong statements about
implementation that not all implementers might want to be bound by.
However, if you reworded slightly you can shoft this to the "logical"
construction of a node, which would be fine. For example...
The logical composition of a hybrid node contains at least two
distinct switching elements that are interconnected by "internal
links" to provide adaptation between the supported switching
capabilities. These internal links have finite capacities that must
be taken into account when computing the path of a multi-region
TE-LSP.
===
3.1 Overview
OLD
In an MRN environment, some LSRs could contain, under the control of
a single GMPLS instance, multiple switching capabilities such as PSC
and TDM or PSC and Lambda Switching Capability (LSC).
NEW
In an MRN environment, some LSRs could contain multiple switching
capabilities such as PSC and TDM, or PSC and LSC, all under the
control of a single GMPLS instance,
===
3.1 Overview
OLD
These nodes, hosting multiple Interface Switching Capabilities (ISC),
just like other nodes (hosting a single Interface Switching
Capability) are required to hold and advertise resource information
on link states and topology.
NEW
These nodes, hosting multiple Interface Switching Capabilities (ISC)
[RFC4202], are required to hold and advertise resource information
on link states and topology, just like other nodes (hosting a single
ISC).
===
3.1 Overview
OLD
They also may have to consider certain
portions of internal node resources to terminate hierarchical label
switched paths (LSPs), since circuit switch capable units such as
TDMs, LSCs, and FSCs require rigid resources.
NEW
They may also have to consider some portions of internal node
resources use to terminate hierarchical LSPs, since in circuit-
switching technologies (such as TDM, LSC, and FSC) LSPs require the
use of specific and unsharable resources.
===
3.1 Overview
OLD
For example, a node
with PSC+LSC hierarchical switching capability can switch a Lambda
LSP but may not be able to can never terminate the Lambda LSP if
there is no unused adaptation capability between the LSC and the PSC
switching capabilities.
NEW
For example, a node with PSC+LSC hierarchical switching capability
can switch a lambda LSP, but cannot terminate the Lambda LSP if there
is no available (i.e., not already in use) adaptation capability
between the LSC and the PSC switching components.
===
3.1 Overview
Another example occurs when L2SC (Ethernet) switching can be adapted
in LAPS X.86 and GFP for instance before reaching the TDM switching
matrix.
Insert paragraph break.
Similar circumstances can occur, if a switching fabric that
supports both PSC and L2SC functionalities is assembled with LSC
interfaces enabling "lambda" encoding. In the switching fabric, some
interfaces can terminate Lambda LSPs and perform frame (or cell)
switching whilst other interfaces can terminate Lambda LSPs and
s/whilst/while/
perform packet switching.
===
3.2 Interface Adjustment Capability Descriptor (IACD)
The interface adjustment capability descriptor (IACD) provides the
information for the forwarding/switching) capability only.
d/)/
d/only/
OLD
Note that the addition of the IACD as TE link attributes does not
modify format/messaging and processing associated to the Interface
Switching Capability Descriptor (ISCD) defined in [RFC4202].
NEW
Note that the addition of the IACD as a TE link attribute does not
modify the format of the Interface Switching Capability Descriptor
(ISCD) defined in [RFC4202], and does not change how the ISCD is
carried in the routing protocols or how it is processed when it is
received [RFC4201], [RFC4203],
===
3.2.1 OSPF
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | Switching Cap | Encoding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I really think it would be helpful to have different names for the
fields. For example...
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sw Cap Low | Encoding Low | Sw Cap High | Encoding High |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
===
3.2.1 OSPF
Encoding (byte 4) - 8 bits
Set to the encoding of the available adaptation pool and to
0xFF when the corresponding SC value has no access to the wire,
i.e., there is no ISC sub-TLV for this upper switching
capability.
This is the first (and only!) mention of the adaptation pool. I think
some explanation is needed in the document, and a reference from here.
===
3.2.1 OSPF
Other fields MUST be processed as specified in [RFC4202] and
[RFC4203].
But one of the "other fields" is "Adjustment Capability-specific
information". Not only is this not present in RFCs 4202 and 4203, but
it is also not described in this I-D.
===
3.2.1 OSPF
The presence of the IACD sub-TLV as part of the TE Link TLV does not
modify format/messaging and processing associated to the ISCD defined
in [RFC4203].
Delete this? You already said it in Section 3.2.
===
3.2.2 IS-IS
Identical comments to those for Seciton 3.2.1.
===
4. Multi-Region Signaling
The node then extracts from the ERO the
subsequence of hops from itself to the other end of the region.
s/subsequence/sub-sequence/
The node then compares the subsequence of hops with all existing FA-
s/subsequence/sub-sequence/
===
4. Multi-Region Signaling
o If a match is found, that FA-LSP has enough unreserved bandwidth
for the LSP being signaled, and the PID of the FA-LSP is
This is the first use of "PID" in this I-D. But anyway, isn't it
"G-PID"?
the ERO in that message is adjusted by removing
the subsequence of the ERO that lies in the FA-LSP, and replacing
s/subsequence/sub-sequence/
===
4. Multi-Region Signaling
Note: compatible PID implies that traffic can be processed by both
ends of the FA-LSP without drop.
This could be clearer.
===
4. Multi-Region Signaling
Applying the procedure of [RFC4206], in a MRN environment MAY lead to
setup one-hop FA-LSPs between each node. Therefore, considering that
s/setup one-hop/the setup of single-hop/
s/each node/each pair of nodes/
the path computation is able to take into account richness of
information with regard to the SC available on given nodes belonging
to the path, it is consistent to provide enough signaling
information
to indicate the SC to be used and on over which link. Particularly,
s/on over/over/
in case a TE link has multiple SC advertised as part of its ISCD
sub-
s/in case/in the case that/
s/SC/SCs/
TLVs, an ERO does not allow selecting a particular SC.
You mean: does not provide a mechanism to select... ?
===
4. Multi-Region Signaling
OLD
Limiting modifications to existing RSVP-TE procedures [RFC3473] and
referenced, this document defines a new sub-object of the eXclude
Route Object (XRO), see [RFC4874], called Switching Capability sub-
object. This sub-object enables (when desired) the explicit
identification of (at least one) switching capability to be excluded
from the resource selection process described here above.
NEW
In order to limit the modifications to existing RSVP-TE procedures
([RFC3473] and associated work), this document defines a new sub-
object of the eXclude Route Object (XRO), see [RFC4874], called the
Switching Capability sub-object. This sub-object enables (when
desired) the explicit identification of at least one switching
capability to be excluded from the resource selection process
described above.
===
4. Multi-Region Signaling
Including this sub-object as part of the XRO that explicitly
indicates which SCs have to be excluded (before initiating the
procedure described here above) over a specified TE link solves the
ambiguous choice among SCs that are potentially used along a given
path and give the possibility to optimize resource usage on a multi-
region basis. Note that implicit SC inclusion is easily supported by
explicitly excluding other SCs (e.g. to include LSC, it is required
to exclude PSC, L2SC, TDM and FSC).
You don't mention here the use of the new sub-object in an ERO Explicit
Exclusion Route sub-object [RFC4874]. I think you should.
Either you allow it (in which case the final sentence of your paragraph
above directly contradicts the earlier "an ERO does not allow selecting
a particular SC", or you must explicitly exclude it.
===
4.1 SC Subobject Encoding
Previously you have "sub-object"
RFC3209 seems to use "subobject" to perhaps you can fix this up globally.
===
4.1 SC Subobject Encoding
The contents of an EXCLUDE_ROUTE object defined in [RFC4874] are a
series of variable-length data items called subobjects. This
document defines the Switching Capability (SC) subobject of the XRO
(Type 35), its encoding and processing.
s/35/35 TBD by IANA/
===
4.1 SC Subobject Encoding
1 indicates that the specified SC should be excluded or
avoided with respect to the preceding numbered (Type 1 or
Type 2) or unnumbered interface (Type) subobject
and
This sub-object must follow the set of numbered or unnumbered
interface sub-objects to which this sub-object refers. In case, of
loose hop ERO subobject, the XRO sub-object must precede the loose-
hop sub-object identifying the tail-end node/interface of the
traversed region(s).
I think there is an important piece of information hiding here!
Recall, this is the XRO so it says things that have to be globally
avoided on the whole path. You are saying that there is an encoding
sequence rule within the XRO - this is new behavior.
Or are you actually describing the behavior within the Explicit
Exclusion Route sub-object of the ERO?
But, you have also said "the set of..." and I don't understand how
you delimit that set. And what if I want to completely exclude if-A and
just limit the SC on if-B. My XRO would read {if-A, if-B, SC} and it
might look like this just means limit the SC on both if-A and if-B.
Furthermore, it is expected, when label sub-object are following
numbered or unnumbered interface sub-objects, that the label value is
compliant with the SC capability to be explicitly excluded.
And this paragraph is definitely all about the ERO.
===
5. Virtual TE link
A virtual TE link is defined as a TE link between two upper layer
nodes that is not associated with a fully provisioned FA-LSP in a
lower layer.
Suggest you add a reference here. Presumably RFC 5212.
Two techniques can be used for the setup, operation, and maintenance
of Virtual TE links. The corresponding GMPLS protocols extensions are
s/Virtual/virtual/
===
5.1 Edge-to-edge Association
This approach that does not require state maintenance on transit LSRs
s/approach/approach,/
s/LSRs/LSRs,/
===
5.1 Edge-to-edge Association
Paragraph doesn't appear to make sense. Suggestion below.
OLD
This technique consists of exchanging identification and TE
attributes information directly between TE link end points. These TE
link end-points correspond to the LSP head-end and tail-end points of
of the LSPs that will be established. The end-points MUST belong to
the same (LSP) region through the establishment of a call between
terminating LSRs.
NEW
This technique consists of exchanging identification and TE
attributes information directly between TE link end points through
the establishment of a call between terminating LSRs. These TE
link end-points correspond to the LSP head-end and tail-end points of
of the LSPs that will be established. The end-points MUST belong to
the same (LSP) region.
===
5.1 Edge-to-edge Association
Once the call is established the resulting association populates the
local TEDB
First use of TEDB.
===
5.1 Edge-to-edge Association
and the resulting TE link is advertised
Should that read "resulting virtual TE link"
===
5.1 Edge-to-edge Association
OLD
The latter can then be used to attract traffic. Once an upper
layer/lower region LSP makes use of this TE link. A set of one or
more LSPs MUST be initially established using procedures defined in
[RFC4206] before the FA LSP can be used for nesting the incoming LSP.
NEW
The latter can then be used to attract traffic. When an upper
layer/region LSP tries to make use of this virtual TE link, one
or more FA LSPs MUST be established using procedures defined in
[RFC4206] to make the virtual TE link "real" and allow it to carry
the upper layer/region LSP.
===
5.1 Edge-to-edge Association
In order to distinguish usage of such call from a classical call (as
defined e.g. in [RFC4139]), a CALL ATTRIBUTES object is introduced.
Suggest delete the paranthetical text or replace the reference with
RFC4974 as 4139 neither describes classical calls, nor defines any
protocol procedures.
===
5.1.1 CALL_ATTRIBUTES Object
The CALL_ATTRIBUTES object is used to signal attributes required in
support of a call, or to indicate the nature or use of a call. It is
built on the LSP-ATTRIBUTES object defined in [RFC4420].
s/build/modelled/
===
5.1.1 CALL_ATTRIBUTES Object
One C-Type is defined, C-Type = 1 for CALL Attributes.
Insert paragraph break.
This object is
optional and may be placed on Notify messages to convey additional
information about the desired attributes of the call.
s/optional/OPTIONAL/
s/may/MAY/
===
5.1.2 Processing
Specifically, if an egress (or intermediate) LSR does not support the
object, it forwards it unexamined and unchanged. This facilitates
the exchange of attributes across legacy networks that do not support
this new object.
This paragraph has no meaning for the currently defined usage.
Notify messages are forwarded without inspection except by the addressed
node.
So, you could say that you are using 11bbbbbb so that the receiver is
not required to process the object. Is that what you want?
Suggest that you delete "Specifically"
===
5.1.2 Processing
The CALL_ATTRIBUTES object may be used to report call operational
state on a Notify message.
This may be true, but it is a surprise to the reader. We were happily
planning to use this to control the call as described in Section 5.1.1.
===
5.1.2 Processing
OLD
CALL_ATTRIBUTES class = 201, C-Type = 1
NEW
CALL_ATTRIBUTES class = 201 (TBD by IANA), C-Type = 1
===
5.1.2 Processing
The Attributes TLVs are encoded as described in Section 3.
I don't think so!
Possibly 5.1.3?
===
5.1.3 Attributes TLVs
Attributes carried by the CALL_ATTRIBUTES object are encoded within
TLVs. One or more TLVs may be present in each object.
s/may/MAY/ ?
Do you need to describe what happens if the object is empty?
===
5.1.3 Attributes TLVs
Length
Suggest you use the text which the IESG has decreed for rfc4420-bis as
below.
Indicates the total length of the TLV in octets. That is, the
combined length of the Type, Length, and Value fields, i.e.,
four plus the length of the Value field in octets.
The entire TLV MUST be padded with between zero and three
trailing zeros to make it four-octet aligned. The Length field
does not count any padding.
===
5.1.4 Attributes Flags TLV
The TLV Type 1 indicates the Attributes Flags TLV. Other TLV types
s/1/1 (TBD by IANA)/
Section 8).The Attributes Flags TLV may be present in a
s/may/MAY/
===
5.1.5 Call inheritance Flag
Please capitalise header
===
5.1.5 Call inheritance Flag
This document introduces a specific flag (MSB position bit 0) of the
For me, MSB means "most significant byte", and msb means "most
significant bit".
I suggest you just spell this out, as you don't use the acronym
anywhere else.
===
5.1.5 Call inheritance Flag
The Call inheritance flag MUST be set to 1 in order to indicate that
the established association is to be translated into a TE link
advertisement. The value of this flag is by default set to 1.
I don't think so!
You can't tell the implementation what default to set.
And the default is zero when the flag is absent.
===
5.1.5 Call inheritance Flag
Setting
this flag to 0 results in a hidden TE link or in deleting the
corresponding TE link advertisement (by setting the corresponding
Opaque LSA Age to MaxAge).
So this is a call modification issue that causes the TE link to be
withdrawn.
What would happen to LSPs using the TE link if it has subsequently
been made real from being virtual?
===
5.1.5 Call inheritance Flag
The notify message used for establishing the association is defined
s/notify/Notify/
as per [RFC4974]. Additionally, the notify message must carry an
s/notify/Notify/
===
5.2. Soft Forwarding Adjacency (Soft FA)
o The first one consists in setting up the FA LSP by precluding
resource commitment during its establishment.
ADD
These are known as pre-planned LSPs.
===
5.2.1 Pre-planned LSP Flag
s/Pre-planned/Pre-Planned/
The LSP ATTRIBUTES object and Attributes Flags TLV are defined in
s/LSP ATTRIBUTE object/LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects/
[RFC4420]. The present document defines a new flag, the pre-planned
s/The present/This/
s/pre-planned/Pre-Planned/
This flag, part of the LSP_REQUIRED ATTRIBUTE object, follows
s/LSP_REQUIRED ATTRIBUTE/LSP_REQUIRED_ATTRIBUTES/
The flag is part of the TLV, not part of the object. The TLV can be
carried on the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES
object. So perhaps you need to tweak this language a little.
You seem to be missing an IANA instruction in section 8.
Look at the registry at http://www.iana.org/assignments/rsvp-te-
parameters/rsvp-te-parameters.xhtml and be sure to supply all of the
necessary information.
processing of [RFC4420] for that object. That is, LSRs that do not
recognize the object reject the LSP setup effectively saying that
s/reject/MUST reject/
they do not support the attributes requested. Indeed, the newly
defined attribute requires examination at all transit LSRs.
o When set to 0 this means that the LSP should be fully provisioned.
s/should/MUST/
o When set to 1 this means that the LSP should be provisioned in the
s/should/MUST/
If an LSP is established with the pre-planned Flag set to 0, it MAY
be re-signaled by setting the Flag to 1.
And what is an implementation supposed to do?
===
5.2.2 Path Provisioned LSPs
There is a difference in between an LSP that is established with 0
s/in between/between/
However, the former is currently not possible using the GMPLS
protocol suite (following technology specific SENDER_TSPEC/FLOWSPEC
definition). Indeed, Traffic Parameters such as those defined in [RFC
4606] do not support setup of 0 bandwidth LSPs.
This appears to be contradicted by your description of PSC and L2SC,
below. How about...
NEW
However, the former is not appropriate in the circuit switching
technologies where label allocation is tighly coupled with resource
allocation. Indeed, where there is a technology-specific
SENDER_TSPEC/FLOWSPEC definition, traffic parameters (such as those
defined in [RFC4606]) do not support setup of 0 bandwidth LSPs.
Mechanisms for provisioning (pre-planned or not) LSP with 0 bandwidth
s/(pre-planned or not) LSP/an LSP (pre-planned or not)/
is straightforward for PSC the SENDER_TSPEC/FLOWSPEC, the Peak Data
s/PSC the/PSC: In the/
For TDM and LSC LSP, a NULL Label value is used to prevent resource
s/LSP/LSPs/
===
6. Backward compatibility
Please capitalise heading.
===
6. Backward compatibility
New objects and procedures defined in this document are running
s/running/run/
OLD
within a given TE domain. The latter, defined as group of LSRs that
enforces a common TE policy, is thus expected to run in the context
NEW
within a given TE domain, defined as group of LSRs that
enforces a common TE policy. Thus, the extensions defined in this
document are expected to run in the context
of a consistent TE policy. Specification for a consistent TE policy
s/for/of/
Section 5.1 if this is method selected or creating edge-to-edge
s/is methos/is the method/
s/or/for/
In case the Soft FA method is used for the creation of Virtual TE
s/In case the/If the/
s/Virtual/virtual/
===
7. Security Considerations
the proposed GMPLS extensions is limited to single TE domain. Such
s/to single/to a single/
s/Such/Such a/
OLD
this context, multi-switching layer comprised within such TE domain
NEW
this context, multiple switching layers within such TE domains
===
9.1 Normative References
[GR-TELINK]
Does this I-D need to be a normative reference? The I-D *is* progressing
and has passed WG last call, but there are still some updates pending
and I am not confident that it will complete quickly.
If you cannot move it to an informative reference, maybe you can work
with its author to complete the remaining actions.
===
9.1 Normative References
[RFC4420] Farrel, A., et al., "Encoding of Attributes for
You could add a reference to draft-ietf-ccamp-rfc4420bis although it will
proably be published and obsolete RFC4420 before this I-D is published.
===
Author's Addresses
I believe Jean-Louis' has changed...
jeanlouis.leroux@orange-ftgroup.com
===
Contributors
Eiji has new coordinates...
Eiji Oki
University of Electro-Communications
Tokyo
Japan
Email: oki@ice.uec.ac.jp
===