Subject: GMPLS features applicable to MPLS

From: David Charlap <[email-masked]>
Date: Thu, 21 Nov 2002 11:52:53 -0500

During the course of development, I have noticed that there are several 
features of generalized-RSVP (draft-ietf-mpls-generalized-rsvp-te-09) 
that are applicable to non-generalized MPLS networks.

Two immediately come to mind:

1: Support unnumbered links in explicit routes (as defined by 
draft-ietf-mpls-rsvp-unnum-08) which requires as a prerequisite, support 
for the IF_ID versions of the HOP and ERROR_SPEC objects (section 8)

2: Fault handling and restart capabilities (section 9)

Right now, in order to provide thse features in an MPLS switch, one must 
either use a proprietary solution, or must attempt a partial 
implementation of GMPLS for the MPLS environment.

What should be done about this?  I don't think it's appropriate to 
simply tell people "use GMPLS or do without the features".

Perhaps a section on applicability to MPLS networks can be added to the 
relevant GMPLS drafts?  Or perhaps those sections of GMPLS that are also 
applicable to MPLS should be broken off into separate drafts?

Opinions?

-- David

---

From: Nabil Seddigh <[email-masked]>
Date: Thu, 21 Nov 2002 12:04:53 -0500

David, 

This is an excellent point that must surely be a source of concern
to many! It is certainly an issue that has been raised before on
this mailing list.

For various reasons, the authors did not wish to undertake
the effort required to change the current drafts.

Unnumbered links & graceful restart are not specific to gmpls
and I never understood the rational for rolling them into
the gmpls drafts. IMHO, it is better to remove the content in 
2 separate drafts. 

However, if this is too much work for the authors at this 
point then approach of an "MPLS-applicable" section in the 
GMPLS drafts may be a suitable compromise.

Best,
Nabil Seddigh
[email-masked]

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 21 Nov 2002 14:33:02 -0800 (PST)

Hi David,

> that are applicable to non-generalized MPLS networks.

There are those who refer to generalized and non-generalized MPLS
networks, those who talk about GMPLS and classical MPLS, etc.

I would prefer to view this at two levels:
  o (A) generalized signaling and (B) non-generalized/classical signaling
  o (i) non-packet and (ii) packet LSPs (or MPLS networks)

(A) can be used for both (i) and (ii)
(B) can be used for (ii), but does rather poorly for (i)

If an applicability statement is needed to say this, so be it.

Kireeti.

---

From: Loa Andersson <[email-masked]>
Date: Thu, 21 Nov 2002 21:12:21 -0500

All,

let me see if I understand this correctly.

I think that the general problem is -given the definitions by Kireeti
below - that:

- something specified in a ccamp spec makes perfect sense
   for something in vanilla ;) mpls (using signaling type B)

- the ccamp spec specifies more than what is needed (makes sense) for
   the vanilla mpls that has to be implemented to comply to the with the
   spec

Then the issue is, how do we handle this?

Is this the background for the question? If so, I can see several
ways of doing things

- split documents, one mpls and another ccamp one, where the ccamp
   include the mpls doc (by reference)
- do it by applicability statements, from the mpls side saying "what is
   specified in the ccamp if doc is a great idea, but if you apply it to
   packet mpls you don need to implement ..."
- include info in the ccamp doc on what is needed in packet mpls

/Loa

-- 
     /Loa

     Loa Andersson
     Utfors AB
     Råsundavägen 12
     Box 525, 169 29 Solna
     Mobile          +46 70 848 5038
     Email           [email-masked]

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 21 Nov 2002 19:56:01 -0800 (PST)

Hi Loa,

>    the vanilla mpls that has to be implemented to comply to the with the

and sometimes less than what is needed.

CCAMP's charter is to produce specs that apply across a multitude
of technologies, *one* of them being MPLS.

>    include the mpls doc (by reference)

Excellent idea: CCAMP produces the COMMON document, MPLS refines it
to tailor it to MPLS.  Actually, this was the idea all along.

Important change: the mpls doc cites the ccamp doc, not vice versa.

Case in point: CCAMP produces a spec for (symmetric bw) bidirectional
LSPs.  You *can* signal a bidir LSP in MPLS with that.  However, you
can't do MPLS LSPs with fast reroute (as George pointed out).  That's
where the second *MPLS* document (check charter first!) that builds
on the CCAMP doc comes in.  However, a document that does bidir LSPs
*another* way helps no one.

>    packet mpls you don need to implement ..."

That would be fine, if no protocol changes/additions are needed.

> - include info in the ccamp doc on what is needed in packet mpls

We've spent a lot of time removing technology-specific work from the
COMMON specs.  I don't think we want to go this way.

Kireeti.

---

