The MPLS WG Archive

["DECRAENE Bruno RD-CORE-ISS" <bruno.decraene@francetelecom.com>]

Richard,

With ordered label distribution, the ingress PE gains the knowledge of
the MPLS/LDP failure. But it still has no mean to reroute the traffic.
So that does not solve the problem described in the draft. (VPN traffic
is still dropped).

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

I understand your point and I don't like either using one protocole
(IGP) to advertise another protocole (LDP) status/failure.

However, I believe the "acceptability"  may depend on what the network
is used for: 
- MPLS VPN only --> I rather agree with the draft point of view (better
to reroute all protocoles)
- multiservice: IP, MPLS LDP, MPLS TE/FRR --> I rather agree with you.


All,

This may not be specific to MPLS LDP.
The problem seems to be the same with any other protocol that IPv4. For
example with IPv6 (and single IGP topology) if IPv6 is disabled on a
link or a router.

Regards,
Bruno

> -----Original Message-----
> From: mpls-bounces@lists.ietf.org 
> [mailto:mpls-bounces@lists.ietf.org] On Behalf Of 
> richard.spencer@bt.com
> Sent: Friday, October 22, 2004 9:40 AM
> To: mjork@avici.com; mpls@ietf.org
> Subject: RE: [mpls] new I-D draft-jork-ldp-igp-sync-00
> 
> 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
> 

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