Hi Mike, Thanks for these comments.
Please see inline, > -----Message d'origine----- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de Adrian Farrel > Envoyé : jeudi 15 février 2007 12:10 > À : [email protected] > Objet : Review comments on > draft-ietf-pce-disco-proto-isis-02.txt from ISIS WG > > > ----- Original Message ----- > From: "mike shand" <[EMAIL PROTECTED]> > To: "Adrian Farrel" <[EMAIL PROTECTED]> > Cc: <[email protected]>; "'Jean Philippe Vasseur'" <[EMAIL PROTECTED]> > 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 protected] https://www1.ietf.org/mailman/listinfo/pce