From: David Charlap <[email-masked]>
Date: Thu, 21 Nov 2002 15:30:54 -0500

jeff pickering wrote:
> Also note that there is a history of this since the hellos in rfc3209 are
> not specific to rsvp-te either.

I remember that discussion.  But it's not quite the same.

RSVP-Hello was originally introduced in the Refresh Reduction draft. 
The working group elected to get rid of it, on the grounds that Hellos 
change the fundamental nature of RSVP from soft-state to hard-state.  It 
was adopted MPLS working group (and incorporated into RSVP-TE) because 
the RSVP working group had rejected it.

Without rehashing the merits of that decision, I'd just like to point 
out that this situation is a bit different.

A parallel situation would be if unnumbered links and restart capability 
were proposed as a part of RSVP-TE, and were then rejected by the MPLS 
working group, and then adopted by CCAMP for use in generalized-RSVP-TE.

But to my knowledge, it didn't go this way.  As far as I know, these 
extensions were originally created as a part of the generalized-RSVP-TE 
work.  And that's fine.  Any group that develops something useful should 
be able to do so.  But now that these features are designed, and they 
are seen as desirable in the non-generalized architecture, the question 
is how (if at all) they should be ported to that architecture.

-- David

---

From: David Charlap <[email-masked]>
Date: Fri, 22 Nov 2002 10:02:28 -0500

>   the vanilla mpls that has to be implemented to comply to the with the

This was my original question.

> - include info in the ccamp doc on what is needed in packet mpls

Any one of these would be fine for me.  My main concern here is that 
MPLS vendors will start implementing those features, and some may ignore 
the GMPLS approach, thinking that those drafts are not applicable to 
non-generalized MPLS.  This may lead to interop issues.

Of course, vendors often ignore drafts anyway, but at least this way 
they'll know that there is something out there that they can choose to 
implement or ignore.  And those that need to pull pieces of GMPLS into 
their MPLS implementations will know how much must be pulled in to 
properly support the features under development.

-- David

---

From: Rohit Dube <[email-masked]>
Date: Fri, 22 Nov 2002 14:21:27 -0500

On Fri, 22 Nov 2002 10:02:28 -0500 David Charlap writes:
[snip]
=>Any one of these would be fine for me.  My main concern here is that 
=>MPLS vendors will start implementing those features, and some may ignore 
=>the GMPLS approach, thinking that those drafts are not applicable to 
=>non-generalized MPLS.  This may lead to interop issues.
=>
=>Of course, vendors often ignore drafts anyway, but at least this way 
=>they'll know that there is something out there that they can choose to 
=>implement or ignore.  And those that need to pull pieces of GMPLS into 
=>their MPLS implementations will know how much must be pulled in to 
=>properly support the features under development.

Excellent points David. And in fact this is what happened with the 
"bidirectional lsps for classical mpls" draft that I presented at the
IETF. 

A quick solution is needed for this class of problems!

Regards,
--rohit.

---

From: Lou Berger <[email-masked]>
Date: Thu, 21 Nov 2002 22:29:10 -0500

GMPLS applies to packets as well.  It seems that all that is need here is 
an explanation (app note) of how to use gmpls with packets.  This should be 
a short document...

(it just takes using the new label request and label object...)

Lou

---

From: jeff pickering <[email-masked]>
Date: Thu, 21 Nov 2002 14:57:39 -0800

Jeff

---

From: Marcus Brunner <[email-masked]>
Date: Mon, 25 Nov 2002 15:43:33 +0100

> If an applicability statement is needed to say this, so be it.

Yes, IMHO GMPLS was always sort of a version 2 of MPLS being backward 
compatible with version 1 (MPLS) still runs for packet space, but extensted 
to be useful for other technologies.

Might be a good idea to write down the applicability of GMPLS to packet 
networks.

Marcus

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
personal home page: http://www.brubers.org/marcus

---

From: [email-masked]
Date: Mon, 25 Nov 2002 17:30:00 +0100

Hi all,
I support the idea that by definition GMPLS is a superset of MPLS.
It makes sense to have a document that clarify the applicability of GMPLS for
Packet LSPs (and also for L2LSPs –ATM/FR/Eth…- ?).
We may also consider their future integration.

regards

Emmanuel

---

From: Nabil Seddigh <[email-masked]>
Date: Mon, 25 Nov 2002 11:55:57 -0500

Lou, 

In theory, GMPLS is supposed to encompass MPLS and packet-based
devices as well. In practise, there appears to be a clear 
demarcation between MPLS & GMPLS. This is further confirmed
by industry usage of GMPLS for application to optical systems.

