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

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Thu, 1 Mar 2007 20:48:53 +0100

Hi Mike,

Thanks for these comments.

Please see inline,

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Adrian Farrel
> Envoyé : jeudi 15 février 2007 12:10
> À : [email-masked]
> Objet : Review comments on 
> draft-ietf-pce-disco-proto-isis-02.txt from ISIS WG
> 
> 
> ----- Original Message -----
> From: "mike shand" <[email-masked]>
> To: "Adrian Farrel" <[email-masked]>
> Cc: <[email-masked]>; "'Jean Philippe Vasseur'" <[email-masked]>
> 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

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce