Hi Les, Thanks for these comments.
Please see inline, > -----Message d'origine----- > De : Adrian Farrel [mailto:[EMAIL PROTECTED] > Envoyé : mercredi 21 février 2007 11:53 > À : [EMAIL PROTECTED] > Objet : [Pce] Comments on > draft-ietf-pce-disco-proto-isis-02.txt from ISISWG > > ----- 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. OK, to be eliminated > > 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. In the PCE context the defintion of a domain is as follows (as per RFC 4655): "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." Is that OK if we refer to [RFC4655] and indicate that this definition applies to a PCE context? > > Section 3.1.1 > > inter-area, inter-AS, inter-layer\205 > > LES: Remove Formatting character \205 OK > > 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. Right. We are going to rephrase as follows: The flooding scope for PCE information advertised through IS-IS can be a single L1 area, a L1 area and the L2 sub-domain (when the PCE is a L1L2 node), or the entire IS-IS domain (S bit set in the Router Capability TLV). Does that make sense? > > 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. OK, we are going to remove the above paragraph > > 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. OK > > The format of the IS-IS PCED TLV and its sub-TLVs is the > identical to > > > LES: s/the identical/identical OK > > 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." OK > > 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. OK, to be added. > > 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]". OK > Which causes me to mention that you have no reference to ISO > 10589 in the references section, a most serious breach of > etiquette indeed!! OK, to be added > > 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. OK > > Section 5 > > defined in [IS-IS-CAP]. A such, elements of procedures are > inherited > > > LES: s/A such/As such OK > > domain, itMUST be carried within an IS-IS CAPABILITY TLV > having the S > > > LES: s/itMUST/it MUST OK > > 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". You are right the PCE is a functional block. But it is often assimilated to the node hosting the PCE function, which is an IS-IS node in this draft. Is that OK if we say "An IS-IS node acting as PCE MUST originate"... > 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..." Let say "An IS-IS node acting as PCC..." ? > - 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. Yes it is out of the scope. > > 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. Yes this is the latter, we are going to rephrase as suggested. > > 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! Yes TLVs :-) > > > in particular the privacy PCE discovery information. > > LES: s/privacy/privacy of OK Again, thanks a lot for these comments. Once the last call is completed, we are going to submit a new revision that accounts for all these comments. Best Regards, JL > > 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 > > > _______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
