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

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

Adrian,

Great, thanks for the clarification. I do agree that it
seems a terminology issue. In that case, what we mean is
inter-domain.

I think we picked "inter-region" because somewhere along
the line (around Seoul, I think) some discussions occurred
at the IETF and the ML, where it appeared that one should use "inter-region"
to cover both inter-area and inter-AS.

I guess if "inter-domain" is the preferred terminology, we are
happy to do that, since that is what we have meant all along.

Thanks,
-Vishal

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, December 07, 2004 8:06 AM
> To: v.sharma@ieee.org
> Cc: ccamp@ops.ietf.org
> Subject: Re: Draft minutes from Tove:
> draft-dachille-inter-region-path-setup-04.txt
>
>
> Hi,
>
> > Thanks for the observations. I have several things I'd want
> > to discuss with respect to your note below, and will take
> > them one-by-one in different emails to break the discussion
> > down to small, manageable emails that folks can read easily.
>
> Fair enough.
>
> > > > 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?
> >
> > Wait a minute... there seems a fundamental contradiction above.
> >
> > So, first things first ...
> > If what you say is true (that LSPs are unlikely to start in one
> > region and end in another), why are all of us in
> > CCAMP working on inter-region LSP issues?
>
> I think this is just a terminology issue.
> "Region" got stolen by the hierarchy draft.
>    The information carried in the Interface Switching Capabilities is
>    used to construct LSP regions, and determine regions' boundaries as
>    follows.
> draft-ietf-mpls-lsp-hierarchy-08.txt section 7.
>
> This is confirmed in draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
>
> Thus, when trying to consolidate the work within CCAMP I picked
> "domain" which seemed to
> be largely unused around GMPLS. In
> draft-ietf-ccamp-inter-domain-framework-00.txt we
> have...
>    For the purposes of this document, a domain is considered to be any
>    collection of network elements within a common sphere of address
>    management or path computational responsibility. Examples of such
>    domains include IGP areas and Autonomous Systems.
>
> As an aside, nested domains are currently out of scope of
> draft-ietf-ccamp-inter-domain-framework-00.txt because they are
> simply treated using FAs.
> There is, therefore a clear overlap between nested domains and regions.
>
> A
>
>