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.
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
