Hi Les > This is better, but I really think it is unnecessary. > IS-IS is advertising information that the PCE application > provides. Clearly if that information changes, IS-IS must > update the relevant LSP(s). I don't know why we have to say > that - what else could IS-IS possibly do? Advertise something > other than what PCE provides? > > As the manner in which the information is transferred between > the PCE application and an IS-IS instance is out of scope for > this spec I don't see what discussing this adds. > > Consider RFC 3784. In that case IS-IS is advertising > information on behalf of TE. I don't think you will find any > language logically equivalent to what you are proposing in > 3784 - it's just not needed.
OK, so we are going to remove these aspects. Best Regards, JL > -----Message d'origine----- > De : Les Ginsberg (ginsberg) [mailto:[EMAIL PROTECTED] > Envoyé : mercredi 7 mars 2007 00:57 > À : LE ROUX Jean-Louis RD-CORE-LAN; Mike Shand (mshand) > Cc : [EMAIL PROTECTED]; [EMAIL PROTECTED]; David Ward; Chris Hopps > Objet : RE: [Pce] Comments on > draft-ietf-pce-disco-proto-isis-02.txt from ISISWG > > > > > -----Original Message----- > > From: LE ROUX Jean-Louis RD-CORE-LAN > [mailto:[EMAIL PROTECTED] > > ftgroup.com] > > Sent: Tuesday, March 06, 2007 3:32 PM > > To: Les Ginsberg (ginsberg); Mike Shand (mshand) > > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; David Ward; Chris Hopps > > Subject: RE: [Pce] Comments on > draft-ietf-pce-disco-proto-isis-02.txt > > from ISISWG > > > > Hi Les, > > > > > -----Message d'origine----- > > > De : Les Ginsberg (ginsberg) [mailto:[EMAIL PROTECTED] Envoyé : > > > mardi 6 mars 2007 19:28 À : Mike Shand (mshand) Cc : LE ROUX > > > Jean-Louis RD-CORE-LAN; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; David > > > Ward; Chris Hopps Objet : RE: [Pce] Comments on > > > draft-ietf-pce-disco-proto-isis-02.txt from ISISWG > > > > > > > > > > > > > -----Original Message----- > > > > From: Mike Shand (mshand) > > > > Sent: Tuesday, March 06, 2007 12:40 AM > > > > To: Les Ginsberg (ginsberg) > > > > Cc: LE ROUX Jean-Louis RD-CORE-LAN; [EMAIL PROTECTED]; > > > [EMAIL PROTECTED]; > > > > David Ward; Chris Hopps > > > > Subject: RE: [Pce] Comments on > > > draft-ietf-pce-disco-proto-isis-02.txt > > > > from ISISWG > > > > > > > > I agree with Les' responses. My only concern is the issue > > > of whether > > > > or not a PCE is an IS-IS router or not. I assume that it > > > usually is, > > > > but need not be. The text doesn't seem to work for the case > > > where it > > > > is not. Is the assumption that in this case some IS-IS > router will > > > > APPEAR to be a PCE, but the actual PCE will be located > > > elsewhere and > > > > some undefined communication method used between the > two. In that > > > > case, to all intents and purposes the IS-IS router *is* a > > > PCE, in just > > > > the same way that you could (if you were so minded) > have an IS-IS > > > > router whose SPF processing was handed off to some > other piece of > > > > hardware located elsewhere in the network. > > > > > > > > I guess the question I am asking is; can you tell by > looking at the > > > > bits on the wire whether the PCE function is collocated > > > with an IS-IS > > > > router or not? > > > > > > > > If you can tell (and hence distinguish the case where > it is not), > > > > then draft needs to describe this. If you can't tell, > then I guess > > > > there is no issue. > > > > > > I think I am slightly less forgiving with the language in the > > > draft than Mike. > > > > > > Quoting RFC 4655 > > > > > > "A Path Computation Element (PCE) is an entity that is capable of > > > computing a network path or route based on a network > graph, and of > > > applying computational constraints during the > computation. The PCE > > > entity is an application that can be located within a > > > network node or > > > component, on an out-of-network server, etc." > > > > > > I don't think it matters whether the PCE happens to be > > > co-located on a router running an IS-IS instance or not - the > > > key point is that a PCE (as well as PCC) is NOT an instance > > > of the IS-IS protocol. It therefore is simply wrong to say - > > > as you do in Section 5: > > > > > > "A PCE MUST originate a new IS-IS LSP..." > > > > > > And it is also wrong to say as you do later in the same section > > > > > > "When the PCE function is deactivated on a node, the node > > > MUST originate a new IS-IS..." > > > > > > I don't think this should be very controversial - just avoid > > > language which suggests that because IS-IS happens to be > > > advertising information on behalf of a PCE application that > > > it is the PCE application which is actually responsible for > > > actions which are clearly the responsibility of the IS-IS > instance. > > > > > > For example, for the latter case you might say something like: > > > > > > "When the PCE function is deactivated the information > > > associated with this PCE which is currently being advertised > > > in IS-IS LSPs MUST be withdrawn." > > > > OK, I get your point, so what about: > > > > An IS-IS router MUST originate a new IS-IS LSP whenever > there is a > > change in a PCED TLV > > associated with a PCE it advertises. > > > > When a PCE is deactivated, the IS-IS Router advertising > this PCE MUST > > originate a new IS-IS LSP that does no longer include > the corresponding > > PCED TLV. > > This is better, but I really think it is unnecessary. > IS-IS is advertising information that the PCE application > provides. Clearly if that information changes, IS-IS must > update the relevant LSP(s). I don't know why we have to say > that - what else could IS-IS possibly do? Advertise something > other than what PCE provides? > > As the manner in which the information is transferred between > the PCE application and an IS-IS instance is out of scope for > this spec I don't see what discussing this adds. > > Consider RFC 3784. In that case IS-IS is advertising > information on behalf of TE. I don't think you will find any > language logically equivalent to what you are proposing in > 3784 - it's just not needed. > > Les > > > > > Regards, > > > > JL > > > > > > > > (Just a suggestion) > > > > > > Les > > > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > Mike > > > > > > > > At 22:12 05/03/2007, Les Ginsberg \(ginsberg\) wrote: > > > > > > > > >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. > > > > > > > > I agree. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > Les is of course correct. > > > > > > > > > > > > > > > > > > > > > > > > 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
