The MPLS WG Archive

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

(sorry for the previous mail - too quick on 
the trigger)...



Ok, 
 many "hidden" intentions were assigned to the 
extended tunnel ID.
It might be usefull to make an attempt and clarify 
what is it usefull for.

The following was sent in private email.

Do my assumptions make any sense ?


Andi.



-----Original Message-----
From: Abes, Andi 
Sent: Thursday, April 13, 2000 6:00 PM
To: 'Dimitry Haskin'; Abes, Andi
Subject: RE: FW: I-D
ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.t xt


Could be, but I'm not copletly sure about that.
I think there are many issues about corssing administrative
domains.

I might be wrong here, but bare with me.
Basically the Egress makes the decission on what style to 
use for a session, and the ingress has very little say in it.

Yes, there's the "might-reroute" session attribute. There's also
the "merging-permitted" - which I didn't really understand.

Other that those 2 flags, which are very limited info, and 
considered recomendation only, the ingress has very 
little avenues to express its will.

The extened tunnel ID, in my mind, is to allow the 
ingress the capability to disallow any type of sharing.

The rational being:
The "network" will attempt to reduce resource utilization
as much as possible - merge what ever it can - so the 
ingress doesn't realy need to ask for it.
But... The ingress might want to allow an LSP to receive 
prefered treatment, and explicitly dis-allow any type 
of resource sharing. This would be accomplished using
the extended ID.







> -----Original Message-----
> From: Dimitry Haskin [mailto:dhaskin@nexabit.com]
> Sent: Thursday, April 13, 2000 5:47 PM
> To: Abes, Andi
> Subject: RE: FW: I-D
> ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.t xt
> 
> 
> Andi,
> 
> If all sessions that terminate at the same egress are 
> configured by the same
> administrative entity there is no need for the extended 
> tunnel ID in the
> Session object. My understanding is that the extended tunnel 
> ID was intended
> to allow initiation of RSVP sessions in different 
> administrations without
> necessity of close cooperation in identifying the sessions.
> 
> ----------------------------------------------------------------------
> Dimitry Haskin
> Lucent Technologies Internetworking Systems
> 
> 
> > -----Original Message-----
> > From: Abes, Andi [mailto:aabes@quarrytech.com]
> > Sent: Thursday, April 13, 2000 5:36 PM
> > To: Dimitry Haskin
> > Subject: RE: FW: I-D
> > ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.t xt
> > 
> > 
> > Ok,
> > so what's to prevent Rc chosing the same value
> > as Ra for the extended ID ?
> > 
> > My understanding was that the Tunnel ID is not "picked"
> > by either Ra Rb or Rc - it has to be administratively 
> > assigned.
> > The Tunnel ID has very important implications on the way
> > that LSP's are going to be treated (can they be merged / shared 
> > and the likes).
> > In our system - we are going to allow the user control over it.
> > 
> > 
> > Andi.
> > 
> >