The MPLS WG Archive

[Dimitry Haskin <dhaskin@nexabit.com>]

Eric,
> 
> 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.
>
If such a check is possible I've no problem with that. It could be a plain
nuisance in some neighborly communities but ok.. It still does not mean that
it is necessarily illegal or that it does not serve any purpose driving
someone's car.

Back to reality, draft-swallow-rsvp-bypass-label-00.txt provides an example
of different ingress nodes using the same session objects including the
extended tunnel id for association of backup LSPs with LSPs being backed up.


> 	After that, it might not seem so useful.
> 
> --
> Eric Gray

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