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

[JP Vasseur <[e-mail]>]

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

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 <[e-mail]> 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"
>>> <[e-mail]>
>>> To: "Stephen Morris" <[e-mail]>;
>>> <[e-mail]>;
>>> <[e-mail]>; "JP Vasseur"
>>> <[e-mail]>
>>> Cc: "Ting_Wo Chung" <[e-mail]>;
>>> <[e-mail]>; "Richard
>>> Rabbat" <[e-mail]>;
>>> "raymond.zhang"
>>> <[e-mail]>; "Paul Mabey"
>>> <[e-mail]>
>>> 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 : [e-mail]
>>>> [mailto:[e-mail]] De la part de
>>>>
>>> Stephen Morris
>>>
>>>> Envoyé : dimanche 4 septembre 2005 23:27
>>>> À : [e-mail];
>>>>
>>> [e-mail];
>>>
>>>> JP Vasseur
>>>> Cc : Ting_Wo Chung; [e-mail]; 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 <[e-mail]>
>>>> 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:[e-mail]]
>>>>>>>> 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 : [e-mail]
>>>>>>>> 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
>>>>>> [e-mail]
>>>>>> https://www1.ietf.org/mailman/listinfo/pce
>>>>>>
>>>>>> .
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pce mailing list
>>>>> [e-mail]
>>>>>
>>>
>>>
>> === message truncated ===
>>
>>
>>
>>
>> ___________________________________________________________
>> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pce
>

_______________________________________________
Pce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pce