Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-isis-02.txt from ISISWG

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Wed, 7 Mar 2007 00:32:23 +0100

Hi Les, 

> -----Message d'origine-----
> De : Les Ginsberg (ginsberg) [mailto:[email-masked]] 
> Envoyé : mardi 6 mars 2007 19:28
> À : Mike Shand (mshand)
> Cc : LE ROUX Jean-Louis RD-CORE-LAN; [email-masked]; 
> [email-masked]; 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-masked]; 
> [email-masked]; 
> > 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. 

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:jeanlouis.leroux@orange- ftgroup.com]
> > > > Sent: Thursday, March 01, 2007 11:14 AM
> > > > To: [email-masked]; [email-masked]; 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-masked]] Envoyé : 
> > > > > mercredi 21 février 2007 11:53 À : [email-masked] Objet : [Pce] 
> > > > > Comments on draft-ietf-pce-disco-proto-isis-02.txt from ISISWG
> > > > >
> > > > > ----- Original Message -----
> > > > >
> > > > > From: "Les Ginsberg (ginsberg)" <[email-masked]>
> > > > > To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
> > > > > Cc: "Jean Philippe Vasseur (jvasseur)" <[email-masked]>
> > > > > 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-masked]]
> > > > > > Sent: Wednesday, February 14, 2007 9:36 AM
> > > > > > To: [email-masked]
> > > > > > 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-masked] and [email-masked])
> > > > > >
> > > > > > 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-masked]
> > > > > > https://www1.ietf.org/mailman/listinfo/isis-wg
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Pce mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/pce
> > > > >
> > > > >
> > > > >
> 

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Wed, 7 Mar 2007 08:38:53 +0100

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

> Envoyé : mercredi 7 mars 2007 00:57
> À : LE ROUX Jean-Louis RD-CORE-LAN; Mike Shand (mshand)
> Cc : [email-masked]; [email-masked]; David Ward; Chris Hopps
> > Sent: Tuesday, March 06, 2007 3:32 PM
> > To: Les Ginsberg (ginsberg); Mike Shand (mshand)
> > Cc: [email-masked]; [email-masked]; David Ward; Chris Hopps
> > > De : Les Ginsberg (ginsberg) [mailto:[email-masked]] Envoyé : 
> > > mardi 6 mars 2007 19:28 À : Mike Shand (mshand) Cc : LE ROUX 
> > > Jean-Louis RD-CORE-LAN; [email-masked]; 
> [email-masked]; David 
> > > Ward; Chris Hopps Objet : RE: [Pce] Comments on 
> >    An IS-IS router MUST originate a new IS-IS LSP whenever 
> there is a
> > change in a PCED TLV
> >    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
> > > >
> > > > > > > Comments on