The MPLS WG Archive

[Eric Gray <EGray@zaffire.com>]

Dimitry,

	Speaking as one who has used an analogy
before, this one is a bit of a stretch.  But
let's take it for a stroll.

	What I am saying is that - should you get
pulled over in your wife's car - you should not
be surprised when you are detained pending a
verification that you have permission from the
owner of the vehicle.  A police officer would
absolutely be within his/her rights to insist
on performing such a check.

	After that, it might not seem so useful.

--
Eric Gray

-----Original Message-----
From: Dimitry Haskin [mailto:dhaskin@nexabit.com]
Sent: Friday, April 14, 2000 7:35 AM
To: Eric Gray; mpls@UU.NET
Subject: RE: FW: I-D
ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.t xt


Eric,

An LSR using an address of another LSR as the extended tunnel ID is as much
forgery as me driving my wife's car is a crime. If there is consent and a
purpose, it is perfectly legal and even useful.

----------------------------------------------------------------------
Dimitry Haskin
Lucent Technologies Internetworking Systems


> -----Original Message-----
> From: Eric Gray [mailto:EGray@zaffire.com]
> Sent: Thursday, April 13, 2000 6:30 PM
> To: 'Dimitry Haskin'; David Charlap; mpls@UU.NET
> Cc: Abes, Andi
> Subject: RE: FW: I-D
> ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.t xt
> 
> 
> Dimitry,
> 
> 	I think this is wrong for a couple of reasons.
> 
> 	One is that the session object is defined such
> that the last four bytes of the extended tunnel ID is
> defined to be an IP address of the tunnel ingress.  
> This is done explicitly to provide a globally unique
> tunnel identifier which MUST then be under the control
> of the owner of that IP address.
> 
> 	The second is that it should be an error.  Since
> the extended tunnel ID is defined the way that it is,
> allowing any LSR to use the address of another LSR -
> even one that is not necessarily particularly local -
> is allowing forgery.  The fact that enforcement of
> the definition of the extended tunnel ID MIGHT be hard
> to do should not be taken to mean that nobody will do
> it - or that anybody doing so is wrong.
> 
> --
> Eric Gray
> 
> -----Original Message-----
> From: Dimitry Haskin [mailto:dhaskin@nexabit.com]
> Sent: Thursday, April 13, 2000 1:12 PM
> To: David Charlap; mpls@UU.NET
> Cc: Abes, Andi
> Subject: RE: FW: I-D
> ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.t xt
> 
> 
> A small but not insignificant correction.
> 
> > > ...
> > > 1. For LSP's to be belong to the same session they need
> > >    to share the same egress point and tunnel ID.
> > >    If the exteneded tunnel ID is set to the Ingress IP 
> address, only
> > >    LSP's originating at the same ingress could ever belong to the
> > >    same session.
> > 
> > Yes.
> > 
> 
> There is nothing to prevent nor it is an error for LSPs originating at
> different ingress nodes to share the same extended tunnel ID 
> even if this ID
> happen to be set to an address of one of the ingress nodes.
> 
> Dimitry
>