[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Moving forward with the CCAMP charter



Adrian Farrel wrote:

i would consider the saturarion document and probably cluster it with
the set of items on "deployment/advices/BCPs/etc."


Well, the control plane saturation I-D defines new protocol procedures and
encodings so it needs to be standards track if we do it.

Thus my response to JP.

i am fine with a category "control plane robustness" separated from the one mentioned here below

note: however, i am not necessarily sure that the type outcome must be driver for classification e.g. the saturation document is an outcome of practicing RSVP-TE with mechanisms such as soft-provisioning

If you are raising a new category of work (and I know you commented on
this in Paris) for deployment/advices/BCPs/etc. I would appreciate it if
you could:
- compare what you want with "Interoperability reports and advice"
- suggest some I-D titles that you might
   - want to see
   - be willing to work on (note, these two categories do not have to
overlapping)

yes, for the time being i think that two major topics are falling in this category:
1) TE link operation(s) and processing practices (which is at the end what makes GMPLS) is a typical topic that would require further development
2) inter-domain relationship(s)/exchanges and admission control policies

there is an item on "OAM Requirements for GMPLS Networks" with a
lifetime of around 18 months, while it is difficult to have a detailed
view on them wouldn't be advisable to think upon starting an item mid of
next year where details (could be info) would be put together


I think there is some detail missing from your suggestion. I think you are
saying that we should plan to start developing solutions to meet the OAM
requirements that we will document. This sounds very good, but I am
unwilling to insert a milestone without knowing what we are going to work
on or whether anyone has any intention of doing the work or developing the
software.

this is the reason why i did myself tried to position the requirement document (it is the same reasoning at the end) it is also clear that such a topic would benefit from more operational feedback on GMPLS network operation(s)

I would suggest that this is an item that we should monitor and know that
the chairs are likely to look favorably on solutions work that meets the
requirements.


ok

In the back of my mind, however, is the tunnel trace I-D which lies in a
coffin with a stake through its heart. Not because there weren't
requirements (we have an RFC documenting the requirements) and not because
no-one wanted to write the I-D (we had several authors), but because
no-one wanted to implement.

reason why it may be advisable to have a better view on the "toolset" that would be valuable for operating GMPLS networks (bottom-up)

several questions

>     - ASON Routing solutions
>       * first version of WG draft
>       * submit for IESG review

-> does this mean you envision a single document for IS-IS and OSPF
(note i hope these can be submitted to the IESG by 2Q'06 instead of
October 2006) also cross-WG review period should be considered

Not clear that a BGP draft isn't needed too! 

a complete response to this question would deserve an I-D by itself ;-)

These are generic milestones (I have already proposed too many
milestones!).
If the changes are tiny and use existing TLVs then a single I-D will
probably do.
Otherwise, one I-D per protocol.


ok

> Mar 06 First version of WG informational I-D Aligning GMPLS protocols
across the standards bodies

and

>     - Aligning GMPLS protocols across the standards bodies
>       - Information I-D not intended for publication as an RFC
>       * first version of WG draft

-> what the first sub-bullet implies ? note that i do not see other
specific milestone(s) for this document while the second sub-bullet
refers to a WG I-D ?


Yes. We need to drive closer alignment between the various uses of GMPLS
protocols across the standard bodies. In order to colate our thoughts and
direct discussions in and out of CCAMP we will need to document our ideas
in an I-D. Because we wish to demonstrate CCAMP community cohesion behind
our thoughts, this will need to be a WG I-D (hence the milestone and
starred bullet).

the objective is sensible and i also think valuable to have such common view been written down

However, it is far from clear that the I-D will need to progress to RFC.
After all, once we identify the actions that are needed, we will carry out
the actions. We will then need to update the I-D for further actions etc.

If, on the other hand, the I-D turns out to document longer-term or
ongoing procedures (like the GMPLS change process) we will certainly need
to progress the I-D.

so, this document is meant to be a "process" I-D; therefore, its progress is indeed dependent on action lines that are to be documented

> Mar 06 Submit GMPLS routing and signaling interoperability advice I-D
for IESG review

-> do you have more details on this specific work item 

Not completely sure. It seems to me that if we are doing stuff for
signaling, we should also do it for routing. It is possible that this
folds natrually into the existing signaling (addressing) I-D. Hence this
milestone depends on the work item...


i see now to what you are referring to

note: i would also suggest focusing the below reference i-d on addressing space setting and processing practices (as the name indicates)

    Interoperability reports and advice
    - signaling and routing
      - already have draft-ietf-ccamp-gmpls-addressing-01.txt
      * submit for IESG review

thanks for the hard work, 


You're welcome.
Thanks for the support.

Adrian



.