Hi Les, Please see inline,
> -----Message d'origine----- > De : Les Ginsberg (ginsberg) [mailto:[EMAIL PROTECTED] > Envoyé : lundi 5 mars 2007 23:12 > À : LE ROUX Jean-Louis RD-CORE-LAN; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Cc : Mike Shand (mshand); David Ward; Chris Hopps > Objet : RE: [Pce] Comments on > draft-ietf-pce-disco-proto-isis-02.txt from ISISWG > > > 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. what about the term "Path Computation Domain"? > > > > > > > > > > > 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. Actually a L1L2 node may include a PCED TLV in a Router Cap TLV with the S bit cleared, both in its L1 and L2 LSPs. We are going to clarify this point. > > > > > 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. OK, I see, so what about "An IS-IS router MUST originate a new IS-IS LSP whenever the content of any of the PCED TLV changes"? > > > > > > 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. What about "An IS-IS router MUST be able to detect..."? > > > > > > - 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. Would it be OK if we only refer to "IS-IS routers"? Best Regards, JL > > 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
