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

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

--- JP Vasseur <jvasseur@cisco.com> wrote:

> Hi,
> 
> Adding a few comments.
> 
> On Sep 7, 2005, at 6:00 AM, Adrian Farrel wrote:
> 
> > Hi,
> >
> >
> >> 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).
> 
> 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
> >> 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?
> >
> >
> >> 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.
> >>
> >
> > 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.

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

> >
> 
> See my comment (2) above.
> 
> >
> >> (2) PCEs should be able to assist the NMS in
> >> 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).
> >
> 
> 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.
> 
> >
> >> I'm basically trying to reduce the amount of
> >> discovery-related traffic. The latter often gives
> >> network management a bad name :-).
> >>
> >> Best wishes
> >> Stephen
> >>
> >> --- Adrian Farrel <adrian@olddog.co.uk> wrote:
> >>
> >>
> >>> 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"
> >>> <jeanlouis.leroux@francetelecom.com>
> >>> To: "Stephen Morris" <stephenbjm@yahoo.com>;
> >>> <dpapadimitriou@psg.com>;
> >>> <dimitri.papadimitriou@alcatel.be>; "JP Vasseur"
> >>> <jvasseur@cisco.com>
> >>> Cc: "Ting_Wo Chung" <ting_wo.chung@bell.ca>;
> >>> <pce@ietf.org>; "Richard
> >>> Rabbat" <richard.rabbat@us.fujitsu.com>;
> >>> "raymond.zhang"
> >>> <raymond.zhang@bt.infonet.com>; "Paul Mabey"
> >>> <paul.mabey@qwest.com>
> >>> Sent: Monday, September 05, 2005 6:49 AM
> >>> Subject: RE: [Pce] Re: Progress on
> >>> draft-ietf-pce-discovery-reqs-01.txt
> >>>
> >>>
> >>> Hi Stephen,
> >>>
> >>> If the "interested entity" is a PCC then the
> answer
> >>> is YES.
> >>>
> >>>
> >>> Regards
> >>>
> >>> JL
> >>>
> >>>
> >>>> -----Message d'origine-----
> >>>> De : pce-bounces@lists.ietf.org
> >>>> [mailto:pce-bounces@lists.ietf.org] De la part
> de
> 
=== message truncated ===

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

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce