To: "LE ROUX Jean-Louis RD-CORE-LAN" <jeanlouis.leroux@orange-ftgroup.com>
From: mike shand <mshand@cisco.com>
Subject: RE: Review comments on draft-ietf-pce-disco-proto-isis-02.txt
from ISIS WG
Cc: <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>, <pce@ietf.org>,
"les Ginsberg \(ginsberg\)" <ginsberg@cisco.com>
At 19:48 01/03/2007, LE ROUX Jean-Louis RD-CORE-LAN wrote:
Hi Mike,
Thanks for these comments.
Please see inline,
> -----Message d'origine-----
> De : owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] De la part de Adrian Farrel
> Envoy=E9 : jeudi 15 f=E9vrier 2007 12:10
> =C0 : ccamp@ops.ietf.org
> Objet : Review comments on
> draft-ietf-pce-disco-proto-isis-02.txt from ISIS WG
>
>
> ----- Original Message -----
> From: "mike shand" <mshand@cisco.com>
> To: "Adrian Farrel" <adrian@olddog.co.uk>
> Cc: <isis-wg@ietf.org>; "'Jean Philippe Vasseur'" <jvasseur@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=20
within a common sphere of address management or=20
path computation responsibility. Examples of=20
domains include IGP areas, Autonomous Systems=20
(ASes), and multiple ASes within a Service=20
Provider network. Domains of path computation=20
responsibility may also exist as sub-domains of areas or ASes."
We are going to clarify. We can use the term=20
"Path Computation Domain" to be more specific.
Yes. I think it is important to make that differentiation.
> >
> >
> > 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 +=20
PCE-CAP-FLAGs (with 32 flags) =3D 40 bytes.
This let 256 - 2 -40 =3D 214 bytes for the=20
PCE-DOMAINS and PCE-NEIG-DOMAINS, which allows=20
encoding 35 neighbor ASes for instance.
Splitting a PCED TLV would add useless complexity.
We are going to add this statement : The PCED=20
TLV MUST fit in with a single ISIS CAP TLV.
By the way this restricts the number of PCE=20
domains and neighbor domains to a reasonable value.
Does that make sense?
Yes. The above statement removes any problems.
> >
> > 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,=20
we are going to submit a new revision that accounts for all these
comments.
Regards,
JL