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

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

Loa,

This seems to contradict draft-ietf-mpls-label-encaps-07.txt section 2.2,
which points out that there are cases where an LSR needs to know the network
layer protocol.
- When packets exit the LSP tunnel, they have to be processed by the network
layer protocol.
- When a transit LSR detects an error such as MTU exceeded or TTL expired,
it should generate an appropriate network layer error message (eg an ICMP
message if the network layer protocol is IPv4 or IPv6).  To do that the LSR
has to "guess" the network layer protocol.

Have I missed something?  Or do you have other mechanisms for handling these
problems?

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?

	Nick.

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

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.
> 
> -----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
> >

-- 

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 13:14:06 -0500

Nick,

	No.

	Use of a specific mechanism to 'conceal' the
encasulation used in enclosed data from intermediate
LSRs does not prevent the ingress and egress of the 
LSP from doing their job.

	'There are cases' implies that there may be 
'other cases'...

> - When packets exit the LSP tunnel, they have to be processed by the network

If I have an application for tunneling non-IP traffic,
tunnel end-points must be aware of the application.

So what?

> has to "guess" the network layer protocol.

No, for two reasons.

1 -
If it does not know the network layer, then it does
not need to "guess" anything.  It can simply discard
the packet silently and the user will need to take 
this as part of the cost of doing business in secret.

2-
Tunneled messages are not aged enroute (by TTL or any
other mechanism) since the tunneled messages are not 
processed while they are in the tunnel.  The outer
message that encapsulates the tunneled messages may be
aged, however.  But - in the event that such messages
expire - the error messages that MAY result will be
directed at the sender of the encapsulated message
(that would be the tunnel ingress).  In proposals 
discussed for MPLS, the error messages could be for-
warded to the egress of the LSP - and the egress 
should be able to determine how to return an error to 
the ingress (at least, that's how I understood it from 
earlier discussion).  In either case, the ingress -
which originally encapsulated the message - should be
able to determine if further error reporting is needed
and how to go about doing so is it is.

> protocols for further study?

Then you accept a non-truth.  Mainstream interest is in
IPv4, no doubt, but there are more things in this world
than can be contained in an IPv4 philosophy. :-)

-- 
Eric Gray