Pandian, Vijay | 1 Mar 03:35 2007

Question on draft-ietf-ccamp-gmpls-ason-routing-ospf-02.txt

Hi,
 
In section 4.2 Technology Specific Bandwidth Accounting, it says:
 
   In the ASON context, accounting on per timeslot basis using 32-bit
   tuples of the form <signal_type (8 bits); number of unallocated
   timeslots (24 bits)> may optionally be incorporated in the
   technology specific field of the ISCD TE link attribute when the
   switching capability field is set to TDM value. When included,
   format and encoding MUST follow the rules defined in [RFC4202].
 
The signal types as defined in RFC4606 Section 2.1 covers a basic set. The signal type is used in conjunction with the other attributes like RCC, NCC, etc., to determine other Elementary Signal such as STS-12c SPE, STS-48c SPE, STS-192c SPE etc.
 
It is not clear to me how this 8-bit filed could be used to cover all the different types of signal types.
 
Thanks and best regards,
 
Vijay
rfc-editor | 1 Mar 06:10 2007

RFC 4801 on Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management


A new Request for Comments is now available in online RFC libraries.

        
        RFC 4801

        Title:      Definitions of Textual Conventions for 
                    Generalized Multiprotocol Label Switching (GMPLS) 
                    Management 
        Author:     T. Nadeau, Ed.,
                    A. Farrel, Ed.
        Status:     Standards Track
        Date:       February 2007
        Mailbox:    tnadeau <at> cisco.com, 
                    adrian <at> olddog.co.uk
        Pages:      9
        Characters: 16347
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ccamp-gmpls-tc-mib-11.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4801.txt

This document defines a Management Information Base (MIB) module
that contains textual conventions (TCs) to represent commonly used
Generalized Multiprotocol Label Switching (GMPLS) management
information.  The intent is that these textual conventions will
be imported and used in GMPLS-related MIB modules that would
otherwise define their own representations.  [STANDARDS TRACK]

This document is a product of the Common Control and Measurement Plane
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.Please refer to the current edition of the Internet
 Official Protocol Standards (STD 1) for the standardization state and
 status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST <at> IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body 

help: ways_to_get_rfcs. For example:

        To: rfc-info <at> RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager <at> RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR <at> RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...

rfc-editor | 1 Mar 06:08 2007

RFC 4803 on Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base


A new Request for Comments is now available in online RFC libraries.

        
        RFC 4803

        Title:      Generalized Multiprotocol Label Switching (GMPLS) 
                    Label Switching Router (LSR) Management Information 
                    Base 
        Author:     T. Nadeau, Ed., A. Farrel, Ed.
        Status:     Standards Track
        Date:       February 2007
        Mailbox:    tnadeau <at> cisco.com, 
                    adrian <at> olddog.co.uk
        Pages:      42
        Characters: 79925
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ccamp-gmpls-lsr-mib-15.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4803.txt

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects to configure and/or
monitor a Generalized Multiprotocol Label Switching (GMPLS) Label
Switching Router (LSR).  [STANDARDS TRACK]

This document is a product of the Common Control and Measurement Plane
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.Please refer to the current edition of the Internet
 Official Protocol Standards (STD 1) for the standardization state and
 status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST <at> IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body 

help: ways_to_get_rfcs. For example:

        To: rfc-info <at> RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager <at> RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR <at> RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...

rfc-editor | 1 Mar 06:09 2007

RFC 4802 on Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base


A new Request for Comments is now available in online RFC libraries.

        
        RFC 4802

        Title:      Generalized Multiprotocol Label Switching (GMPLS) 
                    Traffic Engineering Management Information Base 
        Author:     T. Nadeau, Ed., A. Farrel, Ed.
        Status:     Standards Track
        Date:       February 2007
        Mailbox:    tnadeau <at> cisco.com, 
                    adrian <at> olddog.co.uk
        Pages:      60
        Characters: 118164
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ccamp-gmpls-te-mib-16.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4802.txt

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects for Generalized
Multiprotocol Label Switching (GMPLS)-based traffic engineering.
[STANDARDS TRACK]

