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: Thu, 1 Mar 2007 20:13:39 +0100

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?

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

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

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

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

> 
>    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: "Les Ginsberg \(ginsberg\)" <[email-masked]>
Date: Mon, 5 Mar 2007 14:12:18 -0800

Jean-Louis -

Sorry for the delayed response.
Comments inline.

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

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.

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

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

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.

> Let say "An IS-IS node acting as PCC..." ?

Please see my previous comment.

> Yes it is out of the scope.

So, you could just remove the language entirely.

   Les

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Tue, 6 Mar 2007 23:55:29 +0100

Hi Les,

Please see inline, 

> De : Les Ginsberg (ginsberg) [mailto:[email-masked]] 
> Envoyé : lundi 5 mars 2007 23:12
> À : LE ROUX Jean-Louis RD-CORE-LAN; [email-masked]; 
> [email-masked]
> Cc : Mike Shand (mshand); David Ward; Chris Hopps
> Objet : RE: [Pce] Comments on 
> > Subject: RE: [Pce] Comments on 
> > > De : Adrian Farrel [mailto:[email-masked]] Envoyé : 
> mercredi 21 
> > > février 2007 11:53 À : [email-masked] Objet : [Pce] Comments on 
> definition 
> > > since as Mike points out it is not used in the document.
> > 
> > OK, to be eliminated
> > 
> > >
> > > 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 
> > 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"?

> > >    be limited to one or more IS-IS areas the PCE belongs 
> to, or can 
> > > be
> > >
> > > There is no defined method to restrict flooding to some subset of 
> > > the areas in a domain.
> > 
> > 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:
> 
> 2)L2 sub-domain (only available at Level-2 when S bit is 
> clear) 3)Entire routing domain (S bit set)
> 

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.

> > >    flooding scope may comprise these areas. This could be 
> the case 
> > > for a
> > >
> important to 
> > > use that terminology consistently throughout the document.
> > 
> > OK
> > 
> > >
> > > "The following sub-sections describe the sub-TLVs which may be 
> > > carried within the PCED sub-TLV."
> > 
> > OK
> > 
> > >
> > > Section 4.1.3
> > >
> > > 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
> > 
> etiquette 
> > > indeed!!
> > > 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
> assumed to 
> > > be the same - it MUST be explicitly stated.
> > 
> > OK
> > 
> > >
> > > Section 5
> > >
> > >    domain, itMUST be carried within an IS-IS CAPABILITY 
> TLV having 
> > > the S
> > >
> > >
> > > LES: s/itMUST/it MUST
> > 
> > OK
> > 
> > >
> > > 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.
> 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.
> > >

What about "An IS-IS router MUST be able to detect..."?

> So, you could just remove the language entirely.

Would it be OK if we only refer to "IS-IS routers"?

Best Regards,

JL

> > > 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)?
> 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.
> > 
> > Once the last call is completed, we are going to submit a 
> new revision 
> > that accounts for all these comments.
> > 
> > Best Regards,
> > 
> > JL
> > 
> > >
> > >    Les
> > >
> > >