Subject: RE : [Pce] PCE Disco Reqs v01

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Fri, 8 Jul 2005 09:40:12 +0200

Hi Igor
 
Thanks for these useful comments/suggestions
 
Please see inline,

-----Message d'origine-----
De : Igor Bryskin [mailto:[email-masked]] 
Envoyé : mercredi 6 juillet 2005 17:40
À : LE ROUX Jean-Louis RD-CORE-LAN; [email-masked]
Objet : Re: [Pce] PCE Disco Reqs v01

JL.
 
I have a couple of questions/comments.
 
1. On more than one occasions you use the term "TE-LSP path computation request". This sounds like an assumption that paths are computed separately for each TE-LSP. In reality, though, a single path computation request for a protected service is expected to determine paths for multiple LSPs (working and protecting). Furthermore, a single path computation may be performed for multiple services to make them possible sharing protection resources. I would suggest dropping the "TE-LSP" from the "TE-LSP path computation" combination;
 
[JLLR] This is a valid point, I will update as per your proposal 
 
2. In section 5.1.3 you mentioned among GMPLS capabilities a capability to compute multi-layer paths. This sounds inaccurate: paths are always computed in one network layer, however, a capable PCE may determine/suggest necessary reconfigurations in lower layer(s) in order to satisfy a particular path computation request;
[JLLR] I'm not sure I follow you here. The PCE may be aware of topology in multiple layers and compute a multi-layer path.
As per defined in LSP-HIER an ERO can contain elements with distinct ISCs. Actually this will trigger LSP nesting at region boundaries. 
But I agree with you that "this may require the PCE to  determine/suggest necessary reconfigurations in lower layer(s) in order to satisfy a particular path computation request"; This is actually what we call VNT reconfiguration in MRN.
Also note that the objective here in this doc is not to explain the capabilities, this will actually be done in a separate document.

3. I believe it should be stated more clearly that 2 stages of PCE discovery are needed: basic stage and detailed stage. During the basic stage PCE publishes some basic information about itself (presence, computation scope, etc.) on the network independently from PCCs. Interested PCCs should be able to participate in the detailed discovery stage, that is, to establish communication sessions (via PCC-PCE or a separate protocol) with the PCE to request/subscribe on the PCE detailed information (capability, CPU power, capacity, status, etc.). This would be good IMO both from the scalability and security points of view.
[JLLR] Note that this is already partially addressed in the capability section:
" It is paramount that dynamic capability discovery MUST NOT generate 

an excessive amount of information...  

 If required, the exhaustive discovery of detailed capabilities could be ensured by means of the PCC-PCE communication protocol.

Actually a tradeoff should be found between capability discovery by the PCE discovery mechanism and by the PCC-PCE communication protocol. One of the objectives of the PCE discovery mechanism is to help PCCs to select appropriate PCEs and limit the likelihood of PCC-PCE communication rejections that may occur in case a PCE cannot support a given capability. " 

I intend to agree with your proposal, but this may be too solution oriented 

"Interested PCCs should be able to participate in the detailed discovery stage, that is, to establish communication sessions (via PCC-PCE or a separate protocol) with the PCE to request/subscribe on the PCE detailed information (capability, CPU power, capacity, status, etc.). This would be good IMO both from the scalability and security points of view."

Why mandating the use of a PCC-PCE communication sessions for detailed discovery? This may be too solution oriented. One could argue that this may not scale, as you would have to setup a session with all PCEs in order to now their capabilities and that this could rather be done more efficiently thanks to IGP flooding, using a set of bit flags, at least for simple capabilities...

Hence, what about saying that there are too stages in PCE discovery (Basic, detailed...) that can be ensured either with the same discovery mechanism or using distinct mechnanisms?

4. Responding to your questions:
        -Is there a need for the discovery of PCE capacity in terms of  
         computation power? This static parameter could be used to  
         ensure weighted load balancing of requests in case PCEs do not  
         have the same capacity. 
Yes. It could be achieved by a direct request from a PCC during the detailed discovery stage (see above).
[JLLR] So you consider that this necessarily requires a PCC-PCE session?
One could argue that this may also be done in an efficient way thanks to IGP flooding:
For instance one could argue that a flag flooded into the IGP, is more efficient than N notifications sent by a PCE to its N PCCs using a PCC-PCE communication session...

        -Would it be useful that a PCE report its status as "congested"  
         in case it is too busy? PCCs may then use this dynamic  
         information to prefer a different PCE.  

Yes. It could be achieved by a subscription of a PCC on the PCE's status change (also during the detailed discovery stage ).
[JLLR] Same remark
 
Thanks a lot for these valuable comments,
 
Regards
 
JL 
 
Cheers,
Igor

----- Original Message ----- 
From: LE ROUX Jean-Louis  <mailto:[email-masked]> RD-CORE-LAN 
To: [email-masked] 
Sent: Wednesday, June 29, 2005 8:00 AM
Subject: [Pce] PCE Disco Reqs v01