This document is a product of the Common Control and Measurement Plane
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.Please refer to the current edition of the Internet
 Official Protocol Standards (STD 1) for the standardization state and
 status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST <at> IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body 

help: ways_to_get_rfcs. For example:

        To: rfc-info <at> RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager <at> RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR <at> RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...

Dimitri.Papadimitriou | 1 Mar 08:54 2007
Picon

Re: Question on draft-ietf-ccamp-gmpls-ason-routing-ospf-02.txt

hi vijay

technology specific information encoding as part
of the techno specific field of the ISCD sub-TLV
is outside scope of this document, that defines
the generic routing mechanisms for OSPF

the paragraph you pointed is given as example, to
clearly indicate where this information has to be
encoded but is not going to be further detailed

in other terms techno-specific bw accounting is
outside the scope of the document

thanks,
- d.

"Pandian, Vijay" <Vijay.Pandian <at> sycamorenet.com>
Sent by: owner-ccamp <at> ops.ietf.org
01/03/2007 03:35

        To:     <ccamp <at> ops.ietf.org>
        cc: 
        Subject:        Question on 
draft-ietf-ccamp-gmpls-ason-routing-ospf-02.txt

Hi,

In section 4.2 Technology Specific Bandwidth Accounting, it says:

   In the ASON context, accounting on per timeslot basis using 32-bit 
   tuples of the form <signal_type (8 bits); number of unallocated 
   timeslots (24 bits)> may optionally be incorporated in the 
   technology specific field of the ISCD TE link attribute when the 
   switching capability field is set to TDM value. When included, 
   format and encoding MUST follow the rules defined in [RFC4202]. 

The signal types as defined in RFC4606 Section 2.1 covers a basic set. The 
signal type is used in conjunction with the other attributes like RCC, 
NCC, etc., to determine other Elementary Signal such as STS-12c SPE, 
STS-48c SPE, STS-192c SPE etc.

It is not clear to me how this 8-bit filed could be used to cover all the 
different types of signal types.

Thanks and best regards,

Vijay

Adrian Farrel | 1 Mar 12:05 2007
Picon

Re: Question on draft-ietf-ccamp-gmpls-ason-routing-ospf-02.txt

Hi,

From which response, I interpret Dimitri as saying that:

"Further, technology-specific documents might be written to define standard 
encoding of this (and other?) fields of the ISCD sub-TLV."

Is that correct?

The text in 4.2 appears more definitive than that. Perhaps, if the text 
shows just a potential encoding and not a defined encoding, you might 
consider making that very clear of removing the text?

Thanks,
Adrian
----- Original Message ----- 
From: <Dimitri.Papadimitriou <at> alcatel-lucent.be>
To: "Pandian, Vijay" <Vijay.Pandian <at> sycamorenet.com>
Cc: <ccamp <at> ops.ietf.org>; <owner-ccamp <at> ops.ietf.org>
Sent: Thursday, March 01, 2007 7:54 AM
Subject: Re: Question on draft-ietf-ccamp-gmpls-ason-routing-ospf-02.txt

> hi vijay
>
> technology specific information encoding as part
> of the techno specific field of the ISCD sub-TLV
> is outside scope of this document, that defines
> the generic routing mechanisms for OSPF
>
> the paragraph you pointed is given as example, to
> clearly indicate where this information has to be
> encoded but is not going to be further detailed
>
> in other terms techno-specific bw accounting is
> outside the scope of the document
>
> thanks,
> - d.
>
>
>
>
>
> "Pandian, Vijay" <Vijay.Pandian <at> sycamorenet.com>
> Sent by: owner-ccamp <at> ops.ietf.org
> 01/03/2007 03:35
>
>        To:     <ccamp <at> ops.ietf.org>
>        cc:
>        Subject:        Question on
> draft-ietf-ccamp-gmpls-ason-routing-ospf-02.txt
>
>
> Hi,
>
> In section 4.2 Technology Specific Bandwidth Accounting, it says:
>
>   In the ASON context, accounting on per timeslot basis using 32-bit
>   tuples of the form <signal_type (8 bits); number of unallocated
>   timeslots (24 bits)> may optionally be incorporated in the
>   technology specific field of the ISCD TE link attribute when the
>   switching capability field is set to TDM value. When included,
>   format and encoding MUST follow the rules defined in [RFC4202].
>
> The signal types as defined in RFC4606 Section 2.1 covers a basic set. The
> signal type is used in conjunction with the other attributes like RCC,
> NCC, etc., to determine other Elementary Signal such as STS-12c SPE,
> STS-48c SPE, STS-192c SPE etc.
>
> It is not clear to me how this 8-bit filed could be used to cover all the
> different types of signal types.
>
> Thanks and best regards,
>
> Vijay
>
>
>
>
> 

