The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] new I-D draft-jork-ldp-igp-sync-00
Richard,
Take a look at the following topology.
A---B-----\
| | \ \
C D---E---F
| | / /
G---H-----/
The network uses ordered control to distribute labels. A
and G are egress for an LDP FEC that is sent to F. IP and LDP are enabled on all
the links. Preferred paths (due to IGP metrics) are F-E-D-B-A and F-E-D-H-G.
Metrics for E-B and E-H are high; so high that the second best path for E to A/G
is via F. As you well know, the path selection for LDP follows the
IGP.
Disable LDP on the link between D and E. Should E withdraw the label to F? It has no idea about LDP state on F-B and F-H and therefore the label remains distributed on the "upstream" link even with ordered control. F relies on the IGP to determine that traffic should be moved to F-B-A and F-H-G, but the IGP is perfectly happy flowing along F-E-D-B-A and F-E-D-H-G. F points to E and E points to F in this steady state. Go back to steady state. Reboot node E and node D. Traffic moves along the paths E-F-B-A and E-F-H-G for the reboot period. At what time should the traffic begin to flow along the preferred path? Even ordered control even allows E to distribute to F before the D has completed label distribution to E. Why should F converge onto the best IGP path (creating the black hole yet again) before LDP is in sync? There are always protocol interactions that require two protocols to have some level of sync and this is an important one. BTW -- WRT to you comment about RSVP-TE LSPs beign rerouted, recall that RSVP-TE has a separate set of traffic engineering metrics such that it is perfectly happy to stay on a link when the IGP metric is set high according to Markus' draft. You can decouple these metrics from the IGP metrics if you don't have lossless TE LSP reroutes. Don ----- Original Message -----
From: <richard.spencer@bt.com>
To: <mjork@avici.com>; <mpls@ietf.org>
Sent: Friday, October 22, 2004 3:40 AM
Subject: RE: [mpls] new I-D
draft-jork-ldp-igp-sync-00 > > 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
|
|