Hi all, 

Version 01 of the PCE discovery reqs ID has just been published 
 <http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-01.txt> http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-01.txt 

This version takes into account comments received during Minneapolis session and on the list. 

Here are the major changes since 00: 
-Added multi-area network case in the problem statement 
-Added application scenario (section 4) 
-Section 5.1 on capability discovery modified as per discussions on the list: 
        -Discovery of PCE location, PCE scopes and domain(s) under control is mandatory 
        -Capability discovery is no longer a MUST 
       The list of capabilities is now out of the scope and should be addressed in a 
       separate document. 
       
-Added section 5.6 on extensibility 
-Added Security section 

Section 5.5 (Discovery of PCE capacity and congestion) requires WG feedback: 
-Is there a need for the discovery of PCE capacity in terms of computation power? This static parameter could be used to ensure weighted load balancing of requests in case PCEs do not have the same capacity. 

-Would it be useful that a PCE report its status as "congested" in case it is too busy? PCCs may then use this dynamic information to prefer a different PCE. 

Your comments/feedback would be highly welcome, especially on the above point 

Best Regards, 

JL 

  _____  

_______________________________________________
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: "Igor Bryskin" <[email-masked]>
Date: Fri, 8 Jul 2005 10:10:21 -0400

MessageJL,

Please, see inline.
  ----- Original Message ----- 
  From: LE ROUX Jean-Louis RD-CORE-LAN 
  To: Igor Bryskin ; [email-masked] 
  Sent: Friday, July 08, 2005 3:40 AM
  Subject: RE : [Pce] PCE Disco Reqs v01

  Hi Igor

  Please see inline,

    -----Message d'origine-----
    De : Igor Bryskin [mailto:[email-masked]] 
    Envoyé : mercredi 6 juillet 2005 17:40
    À : LE ROUX Jean-Louis RD-CORE-LAN; [email-masked]
    Objet : Re: [Pce] PCE Disco Reqs v01

    JL.

     

    2. In section 5.1.3 you mentioned among GMPLS capabilities a capability to compute multi-layer paths. This sounds inaccurate: paths are always computed in one network layer, however, a capable PCE may determine/suggest necessary reconfigurations in lower layer(s) in order to satisfy a particular path computation request;
    [JLLR] I'm not sure I follow you here. The PCE may be aware of topology in multiple layers and compute a multi-layer path.
    IB>> By computing a multi-layer path we actually mean computing path in the layer in question (that is, layer where the LSP will be provisioned) + necessary re-configurations in lower layers, would you agree with that ? 

    As per defined in LSP-HIER an ERO can contain elements with distinct ISCs. 
    IB>> This is just one way - top_to_bottom - to achieve dynamic lower layer re-configurations. As you correctly pointed out the VNT approach is another alternative, IMO much more reasonable and realistic. My point was that by PCE multi-layer capabilities we mean the support of dynamic re-configurations of multiple layers according to all feasible scenarios, and "the capability to compute multi-layer paths" is not adequate and somehow confusing term. 

    Actually this will trigger LSP nesting at region boundaries. 
    IB>> Correction, on layer boundaries :=)

    IB>> If you require capabilities without explaining what these capabilities mean, there will be a room for misinterpretation. I think it would be reasonable to request the definition in the" PCE architecture" document and make a reference to it.

    IB>> Scalability is just one of the problems. As Eric correctly pointed out the security concerns are very serious. PCE can disclose all information about itself only to PCCs it trusts.

    [IB>> It does not have to be the same protocol as used to request path computations. However, I can see the benefits of combining the two protocols togather. This, for instance, would make introduction of new constraints or optimization criterias simpler] 

    IB>> Well, this is a very popular statement in discussions around any requirements document. However, I don't see how it could be applied in this case. I was only asking to break the discovery process into 2 stages - basic (lightweighted and unsecure) and detailed, so that on one hand the scalability and secirity issues could be addresseb, and on the other hand PCCs could obtain all necessary information to choose the PCE to work with.

    IB>> See the comment above. Note, also, that in order to request a path computation PCC will have to setup a session anyway. Besides, if a PCC will install sessions with all PCEs it knows about, would it be a signifficant overhead ?

    IB>> Sounds good.

    IB>> a) security; b) one flag is probably not enough; c) what if the PCC is not an IGP-TE speaker?

    Have agreat weekend
    Igor

    Regards

    JL 

    Cheers,
    Igor

      ----- Original Message ----- 
      From: LE ROUX Jean-Louis RD-CORE-LAN 
      To: [email-masked] 
      Sent: Wednesday, June 29, 2005 8:00 AM
      Subject: [Pce] PCE Disco Reqs v01

      Hi all, 

      Version 01 of the PCE discovery reqs ID has just been published 
      http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-01.txt 

             

      Best Regards, 

      JL 

--------------------------------------------------------------------------