Subject: RE: bridging over mpls

From: Kireeti Kompella <[email-masked]>
Date: Tue, 23 Nov 1999 10:03:59 -0800 (PST)

> Isn't this "agreement" something we need to look at?

Yes, but not necessarily in the MPLS encapsulation document.
This agreement can set up using another 'signalling' protocol.

A fine example is BGP MPLS VPNs, where the basic LSP is just a
transport that can have IP traffic, VPN traffic that has a nested
(stacked) label to identify the VPN, or perhaps even other kinds
of traffic.  The nested labels are 'signalled' using BGP, which
crafts the end-to-end 'agreement' as to what is contained beyond
the nested label.

In effect the nested label acts as both a protocol demux and an
identifier ("X: VPN traffic for VPN x"; "Y: voice data for voice
gateway y"; ...).  Since you anyway need a signalling protocol to
allocate/distribute these labels, a SNAP header is redundant (but
see below).

> Of course it's fine to say that it is a configuration issue or an
> implementation issue, but that doesn't seem to solve the interoperation
> issues that will arise.

The interoperation issue is strictly between the endpoints of the
LSP: all the intermediate routers just forward MPLS frames.

> If my ingress sets up two tunnel LSPs one for IP traffic and one for (say)
> tunneled Ethernet (or IPX, or Voice) how will the egress know which tunnel
> is which?  How will it know how to handle the payload?

In the case of 'dedicated LSPs', one for each traffic type, in-band
signalling (or a SNAP header) makes perfect sense.  However, with
such a scheme, the number of signalled LSPs could become an issue,
which is why treating signalled LSPs as just transport is also needed.

Kireeti.

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 23 Nov 1999 20:23:22 +0200 (EET)

> allocate/distribute these labels, a SNAP header is redundant (but

it is redundant in the case where the lsp carries packets belonging to
only one protocol (vc muxing in rfc1483), but is needed if the same lsp
carries packets of multiple protocols (llc/snap encap in rfc1483).

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 23 Nov 1999 20:32:33 +0200 (EET)

> This agreement can set up using another 'signalling' protocol.

yes, i'm not proposing to include the signaling issues into the mpls
encap document.  those can and should be covered in ldp, bgp,
etc. signaling documents.  it is enough that the encap document
recognizes the fact that the protocol carried in the mpls payload can be
anything and that the receiver can determine the protocol of the payload
either from the label (one protocol per lsp) or from a multiplexing
header placed in front of the packet in the payload (many protocols per
lsp).

-- juha

---

From: Eric Rosen <[email-masked]>
Date: Tue, 23 Nov 1999 13:55:36 -0500

Juha> it  is enough that  the encap  document recognizes  the fact  that the
Juha> protocol carried in the mpls payload can be anything

Certainly the  verbiage in the encaps  doc needs to be  slightly reworked to
indicate that the payload is not necessarily a "network layer" packet. 

(Presumably no one is actually refusing to implement layer 2 payloads on the
grounds  that the encaps  spec only  mentions network  layer payloads.)

Juha> and that the receiver can determine the protocol of the payload
Juha> either from the label (one protocol per lsp) or from a multiplexing
Juha> header placed in front of the packet in the payload (many protocols per
Juha> lsp).

I would tend to make the latter  case a subcase of the former by saying that
one of the possible payload protocols is SNAP/SAP encapsulation (or whatever
your favorite multiplexing protocol is).

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 23 Nov 1999 21:01:16 +0200 (EET)

> your favorite multiplexing protocol is). 

fine, juha

---

From: Grenville Armitage <[email-masked]>
Date: Tue, 23 Nov 1999 11:06:21 -0800

Eric Rosen wrote:
	[..]
> your favorite multiplexing protocol is).

I tend to agree with Eric here that once the encaps doc allows the
LSP to carry any 'layer' PDU, the ability to mux different L3 PDUs
naturally falls out from the case where the LSP is carrying L2 PDUs.
Such an observation would be minimal and sufficient change to the
encaps document.

cheers,
gja