----- Original Message -----
From: "Les Ginsberg (ginsberg)" <[EMAIL PROTECTED]>
To: "Adrian Farrel" <[EMAIL PROTECTED]>; <[email protected]>
Cc: "Jean Philippe Vasseur (jvasseur)" <[EMAIL PROTECTED]>
Sent: Monday, February 19, 2007 6:56 PM
Subject: RE: [Isis-wg] PCE working group last call
ondraft-ietf-pce-disco-proto-isis-02.txt
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:[EMAIL PROTECTED]
Sent: Wednesday, February 14, 2007 9:36 AM
To: [email protected]
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
([EMAIL PROTECTED] and [EMAIL PROTECTED])
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 protected]
https://www1.ietf.org/mailman/listinfo/isis-wg
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
