Subject: RE: CR-LDP indicator for network layer protocol

From: "Bilel Jamoussi" <[email-masked]>
Date: Tue, 16 Nov 1999 11:05:10 -0600

Nick,

cr-ldp does not preclude the use of the FEC elements (Type=0x01, 0x02, 0x03)
defined in LDP. Please read section 4.10 of cr-ldp.

Bilel.

-----Original Message-----
From: Nick Weeds [mailto:[email-masked]]
Sent: Tuesday, November 16, 1999 9:22 AM
To: Jamoussi, Bilel [BL3:2001-I:EXCH]
Cc: [email-masked]'
Subject: CR-LDP indicator for network layer protocol

Bilel,

As far as I can see, the CR-LDP Label Request messages doesn't carry an
indicator of the network layer protocol to be carried on the LSP tunnel
being set up.  Is this deliberate?

Background:

*	draft-ietf-mpls-label-encaps-07.txt section 2.2 discusses the need
to determine the network layer protocol for labeled packets, and also
discusses the problem of determining the network layer protocol.  The
general intent is to infer the the network layer protocol from the top
label:
"... the identity of the network layer protocol must be inferable from the
value of the label which is popped from the bottom of the stack,  possibly
along with the contents of the network layer header itself."
To avoid guessing, the LSP setup protocol must carry the network layer
protocol to be carried on the LSP.

*	RSVP includes the network layer protocol (ethertype) in the
LABEL_REQUEST object.

*	LDP implicitly includes the network layer protocol in the FEC TLV
because the FEC element contains the address family (and address families
are closely related to protocols).

*	CR-LDP doesn't include the address family in the CR-LDP FEC TLV, and
doesn't appear to have an alternative mechanism for indicating the network
layer protocol.

Thus it appears the LSRs are left to guess the network layer protocol for
any packet received on an LSP tunnel set up using CR-LDP.

This isn't a problem if we restrict ourselves to IPv4.  With IPv4 and IPv6
it's easy to distinguish the protocol by looking at the IP header.  
However, if other protocols are carried in future then protocol guessing
might be difficult, so it would still be desirable to carry the network
layer protocol id in the CR-LDP Label Request message.

What do you think?  Do you think we should retain a network layer protocol
identifier in the CR-LDP FEC TLV?

Thanks,

	Nick.

> Nick Weeds
> Software Developer
> Data Connection Ltd
> Tel:	+44 1244 313440		Fax:	+44 1244 312422
> Email:	[email-masked]		Web:
> http://www.datcon.co.uk
>

---

From: "Loa Andersson" <[email-masked]>
Date: Tue, 16 Nov 1999 18:13:43 +0100

All,

the opague FEC is opague just because you not supposed to try to
guess the "underlying" protocol.

/Loa

Bilel Jamoussi wrote:
> 
> Nick,
> 
> cr-ldp does not preclude the use of the FEC elements (Type=0x01, 0x02,
> 0x03) defined in LDP. Please read section 4.10 of cr-ldp.
> 
> Bilel.
> 

-- 

Loa Andersson
Director Technology Center, EMEA
St Eriksgatan 115, PO Box 6701
113 85 Stockholm, Sweden
phone: +46 8 50 88 36 34,   mobile + 46 70 522 78 34
e-mail: [email-masked]

---

From: Eric Gray <[email-masked]>
Date: Tue, 16 Nov 1999 12:52:07 -0500

Loa,

	Among other things.  The opaque FEC also eliminates 
the need to specify a FEC for a tunnel when the FEC(s) sup-
ported by that tunnel are numerous, sparsely aggregated, 
frequently changing or just not relevant to the tunnel.  I
believe it's fair to say that some of these may often apply 
in TE.  It's also likely that at least one will always apply
in many VPN architectures.

	In any case, not being able to infer anything about
the MPLS encapsulated data - including what the underlying
protocol is - is a by-product implication of opaque usage.
This can be important if the CR-LSP is being used to carry
non-IP encapsulated voice, SNA, or other message formats and
the CR-LSP includes one or more elements that would like to 
provide load-sharing across multiple local paths.  Failure 
to take this into account may result in randomly re-ordering
messages in some load-sharing schemes.

-- 
Eric Gray		Email: mailto:[email-masked]
Voice: (978)960-6162	Fax: (978)960-1101
In Person:MV 21-2E33	1600 Osgood St., N. Andover, MA 01845