[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



And, I should add, that the only protocol "extension" that
draft-dachille requires is an ARO object, which is cloned
after the ERO object, and can simply be "flipped" to form
the ERO object of the second (diverse) path when setting
up that path.
(As was illustrated in the fig. on slide 3 of the D.C.
presentation.)

-Vishal

> -----Original Message-----
> From: Vishal Sharma [mailto:v.sharma@ieee.org]
> Sent: Monday, December 06, 2004 10:22 PM
> To: Adrian Farrel; Ugo Monaco
> Cc: ccamp@ops.ietf.org; Alessio D'Achille; Daniele Alì; Marco Listanti;
> Tove Madsen
> Subject: RE: Draft minutes from Tove:
> draft-dachille-inter-region-path-setup-04.txt
>
>
> Hi Adrian,
>
> Some comments, observations, and questions in-line
> in two successive emails.
>
> Here's the second ...
>
> -Vishal
>
> > -----Original Message-----
> > From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> > Sent: Saturday, December 04, 2004 10:40 AM
> > To: Ugo Monaco
> > Cc: ccamp@ops.ietf.org; Vishal Sharma; Alessio D'Achille; Daniele Alì;
> > Marco Listanti; Tove Madsen
> > Subject: Re: Draft minutes from Tove
> >
>
> <snip>
>
> > (draft-ietf-tewg-interas-mpls-te-req-09.txt), in particular is in
> > accordance with Section:
> >
> > 5.1.1. Inter-AS MPLS TE Operations and Interoperability
> > 5.1.5.  Re-optimization
> > 5.1.8. Scalability and Hierarchical LSP Support
> > 5.1.11. Extensibility
> > 6. Security Considerations
> >
> > This was also the basis on which we got some good feedback
> > from the service provider community in the extensive discussions
> > before, during, and after Seoul.
> > May be we need to better point out this issue in the next version of the
> > draft.
> >
> > 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".)
>
> 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.)
>
> 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.
>
> > 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.).
>
> > 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.
>
> 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?
>