The best approach would have been to denote the lowest common 
denominator objects as part of MPLS and other extensions as GMPLS. 
This I believe was David's point wrt to Hitless Restart and 
Unnumbered Links which could be used with the packet MPLS 
defined today. Not doing so causes some confusion.

Let me try to illustrate with one example. Using 3rd party stack 
source vendors is becoming more and more commonplace. Such vendors 
would offer GMPLS & MPLS as separate code offerings. In order to 
implement a packet-based MPLS device that supports Hitless Restart
& Unnum Links, they would need to purchase and integrate an
entire GMPLS stack which their device does not otherwise
require.

Best,
Nabil Seddigh

---

From: Ping Pan <[email-masked]>
Date: Mon, 25 Nov 2002 09:00:34 -0800

Hmmm... have to bite now. Who is confused here? The carriers? Don't 
think so. They know exactly which feature to have in their networks. The 
developers? Don't think so either. They know what can and cannot be 
implemented. So if we have enough solutions floating around in various 
drafts and RFC's. Why write more document?

- Ping

---

From: David Charlap <[email-masked]>
Date: Mon, 25 Nov 2002 12:26:14 -0500

> drafts and RFC's. Why write more document?

Because the developers implementing these features for MPLS switches are 
not necessarily going to do it in the GMPLS way.  They may very well 
review the available documents and conclude "unnumbered links are only 
specified for GMPLS and not MPLS, so we're free to pursue a proprietary 
solution for our MPLS products."

-- David

---

From: Nabil Seddigh <[email-masked]>
Date: Mon, 25 Nov 2002 13:03:16 -0500

Ping,

You make a good point. This discussion is about document organization.
Nothing earth shattering. This would not be important except that
in some ways the world has changed.

No longer do we have only a handful of implementations
of a particular protocol - all being done by folks who work 
in 2 or 3 companies. Protocols are being implemented by 
an increasing number of companies with development in many parts
of the world other than North America.

Having well organized content simply makes lives easier for
future developers. In this particular case, it also has clear
implications on $ and code creep - see my previous email.

Ideally, the Hitless Restart content & Unnumbered Links content
should have remained separate content applicable to MPLS.
Otherwise the next best compromise is an applicability
statement draft.

Best,
Nabil

---

From: [email-masked]
Date: Mon, 25 Nov 2002 19:57:09 +0100

well if there was no confusion, the question would have
been why such e-mail exchanges, imho they translate the
need for consolidating the various work performed in
different wg after two years of sustained sup-ip area
efforts,... in any case such i-d's won't hurt whose that 
knows but certainly help in moving forward (taking here a
broader perspective) with these efforts

- dimitri.

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 25 Nov 2002 14:27:44 -0800 (PST)

Hi Nabil,

> the effort required to change the current drafts.

There is an infinitude of ways that people can misunderstand,
misinterpret and misimplement specs.  There isn't enough time to
set everyone straight.  Besides which, the drafts are fine; what
*might* be needed is an applicability statement.

> Unnumbered links & graceful restart are not specific to gmpls

Can you explain to me "specific to Generalized MPLS"?  If you do,
I will write the applicability statement myself :-)

> the gmpls drafts. IMHO, it is better to remove the content in

Unnumbered *is* a separate draft!  (... as is LSP hierarchy, before
someone says that hierarchy is specific to GMPLS.)

> GMPLS drafts may be a suitable compromise.

Authors tend to get so into their work that they cannot always see
that some topics are confusing.  It is then up to *someone else*
with a *new* point of view to write the app statement (not the
authors), especially when the authors themselves think such
statements are not needed.

Kireeti.

---

From: Nabil Seddigh <[email-masked]>
Date: Tue, 26 Nov 2002 12:28:19 -0500

Hi Kireeti,

> I will write the applicability statement myself :-)

I replied to this in a previous post and I think others on this
thread essentially said the samething.  Box & stack vendors 
typically like to implement all of a draft. It is much easier and
more interoperable than picking and choosing sections from a 
variety of drafts. As for an applicability draft, the thoughts
are clear in my head even if it is not being expressed clearly 
via email. If there is interest, I could put something together.

There's a lot of new spec (objects & behavious) in the gmpls drafts 
(functional & signaling) that many plain router vendors or router 
stack vendors  would not implement - ie no desire to configure 
optics or tdm via signalling. Yet the unnumbered link & 
hitless restart features may be of interest to such vendors. 
It would be nice if they didn't have to wade through GMPLS docs
too extract this info.

> Unnumbered *is* a separate draft!  (... as is LSP hierarchy, 
> before someone says that hierarchy is specific to GMPLS.)

True enough. However, part of section 9.1 of 
http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-09.txt
contains content that's not in the unnum draft and which 
would be incorporated by someone implementing the unnum draft.

Best,
Nabil