[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