Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Mikael Abrahamsson <swmike@swm.pp.se> Wed, 03 March 2010 09:47 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF753A8B28 for <mpls@core3.amsl.com>; Wed, 3 Mar 2010 01:47:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUgTqXk89Nvb for <mpls@core3.amsl.com>; Wed, 3 Mar 2010 01:47:04 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by core3.amsl.com (Postfix) with ESMTP id 3089C3A8ADE for <mpls@ietf.org>; Wed, 3 Mar 2010 01:47:04 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 371A0A0; Wed, 3 Mar 2010 10:47:00 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 359E69C for <mpls@ietf.org>; Wed, 3 Mar 2010 10:47:00 +0100 (CET)
Date: Wed, 03 Mar 2010 10:47:00 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: "mpls@ietf.org" <mpls@ietf.org>
In-Reply-To: <5A5E55DF96F73844AF7DFB0F48721F0F52E454217C@EUSAACMS0703.eamcs.ericsson.se>
Message-ID: <alpine.DEB.1.10.1003031045400.11822@uplift.swm.pp.se>
References: <4B890BA3.8010306@pi.nu> <787be2781003021233i3ae4740cx3139416a2d05d2ae@mail.gmail.com> <8249B703AE8442429AF89B86E8206AA26CC4478166@EUSAACMS0703.eamcs.ericsson.se> <787be2781003021415y46ca7a7euddcb12c552358102@mail.gmail.com> <8249B703AE8442429AF89B86E8206AA26CC4478201@EUSAACMS0703.eamcs.ericsson.se> <787be2781003021428q450c2a7dy65409dcbc635cd70@mail.gmail.com> <8249B703AE8442429AF89B86E8206AA26CC447822A@EUSAACMS0703.eamcs.ericsson.se> <787be2781003021448qc02704dpbd88ad84ba4ca239@mail.gmail.com> <5A5E55DF96F73844AF7DFB0F48721F0F52E45420AC@EUSAACMS0703.eamcs.ericsson.se> <alpine.DEB.1.10.1003030733300.11822@uplift.swm.pp.se> <5A5E55DF96F73844AF7DFB0F48721F0F52E4542175@EUSAACMS0703.eamcs.ericsson.se> <alpine.DEB.1.10.1003030833180.11822@uplift.swm.pp.se> <5A5E55DF96F73844AF7DFB0F48721F0F52E4542177@EUSAACMS0703.eamcs.ericsson.se> <alpine.DEB.1.10.1003030916150.11822@uplift.swm.pp.se> <5A5E55DF96F73844AF7DFB0F48721F0F52E454217C@EUSAACMS0703.eamcs.ericsson.se>
User-Agent: Alpine 1.10 (DEB 962 2008-03-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Mar 2010 09:47:05 -0000

On Wed, 3 Mar 2010, Sriganesh Kini wrote:

> [Sri] If both ends are not capable of LDP/IGP Sync it seems like a 
> misconfig (or lack of a config knob)

Correct, but still valid (would mean LDP/IGP sync would work even if only 
one end of the link had it implemented.

> [Sri] If the goal is to achieve overload-bit like behavior with the 
> exception of allowing transit traffic through the router when no other 
> path is available, then it can be achieved with "max-metric 
> all-interfaces" on one router even though this results in each link 
> being uni-directionally at max-cost. This is because during SPF 
> computation, to transit the router, it will have to go through one link 
> in the direction that it is advertised with max-cost.

That doesn't solve directly connected interfaces in HSRP/VRRP type 
redundancy scenarios.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se