Adrian Farrel | 1 Mar 14:58 2007
Picon

New revision of draft-ietf-ccamp-lsp-stitching

Hi,

I appear to have taken over editing this I-D to prepare it for WG last call.

Here are my responses to my own review comments (yes, really!) that have 
been incorporated into the new revision just submitted.

Adrian

> ===
>
> idnits generates the following comments
>  * There are 96 instances of too long lines in the document, the longest
>    one being 1 character in excess of 72.

Indentation fixed.

>  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
>  - It seems as if not all pages are separated by form feeds - found 0 form
>    feeds but 22 pages

Form feeds inserted.

> ===
>
> The boilerplate will need to be updated for the new IETF Trust language.

Updated.

> ===
> Abstract.
>
> First paragraph is a good introduction.
> Second paragraph is fine and OK.
> But the Abstract also needs to say what the document is about!
> I suggest the addition of a new 2nd paragraph as follows...
>
>    This document describes extensions to the existing GMPLS signaling
>    protocol (RSVP-TE) to establish e2e LSPs from S-LSPs, and describes
>    how the LSPs can be managed using the GMPLS signaling and routing
>    protocols.

Test added.

> ===
>
> Acronyms
>
> Acronyms need to be expanded on their first use in the body of the 
> document regardless of whether they appear in the document title or in the 
> Abstract.
> I found...
> LSP
> GMPLS
> P2MP
> RRO

Changes made.

> ===
>
> Introduction
>
> The Introduction section is pretty lumpy. It seems to spend most of its 
> time talking about hierarchical LSPs, and only defines stitching in the 
> final paragraph.
>
> I suggest some re-ordering and a little editing as follows:
>
> New Section 1
>
>    A stitched Generalized Multiprotocol Label Switching (GMPLS) Traffic
>    Engineering (TE) Label Switched Path (LSP) is built from a set of
>    different LSP segments (S-LSPs) that are connected together in the
>    data plane in such a way that a single end-to-end LSP is realized in
>    the data plane.  In this document, we define the concept of LSP
>    stitching and detail the control plane mechanisms and procedures
>    (routing and signaling) to accomplish this.  Where applicable,
>    similarities and differences between LSP hierarchy [2] and LSP
>    stitching are highlighted.  Signaling extensions required for LSP
>    stitching are also described here.
>
>    It may be possible to configure a GMPLS node to switch the traffic
>    from an LSP for which it is the egress, to another LSP for which it
>    is the ingress, without requiring any signaling or routing extensions
>    whatsoever, and such that the operation is completely transparent to
>    other nodes.  This results in LSP stitching in the data plane, but
>    requires management intervention at the node where the stitching is
>    performed.  With the mechanism described in this document, the node
>    performing the stitching does not require configuration of the pair
>    of S-LSPs to be stitched together.  Also, LSP stitching as defined
>    here results in an end-to-end LSP both in the control and data
>    planes.

Done.

