Subject: Next hop Change

From: "Hemant P. Kelkar" <[email-masked]>
Date: Mon, 10 Sep 2001 02:26:45 -0400 (EDT)

Hi Everybody,
This is regarding the Next Hop change in the LDP state Machine.
"draft-ietf-mpls-ldp-state-04" states that, the LSR can be configured as
either "local repair" or "global repair". How does the LSR detects new
better next hops ? Which mechanism does it employ to discover new paths,
other than LDP advertaisements ?

Regards,
Hemant

---

From: "Nagabhushana Ramaswamy Nadig" <[email-masked]>
Date: Mon, 10 Sep 2001 13:20:27 +0400 (RET)

Triggers from your IGP.......

regards
Bhushana

---

From: Eric Gray <[email-masked]>
Date: Mon, 10 Sep 2001 09:43:00 -0400

Hemant,

    This is an implementation detail.  :-)

    When an LSP is established, the local LSR is able to determine whether
or not it can (or should) detect a change in optimal next hop.  If the LSP is
pinned, or the next hop is a strict hop that is not an abstract node (i.e. - an
AS or address prefix), then the LSR cannot and should not attempt to find
a better next hop for the life of the LSP.  Otherwise, the LSR needs to do
whatever implementation specific trick is required in order to ensure that
it is notified by the appropriate software entity (e.g. - routing) when the
'best path' to the LSP next hop (not necessarily the same as a routing next
hop, for instance), or LSP destination, changes.

    This is not hard to do.

--
Eric Gray

---

From: "HariKishan" <[email-masked]>
Date: Mon, 10 Sep 2001 09:42:14 -0700

Eric,
	The LDP RFC3036 NH.2 states that label should be removed
from forwarding/switching use when a change in FEC next hop
is detected.

But "draft-ietf-mpls-ldp-state-04" state machine seems to
operate in a different way. The LDP state machine retains
the label till the local/global repair completes/fails. This
behavior is different from the described NH algorithm in RFC 3036.

I think the state machine behavior should strictly follow whatever
is stated in RFC3036!!! Is it really a bug in the draft or did I 
miss something!!

thanks,
Kishan
---------------------------------
HariKishan Desineni,
Ericsson Inc,
Santabarbara,
California - 93117
Office:(805) 562 6419
Home:(805) 562 8841

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf 
> Of Eric Gray
> Sent: Monday, September 10, 2001 6:43 AM
> To: Hemant P. Kelkar
> Cc: [email-masked]; [email-masked]
> Subject: Re: Next hop Change
> 
> 
> Hemant,
>

---

From: Eric Gray <[email-masked]>
Date: Mon, 10 Sep 2001 15:01:08 -0400

Kishan,

    If you consider that the LDP state machine draft is intended to be an
Informational RFC (once all of the drafts to which it refers are RFCs),
and RFC 3036 is a proposed standard, then what RFC 3036 says will
over-ride - whenever and where-ever processing applies to LDP only.

    However, the LDP state machine draft also covers state machines
applying to CR-LDP.  For applications (such as TE or VPN) where an
LSP is established using an explicit route, your line of reasoning does
not apply.  Following the approach specified in LDP results in uneeded
disruption of the application's services.

--
Eric Gray