Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt
Greg Mirsky <gregimirsky@gmail.com> Tue, 02 March 2010 22:15 UTC
Return-Path: <gregimirsky@gmail.com>
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 3C72728C29C for <mpls@core3.amsl.com>; Tue, 2 Mar 2010 14:15:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level:
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 IhVssCnVZ8g4 for <mpls@core3.amsl.com>; Tue, 2 Mar 2010 14:15:38 -0800 (PST)
Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by core3.amsl.com (Postfix) with ESMTP id AB88528C188 for <mpls@ietf.org>; Tue, 2 Mar 2010 14:15:31 -0800 (PST)
Received: by bwz3 with SMTP id 3so745614bwz.29 for <mpls@ietf.org>; Tue, 02 Mar 2010 14:15:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=XWky3i2Wva0h1iR30Y3Gg4XOs0bONR8Je8+9O11vYIY=; b=cwjyxgIcdbTuOka9WrQCZ1s8BEPW80Knqn9FPAFVsw2Aq17kmNnjj+IvBcOcLcMb/b IfkcbOZ6Odvc5OgyCvGpUnTJEDb4g+yWEpEYmdzIGPgHwINPTzXwjWyKVyvUkwIEyrfQ LXBF/geTk7QGiolAmazStwA+gdHeriUQowm5Q=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ut69HM+loHC9JKPdNJt0//63yUpK0mMKyGGH2z9B87xf50PCDvo1QcP/Xv8G64StWG jlAR6IUVF9gFFueM7cUCvcRKy/0cFoIP1ihBZlgIwirISPuOZJnn86dQSDpJPoHXJ2nZ 1iQd38o9TbQ9Kn7XJtjAxcHzjog4b3Gz/u8mg=
MIME-Version: 1.0
Received: by 10.204.36.199 with SMTP id u7mr5110583bkd.212.1267568118422; Tue, 02 Mar 2010 14:15:18 -0800 (PST)
In-Reply-To: <8249B703AE8442429AF89B86E8206AA26CC4478166@EUSAACMS0703.eamcs.ericsson.se>
References: <4B890BA3.8010306@pi.nu> <8249B703AE8442429AF89B86E8206AA26CC440774B@EUSAACMS0703.eamcs.ericsson.se> <787be2781003011627w631803ecmf20f27842c91943a@mail.gmail.com> <8249B703AE8442429AF89B86E8206AA26CC4407756@EUSAACMS0703.eamcs.ericsson.se> <787be2781003011701x2856d62dib00a194ca5540939@mail.gmail.com> <8249B703AE8442429AF89B86E8206AA26CC44077AA@EUSAACMS0703.eamcs.ericsson.se> <787be2781003011755y567b9f7ekd13f0f3279bd4bae@mail.gmail.com> <8249B703AE8442429AF89B86E8206AA26CC447809D@EUSAACMS0703.eamcs.ericsson.se> <787be2781003021233i3ae4740cx3139416a2d05d2ae@mail.gmail.com> <8249B703AE8442429AF89B86E8206AA26CC4478166@EUSAACMS0703.eamcs.ericsson.se>
Date: Tue, 02 Mar 2010 14:15:18 -0800
Message-ID: <787be2781003021415y46ca7a7euddcb12c552358102@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
To: Wenhu Lu <wenhu.lu@ericsson.com>
Content-Type: multipart/alternative; boundary="00032555850a6d67750480d8b3bd"
Cc: "mpls@ietf.org" <mpls@ietf.org>
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: Tue, 02 Mar 2010 22:15:40 -0000
Hi Wenhu, we all have our own preferences and understanding of "simple". Regards, Greg On Tue, Mar 2, 2010 at 1:33 PM, Wenhu Lu <wenhu.lu@ericsson.com> wrote: > Hi Greg, > If a link is a cut-edge, we don't do anything (I mean changing LSA, or wait > on an LDP timer). > Just follow regular IGP procedure. Simple enough, right? > Thanks, > -wenhu > > ------------------------------ > *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] > *Sent:* Tuesday, March 02, 2010 12:34 PM > > *To:* Wenhu Lu > *Cc:* mpls@ietf.org > *Subject:* Re: [mpls] working group last call on > draft-ietf-mpls-ldp-igp-sync-bcast-00.txt > > Hi Wenhu, > I don't see my suggestion as "different method". I view your work as having > two parts: > > - definition of cut-edge broadcast IGP interface > - advertisement of Stub Link in RTR LSA (OSPF case, IS-IS identical) > instead of Transit Link until the LDP converges > > If you agree that my understanding of your work is correct, then I can step > to my question: How critical to benefit of your work definition of cut-edge > status? I don't see it as critical but as optimization for IP convergence. > Thus is my suggestion, to make cut-edge definition step in IGP-LDP > convergence on a broadcast segment optional. > > Regards, > Greg > > On Tue, Mar 2, 2010 at 12:24 PM, Wenhu Lu <wenhu.lu@ericsson.com> wrote: > >> Hi Greg, >> I don't quite understand your question. Were you proposing a different >> method to handle the "cut-edge"? >> Would you elaborate a bit ? >> Thanks, >> -wenhu >> >> ------------------------------ >> *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] >> *Sent:* Monday, March 01, 2010 5:55 PM >> >> *To:* Wenhu Lu >> *Cc:* mpls@ietf.org >> *Subject:* Re: [mpls] working group last call on >> draft-ietf-mpls-ldp-igp-sync-bcast-00.txt >> >> Hi Wenhu, >> if "cut-edge" is optimization, why not just propose to advertise link to >> broadcast network as stub until LDP has converged? That would not require >> the change in SPF and will work. >> >> Regards, >> Greg >> >> On Mon, Mar 1, 2010 at 5:49 PM, Wenhu Lu <wenhu.lu@ericsson.com> wrote: >> >>> Hi Greg, >>> Glad we finally converged. >>> A few more inline. >>> >>> ------------------------------ >>> *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] >>> *Sent:* Monday, March 01, 2010 5:02 PM >>> >>> *To:* Wenhu Lu >>> *Cc:* mpls@ietf.org >>> *Subject:* Re: [mpls] working group last call on >>> draft-ietf-mpls-ldp-igp-sync-bcast-00.txt >>> >>> Hi Wenhu, >>> >>> yes, I stay corrected. The RFC 5443 states that only affected link to be >>> maxed. In case of the whole node coming up it will be applied to all node >>> links and thus work for any iIGP interface type. >>> If only one link, then IGP convergence over the broadcast interface >>> might precede LDP. But then, if link B-PE2 is up, B's interface to the >>> broadcast segment is not the "cut-edge" because alternative path PE2-D-C >>> exists. Would you agree? >>> [luw] Yes, that's correct. Our method works in both "cut-edge" and >>> "non-cut-edge" scenarios. >>> Regards, >>> -wenhu >>> >>> Regards, >>> Greg >>> >>> On Mon, Mar 1, 2010 at 4:33 PM, Wenhu Lu <wenhu.lu@ericsson.com>wrote: >>> >>>> Hi Greg, >>>> Inline. >>>> >>>> ------------------------------ >>>> *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] >>>> *Sent:* Monday, March 01, 2010 4:28 PM >>>> >>>> *To:* Wenhu Lu >>>> *Cc:* mpls@ietf.org >>>> *Subject:* Re: [mpls] working group last call on >>>> draft-ietf-mpls-ldp-igp-sync-bcast-00.txt >>>> >>>> Hi Wenhu, >>>> >>>> I think that you are overlooking the fact that B advertises at >>>> LSInfinity its ALL links, including to PE2 in your diagram. >>>> [luw] No, not all links, but only the affected link. >>>> Please double check RFC5443 section 2, third paragraph, quoted below: >>>> In detail: when LDP is not "fully operational" (see below) *on a given >>>> link*, the IGP will advertise *the link* with maximum cost to avoid >>>> any >>>> transit traffic over it. >>>> >>>> Best regards, >>>> -wenhu >>>> >>>> >>>> >>>> Thus, as I understand OSPF, there's no way A will select B for its >>>> path to PE2. Yes, you've found another way "to slice the cake" but, as I've >>>> mentioned, the main issue is when to advertise the real IGP cost being >>>> handled by both documents identically. >>>> >>>> Regards, >>>> Greg >>>> >>>> On Mon, Mar 1, 2010 at 4:15 PM, Wenhu Lu <wenhu.lu@ericsson.com> wrote: >>>> >>>>> Hi Greg, >>>>> "I don't think that A has or can to do anything." - that's exactly my >>>>> point. i.e. A cannot manipulate its cost to favor C or B. >>>>> Now B can't either ! >>>>> If you increase B's cost (to the LAN) to LSInfinity, it still doesn't >>>>> change A's decision. >>>>> "A->B->PE2" is still shorter than "A->C->D->PE2". >>>>> >>>>> The traffic thus will be directed to B, hence the traffic loss. >>>>> >>>>> Regards, >>>>> -wenhu >>>>> >>>>> ------------------------------ >>>>> *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] >>>>> *Sent:* Monday, March 01, 2010 3:32 PM >>>>> *To:* Wenhu Lu >>>>> *Cc:* mpls@ietf.org >>>>> >>>>> *Subject:* Re: [mpls] working group last call on >>>>> draft-ietf-mpls-ldp-igp-sync-bcast-00.txt >>>>> >>>>> Hi Wenhu, >>>>> I've snipped text to leave only your question for further discussion. >>>>> >>>>> >>>>>> >>>>>> [luw] Let me ask a simple question. In the following diagram, let's >>>>>> assume the link cost is 10 everywhere. >>>>>> >>>>>> | >>>>>> | +---+ +---+ >>>>>> |----| B |-----------|PE2| >>>>>> | +---+ +---+ >>>>>> +---+ +---+ | | >>>>>> |PE1|----| A |----| | >>>>>> +---+ +---+ | | >>>>>> | +---+ +---+ | >>>>>> |----| C |----| D |----+ >>>>>> | +---+ +---+ >>>>>> >>>>>> Originally the primary LSP from PE1 to PE2 is "PE1-A-B-PE2". The >>>>>> backup LSP is "PE1-A-C-D-PE2". >>>>>> Now after B's link to the broadcast network (that connects A, B, and >>>>>> C) restores to UP from being DOWN, >>>>>> "A" wants the traffic continues to flow through the backup path >>>>>> "PE1-A-C-D-PE2" for a while, so that it gains >>>>>> time to recover the primary LSP(s). >>>>>> With the RFC5443 method, could you let me know what "A" should do to >>>>>> keep traffic from flowing through "B"? >>>>>> >>>>>> Regards, >>>>>> -wenhu >>>>>> >>>>>> >>>>> I don't think that A has or can to do anything. Per RFC 5443, as well >>>>> as per your work, it is responsibility of up-and-coming node to try not to >>>>> disturb existing topology. The node B can, per RFC 5443, advertise its link >>>>> to the broadcast network (DR in OSPF) with LSInfinity (I'd prefer divide it >>>>> in half but that's me). The real problem, and RFC 5443 clearly acknowledges >>>>> this, is when the node B can advertise the real IGP cost (irrespective of >>>>> type of its IGP interface). Yes, the delay timer is a workaround and sort of >>>>> a "black magic". The LDP End-of-Lib, as both documents point out, is better >>>>> and more appropriate trigger. >>>>> >>>>> Regards, >>>>> Greg >>>>> >>>> >>>> >>> >> >
- [mpls] working group last call on draft-ietf-mpls… Loa Andersson
- Re: [mpls] working group last call on draft-ietf-… benjamin.niven-jenkins
- Re: [mpls] working group last call on draft-ietf-… Sriganesh Kini
- Re: [mpls] working group last call on draft-ietf-… Greg Mirsky
- Re: [mpls] working group last call on draft-ietf-… benjamin.niven-jenkins
- Re: [mpls] working group last call on draft-ietf-… Sriganesh Kini
- Re: [mpls] working group last call on draft-ietf-… Greg Mirsky
- Re: [mpls] working group last call on draft-ietf-… Greg Mirsky
- Re: [mpls] working group last call on draft-ietf-… Wenhu Lu
- Re: [mpls] working group last call on draft-ietf-… Sriganesh Kini
- Re: [mpls] working group last call on draft-ietf-… Greg Mirsky
- Re: [mpls] working group last call on draft-ietf-… benjamin.niven-jenkins
- Re: [mpls] working group last call on draft-ietf-… Greg Mirsky
- Re: [mpls] working group last call on draft-ietf-… Wenhu Lu
- Re: [mpls] working group last call on draft-ietf-… Greg Mirsky
- Re: [mpls] working group last call on draft-ietf-… Wenhu Lu
- Re: [mpls] working group last call on draft-ietf-… Greg Mirsky
- Re: [mpls] working group last call on draft-ietf-… Wenhu Lu
- Re: [mpls] working group last call on draft-ietf-… Greg Mirsky
- Re: [mpls] working group last call on draft-ietf-… Wenhu Lu
- Re: [mpls] working group last call on draft-ietf-… Greg Mirsky
- Re: [mpls] working group last call on draft-ietf-… Wenhu Lu
- Re: [mpls] working group last call on draft-ietf-… Greg Mirsky
- Re: [mpls] working group last call on draft-ietf-… Sriganesh Kini
- Re: [mpls] working group last call on draft-ietf-… Sriganesh Kini
- Re: [mpls] working group last call on draft-ietf-… Wenhu Lu
- Re: [mpls] working group last call on draft-ietf-… Greg Mirsky
- Re: [mpls] working group last call on draft-ietf-… Greg Mirsky
- Re: [mpls] working group last call on draft-ietf-… Wenhu Lu
- Re: [mpls] working group last call on draft-ietf-… Wenhu Lu
- Re: [mpls] working group last call on draft-ietf-… Greg Mirsky
- Re: [mpls] working group last call on draft-ietf-… Wenhu Lu
- Re: [mpls] working group last call on draft-ietf-… Greg Mirsky
- Re: [mpls] working group last call on draft-ietf-… Wenhu Lu
- Re: [mpls] working group last call on draft-ietf-… Sriganesh Kini
- Re: [mpls] working group last call on draft-ietf-… Wenhu Lu
- Re: [mpls] working group last call on draft-ietf-… Wenhu Lu
- Re: [mpls] working group last call on draft-ietf-… Mikael Abrahamsson
- Re: [mpls] working group last call on draft-ietf-… Sriganesh Kini
- Re: [mpls] working group last call on draft-ietf-… Mikael Abrahamsson
- Re: [mpls] working group last call on draft-ietf-… Sriganesh Kini
- Re: [mpls] working group last call on draft-ietf-… Mikael Abrahamsson
- Re: [mpls] working group last call on draft-ietf-… Sriganesh Kini
- Re: [mpls] working group last call on draft-ietf-… Mikael Abrahamsson
- Re: [mpls] working group last call on draft-ietf-… Sriganesh Kini