> Move the following paragraphs (unchanged) from Section 1 to the top of 
> Section 2.
>
>    LSP hierarchy ([2]) provides signaling and routing procedures so
>    that:
>
>    a.  A Hierarchical LSP (H-LSP) can be created.  Such an LSP created
>        in one layer can appear as a data link to LSPs in higher layers.
>        As such, one or more LSPs in a higher layer can traverse this
>        H-LSP as a single hop; we call this "nesting".
>
>    b.  An H-LSP may be managed and advertised (although this is not a
>        requirement) as a Traffic Engineering (TE) link.  Advertising an
>        H-LSP as a TE link allows other nodes in the TE domain in which
>        it is advertised to use this H-LSP in path computation.  If the
>        H-LSP TE link is advertised in the same instance of control plane
>        (TE domain) in which the H-LSP was provisioned, it is then
>        defined as a forwarding adjacency LSP (FA-LSP) and GMPLS nodes
>        can form a forwarding adjacency (FA) over this FA-LSP.  There is
>        usually no routing adjacency between end points of an FA.  An
>        H-LSP may also be advertised as a TE link in a different TE
>        domain.  In this case, the end points of the H-LSP are required
>        have a routing adjacency between them.
>
>    c.  RSVP signaling for LSP setup can occur between nodes that do not
>        have a routing adjacency.

Done, resulting in a shorter Section 1, and a longer Section 2.

> ===
>
> Section 3.2
>
> It might be useful to include a reference to RFC4726 to give some context 
> for inter-domain uses of stitching.

Added in 2nd paragraph.

> ===
>
> Security considerations
>
> I don't think we will get away with what is currently written :-(
> The killer is:
>    Mechanisms described in [6] should be
>    re-examined and may need to be altered to define new security
>    associations based on receiver's IP address instead of the sending
>    and receiving interfaces.
>
> I think that if you say that the re-examination is needed, you must do it. 
> You need to satisfy yourself as to whether any changes (beyond those 
> expressed in RFC4206) are needed.
>
> My view is that you should be able to echo the text of RFC4206 without 
> needing anything further. This is because the relationship between the 
> end-points of the S-LSP is the same as that between the end points of the 
> H-LSP in RFC4206. The precedent for remote signaling adjacencies has 
> already been established, and you are not defining anything new.

