The MPLS WG Archive

[richard.spencer@bt.com]

Markus,

If I understand correctly, the basic idea here is to advertise a link with an artificially high IGP metric until LDP labels have been exchanged between peers across that link. This is to avoid labelled VPN packets being black holed if for example the link is up but LDP tunnel LSP labels have not been exchanged yet, or perhaps LDP has not been configured at one end of a link.

Is this problem not Independent Label Distribution specific? If this is considered to be a problem then why not implement Ordered Label Distribution Control, as per RFC3036: "For each FEC for which the LSR is not the egress and no mapping exists, the LSR MUST wait until a label from a downstream LSR is received before mapping the FEC and passing corresponding labels to upstream LSRs."? This will have the same effect as a PE will not receive a label from a downstream P to reach a remote PE until labels for that LSP have been fully exchanged by each hop across the path. 

If a router implementation has to be changed anyway, instead of changing the implementation to advertise an artificially high IGP metric until "some time after LDP session establishment before declaring LDP fully operational in order to allow for the exchange of label bindings", why not implement ordered label distribution control?

Either I am missing something or this draft proposes a fix to a problem with independent label distribution that can already be avoided by using ordered label distribution as per the RFC3036 standard.

In addition, what about providers using RSVP-TE in parallel with LDP signalling across the same link? If a router detects that LDP has failed across a link and increases the IGP metric, this may cause CSPF to calculate alternate paths for the TE tunnels using that link. 

IMO a solution that effects the routing of native IP traffic and traffic being carried by TE tunnels across a link because of an LDP problem is not acceptable.

Regards,
Richard

> -----Original Message-----
> From: mpls-bounces@lists.ietf.org 
> [mailto:mpls-bounces@lists.ietf.org]On
> Behalf Of Markus Jork
> Sent: 21 October 2004 22:38
> To: mpls@ietf.org
> Subject: [mpls] new I-D draft-jork-ldp-igp-sync-00
> 
> 
> I'd like to make you aware of a new I-D posted recently which
> should be of interest to this wg. It addresses an operational
> problem in LDP networks, see abstract below.
> Comments are of course welcome and encouraged.
> 
> Markus
> 
> 
> ------- Forwarded Message
> 
> To: i-d-announce@ietf.org
> From: Internet-Drafts@ietf.org
> Date: Tue, 19 Oct 2004 07:48:05 -0400
> Subject: I-D ACTION:draft-jork-ldp-igp-sync-00.txt
> List-Id: i-d-announce.ietf.org
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: LDP IGP Synchronization
> 	Author(s)	: M. Jork, et al.
> 	Filename	: draft-jork-ldp-igp-sync-00.txt
> 	Pages		: 8
> 	Date		: 2004-10-18
> 	
> In networks depending on edge-to-edge establishment of MPLS
>    forwarding paths via LDP, blackholing of traffic can occur in
>    situations where the IGP is operational on a link and thus the link
>    is used for IP forwarding but LDP is not operational on 
> that link for
>    whatever reason.  This document describes a mechanism to avoid
>    traffic loss due to this condition without introducing any protocol
>    changes.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-jork-ldp-igp-sync-00.txt
> 
> [...]
> ------- End of Forwarded Message
> 
> 
> 
> 
> _______________________________________________
> mpls mailing list
> mpls@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/mpls
> 

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls