Subject: [PWOT] mpls-in-ip

From: "tom worster" <[email-masked]>
Date: Tue, 27 Feb 2001 11:37:33 -0500

i'd like to ask the to-be-working group three questions 
relating to this draft (it should show in the repository
soon, a url is given below):

1) is an mpls lsp an example of a "pseudo-wire?"

2) can ip be regarded as "transport?"

3) should mpls-in-ip be a standards track work item for
pwot?

in which the terms pseudo-wire and transport express the 
scope of the wg.

my opinions are.

1) yes. if an atm connection, frame relay connection, 
ds1 or oc3 are considered pseudo-wires then i think
an mpls lsp can reasonably be considered a pseudo-wire.

2) yes. the usage of "transport" in the pwot group seems 
to be more general than other uses. if mpls (which is a
sub-ip protocol) is a transport protocol along side tcp,
udp, rtp (which are all super-ip), etc., then i don't
see why ip can't also be regarded as providing transport.

3) if i'm right on the above two points then i think
pwot would the right place to write a standard 
encapsulation of mpls in ip, should the ietf want such 
as standard.

http://thefsb.org/draft-worster-mpls-in-ip-03.txt

c u
fsb

_______________________________________________
pwot mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/pwot

---

From: Dan Tappan <[email-masked]>
Date: Tue, 27 Feb 2001 12:00:11 -0500

>encapsulation of mpls in ip, should the ietf want such

Well, my first reaction was that it's a stretch.

On the other hand I'd agree that defining a standard for MPLSinIP and/or 
documenting MPLSinGRE is a "good thing". And if there isn't another working 
group where it fits, Tom's reasoning below isn't totally outrageous.

Certainly this group seems to be intended to cover both
- tunneling X in MPLS
and
- tunneling X in IP
so
- Tunneling X in MPLS in IP
might be a natural leap.

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 27 Feb 2001 11:12:48 -0800 (PST)

> should mpls-in-ip be a standards track work item for pwot?

Isn't this a solved problem?  MPLS in GRE is trivial, implemented
and raring to be interop tested.

Kireeti.

---

From: Alan Hannan <[email-masked]>
Date: Tue, 27 Feb 2001 11:31:57 -0800

> 1) is an mpls lsp an example of a "pseudo-wire?"

  yes

> 2) can ip be regarded as "transport?"

  yes

> 3) should mpls-in-ip be a standards track work item for

  sure

> encapsulation of mpls in ip, should the ietf want such 

  general agreement from this vector.

---

From: "tom worster" <[email-masked]>
Date: Tue, 27 Feb 2001 14:51:12 -0500

From: Kireeti Kompella [mailto:[email-masked]]
> and raring to be interop tested.

from what i've heard, the extra overhead is not
tolerable in some important apps, e.g. voip
and 3g. but over the core gre is an option.

c u
fsb

---

From: Alan Hannan <[email-masked]>
Date: Tue, 27 Feb 2001 12:07:41 -0800

Tom,

Thus spake tom worster ([email-masked])
> and 3g. but over the core gre is an option.

  Does your statement assert that all important
  applications are not tolerable using IP/MPLS/GRE/*
  or just some?

  -alan

---

From: "tom worster" <[email-masked]>
Date: Tue, 27 Feb 2001 18:07:49 -0500

>   applications are not tolerable using IP/MPLS/GRE/*

like i thusly spake, some.

c u
fsb

---

From: Eric Rosen <[email-masked]>
Date: Wed, 28 Feb 2001 09:25:10 -0500

> 2) can ip be regarded as "transport?" 

I'm  not sure this  is the  right approach.   If we  follow this  out, those
brainiacs in  the IESG are  likely to tell  us that the  MPLS LSP has  to be
carried as a VC in something like draft-martini-l2circuit-encap-mpls-01.

---

From: "tom worster" <[email-masked]>
Date: Wed, 28 Feb 2001 11:28:40 -0500

From: Eric Rosen [mailto:[email-masked]]
> draft-martini-l2circuit-encap-mpls-01.  

i'm not comfortable with the reasoning that a proposal
is not right because the superintendents of the wg
might interpret it the wrong way and come up with
some funny ideas. i think it would be more customary 
for the wg to decide what it would like to do
(within the context of its charter) while assuming
that the wg superintendents are reasonable.

it seems that the potential problem you mention is 
perhaps more a communication issue than a technical 
one.

c u
fsb