Security section re-written as follows:

   From a security point of view, the changes introduced in this
   document model the changes introduced by [2].  That is, the control
   interface over which RSVP messages are sent or received need not be
   the same as the data interface which the message identifies for
   switching traffic.  But the capability for this function was
   introduced in [4] to support the concept of out-of-fiber control
   channels, so there is nothing new in this concept for signaling or
   security.

   The application of this facility means that the "sending interface"
   or "receiving interface" may change as routing changes.  So, these
   interfaces cannot be used to establish security association between
   neighbors, and security associations MUST be bound to the
   communicating neighbors themselves.

   [6] provides a solution to this issue: in Section 2.1, under "Key
   Identifier", an IP address is a valid identifier for the sending (and
   by analogy, receiving) interface.  Since RSVP messages for a given
   LSP are sent to an IP address that identifies the next/previous hop
   for the LSP, one can replace all occurrences of 'sending [receiving]
   interface' with 'receiver's [sender's] IP address' (respectively).
   For example, in Section 4, third paragraph, instead of:

      "Each sender SHOULD have distinct security associations (and keys)
       per secured sending interface (or LIH).  ...  At the sender,
       security association selection is based on the interface through
       which the message is sent."

   it should read:

      "Each sender SHOULD have distinct security associations (and keys)
       per secured receiver's IP address. ...  At the sender, security
       association selection is based on the IP address to which the
       message is sent."

   Thus the mechanisms of [6] can be used unchanged to establish
   security associations between control plane neighbors.

   This document allows the IP destination address of Path and PathTear
   messages to be the IP address of a nexthop node (receiver's address)
   instead of the RSVP session destination address.  This means that the
   use of the IPsec Authentication Header (AH) (ruled out in [6] because
   RSVP messages were encapsulated in IP packets addressed to the
   ultimate destination of the Path or PathTear messages) is now
   perfectly applicable, and standard IPsec procedures can be used to
   secure the message exchanges.

   An analysis of GMPLS security issues can be found in [16].

> ===
>
> IANA considerations
>
> It would be helpful to name the sub-registries to help IANA get these 
> allocations right.
>
> In section 7.1 the registry is "RSVP TE Parameters" (not the registry 
> quoted in section 7) and the sub-registry is "Attributes Flags"
>
> In section 7.2 the registry is "Resource ReSerVation Protocol (RSVP) 
> Parameters" and the sub-registry is "Error Codes and Globally-Defined 
> Error Value Sub-Codes"

Done.

> It is also helpful to supply the precise text you would like added to the 
> registry.
>
> For section 7.1:
>
>                                       Path      Resv      RRO
> Bit   Name                             message   message   sub-object 
> Reference
> ----  -------------------------------  --------  --------  ----------  ---------
> 5     LSP stitching desired bit        Yes       No        Yes 
> [This doc]
>
>
> For section 7.2:
>
>  24  Routing Problem                             [RFC3209]
>
>        23 = Stitching unsupported  [This doc]

Done.

> ===

RE: Review comments on draft-ietf-pce-disco-proto-isis-02.txt from ISIS WG

Hi Mike,

Thanks for these comments.

Please see inline,

> -----Message d'origine-----
> De : owner-ccamp <at> ops.ietf.org 
> [mailto:owner-ccamp <at> ops.ietf.org] De la part de Adrian Farrel
> Envoyé : jeudi 15 février 2007 12:10
> À : ccamp <at> ops.ietf.org
> Objet : Review comments on 
> draft-ietf-pce-disco-proto-isis-02.txt from ISIS WG
> 
> 
> ----- Original Message -----
> From: "mike shand" <mshand <at> cisco.com>
> To: "Adrian Farrel" <adrian <at> olddog.co.uk>
> Cc: <isis-wg <at> ietf.org>; "'Jean Philippe Vasseur'" <jvasseur <at> cisco.com>
> Sent: Thursday, February 15, 2007 10:47 AM
> Subject: Re: [Isis-wg] PCE working group last call on 
> draft-ietf-pce-disco-proto-isis-02.txt
> 
> 
> > Adrian, JP,
> >
> >
> > A few comments below, mostly typos.
> >
> >         Mike
> >
> >
> > General comment... sometimes the document refers to octets and 
> > sometimes to bytes. It would be preferable to use a 
> consistent term throughout.

OK

> >
> >
> >
> > Abstract
> >
> >
> >    along with some of information that can be used for PCE 
> selection.
> >
> >
> > some of THE information
> >
> > or
> >
> > some information

OK

> >
> > 1. Terminology
> >
> > ABR is not a commonly used term in the context of IS-IS and doesn't 
> > appear to be referenced in the document.

OK

> >
> > domain. This definition is different from that commonly used for 
> > IS-IS. Is there a reason for the difference? The document refers to 
> > IS-IS routing domains. Is it intended that a domain is 
> different from a routing domain?

This is a domain as defined in the PCE architecture spec (RFC4655)

"A domain is any collection of network elements within a common sphere of address management or path
computation responsibility.  Examples of domains include IGP areas, Autonomous Systems (ASes), and
multiple ASes within a Service Provider network.  Domains of path computation responsibility may also
exist as sub-domains of areas or ASes."

We are going to clarify. We can use the term "Path Computation Domain" to be more specific.

> >
> >
> > top of page 5
> >
> >
> > This document does not define any new IS-IS elements of procedure.
> >    The procedures defined in [IS-IS-CAP] should be used.
> >
> >
> > should that be ... MUST be used?

OK, MUST be used

> >
> > 3.2 flooding scope
> >
> >
> >   be limited to one or more IS-IS areas the PCE belongs to, 
> or can be
> >
> > one or more IS-IS areas to which the PCE belongs
> >
> > would be better
> >
> >
> > 4.1. The IS-IS PCED TLV
> >
> > In the introduction this is referred to (correctly) as a 
> sub-TLV, but 
> > here and in subsequent text it is referred to as a TLV. This is 
> > confusing to say the least.

OK, to be changed to sub-TLV

> >
> >
> > The format of the IS-IS PCED TLV and its sub-TLVs is the 
> identical to
> >
> > is identical to

OK

> >
> >
> >
> > 4.1.6. The CONGESTION sub-TLV
> >
> >
> >   The CONGESTION sub-TLV is used to indicate a PCE's experiences a
> >
> > to indicate THAT a PCE experiences
> >
> > or
> >
> > to indicate a PCE's experience of a
> >
> > or
> >
> > to indicate that a PCE is experiencing a

OK

> >
> >
> >  VALUE: This comprises a one-byte bit flags indicating the
> >
> >
> > this reads rather strangely
> >
> > this comprises one byte of bit flags....

OK

> >
> >
> >
> >
> > 5. Elements of Procedure
> >
> >
> > typo
> >
> >
> >   domain, itMUST be carried within an IS-IS CAPABILITY TLV 
> having the 
> > S
> >
> >
> >    When the PCE function is deactivated on a node, the node MUST
> >    originate a new IS-IS LSP with no longer any PCED TLV. A 
> PCC MUST be
> >    able to detect that the PCED TLV has been removed from 
> an IS-IS LSP.
> >
> >
> > are we assuming here that all this information will always 
> fit within 
> > a single LSP?  That is probably reasonable

Yes

> >
> > Are we also assuming that it will always fit within a 
> single IS-IS CAP 
> > TLV? That may not be so reasonable.

Actually this sounds reasonable

2 * PCE-ADDRESS + PATH-SCOPE + CONGESTION + PCE-CAP-FLAGs (with 32 flags) = 40 bytes.

This let 256 - 2 -40 = 214 bytes for the PCE-DOMAINS and PCE-NEIG-DOMAINS, which allows encoding 35 neighbor
ASes for instance.

Splitting a PCED TLV would add useless complexity.
We are going to add this statement : The PCED TLV MUST fit in with a single ISIS CAP TLV. 
By the way this restricts the number of PCE domains and neighbor domains to a reasonable value.

Does that make sense?

> >
> > If it requires two IS-IS CAP TLVS, is there a requirement 
> that they be 
> > carried in the same LSP?
> >
> >
> >
> > 7.1. IS-IS sub-TLV
> >
> >    Once a registry for the IS-IS Router Capability TLV defined in
> >    [IS-IS-CAP] will have been assigned, IANA will assign a new
> >
> >
> > "has been assigned" would be better

OK

> >
> >
> >
> > 9.5. Requirements on Other Protocols and Functional Components
> >
> >    The IS-IS extensions defined in this documents does not imply any
> >    requirement on other protocols.
> >
> > do not imply (IS-IS extensions is plural)

OK

Thanks a lot. Once the last call is completed, we are going to submit a new revision that accounts for all
these comments.

Regards,

JL

> 
> 
> 
> 

Internet-Drafts | 1 Mar 21:50 2007
Picon

I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Inter domain Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic
Engineering - RSVP-TE extensions
	Author(s)	: A. Ayyangar, et al.
	Filename	: draft-ietf-ccamp-inter-domain-rsvp-te-05.txt
	Pages		: 21
	Date		: 2007-3-1
	
This document describes procedures and protocol extensions for the
   use of Resource ReserVation Protocol Traffic Engineering (RSVP-TE)
   signaling in Multiprotocol Label Switching Traffic Engineering
   (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and
   non-packet networks to support the establishment and maintenance of
   Label Switched Paths that cross domain boundaries.

   For the purpose of this document, a domain is considered to be any
   collection of network elements within a common realm of address space
   or path computation responsibility. Examples of such domains include
   Autonomous Systems, IGP routing areas, and GMPLS overlay networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-05.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ccamp-inter-domain-rsvp-te-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment: message/external-body, 149 bytes
Zafar Ali (zali | 2 Mar 00:41 2007
Picon

Next steps for draft-ietf-ccamp-mpls-graceful-shutdown-01.txt....

Hi Adrian, Deborah, Dimitri, and campers-  
 
As we mentioned at the last IETF meeting, http://www3.ietf.org/proceedings/06nov/slides/ccamp-17/sld1.htm, we have addressed all outstanding comments, except the following comment from Dimitri, related to this ID. Should you have any further comment, please share.
 
The only remaining comment that is not closed is "should this ID be informational or standard track". IMO the ID defines a new error-subcode and some specific behavior, and should be standard track. Can you please comment on this. 
 
The ID has been stable for quite some time and following the closure of the above, we would like to request last call. 
 
Thanks
 
Regards... Zafar  

Gmane