Subject: RE: [Pce] Re: Progress on draft-ietf-pce-discovery-reqs-01.txt

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Mon, 5 Sep 2005 07:49:43 +0200

Hi Stephen,

If the "interested entity" is a PCC then the answer is YES.

Regards

JL 

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Stephen Morris
> Envoyé : dimanche 4 septembre 2005 23:27
> À : [email-masked]; [email-masked]; 
> JP Vasseur
> Cc : Ting_Wo Chung; [email-masked]; Richard Rabbat; 
> raymond.zhang; Paul Mabey
> Objet : Re: [Pce] Re: Progress on draft-ietf-pce-discovery-reqs-01.txt
> 
> Hi JP, All
> In section 6.3. "PCE Information Synchronization", does this 
> requirement allow for a PCE to notify an interested entity 
> (e.g., a network management system) of a capability (or some 
> other) change?
> Best wishes
> Stephen
> 
> --- dimitri papadimitriou <[email-masked]>
> wrote:
> 
> > hi jp, all
> > 
> > the following chart discussed by JL during the last meeting pretty 
> > well summarize the issues
> > 
> >
> <http://www3.ietf.org/proceedings/05aug/slides/pce-1/sld7.htm>
> > 
> > based on the discussion one has had during the
> > meeting (and even if it 
> > not appropriate to consider specific implementation)
> > one could draw some 
> > line that for "discovering" the exact state (load,
> > congestion) and 
> > detailed capabilities a protocol preserving several
> > requirements such as 
> > adapted to exchange of such detailed information,
> > minimize overhead 
> > (conservative), confidentiality, etc.
> > 
> > thanks,
> > - dimitri.
> > 
> > 
> > 
> > JP Vasseur wrote:
> > 
> > > Hi Jean-Louis,
> > > 
> > > On Aug 31, 2005, at 3:13 AM, LE ROUX Jean-Louis
> > RD-CORE-LAN wrote:
> > > 
> > >> Hi Jean-Philippe,
> > >>
> > >> we plan to post a new revision by mid-september.
> > >> Is that OK?
> > >>
> > > 
> > > Perfect, thanks. Provided that the remaining
> > issues are sorted out,  we 
> > > could go for WG LC on this ID.
> > > 
> > > JP.
> > > 
> > >> Regards,
> > >>
> > >> JL
> > >>
> > >>
> > >>> -----Message d'origine-----
> > >>> De : JP Vasseur [mailto:[email-masked]]
> > >>> Envoyé : mardi 30 août 2005 17:52
> > >>> À : LE ROUX Jean-Louis RD-CORE-LAN; Paul Mabey;
> > Eiji Oki;
> > >>> Richard Rabbat; Ting_Wo Chung; raymond.zhang
> > >>> Cc : [email-masked]
> > >>> Objet : Progress on
> > draft-ietf-pce-discovery-reqs-01.txt
> > >>>
> > >>> Hi,
> > >>>
> > >>> First of all, thanks for the very significant
> > progress which
> > >>> has been made on this ID over the past 6 months.
> > As discussed
> > >>> during the last meeting in Paris, there are
> > still a few
> > >>> issues to be sorted out.
> > >>> Could we try to close on these remaining issues
> > so as to
> > >>> quickly start the protocol work (we're a bit
> > late on this  Milestone) ?
> > >>>
> > >>> Thanks.
> > >>>
> > >>> JP.
> > >>>
> > >>
> > > 
> > > _______________________________________________
> > > Pce mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/pce
> > > 
> > > .
> > > 
> > 
> > _______________________________________________
> > Pce mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pce
> > 
> 
> 
> 
> 		
> ___________________________________________________________ 
> To help you stay safe and secure online, we've developed the 
> all new Yahoo! Security Centre. http://uk.security.yahoo.com
> 
> _______________________________________________
> 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: "Adrian Farrel" <[email-masked]>
Date: Mon, 5 Sep 2005 11:35:10 +0100

Hi,

Jean-Louis is right; the requirement is focused on allowing PCEs to convey
information to PCCs.

Another entity would be able to "listen in" and gather information for its
own use, but such a requirement is out of scope for this document.

I guess it depends on the purpose of the function you are suggesting. For
example, if you want the NMS to be able to track the status of the PCE,
this would probably be a perfectly adequate technique. However, it does
rely on the NMS being able to listen in. That is: suppose the solution to
PCE discovery is an opaque LSA in OSPF; you would need the NMS to be able
to participate (at least passively) in the OSPF exchanges. Since the NMS
may be remote through a distinct management plane network, this might not
be possible.

The alternative solution to gathering status information at the NMS would
appear to be unchanged from the way network devices report status
information today. From an IETF standardisation point of view, this
requires MIB modules to allow the NMS to read information and to let the
PCE report asynchronous Notifications. Obviously, piles of other
proprietary or standard mechanisms exist outside the IETF.

