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

From: Nick Weeds <[email-masked]>
Date: Tue, 16 Nov 1999 17:55:31 -0000

Bilel,
 
This partially addresses the issue, but I don't think it is a complete
solution.
 
FEC types 0x01,0x02,0x03 have definite semantics which go beyond merely
specifying the network layer protocol.  If we intend to "borrow" one of
these FEC types to specify the network layer protocol alone, we should
specify how it should be done.  One possibility would be to use an address
prefix FEC with prefix length 0.
 
If we do intend to use one of the existing FEC types in preference to the
CR-LDP FEC type, we should make this clear.  Unless we explain the intended
use of FEC types and the corresponding inferences about the network layer
protocol, it's very unlikely that consistent usage will emerge.  Without
consistent usage, you're really just left to "guess" the network layer
protocol, which is the difficulty we started with.
I do completely accept that for the moment nobody's interested in protocols
other than IPv4. Should we just "guess" IPv4 and leave other network layer
protocols for further study?  I really don't have a strong objection to
that.  I raised the question because (1) I didn't know whether that was your
intention and (2) the removal of the network layer protocol identifier from
the CR-LDP FEC could very well have been unintended.

    Nick.

-----Original Message-----
From: Bilel Jamoussi [mailto:[email-masked]]
Sent: 16 November 1999 17:05
To: Nick Weeds
Cc: [email-masked]'
Subject: RE: CR-LDP indicator for network layer protocol

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] <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 <http://www.datcon.co.uk>  
>

---

From: Eric Gray <[email-masked]>
Date: Tue, 16 Nov 1999 13:22:57 -0500

Nick,

	See below

You wrote:
> Bilel,
>  
> This partially addresses the issue, but I don't think it 
> is a complete solution.
>  
> FEC types 0x01,0x02,0x03 have definite semantics which go 
> beyond merely specifying the network layer protocol.  If 
> we intend to "borrow" one of these FEC types to specify 
> the network layer protocol alone, we should specify how 
> it should be done.  One possibility would be to use an 
> address prefix FEC with prefix length 0.

This is a bad idea in general.

>  
> If we do intend to use one of the existing FEC types in 
> preference to the CR-LDP FEC type, we should make this 
> clear.  Unless we explain the intended use of FEC types 
> and the corresponding inferences about the network layer 
> protocol, it's very unlikely that consistent usage will 
> emerge.  Without consistent usage, you're really just 
> left to "guess" the network layer protocol, which is the 
> difficulty we started with.

I disagree, as pointed out in separate mail.

> 
> I do completely accept that for the moment nobody's 
> interested in protocols other than IPv4. Should we just 
> "guess" IPv4 and leave other network layer protocols for 
> further study?  I really don't have a strong objection 
> to that.  

I do.

> I raised the question because (1) I didn't know 
> whether that was your intention and (2) the removal of 
> the network layer protocol identifier from the CR-LDP FEC 
> could very well have been unintended.

It was not.

-- 
Eric Gray

---

From: Srinivasan Balaji <[email-masked]>
Date: Wed, 17 Nov 1999 12:16:29 -0500

Folks,
  I wasn't sure whether this thread has been put to
rest, but wanted to give my 2c if we are looking to
solve the problem.
  We can do something similar to what is done
in ATM signaling, i.e. carrying an object which
indicates one of two things :
   a. A value indicating the 'upper layer
packets type' in the LSP (IPv4, voice,FR, IPv6,
VPN packets,.....)
   b. Or, a value indicating that LLC multiplexing
will be used in the packets sent on the LSP. We
can keep coming with Protocol IDs for newer
applications like VPNs which can then have more
sub-headers identifying VPNIDs and then its own
protocols etc. For existing protocols the existing
header can be used (RFC 1483).

  We know that mandating just one type of packets
in the LSP may not be very beneficial in all cases, having
the flexibility will definitely help.

Thanks
Balaji.

--
  -----------------------------------------------------------------
  Srinivasan Balaji
  Ficon Technology
  Voice : (732) 283-2770 xtn.303
  Fax   : (732) 283-2848
  mailto:[email-masked]
  Web   : http://www.ficon-tech.com
  -----------------------------------------------------------------