The MPLS WG Archive

["Abes, Andi" <aabes@quarrytech.com>]

> -----Original Message-----
> From: Dimitry Haskin [mailto:dhaskin@nexabit.com]
> Sent: Friday, April 14, 2000 10: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
> > 
>