Subject: Working Group Last Call draft-ietf-ccamp-gmpls-mln-extensions-03.txt

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 5 Jan 2009 21:58:27 -0000

Hi,

This email begins a two week working group last call on 
draft-ietf-ccamp-gmpls-mln-extensions-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-extensions-03.txt

Please send your comments to the list before the last call closes 10pm GMT 
January 19, 2009.

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 18 Jan 2009 23:35:47 -0000

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...

   [email-masked]

===
Contributors

Eiji has new coordinates...

   Eiji Oki
   University of Electro-Communications
   Tokyo
   Japan
   Email: [email-masked]

===

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Wed, 21 Jan 2009 12:53:06 +0100

thanks for commenting - here below for a couple of hints and remarks: 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Monday, January 19, 2009 12:36 AM
> To: [email-masked]
> Subject: Working Group Last Call Comments on 

Yes this is the one. I don't know where the former comes ...

> I don't think you have defined "CP"

Do you mean spell out the acronym ? or the term CP instance ?

> 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.

> -- 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 ?

>    supports more than one SwCap, and that the node has at least one

The former. 

>    received [RFC4201], [RFC4203],

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.

> You mean: does not provide a mechanism to select... ?

Yes.

> a particular SC", or you must explicitly exclude it.

Ok. I will also add a couple of sentences of why this is not considered.
Basically an ERO determines the spatial characteristics of the path so
it is more suited to extend generality of the exclusion items in the XRO
than mixing up both objects and associated processing.

> 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.

> And this paragraph is definitely all about the ERO.

This is part of the "new behavior" as well. 

> Should that read "resulting virtual TE link"

Yes I will clarify.

> Notify messages are forwarded without inspection except by 
> the addressed node.

I would say it does not add any protocol specific element more than what
already exists.

> Suggest that you delete "Specifically"

Ok.

> planning to use this to control the call as described in 

Meaning ?

> For me, MSB means "most significant byte", and msb means "most

I will clarify.

> You can't tell the implementation what default to set.

This shall be phrased differently. The message is that disabling this
feature is a part. running mode.

> And the default is zero when the flag is absent.

This is another question. 
 
> 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.

> parameters/rsvp-te-parameters.xhtml and be sure to supply all of the

Ok.

> And what is an implementation supposed to do?

One may simply unallocate resources. So i am not sure about your
question.

> with its author to complete the remaining actions.

Ok.

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 24 Jan 2009 23:18:19 -0000

Hi Dimitri,

Cut down to just our discussions.

>> 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.
>>

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].

> Do you mean spell out the acronym ? or the term CP instance ?

Spell it out.

>>    Companion documents address GMPLS OAM aspects that
>>    have been identified in [MLN-EVAL].
>>
>> Hmmm. I smell a wriggle!
>>
> 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.

> 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.

>>    supports more than one SwCap, and that the node has at least one

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].

> 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.

> 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.

>> planning to use this to control the call as described in

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...

   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.

      0                   1                   2                   3
     |                                                               |
     //                       Attributes TLVs                       //
     |                                                               |

> have impact since no LSP use that resource otherwise it would have

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 24 Jan 2009 23:31:02 -0000

As you'll have noticed, the last call completed on this draft.

Dimitri appears to be hard at work on a revision.
As soon as I get it I'll do the write up and we'll move forward.

Thanks,
Adrian