Jean-Louis - Sorry for the delayed response. Comments inline.
> -----Original Message----- > From: LE ROUX Jean-Louis RD-CORE-LAN [mailto:[EMAIL PROTECTED] > ftgroup.com] > Sent: Thursday, March 01, 2007 11:14 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Les Ginsberg (ginsberg) > Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-isis-02.txt from > ISISWG > > 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? I think in an IS-IS specific document this is going to get confusing - as area and domain have a very specific meaning. So I think you need to define this as "PCE-domain", reference RFC4655, and make clear that this should be distinguished from a domain as defined by ISO 10589 - and use "PCE_domain" in all the appriopriate places in the document. > > > > > > 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). The three options are: 1)Single L1 area (only available at Level-1 - S bit clear) 2)L2 sub-domain (only available at Level-2 when S bit is clear) 3)Entire routing domain (S bit set) You cannot do a combination of #1 and #2 as your statement suggests. > > 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"... But it is also possible to have a PCE which is NOT running on a node which is acting as an IS-IS router. In that case the PCE information is passed to the IS-IS node in some manner which is beyond the scope of this document and IS-IS still advertises the information, but as the IP address of the PCE is NOT an address of the IS-IS router it is wrong to say the IS-IS is "acting as a PCE". IS-IS is simply advertising PCE information which has been provided to it. It does not act as a PCE in any way. > > > 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..." ? Please see my previous comment. > > > - 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. So, you could just remove the language entirely. Les > > > > > > > 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