Cheers,
Adrian

----- Original Message ----- 
From: "LE ROUX Jean-Louis RD-CORE-LAN"
<[email-masked]>
To: "Stephen Morris" <[email-masked]>; <[email-masked]>;
<[email-masked]>; "JP Vasseur" <[email-masked]>
Cc: "Ting_Wo Chung" <[email-masked]>; <[email-masked]>; "Richard
Rabbat" <[email-masked]>; "raymond.zhang"
<[email-masked]>; "Paul Mabey" <[email-masked]>
Sent: Monday, September 05, 2005 6:49 AM
Subject: RE: [Pce] Re: Progress on draft-ietf-pce-discovery-reqs-01.txt

Hi Stephen,

Regards

JL

---

From: Stephen Morris <[email-masked]>
Date: Tue, 6 Sep 2005 22:57:32 +0100 (BST)

Hi Adrian, Jean-Louis, All
A network manager would probably want NMS data on all
of the PCEs in the network. It's a useful mechanism in
discovery to let the managed entities (PCEs in this
case) notify the NMS about changes (such as
capability). This is particularly so in cases where
there are many such entities.

So, I think we have 2 related points here:
(1) External entities (e.g., NMS) should be able to
listen in on PCE changes, including detecting new PCEs
as they appear. This reduces polling.

(2) PCEs should be able to assist the NMS in
discovering them and their capabilities

I'm basically trying to reduce the amount of
discovery-related traffic. The latter often gives
network management a bad name :-).

Best wishes
Stephen

> > > late on this  Milestone) ?
=== message truncated ===

___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 7 Sep 2005 11:00:08 +0100

Hi,

> there are many such entities.

Yes, but let's not get things out of proportion. There will always be at
least as many network switches/routers as there are PCEs in any network
(such is the nature of the architecture).

How do switches/routers currently keep their capabilities (i.e. inventory)
up-to-date with NMS? Why shouldn't PCEs use the same technique?

> as they appear. This reduces polling.

Agreed. If the NMS is capable of listening, there is nothing in any of the
suggestions that prohibits it. However, we should not, I think, make it
compulsory for an NMS to listen to the PCE discovery protocols since this
may be operationally impossible in some configurations.

> discovering them and their capabilities

Certainly if we allow capabilities exchange as part of the PCC-PCE
protocol, this would be possible. The NMS would simply behave as a PCC
(which it will probably want to do anyway for computational purposes).

> To help you stay safe and secure online, we've developed the all new
Yahoo! Security Centre. http://uk.security.yahoo.com

---

From: JP Vasseur <[email-masked]>
Date: Wed, 7 Sep 2005 07:32:47 -0400

Hi,

Adding a few comments.

On Sep 7, 2005, at 6:00 AM, Adrian Farrel wrote:

>> capability).

As pointed out in other emails related to this thread, there is  
nothing preventing the NMS to listen the PCE discovery protocol.

That said,
(1) NMS will undoubtedly require more data that what will/should be  
provided by PCE discovery (since PCCs will not need as much data as NMS)
(2) Some NMS may not support the PCE discovery protocol.

We're seeking for volunteers to work on future MIBs ... Could we  
count you in ?

>> This is particularly so in cases where

See my comment (2) above.

> (which it will probably want to do anyway for computational purposes).

I'm not really convinced here ... If the NMS does not require path  
computation (which is likely to be the case in various  
circumstances), having the NMS acting as a PCC (even if the PCE  
communication protocol support detailed capability discovery), I'd  
prefer the NMS to rely on MIBs.

Thanks.

JP.

