Subject: Question about Labels

From: Arturo Nunez <[email-masked]>
Date: Sun, 21 Jan 2001 00:16:46 -0500 (EST)

Hi:
	I would like to know:
	-	Why when the routers build their tables and assign the labels, why
	are they different in for example 2 switches that are adjacent ??
	-	What happends if the tables in the routers change, as the routes,
	how are they reflected in the labels, should it be through the LDP ??

	Any comment will be welcome ..
	Regards.

	Arturo Nunez

---

From: Arturo Nunez <[email-masked]>
Date: Sun, 21 Jan 2001 00:51:12 -0500 (EST)

Hi:
	Thanks for the answer..

> Hi
>   I would like to answer ur questions. pls describe clearly ur questions.

I will clarify as well I can do..

1) Suppose I have a network as these:

Ingress LSR--- Core LSR ---- Egress LSR

- In the middle (Core) We may have 2 switches that Support LSR
  Now when I have a path = service will be then labels in the devices that
  are involved.
  Why should be labels different in the devices that are near and even why
  are they different in all the devices involved in all the route ??
  If we want do the things easier shouldnt be just be a label, the same ,
  for the path = service ??

2) What happend if the the tables, routes, in the Network change, what is
that related with the labels, how do they change ?? Does it has to be with
the LDP ??

Regards.

Arturo Nunez

---

From: "Morgan, Richard" <[email-masked]>
Date: Mon, 22 Jan 2001 14:57:33 -0000

> If we solve the technical problem of optically swapping lambda's, then
> labels of GMPLS will only be locally significant too.  Any 
> idea if and when
> this will ever happen?

AFAIK 'they' have been able to change the frequency of light in a lab
enviroment, they slow it down or put it through a crystal with huge charges
across it. Currently there is little chance of this being small / easy /
safe enough to put into an optical switched router. Meanwhile you can 'sort
of' swap labels by moving the light beam in space, ie push it down a
physically different fibre within the same bundle.

I'm going to stop there before my very small knowledge on this subject
offends someone on the list !

Rich

---

From: Arturo Nunez <[email-masked]>
Date: Mon, 22 Jan 2001 10:20:42 -0500 (EST)

Hi:
 	  Thanks for the answer.
 		  I have another questions
> > Labels only have local significance - 
 OK.. Thats clear now.
 Now, what about multiple services (FECs) that may follow a same path ??
 How the protocol manage the same route, just with another labels ??
> >The IGP routes in the table are kept separate from LDP / RSVP LSP routes.
> >Should the LSP break in response to a link being broken the information is
> > communicated back down the path to the source of the LSP and is be
> > recalculated using IGP information from there. There are a few extra
> > failovers a LSP can deploy to help the switch over - these are known as
> > secondary routes and fast reroute.
 So as I understand the RVSP must be checking for the integrity of the LSP,
 is that correct ??
 
 Regards
 
 Arturo Nunez

---

From: "Morgan, Richard" <[email-masked]>
Date: Mon, 22 Jan 2001 17:30:19 -0000

> Note that per FEC does not necessarily mean per IP prefix.  Multiple
> prefixes that all leave the MPLS cloud through a common 
> router interface
> and have identical traffic characteristics can be considered a single
> FEC and can use a single LSP.

Opps! I was wondering when I would finally put my foot in my mouth. I was
considering FEC to be a diffserv thing and it is not. I was also considering
LSP's created by an IGP to be a tree following the FEC, as opposed to point
to point LSP's like generated by LDP / RSVP, of course they are also called
LSP's and I misunderstood the question. Thankyou for correcting me :)
 
> WRT LDP, this isn't a problem.  LDP messages are not periodically
> refreshed.  Since TCP is used for message delivery, reliability is
> assumed.  State remains until neighbor failure is detected or 
> the state
> is explicitly torn.  Neighbor failure is detected under one of three
> conditions:
> 	- The neighbor stops broadcasting Hello discovery messages
> 	- The neighbor stops sending Keepalive messages on the TCP
> 	  connection.
> 	- The TCP connection to the neighbor breaks.

That's cleared that for me 

Rich