RE: [Isis-wg] PCE working group last call ondraft-ietf-pce-disco-proto-isis-02.txt

["Les Ginsberg \(ginsberg\)" <[e-mail]>]

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.

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


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

   domain, itMUST be carried within an IS-IS CAPABILITY TLV having the S


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 
   able to detect that the PCED TLV has been removed from an IS-IS LSP.

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:[e-mail]]
> Sent: Wednesday, February 14, 2007 9:36 AM
> To: [e-mail]
> Cc: Jean Philippe Vasseur (jvasseur)
> Subject: [Isis-wg] PCE working group last call ondraft-ietf-pce-disco-
> proto-isis-02.txt
> 
> Hi,
> 
> The PCE working group is holding a last call on
>
http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-isis-02.t
xt
> 
> 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
> ([e-mail] and [e-mail])
> 
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/isis-wg

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