[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Working Group Last Call Comments on draft-ietf-ccamp-gmpls-mln-extensions-03.txt
Hi Dimitri,
Cut down to just our discussions.
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.
Yes this is the one. I don't know where the former comes ...
OK. And grep suggests this is the only use of "control plane region" so I
suggest changing the text to...
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 Label Switching Path (LSP) Region as defined in
[RFC4206].
common TE policy. A CP instance can serve one, two or
more layers.
I don't think you have defined "CP"
Do you mean spell out the acronym ? or the term CP instance ?
Spell it out.
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?
Well the componanion doc. is the GMPLS OAM doc. so listing the
features identified in the EVAL doc. and the match in GMPLS OAM
doc. may be informative.
Well, OK. Best add the reference.
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
I guess you mean "hybrid node" ? it is home made. Do you ask
for further details ?
I like "home made" :-)
I think it is defined in MLN-REQ so you can simply add that.
-- 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?
The former.
OK. How about...
In the MRN context, nodes that have at least one interface that supports
more than one switching capability are called Hybrid nodes [MLN-REQ].
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.
No problem for me but you hit the issue of having e.g. analysis of req.
document that are informative that are introducing definition and then
having to re-introduce them in the protocol docs. in brief, we are
keeping repeating definitions.
Oh. I see. Yes.
But, I went to look in MLN-REQ and MLN-EVAL and I don't find the word "pool"
at all.
If it is defined in another document, I am happy that you have...
Set to the encoding of the available adaptation pool [REF] and to...
But if you can't find it elsewhere, we need a brief definition here.
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.
Yes. The problem is the other way around to prevent complex consistency
checks between XRO and ERO there is no other way to concentrating
exclusions in XRO and inclusions in ERO.
Oh, but in RFC 4874 there is not only the XRO but the EXRS (exclude route
subobject) for use in the ERO as well.
That is, there is already a mechanism for specific hop-by-hop exclusions.
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.
Meaning ?
5.1.1 says
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.
Which seems to be definitive.
Yet 5.1.2 says
The CALL_ATTRIBUTES object may be used to report call operational
state on a Notify message.
So I suggest you do a little rejiggling of the two sections to read...
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].
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.
The CALL_ATTRIBUTES object may also be used to report call operational
state on a Notify message.
5.1.2 Encoding
The CALL_ATTRIBUTES object class is 201 (TBD by IANA) of the form
11bbbbbb. This C-Num value (see [RFC2205], Section 3.10) ensures that
LSRs that do not recognize the object pass it on transparently.
One C-Type is defined, C-Type = 1 for CALL Attributes. This object is
optional and may be placed on Notify messages to convey additional
information about the desired attributes of the call.
CALL_ATTRIBUTES class = 201, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Attributes TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attributes TLVs are encoded as described in Section 3.
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?
This behaviour is required to remove disabled virtual TE links when
corresponding resources are in use. Removing the former shall not
have impact since no LSP use that resource otherwise it would have
been a "real" TE link.
I think I wasn't quite clear in my comment.
It seems to me that if you create an LSP with flag set to 1, an LSP may use
it as a TE link.
Now, if you set the flag to 0 (without first removing the tunneled LSP),
what happens?
I assume that the TE link is withdrawn and the tunneled LSP sees a link
failure.
But maybe a short note to this effect?
Many thanks.
Adrian