RE: Working Group Last Call Comments on draft-ietf-ccamp-gmpls-mln-extensions-03.txt

["PAPADIMITRIOU Dimitri" <[e-mail]>]

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

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Monday, January 19, 2009 12:36 AM
> To: [e-mail]
> Subject: 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.

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

> ===
> 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"

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

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

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.

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

I guess you mean "hybrid node" ? it is home made. Do you ask for further
details ?

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

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

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.

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

Yes.

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

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.

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

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.

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

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

> ===
> 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"

Yes I will clarify.

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

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

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

Ok.

> ===
> 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.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 will clarify.

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

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

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

Ok.

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

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

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

Ok.

> ===
> 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...
> 
>    [e-mail]
> 
> ===
> Contributors
> 
> Eiji has new coordinates...
> 
> 
>    Eiji Oki
>    University of Electro-Communications
>    Tokyo
>    Japan
>    Email: [e-mail]
> 
> === 
> 
> 
>