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

Re: GMPLS in overlay mode



> > > c) the IETF has every right to "bring up" topics that other forums may
> > >         or may not already have discussed, lengthily or otherwise,
> > >         especially when it concerns protocols that the IETF developed.
> >
> > As I recall the OIF discussion, vendors were split over the proposal,
> > and operators indicated strongly that their needs were better addressed by
> > the ongoing UNI and NNI work.
> 
> That's useful information.  However, it does not mean that we shouldn't
> discuss it in the IETF; nor on the other hand does it mean that we (the
> IETF/CCAMP WG) cannot learn from the OIF experience.

Percisely.  Just because a particular set up users do not find a
that a particular approach does not meet their needs does not mean
that the approach is not useful to some other set.  In this particular
case I have had *no* EFTs for the OIF-UNI (code has been available for
over a year).  I have a number of EFTs using GMPLS signalling without
GMPLS routing which is essentially what the draft is about.  It simply
clarifies some things that have been hacked so that we have a standard
approach.  

> > Certainly it would make sense for IETF to take up a proposal that another
> > standards body had rejected IF they are trying to address a different market
> > or application for which this proposal might be an appropriate solution.
> 
> Let me re-iterate: the OIF is *not* a standards body.
> 
> Furthermore, if I understood the authors correctly, there *are* addressing
> a different application.

The OIF-UNI assumes a very low trust model.  The internals of the
network *must* be hidden.  Addressing must be seperable.  Requests for
a specific path are not allowed.

In a setting where the boundry between an edge-node and a core-node
has a higher trust level, you can permit more things.

> > When I suggested that a requirements document might be the correct first
> > step here during the meeting, one of the authors described this as a stalling
> > tactic. What I had in mind was to use this as a time saving tactic:
> 
> The "overlay" document essentially describes a *mode* of using GMPLS.
> There are no major extensions; there are a few procedural changes.  It
> is basically a clarification document that says that GMPLS (which many
> just assume can only be used in "peer" mode) can in fact be used in
> an overlay context.
> 
> A call for consensus to make this a WG document should indicate whether
> folks think this is useful or not.

I might add that the *useful* means
useful-for-some-segment-of-the-market and not just useful-for-me.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824