The MPLS WG Archive

[Vishal Sharma <vsharma87@yahoo.com>]

Dimitri, Bala,

I agree with your philosopy. Especally the part that points out that there are 
no
semantics associated with an LSP setup via GMPLS signaling, as currently
defined. Therefore, any type of LSP (working, protect, shared, etc. ) can be
established with GMPLS signaling.

The issue of restoration signaling and how to associate LSPs with working or
protection routes is something that can be (and in fact has been; at least in 
the
MPLS, IPO, and TE WGs) worked on in parallel.

In my view, the issue being raised by Chuck, Jerry, Eve, and others wrt 
restoration is
whether the current
signaling specs. should specify restoration signaling as well, and whether it
would be possible to completely isolate restoration signaling from GMPLS-SIG
in such a way that later developments of restoration signaling do not affect
GMPLS-SIG. You've said that you feel strongly that these can be decoupled.

I feel that it might be worth spending some CPU cycles to make sure that
this is the case (or is largely the case), since it saves considerable 
retrofitting
in the future. When we began work on the GMPLS SIG specs. over a year ago,
restoration was only just beginning to surface in the IETF, and it is only in 
the
last 6 months or so that there has be greater focus on it. So it makes sense
to take a little time to examine GMPLS-SIG in the light of this.

As for Jerry's point, I think all he is saying is that over the last couple of 
IETFs,
there have been formal calls by the ADs, Acting ADs, and different WG advisors
to formally obtain SP input on several items (such as restoration, TE best 
practices,
etc.), but this does not seem to have been the case for GMPLS signaling specs.
(Of course, as Eric rightly pointed out, this does not prevent any SP or their
representatives from providing such input.)

Finally, and others can correct me if I am wrong, isn't there  a little bit of
contradiction in the IETF stance with respect to SP input, given that 
(technically) we
all come to the IETF, not as representatives of our companies, but rather
as individual contributors.

If so, I am a little confused about what it means
to ask for SP input? Are we asking for individual contributors from the
SP community, and hoping that they will bring in (by osmosis) the overall 
philosophy
of their company, or are we asking for companies to specifically send
their representatives to provide inputs on certain topics that have been
deemed to require SP input?

ADs, Chairs, any comments or clarifications?

Thanks,

-Vishal

On Monday, May 28, 2001 6:17 AM, Dimitri Papadimitriou 
[SMTP:dimitri.papadimitriou@alcatel.be] wrote:
> Eric,
>
> Don't be so pessimistic...
>
> I think (and as also proposed by Bala) that today LSP
> "provisioning" which is specified within the GMPLS-SIG
> can be associated with working, protection, shared-
> protection LSP etc. Meaning there is not "semantic"
> associated with the LSP established through GMPLS so
> they can be used for any purpose.
>
> "Restoration signalling" which can be implemented in
> many ways is today under discussion. Bala thinks about
> a dedicated lighweight protocol but other solution are
> feasible using current signalling protocol extensions
> or not. The good thing is that an open discussion has
> been today engaged.
>
> I don't see any problem with respect to GMPLS-SIG
> document over there. I strongly believe that the
> restoration issues can be proceeded indepedently
> from the current GMPLS drafts today on last call.
>
> - Dimitri.
>
> "Mannie, Eric" wrote:
> >
> > Hello Jerry
> >
> > >correct, as I mentioned, SPs have been formally asked for their
> > >*requirements*, but not on the GMPLS extensions
> >
> > Sorry ! It is an OPEN process since the beginning, everybody can contribute
> > and write a draft. There is no formal process where requirements from
> > operators are asked for. I am not aware of any IETF rule about that !
> >
> > You were welcome to work with us since 1.5 years but you never came to us.
> > You cannot blame us that you never worked on it (we are not responsible for
> > that)! This is true for the thousands of internet drafts being written at
> > the IETF.
> >
> > It is the responsibility of each company individually to decide if they
> > want
> > to contribute or not ! It is not the job of others companies to go to each
> > possible operator/manufacturer and to lobby to have them involved.
> >
> > Regards,
> >
> > Eric << File: dimitri.papadimitriou.vcf >>