RE: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt

["Vishal Sharma" <v.sharma@ieee.org>]

Adrian,

A few last comments on your note ...

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, December 07, 2004 4:19 AM
> To: v.sharma@ieee.org; Ugo Monaco
> Cc: ccamp@ops.ietf.org; Alessio D'Achille; Daniele Alì; Marco Listanti
> Subject: Re: Draft minutes from Tove:
> draft-dachille-inter-region-path-setup-04.txt
>

<snip>

> > So, I think we need to be a bit careful when evaluating the extent of
> > discussion.
> >
> > -- There was also significant discussion of this subject in San Diego --
> > cf. the CCAMP WG meeting minutes again.
> >
> > Since it was then clearly stated that CCAMP WG would focus on
> the "simple"
> > TE aspects first, with diverse routing deemed an "advanced" subject, so
> > naturally for a short while there wasn't much that could be done in
> > this area, as people began focussing on the "simple" aspects.
>
> Yes. That's good, isn't it?
> And now we are ready to move on to the diverse path issues and so
> it is appropriate to
> open up the discussions.

Sure, I agree that it is good to discuss the subject again now.

(Although, the conclusion at San Diego, did put a bit of a damper
on work in this area, at least in so far as discussion on CCAMP goes.
Of course, that did not actually stop progress on the work, as is
evident from the additional simulation results presented during
the presentation of draft-dachille in D.C. last month.)

<snip>

> > >As the working group moves on to specify the problem space that we
> > >are trying to resolve, I hope that we will see more debate about the
> > >possible solutions with a view to arriving at a single set of protocol
> > >extensions.
> >
> > I'm not clear on what is meant by your statement above.
>
> I mean that we should aim to have a single protocol solution if
> it can be applied to a
> wide variety of scenarios, rather than a set of different
> protocol extensions that are
> applicable to specific subsets of the problem. Perhaps, in answer
> to your point below, it
> is not clear why a single set of protocol extensions could not be
> found to serve in both
> (all) cases. If that means that neither of the existing drafts is
> sufficient, that sits
> well with me.

I agree that the fewer enhancements to a protocol we make the
better it is. However, we have to also keep in mind that some
of the drafts (in particular, draft-dachille and draft-decnodder)
are solving somewhat different problems, so it may be infeasible to
find a single extension to serve both cases.

That is, the single extension may end-up being more complicated than
two different extensions (which might be simple and easily decomposable
based on the specific application each addresses).

I don't think having different extensions/enhancements is by
itself a bad thing,
as long as we are not trying to achieve the exact same thing by two
or more means.

The different extensions may not all be used at the
same time, and may serve distinct functions, so they don't overload the
signalling protocol.

-Vishal