>>>> [mailto:[email-masked]] De la part de
>>>>
>>> Stephen Morris
>>>
>>>> À : [email-masked];
>>>>
>>> [email-masked];
>>>
>>>> JP Vasseur
>>>> Objet : Re: [Pce] Re: Progress on
>>>>
>>>> In section 6.3. "PCE Information Synchronization",
>>>>
>>> does this
>>>
>>>> requirement allow for a PCE to notify an
>>>>
>>> interested entity
>>>
>>>> (e.g., a network management system) of a
>>>>
>>> capability (or some
>>>
>>>> other) change?
>>>> Best wishes
>>>> Stephen
>>>>
>>>>> the following chart discussed by JL during the
>>>>>
>>> last meeting pretty
>>>
>>>>> not appropriate to consider specific
>>>>>
>>> implementation)
>>>
>>>>> one could draw some
>>>>> line that for "discovering" the exact state
>>>>>
>>> (load,
>>>
>>>>> congestion) and
>>>>> detailed capabilities a protocol preserving
>>>>>
>>> several
>>>
>>>>> requirements such as
>>>>> adapted to exchange of such detailed
>>>>>
>>> information,
>>>
>>>>> minimize overhead
>>>>>> On Aug 31, 2005, at 3:13 AM, LE ROUX
>>>>>>
>>> Jean-Louis
>>>
>>>>> RD-CORE-LAN wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi Jean-Philippe,
>>>>>>>
>>>>>>> we plan to post a new revision by
>>>>>>>
>>> mid-september.
>>>
>>>>>>> Is that OK?
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>>> À : LE ROUX Jean-Louis RD-CORE-LAN; Paul
>>>>>>>>
>>> Mabey;
>>>
>>>>> Eiji Oki;
>>>>>
>>>>>>>> First of all, thanks for the very
>>>>>>>>
>>> significant
>>>
>>>>> progress which
>>>>>
>>>>>>>> has been made on this ID over the past 6
>>>>>>>>
>>> months.
>>>
>>>>> As discussed
>>>>>
>>>>>>>> Could we try to close on these remaining
>>>>>>>>
>>> issues
>>>
>>>>> so as to
>>>>>

---

From: Stephen Morris <[email-masked]>
Date: Thu, 8 Sep 2005 22:10:58 +0100 (BST)

Hi JP
I'd be happy to help with the MIB work. Just one reply
below :-).
Best wishes
Stephen

--- JP Vasseur <[email-masked]> wrote:

> > Yes, but let's not get things out of proportion.
> There will always  
> > be at
> > least as many network switches/routers as there
> are PCEs in any  
> > network
> > How do switches/routers currently keep their
> capabilities (i.e.  
> > inventory)
> > Agreed. If the NMS is capable of listening, there
> is nothing in any  
> > of the
> > suggestions that prohibits it. However, we should
> not, I think,  
> > make it
> > compulsory for an NMS to listen to the PCE
> discovery protocols  
> > since this

Good point. Often, the NMS will have its own of
discovery software that relies on a heady cocktail of
MIBs, ping, etc. I guess my main point is that the PCE
discovery requirements should try to make life a
little easier on the NMS :-).

> >>> Jean-Louis is right; the requirement is focused
> on
> >>> allowing PCEs to convey
> >>> information to PCCs.
> >>>
> >>> own use, but such a requirement is out of scope
> for
> >>> this document.
> >>>
> >>> I guess it depends on the purpose of the
> function
> >>> you are suggesting. For
> >>> example, if you want the NMS to be able to track
> the
> >>> status of the PCE,
> >>> rely on the NMS being able to listen in. That
> is:
> >>> suppose the solution to
> >>> PCE discovery is an opaque LSA in OSPF; you
> would
> >>> need the NMS to be able
> >>> may be remote through a distinct management
> plane
> >>> network, this might not
> >>> be possible.
> >>>
> >>> appear to be unchanged from the way network
> devices
> >>> report status
> >>> PCE report asynchronous Notifications.
> Obviously,
> >>> piles of other
> >>> proprietary or standard mechanisms exist outside
> the
> >>> IETF.
> >>>
> >>> Cheers,
> >>> Adrian
> >>>
> >>> If the "interested entity" is a PCC then the
> answer
> >>> is YES.
> >>>
> >>>
> >>> Regards
> >>>
> >>> JL
> >>>
> >>>

___________________________________________________________ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

---

From: JP Vasseur <[email-masked]>
Date: Thu, 8 Sep 2005 17:30:38 -0400

Hi Stephen,

On Sep 8, 2005, at 5:10 PM, Stephen Morris wrote:

> Hi JP
> I'd be happy to help with the MIB work.

good, thanks.

JP.

> Just one reply
>>>> A network manager would probably want NMS data on
>>>>
>> all
>>
>>>> of the PCEs in the network. It's a useful
>>>>
>> mechanism in
>>
>>>> discovery to let the managed entities (PCEs in
>>>>
>> this
>>
>>> up-to-date with NMS? Why shouldn't PCEs use the
>>>
>> same technique?
>>
>>>
>>>
>>>
>>>> (1) External entities (e.g., NMS) should be able
>>>>
>> to
>>
>>>> listen in on PCE changes, including detecting new
>>>>
>> PCEs
>>
>>> may be operationally impossible in some
>>>
>> configurations.
>>
>
>>> Certainly if we allow capabilities exchange as
>>>
>> part of the PCC-PCE
>>
>>> protocol, this would be possible. The NMS would
>>>
>> simply behave as a PCC
>>
>>> (which it will probably want to do anyway for
>>>
>> computational purposes).
>>
>>>
>>>
>>
>>>>>> [mailto:[email-masked]] De la part
>>>>>>
>> de
>>
>>