Subject: [Pce] Response to Dimitri Papadimitriou comments on draft-ietf-pce-manageability-requirements-00.txt

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 27 Feb 2007 12:55:48 -0000

Hi Dimitri,

In producing the new revision of the WG doc I have made some changes to 
address your points as follows...

> a couple of comments though
>
> -- concerns on section 3.3 - it will for each document open the pandora
> box of the protocol dependencies - these should remain at most
> illustrative otherwise
>
> o) becoming restrictive with respect to the protocol applicability -
>
> o) potentially impacting and/or assuming other protocol(s) behaviour

Quite right.
In fact, the intention is to uncover any issues that might prevent future 
applicability and to unearth any issues that might cause disruptive impacts 
on other protocoFrom [email-masked] Tue Feb 27 08:01:29 2007
From: "Adrian Farrel" <[email-masked]>
To: "tom.petch" <[email-masked]>,
	"JP Vasseur" <[email-masked]>
Date: Tue, 27 Feb 2007 12:55:35 -0000
Organization: Old Dog Consulting
Cc: [email-masked]
Subject: [Pce] Response to Tom Petch (1) comments on
	draft-ietf-pce-manageability-requirements-00.txt
Reply-To: Adrian Farrel <[email-masked]>

Hi Tom,

Yes, thanks for flagging this to the working group.

I have been working with Dave Harrington on the construction of his I-D 
since there is obvious input that our draft can provide. If/when his work 
catches up with or overtakes our I-D we will consider cutting over to it. I 
expect to see some convergence as we 'borrow' ideas from each other's work.

At the moment, the tone of Dave's I-D is gentle and it offers 'guidance'. We 
are currently trying to be a little firmer with our recommendations in the 
PCE working group. Hopefully this will all be grist to the mill and the 
community will discover the benefits (or otherwise) of the different 
approaches and we will learn some lessons that we can continue to refine.

I have just submitted an update to the PCE working group document, and I 
continue to look for feedback from within the working group or without.

Thanks,
Adrian
----- Original Message ----- 
From: "tom.petch" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; "JP Vasseur" 
<[email-masked]>; <[email-masked]>
Cc: "Dan ((Dan)) Romascanu" <[email-masked]>
Sent: Friday, February 16, 2007 1:23 PM
Subject: Re: [Pce] WG Feed-back 
requiredondraft-farrel-pce-manageability-requirements-02.txt

>A propos of this initiative, I just saw the I-D below which is operating in 
>the
> same space albeit from a different direction.  It uses the FCAPS model of
> management.
>
> Tom Petch
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> Title : Guidelines forls.

In section 3.3 (Liveness Detection and Monitoring) I have added some words 
to help guide what should be discussed.

In section 3.5 (Requirements on Other Protocols and Functional Components) 
which is also relevant here, I have added a caveat to say that the author is 
not expected to describe the interaction with every protocol, but should 
describe the interactions that are assumed in order to achieve correct 
functioning of the new protocol.

Lastly, in section 3.6 (Impact on Network Operation) I have clarified the 
need for examination of backward compatibility from the perspective of 
network management.

> -- generally speaking, the document should state that manageability
> description shall ideally remain device/implementation independent (of
> course there will be always exceptions)

This is a good point that David Harrington has captured in his I-D. I have 
added some text to the introduction sections.

> -- the document says "3.1 Control of Function and Policy
>
>   This sub-section describes the configurable items that exist for the
>   control of function or policy"
>
> the control of functions - via the protocol elements described in the
> document is important - but the term policy is to vague at which level of
> the policy specification does that section applies

Hmmm. I think that I actually meant "Control of Function through 
Configuration and Policy"

That is, I meant that the document should identify which protocol features 
are controllable through policy. I did not mean that the authors should have 
to describe in this section how the policy is controlled (since there are 
frameworks and architectures to discuss that in general terms).

I have updated this section accordingly.

> -- the document on network operations is important as it forces the writer
> to document the dimensions impacting the protocol deployment nevertheless
> assuming this is the case (taking the example of the doc. the implementer
> is aware of the scaling threat) which mechanism are in place to prevent
> protocol deployment ? i guess this boils down somehow to the RFC 1264
> discussion and ultimately to the usefulness of the doc. not in terms of
> description but actual practice

Thanks for reminding me about RFC 1264 and the discussion that led to it 
being obsoleted. Yes, in time, this I-D may also be found to be overly 
oppressive, inflexible, or out of date. Experience will show. At the moment, 
however, the trend has been to ignore manageability and we are trying this 
experiment to see if we can get things back on track.

By the way, I think section 3.6 (Impact on Network Operation) would benefit 
from some additional work and I would appreciate textual suggestions.

Thanks,
Adrian 

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 27 Feb 2007 12:55:48 -0000

Hi Dimitri,

Quite right.
In fact, the intention is to uncover any issues that might prevent future 
applicability and to unearth any issues that might cause disruptive impacts 
on other [email-masked]>
Date: Tue, 27 Feb 2007 12:55:40 -0000
Organization: Old Dog Consulting
Cc: [email-masked]
Subject: [Pce] Response to Matthew Meyer comments on
	draft-ietf-pce-manageability-requirements-00.txt
Reply-To: Adrian Farrel <[email-masked]>

Hi Matthew,

Just been updating the working group document...

> I wonder if in the 3.x section it might be useful to optionally break out 
> a
> legacy protocol interworking & native backward compatibility implications
> subsection to briefly call attention to their management problem spaces.
>
> I see the topic could fall under '3.5 Requirements on Other Protocols'
> however I perceive from the text of that section that the focus is really
> upon protocols that are impacted or required by the proposed protocol,
> not necessarily older cousins that perform a similar function and might
> pose a manageability problem worth reflecting upon.

Yes, this is a good catch.
I think this forms part of "3.6 Impact on Network Operation" since (we 
presume!) the backward compatibility issues are only relevant if the older 
version of the protocol has actually been deployed.
I have added some words to that section.

Regards,
Adrian

 Considering Operations and Management of New 
> Protocols
> Author(s) : D. Harrington
> Filename : draft-harrington-operations-and-management-00.txt
> Pages : 31
> Date : 2007-2-15
>
>   New protocols or protocol extensions are best designed with due
>   consideration of operations and management issues related to the
>   protocol.  Retrofitting operations and management recommendations to
>   protocols is sub-optimal.  The purpose of this document is to provide
>   guidance to authors of protocol documents about aspects to consider
>   related to the operations and management that should be considered
>   for inclusion in documents defining requirements or functionality of
>   new protocols or protocol extensions.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-harrington-operations-and-management-0
> 0.txt

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 27 Feb 2007 12:55:48 -0000

Hi Dimitri,

Quite right.
on other protocols.

Thanks,
Adrian