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

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



Vishal,

> > > Finally the phrase "need further feedback" looks not clear, who needs
> > > feedback? -the list or the authors ?-
>
> > Despite the fact that both drafts have been around for some while, the
> > level of discussion on the ccamp list has been quite low.
>
> I think a few clarifications are rather crucial here:
>
> -- The diverse routing draft has, in fact, received significant discussion
> and debate (from all of the people involved in the inter-area work --
> vendors and providers), right during and after Seoul, from March-May 04
> -- please see the CCAMP WG archives for about 60-70-odd emails on it.
> (I'm not sure how one could classify this as "low".)

You're right, there was some thorough debate on the detailed function as described in an
earlier version of the draft, and you have done a lot to address those issues.

What I am missing (but maybe the community doesn't care?) is a higher-level debate about
the methodology to solve what might best be described as a hard problem. In other words,
while it is fine to get into the details of how ARO works and to polish that solution, I
have not seen the debate as to whether we want to adopt ARO.

In order to pursue this, we are now in need of some effort to develop a framework for
inter-domain diverse path computation.

We're now trying to put some text together for this (if it is a small amount of text it
will go into the existing framework draft - if it turns out to be a lot of text it will go
into its own draft). I know that you, Vishal, have volunteered to get the ball rolling and
when I have your text I will add my own (politically correct) spin before putting it out
to the list for debate.

> Draft-decnodder by contrast has seen much less (perhaps 2-3 emails), if any,
> discussion, so clubbing the two drafts in the same category w.r.t. the
> level of discussion doesn't seem appropriate.
> (It has largely come from me and a couple others.)

Yes. It is not as old as a draft, and has seen less debate.

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

> > I also have the impression that the interest in
> >implementation is not (yet) very strong.
>
> I believe implementation interest will pick up once CCAMP formally
> states an intent to look at this problem (as has already happened by the
> structuring of the WG meeting at D.C.).

What I mean is that I do not hear from providers (or vendors) that they are currently
trying to solve this problem in deployed networks. At the moment, they are still
struggling with simple, unprotected inter-AS TE.

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

> A number of the diverse routing/protection etc. drafts are looking
> at different problems (e.g. draft-decnodder is looking at inter-area
> link protection, while draft-dachille is looking at diverse inter-region
> path setup), so it is not clear how a single set of protocol extensions
> would serve?

Do you really mean inter-region? It seems to me that inter-region is really covered by the
region transit work covered in the two MRN drafts. It is relatively unlikely that an LSP
will start in one region and end in another - the encapsulation and adaptation rules to
achieve that don't look nice. But, perhaps someone has a requirement to deploy this?

Adrian