The MPLS WG Archive

[Markus Jork <mjork@avici.com>]

Richard,

> 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. 
>

Bruno already gave a good answer to this. Ordered control gives you the
advantage that a PE would know that an LSP is not available. But LDP has
to follow IP routing and can't take an alternative path so you'd still
be stuck.

> 
> 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.

Clearly, the solution is not applicable to all networks. It's a good fit
for some but might not be for others. There is an applicability section
in the draft but it probably needs to be expanded a bit to talk about
RSVP-TE use in the network in conjunction with LDP. That is indeed a
good point you raise. The IGP distributes an IGP cost and a TE cost
for a link. So one could raise the IGP cost but leave the TE cost in
place which would prevent RSVP-TE tunnels from rerouting.

Markus


> 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