Subject: [Isis-wg] PCE working group last call on draft-ietf-pce-disco-proto-isis-02.txt

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 14 Feb 2007 17:36:14 -0000

Hi,

The PCE working group is holding a last call on
http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-isis-02.txt

Since this I-D proposes protocol extensions to ISIS we would like the ISIS
working group to participate in this last call, and we have accordingly made
the last call period three weeks in order to give you plenty of time to
respond.

The last call will end at 12 noon GMT on Thursday 8th March.

Please send your comments to the PCE mailing list if you are subscribed. 
Otherwise, please channel your comments through the PCE working group chairs 
([email-masked] and [email-masked])

Background reading is:
RFC4655 - The PCE Architecture
RFC4674 - Requirements for Path Computation Element (PCE) Discovery
                  (These are the requirements that this I-D is addressing)

Thanks,
Adrian

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: mike shand <[email-masked]>
Date: Thu, 15 Feb 2007 10:47:48 +0000

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.

Abstract

    along with some of information that can be used for PCE selection.

some of THE information

or

some information

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.

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?

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?

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.

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

is identical to

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

  VALUE: This comprises a one-byte bit flags indicating the

this reads rather strangely

this comprises one byte of bit flags....

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

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

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

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)

END OF COMMENTS

At 17:36 14/02/2007, Adrian Farrel wrote:
>Please send your comments to the PCE mailing list if you are 
>subscribed. Otherwise, please channel your comments through the PCE 
>working group chairs ([email-masked] and [email-masked])
>
>Background reading is:

---

From: JP Vasseur <[email-masked]>
Date: Thu, 15 Feb 2007 09:21:45 -0500

Thanks for your comments Mike; we'll incorporate them in the next  
revision.

Cheers.

JP.

On Feb 15, 2007, at 5:47 AM, mike shand wrote:

> 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?
>
>
> top of page 5
>
>
> 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  
> are we assuming here that all this information will always fit  
> within a single LSP?  That is probably reasonable
>
>> subscribed. Otherwise, please channel your comments through the  
>> PCE working group chairs ([email-masked] and [email-masked])
>>
>> Background reading is:

---

From: "Les Ginsberg \(ginsberg\)" <[email-masked]>
Date: Mon, 19 Feb 2007 10:56:31 -0800

Section 1

      ABR: IGP Area Border Router (L1L2 router).  

LES: Use "L2 capable router" instead - or eliminate the definition since
as Mike points out it is not used in the document.

      Examples of domains include IGP areas and Autonomous Systems. 
 
LES: area and domain are not the same - though a domain may have only
one area. I would omit this sentence.

Section 3.1.1

     inter-area, inter-AS, inter-layer\205

LES: Remove Formatting character \205

Section 3.2

   The flooding scope for PCE information advertised through IS-IS can 
   be limited to one or more IS-IS areas the PCE belongs to, or can be 

LES: Flooding can only be area or domain scoped flooding. There is no
defined method to restrict flooding to some subset of the areas in a
domain.

   extended across the entire IS-IS routing domain.  
   Note that some PCEs may belong to multiple areas, in which case the 
   flooding scope may comprise these areas. This could be the case for a

   L1L2 router for instance advertising its PCE information within the 
   L2 area and/or a subset of its attached L1 area(s). 

LES: There is no such thing as an L2 area. There is the L2 sub-domain,
which consists of all L2 routers in a domain.

Section 4.1. The IS-IS PCED TLV 

LES: This is a sub-TLV. As Mike has pointed out, it is important to use
that terminology consistently throughout the document.

LES: s/the identical/identical

At the end of Section 4.1 it might be helpful to add:

"The following sub-sections describe the sub-TLVs which may be carried
within the PCED sub-TLV."

Section 4.1.3

   Two DOMAIN sub-TLVs are defined 
                   
            Sub-TLV type   Length        Name   
                 1         Variable     Area ID sub-TLV   
                 2           4          AS number sub-TLV 

LES: These codepoints are not mentioned in the IANA section.

Section 4.1.3.1

   VALUE: This comprises a variable length IS-IS area ID. This is the

          combination of an Initial Domain Part (IDP) and High Order  
          part of the Domain Specific part (HO-DSP)

LES: Rather than invent a term (HO-DSP) which ISO 10589 does not use,
say "this is the area address as defined in [ISO]". Which causes me to
mention that you have no reference to ISO 10589 in the references
section, a most serious breach of etiquette indeed!!

Section 4.1.4

LES: The domain/area sub-TLVs (nested level 3) which are defined in
4.1.3 appear to be "reused" here. This should be explicitly stated as
the scope of the sub-TLV codepoint for domain/area sub-TLVs is the
parent sub-TLV (PCE-domain or PCE-NEIG-DOMAIN) and therefore the
codepoints cannot be assumed to be the same - it MUST be explicitly
stated.

Section 5

   defined in [IS-IS-CAP]. A such, elements of procedures are inherited

LES: s/A such/As such

LES: s/itMUST/it MUST

   A PCE MUST originate a new IS-IS LSP whenever the content  

LES: There is a generic issue here. As a PCE is not a router running the
IS-IS protocol, it cannot generate any LSPs. :-) Therefore you cannot
say (as you do in multiple places) "a PCE originates a new IS-IS LSP".
Similarly, you say:

   A PCC MUST be 

As a PCC is also not equivalent to a router running the IS-IS protocol,
perhaps you want to say "A PCC MUST be informed..." - although I tend to
think that all of the communication between the applications (PCE and
PCC) and the IS-IS protocol instance is out of scope for this document.

   The PCE address, i.e. the address indicated within the PCE ADDRESS 
   sub-TLV, MUST be distributed as part of IS-IS routing;

LES: I am not sure what you mean here. Do you mean that there MUST be a
host route advertisement for the PCE address(es)? Or do you simply mean
that the PCE address(es) must be reachable via some prefix(es)
advertised by IS-IS? If the latter, then please change the wording. As
written it suggests there is a special advertisement required.

 Section 8

  IS-IS provides no mechanism for protecting the privacy of LSAs, and

LES: I don't know what you are trying to say here. Do you mean TLVs?
Certainly not LSAs!

   in particular the privacy PCE discovery information.  

LES: s/privacy/privacy of

   Les

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Wednesday, February 14, 2007 9:36 AM
> To: [email-masked]
> Cc: Jean Philippe Vasseur (jvasseur)
> Subject: [Isis-wg] PCE working group last call ondraft-ietf-pce-disco-
> proto-isis-02.txt
> 
> Hi,
> 
http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-isis-02.t
xt
> working group to participate in this last call, and we have
accordingly
> made
subscribed.