From curtis@occnc.com Tue Aug 2 07:44:14 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67A521F84FA for ; Tue, 2 Aug 2011 07:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDsAoakeyXbd for ; Tue, 2 Aug 2011 07:44:14 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0139C21F84F2 for ; Tue, 2 Aug 2011 07:44:13 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p72Eh3Op061919; Tue, 2 Aug 2011 10:43:03 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201108021443.p72Eh3Op061919@harbor.orleans.occnc.com> To: rtgwg@ietf.org Subject: RTGWG meeting and cl-framework status From: Curtis Villamizar Date: Tue, 02 Aug 2011 10:43:03 -0400 Sender: curtis@occnc.com X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 14:44:14 -0000 FYI- I exchanged email off list with authors and with Alia. Alia is not sure that all of this was captured at the meeting but hasn't seen the meeting notes. Discussion on list is always a good thing. Below are our intentions for the next steps in the CL work. Curtis ------- Forwarded Message From: "So, Ning" To: "curtis@occnc.com" , "Mcdysan, David E" , Lucy yong , "Malis, Andrew G. (Andy)" , Eric Osborne Date: Tue, 2 Aug 2011 09:36:08 -0400 Subject: RE: RTGWG meeting Thread-Topic: RTGWG meeting Thread-Index: AcxQrA7/hwhza/x6QL2aYZ/ZkX2d8gAbKfvQ Message-ID: <6665BC1FEA04AB47B1F75FA641C43BC07A93AAEB@FHDP1LUMXC7V41.us.one.verizon.com> References: <201108020033.p720XqxN048207@harbor.orleans.occnc.com> In-Reply-To: <201108020033.p720XqxN048207@harbor.orleans.occnc.com> Curtis, I remember I stated all the things you listed below explicitly, and I hope clearly as well :-) Of course we can send e-mails to WG mail list and chair to re-iterate the plan, and more importantly, move forward with the stated plan aggressively. Best regards, Ning So Verizon Corporate Technology (office) 972-729-7905 (Cell) 972-955-0914 -----Original Message----- From: curtis@occnc.com [mailto:curtis@occnc.com] Sent: Monday, August 01, 2011 7:34 PM To: Mcdysan, David E; Lucy yong; So, Ning; Malis, Andrew G. (Andy); Eric Osborne Cc: curtis@occnc.com Subject: RTGWG meeting Ning, et al, Just want to confirm that this is what we asked for in the meeting and this is what was agreed to. If some points were missed I'll ask on the mailing list if this plan is OK. 1. Merge so-yong-cl-framework and framework additions. Then discuss on WG mailing list and ask to become WG item. 2. Break out parts of cl-framework (maybe resurect Dave appendix to prior cl-req draft) and create a cl-use-cases. 3. Move management requirements from cl-framework to cl-req. Add any other missed requirements. Respeat the last call. 4. Advance cl-req and cl-framework together. Anything that I missed? Since I managed to be out of the room getting coffee and got this second hand I wanted to confirm. Curtis BTW- Ning, thanks again for presenting the slides. ------- End of Forwarded Message From akatlas@gmail.com Tue Aug 2 07:47:23 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DD611E8082 for ; Tue, 2 Aug 2011 07:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOQpVqCgngi6 for ; Tue, 2 Aug 2011 07:47:22 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0718511E808B for ; Tue, 2 Aug 2011 07:47:21 -0700 (PDT) Received: by gyd5 with SMTP id 5so4893203gyd.31 for ; Tue, 02 Aug 2011 07:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RAZ0CjDIeT6G31faJPWuym2yOCepszhGqUfIhzh9oBw=; b=Lhha+cH0zVaJLTrRd4QPYfgbW5yRgLJ7qqxdoz/MlS/QoTtRt+HVcLqFNspTXA2NJ/ 6lX1i0W+TRR+y3C76mvqyW+xi1UsZ52IXarp1bPd88QsrNMyU6lugdeo8o3IhkgKa16T 9+cK71YuSIL+lKnI7CZpZDxTjuJDJwCs6eO6I= MIME-Version: 1.0 Received: by 10.68.15.200 with SMTP id z8mr413510pbc.103.1312296450588; Tue, 02 Aug 2011 07:47:30 -0700 (PDT) Received: by 10.68.50.6 with HTTP; Tue, 2 Aug 2011 07:47:30 -0700 (PDT) In-Reply-To: <201108021443.p72Eh3Op061919@harbor.orleans.occnc.com> References: <201108021443.p72Eh3Op061919@harbor.orleans.occnc.com> Date: Tue, 2 Aug 2011 10:47:30 -0400 Message-ID: Subject: Re: RTGWG meeting and cl-framework status From: Alia Atlas To: curtis@occnc.com Content-Type: multipart/alternative; boundary=bcaec52160abc7016f04a986d331 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 14:47:23 -0000 --bcaec52160abc7016f04a986d331 Content-Type: text/plain; charset=ISO-8859-1 As I said privately, this looks like a good plan to me. I look forward to reading the updated drafts. Alia On Tue, Aug 2, 2011 at 10:43 AM, Curtis Villamizar wrote: > > FYI- > > I exchanged email off list with authors and with Alia. Alia is not > sure that all of this was captured at the meeting but hasn't seen the > meeting notes. > > Discussion on list is always a good thing. Below are our intentions > for the next steps in the CL work. > > Curtis > > > ------- Forwarded Message > > From: "So, Ning" > To: "curtis@occnc.com" , > "Mcdysan, David E" , > Lucy yong , > "Malis, Andrew G. (Andy)" , > Eric Osborne > Date: Tue, 2 Aug 2011 09:36:08 -0400 > Subject: RE: RTGWG meeting > Thread-Topic: RTGWG meeting > Thread-Index: AcxQrA7/hwhza/x6QL2aYZ/ZkX2d8gAbKfvQ > Message-ID: < > 6665BC1FEA04AB47B1F75FA641C43BC07A93AAEB@FHDP1LUMXC7V41.us.one.verizon.com > > > References: <201108020033.p720XqxN048207@harbor.orleans.occnc.com> > In-Reply-To: <201108020033.p720XqxN048207@harbor.orleans.occnc.com> > > Curtis, > > I remember I stated all the things you listed below explicitly, and I > hope clearly as well :-) Of course we can send e-mails to WG mail list > and chair to re-iterate the plan, and more importantly, move forward > with the stated plan aggressively. > > Best regards, > > Ning So > Verizon Corporate Technology > (office) 972-729-7905 > (Cell) 972-955-0914 > > > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Monday, August 01, 2011 7:34 PM > To: Mcdysan, David E; Lucy yong; So, Ning; > Malis, Andrew G. (Andy); Eric Osborne > Cc: curtis@occnc.com > Subject: RTGWG meeting > > > Ning, et al, > > Just want to confirm that this is what we asked for in the meeting and > this is what was agreed to. If some points were missed I'll ask on > the mailing list if this plan is OK. > > 1. Merge so-yong-cl-framework and framework additions. Then > discuss on WG mailing list and ask to become WG item. > > 2. Break out parts of cl-framework (maybe resurect Dave appendix to > prior cl-req draft) and create a cl-use-cases. > > 3. Move management requirements from cl-framework to cl-req. Add > any other missed requirements. Respeat the last call. > > 4. Advance cl-req and cl-framework together. > > Anything that I missed? > > Since I managed to be out of the room getting coffee and got this > second hand I wanted to confirm. > > Curtis > > > BTW- Ning, thanks again for presenting the slides. > > > > ------- End of Forwarded Message > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > --bcaec52160abc7016f04a986d331 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As I said privately, this looks like a good plan to me.=A0 I look forward t= o reading
the updated drafts.

Alia

On Tue, Aug 2, 2011 at 10:43 AM, Curtis Villamizar &l= t;curtis@occnc.com> wrote= :

FYI-

I exchanged email off list with authors and with Alia. =A0Alia is not
sure that all of this was captured at the meeting but hasn't seen the meeting notes.

Discussion on list is always a good thing. =A0Below are our intentions
for the next steps in the CL work.

Curtis


------- Forwarded Message

From: "So, Ning" <ning.= so@verizon.com>
To: "curtis@occnc.com" &l= t;curtis@occnc.com>,
=A0 =A0"Mcdysan, David E" <dave.mcdysan@verizon.com>,
=A0 =A0Lucy yong <lucy.yong@hua= wei.com>,
=A0 =A0"Malis, Andrew G. (Andy)" <andrew.g.malis@verizon.com>,
=A0 =A0Eric Osborne <eosborne@cis= co.com>
Date: Tue, 2 Aug 2011 09:36:08 -0400
Subject: RE: RTGWG meeting
Thread-Topic: RTGWG meeting
Thread-Index: AcxQrA7/hwhza/x6QL2aYZ/ZkX2d8gAbKfvQ
Message-ID: <6665BC1FEA04AB47B1F75FA641C43BC07A93AAEB= @FHDP1LUMXC7V41.us.one.verizon.com>
References: <201108020033.p720XqxN048207@harbor.orleans.occnc.com> In-Reply-To: <201108020033.p720XqxN048207@harbor.orleans.occnc.com><= br>
Curtis,

I remember I stated all the things you listed below explicitly, and I
hope clearly as well :-) Of course we can send e-mails to WG mail list
and chair to re-iterate the plan, and more importantly, move forward
with the stated plan aggressively.

Best regards,

Ning So
Verizon Corporate Technology
(office) 972-729-7905
(Cell) 972-955-0914=


-----Original Message-----
From: curtis@occnc.com [mailto:curtis@occnc.com]
Sent: Monday, August 01, 2011 7:34 PM
To: Mcdysan, David E; Lucy yong; So, Ning;
=A0 =A0Malis, Andrew G. (Andy); Eric Osborne
Cc: curtis@occnc.com
Subject: RTGWG meeting


Ning, et al,

Just want to confirm that this is what we asked for in the meeting and
this is what was agreed to. =A0If some points were missed I'll ask on the mailing list if this plan is OK.

=A01. =A0Merge so-yong-cl-framework and framework additions. =A0Then
=A0 =A0 discuss on WG mailing list and ask to become WG item.

=A02. =A0Break out parts of cl-framework (maybe resurect Dave appendix to =A0 =A0 prior cl-req draft) and create a cl-use-cases.

=A03. =A0Move management requirements from cl-framework to cl-req. =A0Add =A0 =A0 any other missed requirements. =A0Respeat the last call.

=A04. =A0Advance cl-req and cl-framework together.

Anything that I missed?

Since I managed to be out of the room getting coffee and got this
second hand I wanted to confirm.

Curtis


BTW- Ning, thanks again for presenting the slides.



------- End of Forwarded Message
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtgwg

--bcaec52160abc7016f04a986d331-- From curtis@occnc.com Wed Aug 3 11:36:37 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDF911E8082 for ; Wed, 3 Aug 2011 11:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFypOiNoUmln for ; Wed, 3 Aug 2011 11:36:37 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE2811E8080 for ; Wed, 3 Aug 2011 11:36:37 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p73IZRAY018569; Wed, 3 Aug 2011 14:35:27 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201108031835.p73IZRAY018569@harbor.orleans.occnc.com> To: Sriganesh Kini From: Curtis Villamizar Subject: Re: draft-kini-mpls-frr-ldp-01 for review In-reply-to: Your message of "Mon, 25 Jul 2011 14:09:47 PDT." Date: Wed, 03 Aug 2011 14:35:27 -0400 Sender: curtis@occnc.com Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 18:36:38 -0000 In message Sriganesh Kini writes: > > Hello, > > Regarding draft-kini-mpls-frr-ldp-01. > > We had feedback from the mpls WG to present this draft at RTGWG. Since > our request for a slot was late, there is a chance that we may not > have adequate time at the end of the session for this draft. In any > case we wanted to make the WG aware of the draft and would appreciate > any comments. > > Regards > > - Sri Protection is inherently a traffic engineering problem. IPFRR provides mostly limited coverage protection, without the benefit of signaled SRLG, and with increased potential of transient route loops in the abense of complete and accurate SRLG information or when multiple failures occur that are not covered by SRLG. LDP FRR has all the same issues as IPFRR. So in general I don't support LDP FRR. Even if I did support an LDP FRR, I don't think this draft offers a good approach to LDP FRR. Curtis From sriganeshkini@gmail.com Wed Aug 3 14:07:17 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CBC11E8099 for ; Wed, 3 Aug 2011 14:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntWdxG5T7tnl for ; Wed, 3 Aug 2011 14:07:16 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEF011E807C for ; Wed, 3 Aug 2011 14:07:16 -0700 (PDT) Received: by vxi40 with SMTP id 40so1186106vxi.31 for ; Wed, 03 Aug 2011 14:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=rO9OuaQvgTbgXs3fhdkF7IErVttAl2tYrILalIGwTcM=; b=rJHVhje9IQVNcsfYBW41EAK3yeUW9+nrRfUc8CslyRlbwfIuUVXJa2fMX2ERPvnST3 8dLTjNrWsXtR/B296ZJqxfkb5E44KB2cvt/1+A//1vqO4Yfsf5H4qRgJDSfzsUdcwtru 3oIKPf7btRM0vBNGedbOfKUmazu8PFb62mchc= Received: by 10.52.71.163 with SMTP id w3mr1833vdu.394.1312405648091; Wed, 03 Aug 2011 14:07:28 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.52.184.68 with HTTP; Wed, 3 Aug 2011 14:06:58 -0700 (PDT) In-Reply-To: <201108031835.p73IZRAY018569@harbor.orleans.occnc.com> References: <201108031835.p73IZRAY018569@harbor.orleans.occnc.com> From: Sriganesh Kini Date: Wed, 3 Aug 2011 14:06:58 -0700 X-Google-Sender-Auth: pqIbS6FoWkxMME4CakK5ed6d5yU Message-ID: Subject: Re: draft-kini-mpls-frr-ldp-01 for review To: curtis@occnc.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 21:07:17 -0000 Protection requires avoiding failures that can use some path computation infrastructure that is also useful for TE, but that does not make it the same as a TE problem. LDP FRR that relies on IPFRR (LFA) has limited coverage and associated issues. The proposal is not relying on IPFRR. LDP is widely deployed, so not supporting fast-reroute for LDP is definitely not a good choice. Many providers protect LDP traffic today by running it over a layer of RSVP-TE FRR. That adds complexity and that is what this draft is trying to solve. On Wed, Aug 3, 2011 at 11:35 AM, Curtis Villamizar wrote= : > > In message > Sriganesh Kini writes: >> >> Hello, >> >> Regarding draft-kini-mpls-frr-ldp-01. >> >> We had feedback from the mpls WG to present this draft at RTGWG. Since >> our request for a slot was late, there is a chance that we may not >> have adequate time at the end of the session for this draft. In any >> case we wanted to make the WG aware of the draft and would appreciate >> any comments. >> >> Regards >> >> - Sri > > > Protection is inherently a traffic engineering problem. =A0IPFRR > provides mostly limited coverage protection, without the benefit of > signaled SRLG, and with increased potential of transient route loops > in the abense of complete and accurate SRLG information or when > multiple failures occur that are not covered by SRLG. > > LDP FRR has all the same issues as IPFRR. =A0So in general I don't > support LDP FRR. > > Even if I did support an LDP FRR, I don't think this draft offers a > good approach to LDP FRR. > > Curtis > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > --=20 - Sri From curtis@occnc.com Wed Aug 3 14:24:42 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C42011E8099 for ; Wed, 3 Aug 2011 14:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ht2aw5C-hZyI for ; Wed, 3 Aug 2011 14:24:42 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id DC01211E807C for ; Wed, 3 Aug 2011 14:24:41 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p73LNR3U020886; Wed, 3 Aug 2011 17:23:27 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201108032123.p73LNR3U020886@harbor.orleans.occnc.com> To: Sriganesh Kini From: Curtis Villamizar Subject: Re: draft-kini-mpls-frr-ldp-01 for review In-reply-to: Your message of "Wed, 03 Aug 2011 14:06:58 PDT." Date: Wed, 03 Aug 2011 17:23:27 -0400 Sender: curtis@occnc.com Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 21:24:42 -0000 In message Sriganesh Kini writes: > > Protection requires avoiding failures that can use some path > computation infrastructure that is also useful for TE, but that does > not make it the same as a TE problem. > > LDP FRR that relies on IPFRR (LFA) has limited coverage and associated > issues. The proposal is not relying on IPFRR. LDP is widely deployed, > so not supporting fast-reroute for LDP is definitely not a good > choice. Many providers protect LDP traffic today by running it over a > layer of RSVP-TE FRR. That adds complexity and that is what this draft > is trying to solve. I don't know of any providers that are asking for this solution. It may be a solution without a problem (and IMHO not a good solution at that). Curtis > On Wed, Aug 3, 2011 at 11:35 AM, Curtis Villamizar wrote: > > > > In message > > Sriganesh Kini writes: > >> > >> Hello, > >> > >> Regarding draft-kini-mpls-frr-ldp-01. > >> > >> We had feedback from the mpls WG to present this draft at RTGWG. Since > >> our request for a slot was late, there is a chance that we may not > >> have adequate time at the end of the session for this draft. In any > >> case we wanted to make the WG aware of the draft and would appreciate > >> any comments. > >> > >> Regards > >> > >> - Sri > > > > > > Protection is inherently a traffic engineering problem.  IPFRR > > provides mostly limited coverage protection, without the benefit of > > signaled SRLG, and with increased potential of transient route loops > > in the abense of complete and accurate SRLG information or when > > multiple failures occur that are not covered by SRLG. > > > > LDP FRR has all the same issues as IPFRR.  So in general I don't > > support LDP FRR. > > > > Even if I did support an LDP FRR, I don't think this draft offers a > > good approach to LDP FRR. > > > > Curtis > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg > > > > > > -- > - Sri From akatlas@gmail.com Wed Aug 3 14:25:01 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F95811E807C for ; Wed, 3 Aug 2011 14:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d61DGtUuK4HG for ; Wed, 3 Aug 2011 14:25:00 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id C123E11E80A8 for ; Wed, 3 Aug 2011 14:25:00 -0700 (PDT) Received: by pzk33 with SMTP id 33so2726939pzk.18 for ; Wed, 03 Aug 2011 14:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HQ/Mlyz+JcaEeAa89aljBs14gsBlJuyuZ4Iq66RGU7I=; b=HVDs1sdfSC7ujPjwgDK1GDjRlxmZ+D1r1fralbWfwGU3LQG5TRMVAPNkhqoakgJJan 5bxBbDQlbcfgi8YBfg3UYX4rutT35K7vyBLDskh1Uhy9eeIpOHX/d4+NtSs3UIRe06Ix LDLVlityiAIo76AlAvi2S7/aHDAo2sVqF4omU= MIME-Version: 1.0 Received: by 10.142.82.21 with SMTP id f21mr5360105wfb.398.1312406713539; Wed, 03 Aug 2011 14:25:13 -0700 (PDT) Received: by 10.68.50.6 with HTTP; Wed, 3 Aug 2011 14:25:13 -0700 (PDT) In-Reply-To: References: <201108031835.p73IZRAY018569@harbor.orleans.occnc.com> Date: Wed, 3 Aug 2011 17:25:13 -0400 Message-ID: Subject: Re: draft-kini-mpls-frr-ldp-01 for review From: Alia Atlas To: Sriganesh Kini Content-Type: multipart/alternative; boundary=001636e90ec1f61cbd04a9a07f80 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 21:25:01 -0000 --001636e90ec1f61cbd04a9a07f80 Content-Type: text/plain; charset=ISO-8859-1 Speaking with the WG chair-hat off: I, obviously, agree that LDP fast-reroute is a useful feature to have. This draft, however, appears to trade off the computation of not-via alternates by each hop for PLR computation of the not-via and extending LDP to specifically signal an explicitly routed alternate. It adds back in EROs to LDP This requires more time after a failure to be protected against another one, because it depends on signaling the alternates after the failure. The ability to troubleshoot the new tunnels would appear necessary. The concerns with notvia have been related to the state installed in the forwarding plane, rather than the computation. In that regard, the only benefit is not requiring forwarding state for not-via addresses (or labels) that do not go through a particular node. However, it potentially adds state for each PLR that goes through a given node to a particular next-next-hop. Understanding the changes in state might be useful. It suffers from the same issues as not-via in that it requires tunneling and therefore requires targeted LDP sessions. It does not address how to handle multi-homed-prefixes where the next-next-hop is not in the local area. The basic idea doesn't go beyond LDP unicast, though IP unicast wouldn't be too hard to do. The only theoretical benefit appears to be not using RSVP-TE - but I don't see actual simplification of the created state or operation. I don't believe that avoiding RSVP-TE is its own goal - rather simplification (ok - 1 protocol) and ease of operation are important. Alia On Wed, Aug 3, 2011 at 5:06 PM, Sriganesh Kini wrote: > Protection requires avoiding failures that can use some path > computation infrastructure that is also useful for TE, but that does > not make it the same as a TE problem. > > LDP FRR that relies on IPFRR (LFA) has limited coverage and associated > issues. The proposal is not relying on IPFRR. LDP is widely deployed, > so not supporting fast-reroute for LDP is definitely not a good > choice. Many providers protect LDP traffic today by running it over a > layer of RSVP-TE FRR. That adds complexity and that is what this draft > is trying to solve. > > > On Wed, Aug 3, 2011 at 11:35 AM, Curtis Villamizar > wrote: > > > > In message < > CAOndX-tcB4UVQnWKKoRcdEp6h2jTRAAHFBWLqq-qwgnV5bUD-g@mail.gmail.com> > > Sriganesh Kini writes: > >> > >> Hello, > >> > >> Regarding draft-kini-mpls-frr-ldp-01. > >> > >> We had feedback from the mpls WG to present this draft at RTGWG. Since > >> our request for a slot was late, there is a chance that we may not > >> have adequate time at the end of the session for this draft. In any > >> case we wanted to make the WG aware of the draft and would appreciate > >> any comments. > >> > >> Regards > >> > >> - Sri > > > > > > Protection is inherently a traffic engineering problem. IPFRR > > provides mostly limited coverage protection, without the benefit of > > signaled SRLG, and with increased potential of transient route loops > > in the abense of complete and accurate SRLG information or when > > multiple failures occur that are not covered by SRLG. > > > > LDP FRR has all the same issues as IPFRR. So in general I don't > > support LDP FRR. > > > > Even if I did support an LDP FRR, I don't think this draft offers a > > good approach to LDP FRR. > > > > Curtis > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg > > > > > > -- > - Sri > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > --001636e90ec1f61cbd04a9a07f80 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Speaking with the WG chair-hat off:

I, obviously, agree that LDP fas= t-reroute is a useful feature to have.

This draft, however, appears = to trade off the computation of not-via alternates
by each hop for PLR c= omputation of the not-via and extending LDP to specifically
signal an explicitly routed alternate.=A0 It adds back in EROs to LDP
This requires more time after a failure to be protected against another o= ne, because
it depends on signaling the alternates after the failure.=A0= The ability to troubleshoot the new tunnels would appear necessary.

The concerns with notvia have been related to the state installed in th= e forwarding plane, rather than the computation.=A0 In that regard, the onl= y benefit is not requiring forwarding state for not-via addresses (or label= s) that do not go through a particular node.=A0=A0 However, it potentially = adds state for each PLR that goes through a given node to a particular next= -next-hop.=A0 Understanding the changes in state might be useful.

It suffers from the same issues as not-via in that it requires tunnelin= g and therefore requires targeted LDP sessions.=A0 It does not address how = to handle multi-homed-prefixes where the next-next-hop is not in the local = area.

The basic idea doesn't go beyond LDP unicast, though IP unicast wou= ldn't be too hard to do.

The only theoretical benefit appears to= be not using RSVP-TE - but I don't see actual simplification of the cr= eated state or operation.=A0 I don't believe that avoiding RSVP-TE=A0 i= s its own goal - rather simplification (ok - 1 protocol) and ease of operat= ion are important.

Alia

On Wed, Aug 3, 2011 at 5:06 PM, = Sriganesh Kini <sriganesh.kini@ericsson.com> wrote:
Protection requires avoiding failures that can use some path
computation infrastructure that is also useful for TE, but that does
not make it the same as a TE problem.

LDP FRR that relies on IPFRR (LFA) has limited coverage and associated
issues. The proposal is not relying on IPFRR. LDP is widely deployed,
so not supporting fast-reroute for LDP is definitely not a good
choice. Many providers protect LDP traffic today by running it over a
layer of RSVP-TE FRR. That adds complexity and that is what this draft
is trying to solve.


On Wed, Aug 3, 2011 at 11:35 AM, Curtis Villamizar <curtis@occnc.com> wrote:
>
> In message <CAOndX-tcB4UVQnWKKoRcdEp6h2jTRAAHFBWLqq-qwgn= V5bUD-g@mail.gmail.com>
> Sriganesh Kini writes:
>>
>> Hello,
>>
>> Regarding draft-kini-mpls-frr-ldp-01.
>>
>> We had feedback from the mpls WG to present this draft at RTGWG. S= ince
>> our request for a slot was late, there is a chance that we may not=
>> have adequate time at the end of the session for this draft. In an= y
>> case we wanted to make the WG aware of the draft and would appreci= ate
>> any comments.
>>
>> Regards
>>
>> - Sri
>
>
> Protection is inherently a traffic engineering problem. =A0IPFRR
> provides mostly limited coverage protection, without the benefit of > signaled SRLG, and with increased potential of transient route loops > in the abense of complete and accurate SRLG information or when
> multiple failures occur that are not covered by SRLG.
>
> LDP FRR has all the same issues as IPFRR. =A0So in general I don't=
> support LDP FRR.
>
> Even if I did support an LDP FRR, I don't think this draft offers = a
> good approach to LDP FRR.
>
> Curtis
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>



--
- Sri
__________________________________= _____________
rtgwg mailing list
rtgwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtgwg

--001636e90ec1f61cbd04a9a07f80-- From sriganeshkini@gmail.com Wed Aug 3 15:05:26 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C489211E80A9 for ; Wed, 3 Aug 2011 15:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEOpH2UXm6lI for ; Wed, 3 Aug 2011 15:05:25 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A5DCC21F8752 for ; Wed, 3 Aug 2011 15:05:25 -0700 (PDT) Received: by vxi40 with SMTP id 40so1228124vxi.31 for ; Wed, 03 Aug 2011 15:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=MJKZNV2qReJaIoj+idZTDloWH7o3gugj1tQUa53CTdo=; b=e+HHaxMWaQh+Gll4N4QiiPj2oIRtOLbmzb8TrCzmXVnHtgH3pA9KvBb3PTr8lQ01AE hjEEGo1vB02VixkTIqgIs8djoyYwtr8F8zot8v/z3usLPuuJBTustTtsbrcwvU6T65Dv eABN1s00NW2R+l4bqymQyogUl/tnCNVHPjXrI= Received: by 10.52.176.103 with SMTP id ch7mr93886vdc.59.1312409138139; Wed, 03 Aug 2011 15:05:38 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.52.184.68 with HTTP; Wed, 3 Aug 2011 15:05:08 -0700 (PDT) In-Reply-To: References: <201108031835.p73IZRAY018569@harbor.orleans.occnc.com> From: Sriganesh Kini Date: Wed, 3 Aug 2011 15:05:08 -0700 X-Google-Sender-Auth: 9f5Fa7lhR4jItjKfzY-ooDkTNrg Message-ID: Subject: Re: draft-kini-mpls-frr-ldp-01 for review To: Alia Atlas Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 22:05:26 -0000 inline On Wed, Aug 3, 2011 at 2:25 PM, Alia Atlas wrote: > Speaking with the WG chair-hat off: > > I, obviously, agree that LDP fast-reroute is a useful feature to have. > > This draft, however, appears to trade off the computation of not-via > alternates > by each hop for PLR computation of the not-via and extending LDP to > specifically > signal an explicitly routed alternate.=A0 It adds back in EROs to LDP The explicit backup-path is used only in cases where shortest-path is not available. In many common topologies that we analyzed, the shortest-path is sufficient as backup. Even when a single shortest-path is insufficient, a combination of shortest-paths interconnected by a minimal number of explicit label-swap actions are sufficient. > > This requires more time after a failure to be protected against another o= ne, > because > it depends on signaling the alternates after the failure.=A0 The ability = to > troubleshoot the new tunnels would appear necessary. Multiple failures that are covered within an SRLG are protected when the first failure occurs. Those that are not covered have a low probability and/or will have traffic loss till re-computation. With modern hw the re-computation time should be fairly small. The order of traffic loss should be the same as that with shortest-path re-computation. > > The concerns with notvia have been related to the state installed in the > forwarding plane, rather than the computation.=A0 In that regard, the onl= y > benefit is not requiring forwarding state for not-via addresses (or label= s) > that do not go through a particular node.=A0=A0 However, it potentially a= dds > state for each PLR that goes through a given node to a particular > next-next-hop.=A0 Understanding the changes in state might be useful. The presentation (in MPLS WG) described the change in state for some sample topologies. We are planning to add an applicability section/draft especially for topologies of interest from service providers. > > It suffers from the same issues as not-via in that it requires tunneling = and > therefore requires targeted LDP sessions.=A0 It does not address how to h= andle > multi-homed-prefixes where the next-next-hop is not in the local area. The number of targeted LDP sessions is not much in our analysis of common topologies. Some of the results were presented. Even if number of LDP sessions is indeed a big concern, the protocol extensions defined can use explicit routing for label advertisements and avoid the targeted sessions. Multi-homed prefixes are handled. Correct that when going across areas more topology info and/or more (redundant) link-state advertisements may be needed. > > The basic idea doesn't go beyond LDP unicast, though IP unicast wouldn't = be > too hard to do. This can handle multicast too. But we haven't worked out all the details/cases yet. The draft will be updated for this. > > The only theoretical benefit appears to be not using RSVP-TE - but I don'= t > see actual simplification of the created state or operation.=A0 I don't > believe that avoiding RSVP-TE=A0 is its own goal - rather simplification = (ok - > 1 protocol) and ease of operation are important. The simplification of state is mainly due to re-using most of the existing shortest-path state. Simplification and opex-reduction due to less protocols is an important practical consideration. > > Alia > > On Wed, Aug 3, 2011 at 5:06 PM, Sriganesh Kini > wrote: >> >> Protection requires avoiding failures that can use some path >> computation infrastructure that is also useful for TE, but that does >> not make it the same as a TE problem. >> >> LDP FRR that relies on IPFRR (LFA) has limited coverage and associated >> issues. The proposal is not relying on IPFRR. LDP is widely deployed, >> so not supporting fast-reroute for LDP is definitely not a good >> choice. Many providers protect LDP traffic today by running it over a >> layer of RSVP-TE FRR. That adds complexity and that is what this draft >> is trying to solve. >> >> >> On Wed, Aug 3, 2011 at 11:35 AM, Curtis Villamizar >> wrote: >> > >> > In message >> > >> > Sriganesh Kini writes: >> >> >> >> Hello, >> >> >> >> Regarding draft-kini-mpls-frr-ldp-01. >> >> >> >> We had feedback from the mpls WG to present this draft at RTGWG. Sinc= e >> >> our request for a slot was late, there is a chance that we may not >> >> have adequate time at the end of the session for this draft. In any >> >> case we wanted to make the WG aware of the draft and would appreciate >> >> any comments. >> >> >> >> Regards >> >> >> >> - Sri >> > >> > >> > Protection is inherently a traffic engineering problem. =A0IPFRR >> > provides mostly limited coverage protection, without the benefit of >> > signaled SRLG, and with increased potential of transient route loops >> > in the abense of complete and accurate SRLG information or when >> > multiple failures occur that are not covered by SRLG. >> > >> > LDP FRR has all the same issues as IPFRR. =A0So in general I don't >> > support LDP FRR. >> > >> > Even if I did support an LDP FRR, I don't think this draft offers a >> > good approach to LDP FRR. >> > >> > Curtis >> > _______________________________________________ >> > rtgwg mailing list >> > rtgwg@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtgwg >> > >> >> >> >> -- >> - Sri >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > > --=20 - Sri From jeff.tantsura@ericsson.com Wed Aug 3 15:52:49 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A947821F857D for ; Wed, 3 Aug 2011 15:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hy4C4rufaOCC for ; Wed, 3 Aug 2011 15:52:49 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6DA21F8574 for ; Wed, 3 Aug 2011 15:52:49 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p73Mr01i027742; Wed, 3 Aug 2011 17:53:01 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.59]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 3 Aug 2011 18:52:55 -0400 From: Jeff Tantsura To: "curtis@occnc.com" , Sriganesh Kini Date: Wed, 3 Aug 2011 18:52:53 -0400 Subject: RE: draft-kini-mpls-frr-ldp-01 for review Thread-Topic: draft-kini-mpls-frr-ldp-01 for review Thread-Index: AcxSDFFf/tSmFZvXRqeerNJrsBUcHQAI696A Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60CCA31C45D@EUSAACMS0701.eamcs.ericsson.se> References: Your message of "Mon, 25 Jul 2011 14:09:47 PDT." <201108031835.p73IZRAY018569@harbor.orleans.occnc.com> In-Reply-To: <201108031835.p73IZRAY018569@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 22:52:49 -0000 Hi Curtis, Irrespectively of this draft thanks to GMPLS IGP extensions as per RFC's 4203 & 5307 SRLG info is there, it is up to implementation how to use= it. =20 Regards, Jeff =20 -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of C= urtis Villamizar Sent: Wednesday, August 03, 2011 11:35 To: Sriganesh Kini Cc: rtgwg@ietf.org Subject: Re: draft-kini-mpls-frr-ldp-01 for review=20 In message Sriganesh Kini writes: > =20 > Hello, > =20 > Regarding draft-kini-mpls-frr-ldp-01. > =20 > We had feedback from the mpls WG to present this draft at RTGWG. Since > our request for a slot was late, there is a chance that we may not > have adequate time at the end of the session for this draft. In any > case we wanted to make the WG aware of the draft and would appreciate > any comments. > =20 > Regards > =20 > - Sri Protection is inherently a traffic engineering problem. IPFRR provides mostly limited coverage protection, without the benefit of signaled SRLG, and with increased potential of transient route loops in the abense of complete and accurate SRLG information or when multiple failures occur that are not covered by SRLG. LDP FRR has all the same issues as IPFRR. So in general I don't support LDP FRR. Even if I did support an LDP FRR, I don't think this draft offers a good approach to LDP FRR. Curtis _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From curtis@occnc.com Wed Aug 3 16:34:02 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C60121F8AF1 for ; Wed, 3 Aug 2011 16:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evoRwn7HUaEF for ; Wed, 3 Aug 2011 16:34:01 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 85EFF21F85B1 for ; Wed, 3 Aug 2011 16:34:01 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p73NWqjj022714; Wed, 3 Aug 2011 19:32:52 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201108032332.p73NWqjj022714@harbor.orleans.occnc.com> To: Jeff Tantsura From: Curtis Villamizar Subject: Re: draft-kini-mpls-frr-ldp-01 for review In-reply-to: Your message of "Wed, 03 Aug 2011 18:52:53 EDT." <0ED867EB33AB2B45AAB470D5A64CDBF60CCA31C45D@EUSAACMS0701.eamcs.ericsson.se> Date: Wed, 03 Aug 2011 19:32:52 -0400 Sender: curtis@occnc.com Cc: "rtgwg@ietf.org" , Sriganesh Kini X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 23:34:02 -0000 In message <0ED867EB33AB2B45AAB470D5A64CDBF60CCA31C45D@EUSAACMS0701.eamcs.ericsson.se> Jeff Tantsura writes: > > Hi Curtis, > > Irrespectively of this draft thanks to GMPLS IGP extensions as per > RFC's 4203 & 5307 SRLG info is there, it is up to implementation how > to use it. > > Regards, > Jeff Those are in the extensions for GMPLS which is a superset of RSVP-TE based MPLS. These are sub-TLV added to the Link TLV which provides a good part of the TE-LSDB used by RSVP-TE. With that you get available bandwidth at each priority level, the RSVP-TE 32 bit link attribute vector and other niceties that should have nothing to do with LDP. For example, in RFC-3060 where Link TLV is defined for OSPF. The following sub-TLVs of the Link TLV are defined: 1 - Link type (1 octet) 2 - Link ID (4 octets) 3 - Local interface IP address (4 octets) 4 - Remote interface IP address (4 octets) 5 - Traffic engineering metric (4 octets) 6 - Maximum bandwidth (4 octets) 7 - Maximum reservable bandwidth (4 octets) 8 - Unreserved bandwidth (32 octets) 9 - Administrative group (4 octets) That is what is being extended in RFC4203. So don't run RSVP-TE, just half of it. Then compute LDP paths? Sounds too much like CR-LDP to me. If we reinvent half of RSVP-TE, why not all of it. OTOH, why not just run half of it. Use RSVP-TE LSP with zero BW and MPLS FRR [RFC4090] and forget LDP except for PW signaling. Curtis > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Curtis Villamizar > Sent: Wednesday, August 03, 2011 11:35 > To: Sriganesh Kini > Cc: rtgwg@ietf.org > Subject: Re: draft-kini-mpls-frr-ldp-01 for review > > > In message > Sriganesh Kini writes: > > > > Hello, > > > > Regarding draft-kini-mpls-frr-ldp-01. > > > > We had feedback from the mpls WG to present this draft at RTGWG. Since > > our request for a slot was late, there is a chance that we may not > > have adequate time at the end of the session for this draft. In any > > case we wanted to make the WG aware of the draft and would appreciate > > any comments. > > > > Regards > > > > - Sri > > > Protection is inherently a traffic engineering problem. IPFRR > provides mostly limited coverage protection, without the benefit of > signaled SRLG, and with increased potential of transient route loops > in the abense of complete and accurate SRLG information or when > multiple failures occur that are not covered by SRLG. > > LDP FRR has all the same issues as IPFRR. So in general I don't > support LDP FRR. > > Even if I did support an LDP FRR, I don't think this draft offers a > good approach to LDP FRR. > > Curtis From sriganeshkini@gmail.com Wed Aug 3 17:01:26 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F1611E80AD for ; Wed, 3 Aug 2011 17:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIDqOW4J3fJr for ; Wed, 3 Aug 2011 17:01:25 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4B85821F86CA for ; Wed, 3 Aug 2011 17:01:25 -0700 (PDT) Received: by vws12 with SMTP id 12so77611vws.31 for ; Wed, 03 Aug 2011 17:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=AX8h5Nmw6d7e9V8U+f8uyAzuLDvw2o77leBST7zz8H8=; b=FvQ8tfr7d2uDsHHMKgDG2o9RV3wmzEhTUuztG5572wwbQPoMUp16Xu6hmbt77eGVB5 ZK1lVtRrhP7MQll1OWe5wyZ9F9NLjM/F9BYygXTRZjNoEq9L1/SIaFHWUy0L1M84+qdu is/RTqixvoWjOF3fkBQgp6Q7kGD+B4VPGgwNY= Received: by 10.52.188.6 with SMTP id fw6mr123890vdc.528.1312416098089; Wed, 03 Aug 2011 17:01:38 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.52.184.68 with HTTP; Wed, 3 Aug 2011 17:01:08 -0700 (PDT) In-Reply-To: <201108032332.p73NWqjj022714@harbor.orleans.occnc.com> References: <0ED867EB33AB2B45AAB470D5A64CDBF60CCA31C45D@EUSAACMS0701.eamcs.ericsson.se> <201108032332.p73NWqjj022714@harbor.orleans.occnc.com> From: Sriganesh Kini Date: Wed, 3 Aug 2011 17:01:08 -0700 X-Google-Sender-Auth: JuCHO4DKJizr9sv0S9XRqk5b3zM Message-ID: Subject: Re: draft-kini-mpls-frr-ldp-01 for review To: curtis@occnc.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 00:01:26 -0000 We are re-using whatever is available and is needed. SRLG info is needed at the nodes computing paths to protect the SRLG failure. Using an existing IGP mechanism to do just that is an option. Stretching this to imply that RSVP-TE is reinvented doesn't make sense. Many service providers who have LDP deployed simply don't want the additional complexity of deploying RSVP-TE but they do want sub 50msec protection with full coverage. Moreover RSVP-TE doesn't scale as well. On Wed, Aug 3, 2011 at 4:32 PM, Curtis Villamizar wrote: > > In message <0ED867EB33AB2B45AAB470D5A64CDBF60CCA31C45D@EUSAACMS0701.eamcs= .ericsson.se> > Jeff Tantsura writes: >> >> Hi Curtis, >> >> Irrespectively of this draft thanks to GMPLS IGP extensions as per >> RFC's 4203 & 5307 SRLG info is there, it is up to implementation how >> to use it. >> >> Regards, >> Jeff > > > Those are in the extensions for GMPLS which is a superset of RSVP-TE > based MPLS. =A0These are sub-TLV added to the Link TLV which provides > a good part of the TE-LSDB used by RSVP-TE. =A0With that you get > available bandwidth at each priority level, the RSVP-TE 32 bit link > attribute vector and other niceties that should have nothing to do > with LDP. > > For example, in RFC-3060 where Link TLV is defined for OSPF. > > =A0 The following sub-TLVs of the Link TLV are defined: > > =A0 =A0 =A01 - Link type (1 octet) > =A0 =A0 =A02 - Link ID (4 octets) > =A0 =A0 =A03 - Local interface IP address (4 octets) > =A0 =A0 =A04 - Remote interface IP address (4 octets) > =A0 =A0 =A05 - Traffic engineering metric (4 octets) > =A0 =A0 =A06 - Maximum bandwidth (4 octets) > =A0 =A0 =A07 - Maximum reservable bandwidth (4 octets) > =A0 =A0 =A08 - Unreserved bandwidth (32 octets) > =A0 =A0 =A09 - Administrative group (4 octets) > > That is what is being extended in RFC4203. > > So don't run RSVP-TE, just half of it. =A0Then compute LDP paths? > Sounds too much like CR-LDP to me. > > If we reinvent half of RSVP-TE, why not all of it. =A0OTOH, why not just > run half of it. =A0Use RSVP-TE LSP with zero BW and MPLS FRR [RFC4090] > and forget LDP except for PW signaling. > > Curtis > > >> -----Original Message----- >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf O= f Curtis Villamizar >> Sent: Wednesday, August 03, 2011 11:35 >> To: Sriganesh Kini >> Cc: rtgwg@ietf.org >> Subject: Re: draft-kini-mpls-frr-ldp-01 for review >> >> >> In message >> Sriganesh Kini writes: >> > >> > Hello, >> > >> > Regarding draft-kini-mpls-frr-ldp-01. >> > >> > We had feedback from the mpls WG to present this draft at RTGWG. Since >> > our request for a slot was late, there is a chance that we may not >> > have adequate time at the end of the session for this draft. In any >> > case we wanted to make the WG aware of the draft and would appreciate >> > any comments. >> > >> > Regards >> > >> > - Sri >> >> >> Protection is inherently a traffic engineering problem. =A0IPFRR >> provides mostly limited coverage protection, without the benefit of >> signaled SRLG, and with increased potential of transient route loops >> in the abense of complete and accurate SRLG information or when >> multiple failures occur that are not covered by SRLG. >> >> LDP FRR has all the same issues as IPFRR. =A0So in general I don't >> support LDP FRR. >> >> Even if I did support an LDP FRR, I don't think this draft offers a >> good approach to LDP FRR. >> >> Curtis > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > --=20 - Sri From kireeti@juniper.net Thu Aug 4 01:54:30 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103DD21F8A7E for ; Thu, 4 Aug 2011 01:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEUnTK-UzX61 for ; Thu, 4 Aug 2011 01:54:29 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4F14921F8A6F for ; Thu, 4 Aug 2011 01:54:29 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTjpeUa/F1xV2D6xD1rX54OQPi+KCC1Sq@postini.com; Thu, 04 Aug 2011 01:54:43 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 4 Aug 2011 01:51:44 -0700 From: Kireeti Kompella To: "curtis@occnc.com" Date: Thu, 4 Aug 2011 01:51:40 -0700 Subject: Re: draft-kini-mpls-frr-ldp-01 for review Thread-Topic: draft-kini-mpls-frr-ldp-01 for review Thread-Index: AcxSg7xKMXbtPvKyQjOzNOKhv2x4cg== Message-ID: References: <201108032332.p73NWqjj022714@harbor.orleans.occnc.com> In-Reply-To: <201108032332.p73NWqjj022714@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 08:54:30 -0000 On Aug 3, 2011, at 16:34, "Curtis Villamizar" wrote: > forget LDP except for PW signaling Or better yet, not even for that. [donning Kevlar] K From curtis@occnc.com Thu Aug 4 06:14:51 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8006321F8B40 for ; Thu, 4 Aug 2011 06:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVxo8jJZSJPc for ; Thu, 4 Aug 2011 06:14:50 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9229F21F855A for ; Thu, 4 Aug 2011 06:14:50 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p74DDgda043410; Thu, 4 Aug 2011 09:13:42 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201108041313.p74DDgda043410@harbor.orleans.occnc.com> To: Sriganesh Kini From: Curtis Villamizar Subject: Re: draft-kini-mpls-frr-ldp-01 for review In-reply-to: Your message of "Wed, 03 Aug 2011 17:01:08 PDT." Date: Thu, 04 Aug 2011 09:13:42 -0400 Sender: curtis@occnc.com Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 13:14:51 -0000 In message Sriganesh Kini writes: > > We are re-using whatever is available and is needed. SRLG info is > needed at the nodes computing paths to protect the SRLG failure. Using > an existing IGP mechanism to do just that is an option. Stretching this to > imply that RSVP-TE is reinvented doesn't make sense. Many service > providers who have LDP deployed simply don't want the additional > complexity of deploying RSVP-TE but they do want sub 50msec protection > with full coverage. Moreover RSVP-TE doesn't scale as well. Additional complexity. Enable IGP-TE extensions and configure links, minimum is enable TE per link and advertise defaults. Define a mesh group. Configure defaults for mesh group at zero bandwidth and use of FRR. Done. That is not much complexity. The configuration is identical per node, except per link config since different nodes have different number and naming of links. This is both easy to set up and easily manageable. If later TE is desired, then either set autobandwidth on the mesh group or capture per LSP traffic measurements and begin configuring bandwidth amounts per LSP. The latter takes a small amount of work but is preferred by many service providers. Curtis > On Wed, Aug 3, 2011 at 4:32 PM, Curtis Villamizar wrote: > > > > In message <0ED867EB33AB2B45AAB470D5A64CDBF60CCA31C45D@EUSAACMS0701.eamcs.ericsson.se> > > Jeff Tantsura writes: > >> > >> Hi Curtis, > >> > >> Irrespectively of this draft thanks to GMPLS IGP extensions as per > >> RFC's 4203 & 5307 SRLG info is there, it is up to implementation how > >> to use it. > >> > >> Regards, > >> Jeff > > > > > > Those are in the extensions for GMPLS which is a superset of RSVP-TE > > based MPLS.  These are sub-TLV added to the Link TLV which provides > > a good part of the TE-LSDB used by RSVP-TE.  With that you get > > available bandwidth at each priority level, the RSVP-TE 32 bit link > > attribute vector and other niceties that should have nothing to do > > with LDP. > > > > For example, in RFC-3060 where Link TLV is defined for OSPF. > > > >   The following sub-TLVs of the Link TLV are defined: > > > >      1 - Link type (1 octet) > >      2 - Link ID (4 octets) > >      3 - Local interface IP address (4 octets) > >      4 - Remote interface IP address (4 octets) > >      5 - Traffic engineering metric (4 octets) > >      6 - Maximum bandwidth (4 octets) > >      7 - Maximum reservable bandwidth (4 octets) > >      8 - Unreserved bandwidth (32 octets) > >      9 - Administrative group (4 octets) > > > > That is what is being extended in RFC4203. > > > > So don't run RSVP-TE, just half of it.  Then compute LDP paths? > > Sounds too much like CR-LDP to me. > > > > If we reinvent half of RSVP-TE, why not all of it.  OTOH, why not just > > run half of it.  Use RSVP-TE LSP with zero BW and MPLS FRR [RFC4090] > > and forget LDP except for PW signaling. > > > > Curtis > > > > > >> -----Original Message----- > >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Curtis Villamizar > >> Sent: Wednesday, August 03, 2011 11:35 > >> To: Sriganesh Kini > >> Cc: rtgwg@ietf.org > >> Subject: Re: draft-kini-mpls-frr-ldp-01 for review > >> > >> > >> In message > >> Sriganesh Kini writes: > >> > > >> > Hello, > >> > > >> > Regarding draft-kini-mpls-frr-ldp-01. > >> > > >> > We had feedback from the mpls WG to present this draft at RTGWG. Since > >> > our request for a slot was late, there is a chance that we may not > >> > have adequate time at the end of the session for this draft. In any > >> > case we wanted to make the WG aware of the draft and would appreciate > >> > any comments. > >> > > >> > Regards > >> > > >> > - Sri > >> > >> > >> Protection is inherently a traffic engineering problem.  IPFRR > >> provides mostly limited coverage protection, without the benefit of > >> signaled SRLG, and with increased potential of transient route loops > >> in the abense of complete and accurate SRLG information or when > >> multiple failures occur that are not covered by SRLG. > >> > >> LDP FRR has all the same issues as IPFRR.  So in general I don't > >> support LDP FRR. > >> > >> Even if I did support an LDP FRR, I don't think this draft offers a > >> good approach to LDP FRR. > >> > >> Curtis > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg > > > > > > -- > - Sri From curtis@occnc.com Thu Aug 4 06:43:52 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DE421F8B04 for ; Thu, 4 Aug 2011 06:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+Yw7BOIhvqD for ; Thu, 4 Aug 2011 06:43:51 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7648321F8531 for ; Thu, 4 Aug 2011 06:43:51 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p74DgkvD043698; Thu, 4 Aug 2011 09:42:46 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201108041342.p74DgkvD043698@harbor.orleans.occnc.com> To: Kireeti Kompella From: Curtis Villamizar Subject: Re: draft-kini-mpls-frr-ldp-01 for review In-reply-to: Your message of "Thu, 04 Aug 2011 01:51:40 PDT." Date: Thu, 04 Aug 2011 09:42:46 -0400 Sender: curtis@occnc.com Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 13:43:52 -0000 In message Kireeti Kompella writes: > > On Aug 3, 2011, at 16:34, "Curtis Villamizar" wrote: > > > forget LDP except for PW signaling > > Or better yet, not even for that. > > [donning Kevlar] > > K Yes. I agree. With MS-PW it is now time to define a PW signaling based on RSVP-TE. But we are not there yet. The good news is it appears that Kireeti just volunteered. We look forward to the -00 draft. :-) Thanks, Curtis From kireeti@juniper.net Thu Aug 4 08:02:20 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6411521F8B21 for ; Thu, 4 Aug 2011 08:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C79Low58w9xA for ; Thu, 4 Aug 2011 08:02:20 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5E021F8B1D for ; Thu, 4 Aug 2011 08:02:19 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTjq0h5CSiUhI3wu6d9ovdmUBFw2rmSIv@postini.com; Thu, 04 Aug 2011 08:02:34 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 4 Aug 2011 08:02:11 -0700 From: Kireeti Kompella To: "curtis@occnc.com" Date: Thu, 4 Aug 2011 08:02:05 -0700 Subject: Re: draft-kini-mpls-frr-ldp-01 for review Thread-Topic: draft-kini-mpls-frr-ldp-01 for review Thread-Index: AcxSt3zrVjxtmicRReafu0XOh4dAsg== Message-ID: References: <201108041342.p74DgkvD043698@harbor.orleans.occnc.com> In-Reply-To: <201108041342.p74DgkvD043698@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 15:02:20 -0000 Hi Curtis, On Aug 4, 2011, at 6:44, "Curtis Villamizar" wrote: > With MS-PW it is now time to define a PW signaling > based on RSVP-TE. But we are not there yet. Yes, with MS-PW: "EROs" to thread the MS-PW through the stitching points, "= Traffic Params" for the MS-PW, and "detours" to protect against failures. Been there, had the discussions, suggested RSVP-TE, needed the Kevlar. No -= 00 from me any time soon. However, since then, (three years ago?), I've come to the conclusion that t= he MS-PW idea is flawed; the protocol used is secondary.=20 (Yes, Alia, doesn't belong on this list. Back to your regularly scheduled I= P/LDP FRR sans RSVP debate.) Kireeti From sriganeshkini@gmail.com Thu Aug 4 08:59:58 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C301B21F8B76 for ; Thu, 4 Aug 2011 08:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJI13JAa-jKn for ; Thu, 4 Aug 2011 08:59:58 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id DBEB521F8B75 for ; Thu, 4 Aug 2011 08:59:57 -0700 (PDT) Received: by gwb20 with SMTP id 20so1323439gwb.31 for ; Thu, 04 Aug 2011 09:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=VV9gfrxRCphD0ampqySJCrCx3euAwDxbULxxBFFB38Y=; b=H4t1qmjfocUhlD8h11oYc1vf2SYIGWC5xdK712hqmZVznByKji/BvMO2JIfvz4p9rJ rLqeXs9RmyQNeDNA3r7rRCOkOsszppDhP3bluHIw5vJ8buiwjr+ZG/2Cvm8dgqsL+bKI q6xnYw2Sup2akoTdYEJJ/3j0Lg041YCKosaXQ= Received: by 10.142.199.9 with SMTP id w9mr976550wff.10.1312473612257; Thu, 04 Aug 2011 09:00:12 -0700 (PDT) Received: from [192.168.1.76] (75-54-225-99.lightspeed.frmtca.sbcglobal.net [75.54.225.99]) by mx.google.com with ESMTPS id v1sm2363371pbg.15.2011.08.04.09.00.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Aug 2011 09:00:11 -0700 (PDT) References: <201108041313.p74DDgda043410@harbor.orleans.occnc.com> In-Reply-To: <201108041313.p74DDgda043410@harbor.orleans.occnc.com> Mime-Version: 1.0 (iPad Mail 8L1) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <136C7651-8CCF-4CA7-814C-09F89D5C71F5@gmail.com> X-Mailer: iPad Mail (8L1) From: Sriganesh Kini Subject: Re: draft-kini-mpls-frr-ldp-01 for review Date: Thu, 4 Aug 2011 09:00:09 -0700 To: "curtis@occnc.com" Cc: "rtgwg@ietf.org" , Sriganesh Kini X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 15:59:58 -0000 Inline - Sri Sent from my iPad On Aug 4, 2011, at 6:13 AM, Curtis Villamizar wrote: >=20 > In message > Sriganesh Kini writes: >>=20 >> We are re-using whatever is available and is needed. SRLG info is >> needed at the nodes computing paths to protect the SRLG failure. Using >> an existing IGP mechanism to do just that is an option. Stretching this t= o >> imply that RSVP-TE is reinvented doesn't make sense. Many service >> providers who have LDP deployed simply don't want the additional >> complexity of deploying RSVP-TE but they do want sub 50msec protection >> with full coverage. Moreover RSVP-TE doesn't scale as well. >=20 >=20 > Additional complexity. No. Operationally the complexity is similar to running an LDP network. >=20 > Enable IGP-TE extensions and configure links, minimum is enable TE > per link and advertise defaults. >=20 > Define a mesh group. >=20 > Configure defaults for mesh group at zero bandwidth and use of FRR. >=20 > Done. Full mesh is not as scalable. >=20 > That is not much complexity. The configuration is identical per node, > except per link config since different nodes have different number and > naming of links. This is both easy to set up and easily manageable. >=20 > If later TE is desired, then either set autobandwidth on the mesh > group or capture per LSP traffic measurements and begin configuring > bandwidth amounts per LSP. The latter takes a small amount of work > but is preferred by many service providers. Maybe this is true for some providers that you are aware of. But I have seen= many providers prefer to run an LDP network and want full coverage protecti= on. >=20 > Curtis >=20 >=20 >=20 >> On Wed, Aug 3, 2011 at 4:32 PM, Curtis Villamizar wrot= e: >>>=20 >>> In message <0ED867EB33AB2B45AAB470D5A64CDBF60CCA31C45D@EUSAACMS0701.eamc= s.ericsson.se> >>> Jeff Tantsura writes: >>>>=20 >>>> Hi Curtis, >>>>=20 >>>> Irrespectively of this draft thanks to GMPLS IGP extensions as per >>>> RFC's 4203 & 5307 SRLG info is there, it is up to implementation how >>>> to use it. >>>>=20 >>>> Regards, >>>> Jeff >>>=20 >>>=20 >>> Those are in the extensions for GMPLS which is a superset of RSVP-TE >>> based MPLS. These are sub-TLV added to the Link TLV which provides >>> a good part of the TE-LSDB used by RSVP-TE. With that you get >>> available bandwidth at each priority level, the RSVP-TE 32 bit link >>> attribute vector and other niceties that should have nothing to do >>> with LDP. >>>=20 >>> For example, in RFC-3060 where Link TLV is defined for OSPF. >>>=20 >>> The following sub-TLVs of the Link TLV are defined: >>>=20 >>> 1 - Link type (1 octet) >>> 2 - Link ID (4 octets) >>> 3 - Local interface IP address (4 octets) >>> 4 - Remote interface IP address (4 octets) >>> 5 - Traffic engineering metric (4 octets) >>> 6 - Maximum bandwidth (4 octets) >>> 7 - Maximum reservable bandwidth (4 octets) >>> 8 - Unreserved bandwidth (32 octets) >>> 9 - Administrative group (4 octets) >>>=20 >>> That is what is being extended in RFC4203. >>>=20 >>> So don't run RSVP-TE, just half of it. Then compute LDP paths? >>> Sounds too much like CR-LDP to me. >>>=20 >>> If we reinvent half of RSVP-TE, why not all of it. OTOH, why not just >>> run half of it. Use RSVP-TE LSP with zero BW and MPLS FRR [RFC4090] >>> and forget LDP except for PW signaling. >>>=20 >>> Curtis >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf O= f Curtis Villamizar >>>> Sent: Wednesday, August 03, 2011 11:35 >>>> To: Sriganesh Kini >>>> Cc: rtgwg@ietf.org >>>> Subject: Re: draft-kini-mpls-frr-ldp-01 for review >>>>=20 >>>>=20 >>>> In message >>>> Sriganesh Kini writes: >>>>>=20 >>>>> Hello, >>>>>=20 >>>>> Regarding draft-kini-mpls-frr-ldp-01. >>>>>=20 >>>>> We had feedback from the mpls WG to present this draft at RTGWG. Since= >>>>> our request for a slot was late, there is a chance that we may not >>>>> have adequate time at the end of the session for this draft. In any >>>>> case we wanted to make the WG aware of the draft and would appreciate >>>>> any comments. >>>>>=20 >>>>> Regards >>>>>=20 >>>>> - Sri >>>>=20 >>>>=20 >>>> Protection is inherently a traffic engineering problem. IPFRR >>>> provides mostly limited coverage protection, without the benefit of >>>> signaled SRLG, and with increased potential of transient route loops >>>> in the abense of complete and accurate SRLG information or when >>>> multiple failures occur that are not covered by SRLG. >>>>=20 >>>> LDP FRR has all the same issues as IPFRR. So in general I don't >>>> support LDP FRR. >>>>=20 >>>> Even if I did support an LDP FRR, I don't think this draft offers a >>>> good approach to LDP FRR. >>>>=20 >>>> Curtis >>> _______________________________________________ >>> rtgwg mailing list >>> rtgwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtgwg >>>=20 >>=20 >>=20 >>=20 >> --=20 >> - Sri >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From eosborne@cisco.com Thu Aug 4 09:15:56 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7893421F8B89 for ; Thu, 4 Aug 2011 09:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uao+3hr83tuf for ; Thu, 4 Aug 2011 09:15:55 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1802D21F8B78 for ; Thu, 4 Aug 2011 09:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=7242; q=dns/txt; s=iport; t=1312474570; x=1313684170; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=4CftbmwbxIQAd5z+5tUGAbQKDi3DG8tAcVqsm50Gu5c=; b=AlbaZynSHHKWXJrz29Li48Fi9B2B4hw50EUfZaFWsSVlvcPYUIPxBzB/ LcIXvATuLW/PBTe6KJ1SVPWibc6lLO5KhX6Tol9wYYZtThja84VAxJ2ZF nTd2n6DpiWFPZZcwKgWL2w8X3eR2LSAeKUcuJ2GA0CGPCBoC5R/ovKF7R Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAAKLFOk6tJXG9/2dsb2JhbABDmAyPXHeBQAEBAQEDAQEBDwEdCjQLDAQCAQgRBAEBAQoGFwEGASYfCQgBAQQBEggTB4dOolkBnnyFY18Eh1qQMYty X-IronPort-AV: E=Sophos;i="4.67,317,1309737600"; d="scan'208";a="9704138" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 04 Aug 2011 16:16:10 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p74GG94x001002; Thu, 4 Aug 2011 16:16:09 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Aug 2011 11:16:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-kini-mpls-frr-ldp-01 for review Date: Thu, 4 Aug 2011 11:16:06 -0500 Message-ID: In-Reply-To: <136C7651-8CCF-4CA7-814C-09F89D5C71F5@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-kini-mpls-frr-ldp-01 for review Thread-Index: AcxSv5xq8K2D8F1VQQK9oIYL00SM5QAAVigQ References: <201108041313.p74DDgda043410@harbor.orleans.occnc.com> <136C7651-8CCF-4CA7-814C-09F89D5C71F5@gmail.com> From: "Eric Osborne (eosborne)" To: "Sriganesh Kini" , X-OriginalArrivalTime: 04 Aug 2011 16:16:09.0751 (UTC) FILETIME=[D24FC270:01CC52C1] Cc: Sriganesh Kini , rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 16:15:56 -0000 You say that your solution is simpler than a TE deployment, but you're comparing the wrong things.=20 It is possible to use LFA or something similar for the cases where it works and to use an explicitly routed RSVP-TE path to provide a backup path for cases where LFA doesn't work. This is what you ought to compare to your solution. How much simpler is your solution than what I've described above? They both need - link-state information available for explicit paths - srlg info available, should one want to use it - explicit routing control, even if the paths are dynamically calculated per PLR At that point the only difference I see between what RSVP does and what you want to do with LDP is you have two different protcols. If you want to argue that LDP is 'simple' and RSVP is 'complex' you can't take all the good stuff out of RSVP which gives it its complexity in the first place, put it in LDP and then argue that LDP is still 'simple'. Also, CR-LDP is dead. rfc3468. What is different between your proposed changes to LDP and what CR-LDP did? eric > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of > Sriganesh Kini > Sent: Thursday, August 04, 2011 12:00 PM > To: curtis@occnc.com > Cc: rtgwg@ietf.org; Sriganesh Kini > Subject: Re: draft-kini-mpls-frr-ldp-01 for review >=20 > Inline >=20 > - Sri >=20 > Sent from my iPad >=20 > On Aug 4, 2011, at 6:13 AM, Curtis Villamizar wrote: >=20 > > > > In message > > > > Sriganesh Kini writes: > >> > >> We are re-using whatever is available and is needed. SRLG info is > >> needed at the nodes computing paths to protect the SRLG failure. > >> Using an existing IGP mechanism to do just that is an option. > >> Stretching this to imply that RSVP-TE is reinvented doesn't make > >> sense. Many service providers who have LDP deployed simply don't want > >> the additional complexity of deploying RSVP-TE but they do want sub > >> 50msec protection with full coverage. Moreover RSVP-TE doesn't scale as > well. > > > > > > Additional complexity. >=20 > No. Operationally the complexity is similar to running an LDP network. >=20 > > > > Enable IGP-TE extensions and configure links, minimum is enable TE > > per link and advertise defaults. > > > > Define a mesh group. > > > > Configure defaults for mesh group at zero bandwidth and use of FRR. > > > > Done. >=20 > Full mesh is not as scalable. >=20 > > > > That is not much complexity. The configuration is identical per node, > > except per link config since different nodes have different number and > > naming of links. This is both easy to set up and easily manageable. > > > > If later TE is desired, then either set autobandwidth on the mesh > > group or capture per LSP traffic measurements and begin configuring > > bandwidth amounts per LSP. The latter takes a small amount of work > > but is preferred by many service providers. >=20 > Maybe this is true for some providers that you are aware of. But I have > seen many providers prefer to run an LDP network and want full coverage > protection. >=20 > > > > Curtis > > > > > > > >> On Wed, Aug 3, 2011 at 4:32 PM, Curtis Villamizar > wrote: > >>> > >>> In message > >>> <0ED867EB33AB2B45AAB470D5A64CDBF60CCA31C45D@EUSAACMS0701.eamcs.erics > >>> son.se> > >>> Jeff Tantsura writes: > >>>> > >>>> Hi Curtis, > >>>> > >>>> Irrespectively of this draft thanks to GMPLS IGP extensions as per > >>>> RFC's 4203 & 5307 SRLG info is there, it is up to implementation > >>>> how to use it. > >>>> > >>>> Regards, > >>>> Jeff > >>> > >>> > >>> Those are in the extensions for GMPLS which is a superset of RSVP-TE > >>> based MPLS. These are sub-TLV added to the Link TLV which provides > >>> a good part of the TE-LSDB used by RSVP-TE. With that you get > >>> available bandwidth at each priority level, the RSVP-TE 32 bit link > >>> attribute vector and other niceties that should have nothing to do > >>> with LDP. > >>> > >>> For example, in RFC-3060 where Link TLV is defined for OSPF. > >>> > >>> The following sub-TLVs of the Link TLV are defined: > >>> > >>> 1 - Link type (1 octet) > >>> 2 - Link ID (4 octets) > >>> 3 - Local interface IP address (4 octets) > >>> 4 - Remote interface IP address (4 octets) > >>> 5 - Traffic engineering metric (4 octets) > >>> 6 - Maximum bandwidth (4 octets) > >>> 7 - Maximum reservable bandwidth (4 octets) > >>> 8 - Unreserved bandwidth (32 octets) > >>> 9 - Administrative group (4 octets) > >>> > >>> That is what is being extended in RFC4203. > >>> > >>> So don't run RSVP-TE, just half of it. Then compute LDP paths? > >>> Sounds too much like CR-LDP to me. > >>> > >>> If we reinvent half of RSVP-TE, why not all of it. OTOH, why not > >>> just run half of it. Use RSVP-TE LSP with zero BW and MPLS FRR > >>> [RFC4090] and forget LDP except for PW signaling. > >>> > >>> Curtis > >>> > >>> > >>>> -----Original Message----- > >>>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On > >>>> Behalf Of Curtis Villamizar > >>>> Sent: Wednesday, August 03, 2011 11:35 > >>>> To: Sriganesh Kini > >>>> Cc: rtgwg@ietf.org > >>>> Subject: Re: draft-kini-mpls-frr-ldp-01 for review > >>>> > >>>> > >>>> In message > >>>> >>>> > > >>>> Sriganesh Kini writes: > >>>>> > >>>>> Hello, > >>>>> > >>>>> Regarding draft-kini-mpls-frr-ldp-01. > >>>>> > >>>>> We had feedback from the mpls WG to present this draft at RTGWG. > >>>>> Since our request for a slot was late, there is a chance that we > >>>>> may not have adequate time at the end of the session for this > >>>>> draft. In any case we wanted to make the WG aware of the draft and > >>>>> would appreciate any comments. > >>>>> > >>>>> Regards > >>>>> > >>>>> - Sri > >>>> > >>>> > >>>> Protection is inherently a traffic engineering problem. IPFRR > >>>> provides mostly limited coverage protection, without the benefit of > >>>> signaled SRLG, and with increased potential of transient route > >>>> loops in the abense of complete and accurate SRLG information or > >>>> when multiple failures occur that are not covered by SRLG. > >>>> > >>>> LDP FRR has all the same issues as IPFRR. So in general I don't > >>>> support LDP FRR. > >>>> > >>>> Even if I did support an LDP FRR, I don't think this draft offers a > >>>> good approach to LDP FRR. > >>>> > >>>> Curtis > >>> _______________________________________________ > >>> rtgwg mailing list > >>> rtgwg@ietf.org > >>> https://www.ietf.org/mailman/listinfo/rtgwg > >>> > >> > >> > >> > >> -- > >> - Sri > > > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From jdrake@juniper.net Thu Aug 4 10:02:05 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42F621F8B75 for ; Thu, 4 Aug 2011 10:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.031 X-Spam-Level: X-Spam-Status: No, score=-6.031 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPIhD6uJ2NIL for ; Thu, 4 Aug 2011 10:02:04 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3E021F8B67 for ; Thu, 4 Aug 2011 10:02:04 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTjrQlssgS53lmqCxiVe2uKbd8Sm8DGiA@postini.com; Thu, 04 Aug 2011 10:02:20 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 4 Aug 2011 10:00:51 -0700 From: John E Drake To: "Eric Osborne (eosborne)" , Sriganesh Kini , "curtis@occnc.com" Date: Thu, 4 Aug 2011 10:00:48 -0700 Subject: RE: draft-kini-mpls-frr-ldp-01 for review Thread-Topic: draft-kini-mpls-frr-ldp-01 for review Thread-Index: AcxSv5xq8K2D8F1VQQK9oIYL00SM5QAAVigQAAHFMyA= Message-ID: <5E893DB832F57341992548CDBB333163A0AC0CCBBC@EMBX01-HQ.jnpr.net> References: <201108041313.p74DDgda043410@harbor.orleans.occnc.com> <136C7651-8CCF-4CA7-814C-09F89D5C71F5@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtgwg@ietf.org" , Sriganesh Kini X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 17:02:06 -0000 Nice Sent from my iPhone > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > Of Eric Osborne (eosborne) > Sent: Thursday, August 04, 2011 9:16 AM > To: Sriganesh Kini; curtis@occnc.com > Cc: Sriganesh Kini; rtgwg@ietf.org > Subject: RE: draft-kini-mpls-frr-ldp-01 for review >=20 > You say that your solution is simpler than a TE deployment, but you're > comparing the wrong things. >=20 > It is possible to use LFA or something similar for the cases where it > works and to use an explicitly routed RSVP-TE path to provide a backup > path for cases where LFA doesn't work. This is what you ought to > compare to your solution. >=20 > How much simpler is your solution than what I've described above? They > both need > - link-state information available for explicit paths > - srlg info available, should one want to use it > - explicit routing control, even if the paths are dynamically > calculated per PLR >=20 > At that point the only difference I see between what RSVP does and what > you want to do with LDP is you have two different protcols. If you > want > to argue that LDP is 'simple' and RSVP is 'complex' you can't take all > the good stuff out of RSVP which gives it its complexity in the first > place, put it in LDP and then argue that LDP is still 'simple'. >=20 > Also, CR-LDP is dead. rfc3468. > What is different between your proposed changes to LDP and what CR-LDP > did? >=20 >=20 >=20 >=20 > eric >=20 > > -----Original Message----- > > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On > Behalf > Of > > Sriganesh Kini > > Sent: Thursday, August 04, 2011 12:00 PM > > To: curtis@occnc.com > > Cc: rtgwg@ietf.org; Sriganesh Kini > > Subject: Re: draft-kini-mpls-frr-ldp-01 for review > > > > Inline > > > > - Sri > > > > Sent from my iPad > > > > On Aug 4, 2011, at 6:13 AM, Curtis Villamizar > wrote: > > > > > > > > In message > > > 03A514A@mail.gmail.com> > > > Sriganesh Kini writes: > > >> > > >> We are re-using whatever is available and is needed. SRLG info is > > >> needed at the nodes computing paths to protect the SRLG failure. > > >> Using an existing IGP mechanism to do just that is an option. > > >> Stretching this to imply that RSVP-TE is reinvented doesn't make > > >> sense. Many service providers who have LDP deployed simply don't > want > > >> the additional complexity of deploying RSVP-TE but they do want > sub > > >> 50msec protection with full coverage. Moreover RSVP-TE doesn't > scale as > > well. > > > > > > > > > Additional complexity. > > > > No. Operationally the complexity is similar to running an LDP > network. > > > > > > > > Enable IGP-TE extensions and configure links, minimum is enable TE > > > per link and advertise defaults. > > > > > > Define a mesh group. > > > > > > Configure defaults for mesh group at zero bandwidth and use of > FRR. > > > > > > Done. > > > > Full mesh is not as scalable. > > > > > > > > That is not much complexity. The configuration is identical per > node, > > > except per link config since different nodes have different number > and > > > naming of links. This is both easy to set up and easily > manageable. > > > > > > If later TE is desired, then either set autobandwidth on the mesh > > > group or capture per LSP traffic measurements and begin configuring > > > bandwidth amounts per LSP. The latter takes a small amount of work > > > but is preferred by many service providers. > > > > Maybe this is true for some providers that you are aware of. But I > have > > seen many providers prefer to run an LDP network and want full > coverage > > protection. > > > > > > > > Curtis > > > > > > > > > > > >> On Wed, Aug 3, 2011 at 4:32 PM, Curtis Villamizar > > > wrote: > > >>> > > >>> In message > > >>> > <0ED867EB33AB2B45AAB470D5A64CDBF60CCA31C45D@EUSAACMS0701.eamcs.erics > > >>> son.se> > > >>> Jeff Tantsura writes: > > >>>> > > >>>> Hi Curtis, > > >>>> > > >>>> Irrespectively of this draft thanks to GMPLS IGP extensions as > per > > >>>> RFC's 4203 & 5307 SRLG info is there, it is up to implementation > > >>>> how to use it. > > >>>> > > >>>> Regards, > > >>>> Jeff > > >>> > > >>> > > >>> Those are in the extensions for GMPLS which is a superset of > RSVP-TE > > >>> based MPLS. These are sub-TLV added to the Link TLV which > provides > > >>> a good part of the TE-LSDB used by RSVP-TE. With that you get > > >>> available bandwidth at each priority level, the RSVP-TE 32 bit > link > > >>> attribute vector and other niceties that should have nothing to > do > > >>> with LDP. > > >>> > > >>> For example, in RFC-3060 where Link TLV is defined for OSPF. > > >>> > > >>> The following sub-TLVs of the Link TLV are defined: > > >>> > > >>> 1 - Link type (1 octet) > > >>> 2 - Link ID (4 octets) > > >>> 3 - Local interface IP address (4 octets) > > >>> 4 - Remote interface IP address (4 octets) > > >>> 5 - Traffic engineering metric (4 octets) > > >>> 6 - Maximum bandwidth (4 octets) > > >>> 7 - Maximum reservable bandwidth (4 octets) > > >>> 8 - Unreserved bandwidth (32 octets) > > >>> 9 - Administrative group (4 octets) > > >>> > > >>> That is what is being extended in RFC4203. > > >>> > > >>> So don't run RSVP-TE, just half of it. Then compute LDP paths? > > >>> Sounds too much like CR-LDP to me. > > >>> > > >>> If we reinvent half of RSVP-TE, why not all of it. OTOH, why not > > >>> just run half of it. Use RSVP-TE LSP with zero BW and MPLS FRR > > >>> [RFC4090] and forget LDP except for PW signaling. > > >>> > > >>> Curtis > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On > > >>>> Behalf Of Curtis Villamizar > > >>>> Sent: Wednesday, August 03, 2011 11:35 > > >>>> To: Sriganesh Kini > > >>>> Cc: rtgwg@ietf.org > > >>>> Subject: Re: draft-kini-mpls-frr-ldp-01 for review > > >>>> > > >>>> > > >>>> In message > > >>>> > > >>>> > > > >>>> Sriganesh Kini writes: > > >>>>> > > >>>>> Hello, > > >>>>> > > >>>>> Regarding draft-kini-mpls-frr-ldp-01. > > >>>>> > > >>>>> We had feedback from the mpls WG to present this draft at > RTGWG. > > >>>>> Since our request for a slot was late, there is a chance that > we > > >>>>> may not have adequate time at the end of the session for this > > >>>>> draft. In any case we wanted to make the WG aware of the draft > and > > >>>>> would appreciate any comments. > > >>>>> > > >>>>> Regards > > >>>>> > > >>>>> - Sri > > >>>> > > >>>> > > >>>> Protection is inherently a traffic engineering problem. IPFRR > > >>>> provides mostly limited coverage protection, without the benefit > of > > >>>> signaled SRLG, and with increased potential of transient route > > >>>> loops in the abense of complete and accurate SRLG information or > > >>>> when multiple failures occur that are not covered by SRLG. > > >>>> > > >>>> LDP FRR has all the same issues as IPFRR. So in general I don't > > >>>> support LDP FRR. > > >>>> > > >>>> Even if I did support an LDP FRR, I don't think this draft > offers > a > > >>>> good approach to LDP FRR. > > >>>> > > >>>> Curtis > > >>> _______________________________________________ > > >>> rtgwg mailing list > > >>> rtgwg@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/rtgwg > > >>> > > >> > > >> > > >> > > >> -- > > >> - Sri > > > > > > _______________________________________________ > > > rtgwg mailing list > > > rtgwg@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtgwg > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From akatlas@gmail.com Thu Aug 4 10:22:16 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D848221F8BB3 for ; Thu, 4 Aug 2011 10:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yBo2RsOj6Lp for ; Thu, 4 Aug 2011 10:22:15 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6407621F8B78 for ; Thu, 4 Aug 2011 10:22:15 -0700 (PDT) Received: by pzk33 with SMTP id 33so5875328pzk.18 for ; Thu, 04 Aug 2011 10:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VCGuwLiqNtiQl++OHngHM4q3cKxBCtMXK2RTbA6dWKg=; b=gvFao9KW7DLZz9LVTywX7zGdlBv3UhblFRGnzsIKL8FgX4549LhlPaWAAXY93ii72w Ss6Y0r3UkzR/jl0CJAnRwJu1aJLwrdTOWWhnJ7XV3SpD4tqYyLt32drxJjSs8JBhSrnP B+b9pJrkhW17bkGRf/RgiP3Zh4FImkIc8O9wE= MIME-Version: 1.0 Received: by 10.143.43.17 with SMTP id v17mr970751wfj.56.1312478549074; Thu, 04 Aug 2011 10:22:29 -0700 (PDT) Received: by 10.68.62.162 with HTTP; Thu, 4 Aug 2011 10:22:29 -0700 (PDT) In-Reply-To: References: <201108041313.p74DDgda043410@harbor.orleans.occnc.com> <136C7651-8CCF-4CA7-814C-09F89D5C71F5@gmail.com> Date: Thu, 4 Aug 2011 13:22:29 -0400 Message-ID: Subject: Re: draft-kini-mpls-frr-ldp-01 for review From: Alia Atlas To: "Eric Osborne (eosborne)" Content-Type: multipart/alternative; boundary=001636e8ff5bb162c604a9b139ed Cc: rtgwg@ietf.org, Sriganesh Kini X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 17:22:17 -0000 --001636e8ff5bb162c604a9b139ed Content-Type: text/plain; charset=ISO-8859-1 I agree that is a reasonable comparison. At least RSVP-TE has significant troubleshooting tools and training available. The other question is what is your protection time - i.e. how much time after a topology change does it take to become fully protected? Alia On Thu, Aug 4, 2011 at 12:16 PM, Eric Osborne (eosborne) wrote: > You say that your solution is simpler than a TE deployment, but you're > comparing the wrong things. > > It is possible to use LFA or something similar for the cases where it > works and to use an explicitly routed RSVP-TE path to provide a backup > path for cases where LFA doesn't work. This is what you ought to > compare to your solution. > > How much simpler is your solution than what I've described above? They > both need > - link-state information available for explicit paths > - srlg info available, should one want to use it > - explicit routing control, even if the paths are dynamically > calculated per PLR > > At that point the only difference I see between what RSVP does and what > you want to do with LDP is you have two different protcols. If you want > to argue that LDP is 'simple' and RSVP is 'complex' you can't take all > the good stuff out of RSVP which gives it its complexity in the first > place, put it in LDP and then argue that LDP is still 'simple'. > > Also, CR-LDP is dead. rfc3468. > What is different between your proposed changes to LDP and what CR-LDP > did? > > > > > eric > > > -----Original Message----- > > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > Of > > Sriganesh Kini > > Sent: Thursday, August 04, 2011 12:00 PM > > To: curtis@occnc.com > > Cc: rtgwg@ietf.org; Sriganesh Kini > > Subject: Re: draft-kini-mpls-frr-ldp-01 for review > > > > Inline > > > > - Sri > > > > Sent from my iPad > > > > On Aug 4, 2011, at 6:13 AM, Curtis Villamizar > wrote: > > > > > > > > In message > > > > > > Sriganesh Kini writes: > > >> > > >> We are re-using whatever is available and is needed. SRLG info is > > >> needed at the nodes computing paths to protect the SRLG failure. > > >> Using an existing IGP mechanism to do just that is an option. > > >> Stretching this to imply that RSVP-TE is reinvented doesn't make > > >> sense. Many service providers who have LDP deployed simply don't > want > > >> the additional complexity of deploying RSVP-TE but they do want sub > > >> 50msec protection with full coverage. Moreover RSVP-TE doesn't > scale as > > well. > > > > > > > > > Additional complexity. > > > > No. Operationally the complexity is similar to running an LDP network. > > > > > > > > Enable IGP-TE extensions and configure links, minimum is enable TE > > > per link and advertise defaults. > > > > > > Define a mesh group. > > > > > > Configure defaults for mesh group at zero bandwidth and use of FRR. > > > > > > Done. > > > > Full mesh is not as scalable. > > > > > > > > That is not much complexity. The configuration is identical per > node, > > > except per link config since different nodes have different number > and > > > naming of links. This is both easy to set up and easily manageable. > > > > > > If later TE is desired, then either set autobandwidth on the mesh > > > group or capture per LSP traffic measurements and begin configuring > > > bandwidth amounts per LSP. The latter takes a small amount of work > > > but is preferred by many service providers. > > > > Maybe this is true for some providers that you are aware of. But I > have > > seen many providers prefer to run an LDP network and want full > coverage > > protection. > > > > > > > > Curtis > > > > > > > > > > > >> On Wed, Aug 3, 2011 at 4:32 PM, Curtis Villamizar > > > wrote: > > >>> > > >>> In message > > >>> > <0ED867EB33AB2B45AAB470D5A64CDBF60CCA31C45D@EUSAACMS0701.eamcs.erics > > >>> son.se> > > >>> Jeff Tantsura writes: > > >>>> > > >>>> Hi Curtis, > > >>>> > > >>>> Irrespectively of this draft thanks to GMPLS IGP extensions as > per > > >>>> RFC's 4203 & 5307 SRLG info is there, it is up to implementation > > >>>> how to use it. > > >>>> > > >>>> Regards, > > >>>> Jeff > > >>> > > >>> > > >>> Those are in the extensions for GMPLS which is a superset of > RSVP-TE > > >>> based MPLS. These are sub-TLV added to the Link TLV which > provides > > >>> a good part of the TE-LSDB used by RSVP-TE. With that you get > > >>> available bandwidth at each priority level, the RSVP-TE 32 bit > link > > >>> attribute vector and other niceties that should have nothing to do > > >>> with LDP. > > >>> > > >>> For example, in RFC-3060 where Link TLV is defined for OSPF. > > >>> > > >>> The following sub-TLVs of the Link TLV are defined: > > >>> > > >>> 1 - Link type (1 octet) > > >>> 2 - Link ID (4 octets) > > >>> 3 - Local interface IP address (4 octets) > > >>> 4 - Remote interface IP address (4 octets) > > >>> 5 - Traffic engineering metric (4 octets) > > >>> 6 - Maximum bandwidth (4 octets) > > >>> 7 - Maximum reservable bandwidth (4 octets) > > >>> 8 - Unreserved bandwidth (32 octets) > > >>> 9 - Administrative group (4 octets) > > >>> > > >>> That is what is being extended in RFC4203. > > >>> > > >>> So don't run RSVP-TE, just half of it. Then compute LDP paths? > > >>> Sounds too much like CR-LDP to me. > > >>> > > >>> If we reinvent half of RSVP-TE, why not all of it. OTOH, why not > > >>> just run half of it. Use RSVP-TE LSP with zero BW and MPLS FRR > > >>> [RFC4090] and forget LDP except for PW signaling. > > >>> > > >>> Curtis > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On > > >>>> Behalf Of Curtis Villamizar > > >>>> Sent: Wednesday, August 03, 2011 11:35 > > >>>> To: Sriganesh Kini > > >>>> Cc: rtgwg@ietf.org > > >>>> Subject: Re: draft-kini-mpls-frr-ldp-01 for review > > >>>> > > >>>> > > >>>> In message > > >>>> > > >>>> > > > >>>> Sriganesh Kini writes: > > >>>>> > > >>>>> Hello, > > >>>>> > > >>>>> Regarding draft-kini-mpls-frr-ldp-01. > > >>>>> > > >>>>> We had feedback from the mpls WG to present this draft at RTGWG. > > >>>>> Since our request for a slot was late, there is a chance that we > > >>>>> may not have adequate time at the end of the session for this > > >>>>> draft. In any case we wanted to make the WG aware of the draft > and > > >>>>> would appreciate any comments. > > >>>>> > > >>>>> Regards > > >>>>> > > >>>>> - Sri > > >>>> > > >>>> > > >>>> Protection is inherently a traffic engineering problem. IPFRR > > >>>> provides mostly limited coverage protection, without the benefit > of > > >>>> signaled SRLG, and with increased potential of transient route > > >>>> loops in the abense of complete and accurate SRLG information or > > >>>> when multiple failures occur that are not covered by SRLG. > > >>>> > > >>>> LDP FRR has all the same issues as IPFRR. So in general I don't > > >>>> support LDP FRR. > > >>>> > > >>>> Even if I did support an LDP FRR, I don't think this draft offers > a > > >>>> good approach to LDP FRR. > > >>>> > > >>>> Curtis > > >>> _______________________________________________ > > >>> rtgwg mailing list > > >>> rtgwg@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/rtgwg > > >>> > > >> > > >> > > >> > > >> -- > > >> - Sri > > > > > > _______________________________________________ > > > rtgwg mailing list > > > rtgwg@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtgwg > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > --001636e8ff5bb162c604a9b139ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree that is a reasonable comparison.=A0 At least RSVP-TE has significan= t troubleshooting tools
and training available.

The other questio= n is what is your protection
time - i.e. how much time after a topology = change does it take to become fully protected?

Alia

On Thu, Aug 4, 2011 at 12:16 PM,= Eric Osborne (eosborne) <eosborne@cisco.com> wrote:
You say that your solution is simpler than a TE deployment, but you're<= br> comparing the wrong things.

It is possible to use LFA or something similar for the cases where it
works and to use an explicitly routed RSVP-TE path to provide a backup
path for cases where LFA doesn't work. =A0This is what you ought to
compare to your solution.

How much simpler is your solution than what I've described above? =A0Th= ey
both need
=A0- link-state information available for explicit paths
=A0- srlg info available, should one want to use it
=A0- explicit routing control, even if the paths are dynamically
calculated per PLR

At that point the only difference I see between what RSVP does and what
you want to do with LDP is you have two different protcols. =A0If you want<= br> to argue that LDP is 'simple' and RSVP is 'complex' you can= 't take all
the good stuff out of RSVP which gives it its complexity in the first
place, put it in LDP and then argue that LDP is still 'simple'.

Also, CR-LDP is dead. =A0rfc3468.
What is different between your proposed changes to LDP and what CR-LDP
did?




eric

> -----Original Message-----
> From: rtgwg-bounces@ietf.org= [mailto:rtgwg-bounces@ietf.o= rg] On Behalf
Of
> Sriganesh Kini
> Sent: Thursday, August 04, 2011 12:00 PM
> To: curtis@occnc.com
> Cc: rtgwg@ietf.org; Sriganesh Ki= ni
> Subject: Re: draft-kini-mpls-frr-ldp-01 for review >
> Inline
>
> - Sri
>
> Sent from my iPad
>
> On Aug 4, 2011, at 6:13 AM, Curtis Villamizar <curtis@occnc.com>
wrote:
>
> >
> > In message
> > <CAOndX-vC5zbnYLwKgbRz-u9yctcv7Lm-qKpB8Ly-9e-03A514= A@mail.gmail.com>
> > Sriganesh Kini writes:
> >>
> >> We are re-using whatever is available and is needed. SRLG inf= o is
> >> needed at the nodes computing paths to protect the SRLG failu= re.
> >> Using an existing IGP mechanism to do just that is an option.=
> >> Stretching this to imply that RSVP-TE is reinvented doesn'= ;t make
> >> sense. Many service providers who have LDP deployed simply do= n't
want
> >> the additional complexity of deploying RSVP-TE but they do wa= nt sub
> >> 50msec protection with full coverage. Moreover RSVP-TE doesn&= #39;t
scale as
> well.
> >
> >
> > Additional complexity.
>
> No. Operationally the complexity is similar to running an LDP network.=
>
> >
> > =A0Enable IGP-TE extensions and configure links, minimum is enabl= e TE
> > per link and advertise defaults.
> >
> > =A0Define a mesh group.
> >
> > =A0Configure defaults for mesh group at zero bandwidth and use of= FRR.
> >
> > Done.
>
> Full mesh is not as scalable.
>
> >
> > That is not much complexity. =A0The configuration is identical pe= r
node,
> > except per link config since different nodes have different numbe= r
and
> > naming of links. =A0This is both easy to set up and easily manage= able.
> >
> > If later TE is desired, then either set autobandwidth on the mesh=
> > group or capture per LSP traffic measurements and begin configuri= ng
> > bandwidth amounts per LSP. =A0The latter takes a small amount of = work
> > but is preferred by many service providers.
>
> Maybe this is true for some providers that you are aware of. But I
have
> seen many providers prefer to run an LDP network and want full
coverage
> protection.
>
> >
> > Curtis
> >
> >
> >
> >> On Wed, Aug 3, 2011 at 4:32 PM, Curtis Villamizar
<curtis@occnc.com>
> wrote:
> >>>
> >>> In message
> >>>
<0ED867EB33AB2B45AAB470D5A64CDBF60CCA31C45D@EUSAACMS0701.eamcs.erics
> >>> son.se>= ;
> >>> Jeff Tantsura writes:
> >>>>
> >>>> Hi Curtis,
> >>>>
> >>>> Irrespectively of this draft thanks to GMPLS IGP exte= nsions as
per
> >>>> RFC's 4203 & 5307 SRLG info is there, it is u= p to implementation
> >>>> how to use it.
> >>>>
> >>>> Regards,
> >>>> Jeff
> >>>
> >>>
> >>> Those are in the extensions for GMPLS which is a superset= of
RSVP-TE
> >>> based MPLS. =A0These are sub-TLV added to the Link TLV wh= ich
provides
> >>> a good part of the TE-LSDB used by RSVP-TE. =A0With that = you get
> >>> available bandwidth at each priority level, the RSVP-TE 3= 2 bit
link
> >>> attribute vector and other niceties that should have noth= ing to do
> >>> with LDP.
> >>>
> >>> For example, in RFC-3060 where Link TLV is defined for OS= PF.
> >>>
> >>> =A0 The following sub-TLVs of the Link TLV are defined: > >>>
> >>> =A0 =A0 =A01 - Link type (1 octet)
> >>> =A0 =A0 =A02 - Link ID (4 octets)
> >>> =A0 =A0 =A03 - Local interface IP address (4 octets)
> >>> =A0 =A0 =A04 - Remote interface IP address (4 octets)
> >>> =A0 =A0 =A05 - Traffic engineering metric (4 octets)
> >>> =A0 =A0 =A06 - Maximum bandwidth (4 octets)
> >>> =A0 =A0 =A07 - Maximum reservable bandwidth (4 octets) > >>> =A0 =A0 =A08 - Unreserved bandwidth (32 octets)
> >>> =A0 =A0 =A09 - Administrative group (4 octets)
> >>>
> >>> That is what is being extended in RFC4203.
> >>>
> >>> So don't run RSVP-TE, just half of it. =A0Then comput= e LDP paths?
> >>> Sounds too much like CR-LDP to me.
> >>>
> >>> If we reinvent half of RSVP-TE, why not all of it. =A0OTO= H, why not
> >>> just run half of it. =A0Use RSVP-TE LSP with zero BW and = MPLS FRR
> >>> [RFC4090] and forget LDP except for PW signaling.
> >>>
> >>> Curtis
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: rtgwg= -bounces@ietf.org [mailto:rtg= wg-bounces@ietf.org] On
> >>>> Behalf Of Curtis Villamizar
> >>>> Sent: Wednesday, August 03, 2011 11:35
> >>>> To: Sriganesh Kini
> >>>> Cc: rtgwg@ietf.org<= /a>
> >>>> Subject: Re: draft-kini-mpls-frr-ldp-01 for review > >>>>
> >>>>
> >>>> In message
> >>>>
<CAOndX-tcB4UVQnWKKoRcdEp6h2jTRAAHFBWLqq-qwgnV5bUD-g@mail.gma= il.com
> >>>> >
> >>>> Sriganesh Kini writes:
> >>>>>
> >>>>> Hello,
> >>>>>
> >>>>> Regarding draft-kini-mpls-frr-ldp-01.
> >>>>>
> >>>>> We had feedback from the mpls WG to present this = draft at RTGWG.
> >>>>> Since our request for a slot was late, there is a= chance that we
> >>>>> may not have adequate time at the end of the sess= ion for this
> >>>>> draft. In any case we wanted to make the WG aware= of the draft
and
> >>>>> would appreciate any comments.
> >>>>>
> >>>>> Regards
> >>>>>
> >>>>> - Sri
> >>>>
> >>>>
> >>>> Protection is inherently a traffic engineering proble= m. =A0IPFRR
> >>>> provides mostly limited coverage protection, without = the benefit
of
> >>>> signaled SRLG, and with increased potential of transi= ent route
> >>>> loops in the abense of complete and accurate SRLG inf= ormation or
> >>>> when multiple failures occur that are not covered by = SRLG.
> >>>>
> >>>> LDP FRR has all the same issues as IPFRR. =A0So in ge= neral I don't
> >>>> support LDP FRR.
> >>>>
> >>>> Even if I did support an LDP FRR, I don't think t= his draft offers
a
> >>>> good approach to LDP FRR.
> >>>>
> >>>> Curtis
> >>> _______________________________________________
> >>> rtgwg mailing list
> >>> rtgwg@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/rtgwg
> >>>
> >>
> >>
> >>
> >> --
> >> - Sri
> >
> > _______________________________________________
> > rtgwg mailing list
> > rtgwg@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtgwg
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtgwg

--001636e8ff5bb162c604a9b139ed-- From curtis@occnc.com Thu Aug 4 10:52:09 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7502F5E8002 for ; Thu, 4 Aug 2011 10:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8FEHirAisIT for ; Thu, 4 Aug 2011 10:52:08 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id AEA605E8001 for ; Thu, 4 Aug 2011 10:52:08 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p74Hp0JR058053; Thu, 4 Aug 2011 13:51:00 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201108041751.p74Hp0JR058053@harbor.orleans.occnc.com> To: Sriganesh Kini From: Curtis Villamizar Subject: Re: draft-kini-mpls-frr-ldp-01 for review In-reply-to: Your message of "Thu, 04 Aug 2011 09:00:09 PDT." <136C7651-8CCF-4CA7-814C-09F89D5C71F5@gmail.com> Date: Thu, 04 Aug 2011 13:51:00 -0400 Sender: curtis@occnc.com Cc: "rtgwg@ietf.org" , Sriganesh Kini X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 17:52:09 -0000 Sri, This is turning into a RSVP-TE vs LDP debate. In message <136C7651-8CCF-4CA7-814C-09F89D5C71F5@gmail.com> Sriganesh Kini writes: > > > > Enable IGP-TE extensions and configure links, minimum is enable TE > > per link and advertise defaults. > > > > Define a mesh group. > > > > Configure defaults for mesh group at zero bandwidth and use of FRR. > > > > Done. > > Full mesh is not as scalable. No protocol so far is infinitely scalable. Computation in LDP is one SPF, order(N*logN). RSVP-TE needs N of these CSPF computations, order(N^2*logN). LDP uses multipoint to point (P2MP) LSP, making TE impractical, but using N labels at any given point. RSVP-TE uses point to point (PTP) LSP so it needs order N^2 total LSP of which absolut worst case is N^2/4 crossing a thin cutset in the graph (one or two links). When bumping into OSPF scaling limits, use areas. With ISIS use levels. Both offer a two level hierarchy with some differences. If that isn't enough, at some size neither protocol will function. With RSVP-TE you have to use hierarchy sooner but there are more levels of hierarchy available. First make core one mesh group. Make each region its own mesh group. Some LSR sit on both core and one or more region. The create a mesh group for the edge routers which use the hierarchy in core and regions to go edge to edge. Any restoration is done in the H-LSP and not in the edge mesh group if you just set the "resilience" parameters to make it so. I don't know of anyone who took this out further to access, but add one more layer of hierarchy and build a lot of small access mesh groups and repeat process. There are five levels of hierarchy available. PSC-0 (implied) and PSC-1 to PSC-4. Scaling is solvable to largest networks today. But the FUD remains. That is the short explanation without turning this email thread into a thesis on scalability. > > That is not much complexity. The configuration is identical per node, > > except per link config since different nodes have different number and > > naming of links. This is both easy to set up and easily manageable. > > > > If later TE is desired, then either set autobandwidth on the mesh > > group or capture per LSP traffic measurements and begin configuring > > bandwidth amounts per LSP. The latter takes a small amount of work > > but is preferred by many service providers. > > Maybe this is true for some providers that you are aware of. But I > have seen many providers prefer to run an LDP network and want full > coverage protection. It is entirely possible that RSVP-TE is used much more in core and LDP much more in edges. It could be which target market the product focuses on. Regards, Curtis From sriganeshkini@gmail.com Thu Aug 4 15:03:37 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDCD521F8A58 for ; Thu, 4 Aug 2011 15:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxWHZ-vMSZDK for ; Thu, 4 Aug 2011 15:03:36 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A317721F8A56 for ; Thu, 4 Aug 2011 15:03:36 -0700 (PDT) Received: by vws12 with SMTP id 12so1048216vws.31 for ; Thu, 04 Aug 2011 15:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=CildUk0TPKIxIO390e8+wi2RLFvJsKynlZEkqVOe5Fg=; b=nZ7Dgl9h/rQEoz8XF/uU+tRgpbaywJVmmNB+Kn1VwhB8uC3TCBUfs3XAgPd/E5J5wd geRX2EMDJrJfend67qGll9l/zyPpOwXGLrE9FKFeAjKI76lfiC9Ghq40mxUhaZKlkJ7X O2Rh8XL+w6uMXdLPYn4WokysFE2LcdMnkKjAQ= Received: by 10.52.98.2 with SMTP id ee2mr1465720vdb.461.1312495432093; Thu, 04 Aug 2011 15:03:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.68 with HTTP; Thu, 4 Aug 2011 15:03:22 -0700 (PDT) In-Reply-To: References: <201108041313.p74DDgda043410@harbor.orleans.occnc.com> <136C7651-8CCF-4CA7-814C-09F89D5C71F5@gmail.com> From: Sri Date: Thu, 4 Aug 2011 15:03:22 -0700 Message-ID: Subject: Re: draft-kini-mpls-frr-ldp-01 for review To: "Eric Osborne (eosborne)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 22:03:38 -0000 inline On Thu, Aug 4, 2011 at 9:16 AM, Eric Osborne (eosborne) wrote: > You say that your solution is simpler than a TE deployment, but you're > comparing the wrong things. That was a point brought up in the email thread. The draft only compares it with other approaches used currently to protect LDP traffic. One of them is LDP over RSVP-TE FRR and and that requires running two protocols. The draft doesn't claim that the approach is simpler for TE. We can explicitly state this in the next version to make it clear. > > It is possible to use LFA or something similar for the cases where it > works and to use an explicitly routed RSVP-TE path to provide a backup > path for cases where LFA doesn't work. =A0This is what you ought to > compare to your solution. > > How much simpler is your solution than what I've described above? =A0They > both need > =A0- link-state information available for explicit paths > =A0- srlg info available, should one want to use it > =A0- explicit routing control, even if the paths are dynamically > calculated per PLR In most practical topologies we do not see the need for explicit routing control in LDP. As an example see the link protection topology in the preso. In fact as we analyze more practical topologies, we are seeing lesser need for it. So the explicit routing is more for providing a completeness of the solution to address all topologies. Most practical cases are addressed sufficiently by using the shortest-path LSPs as backup LSPs. It is possible that the way the sections in the draft are currently organized, it gives the impression that explicit routing is always needed. Pls see the presentation, that lists multiple topologies none of which require explicit routing. The draft will be structured to reflect these cases ahead of the exceptional cases. Another option is to have a "simplified-version" of this draft that provides better coverage than IPFRR-LFA with full coverage of LDP for many practical topologies but leave the explicit routing for future consideration. SRLG information is needed if one wants to protect against its failure. If one chooses not to advertise it there is no protection against it, but it is still possible to protect against independent link/node failures. > > At that point the only difference I see between what RSVP does and what > you want to do with LDP is you have two different protcols. =A0If you wan= t > to argue that LDP is 'simple' and RSVP is 'complex' you can't take all > the good stuff out of RSVP which gives it its complexity in the first > place, put it in LDP and then argue that LDP is still 'simple'. We are using the minimal extension to LDP to get around failures. The "RSVP protocol" is much more than just that. > > Also, CR-LDP is dead. =A0rfc3468. > What is different between your proposed changes to LDP and what CR-LDP > did? As stated earlier the explicit routing extension to LDP is minimal and that too can be removed for the "simplified-version". CR-LDP can stay as-is ! > > > > > eric > >> -----Original Message----- >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > Of >> Sriganesh Kini >> Sent: Thursday, August 04, 2011 12:00 PM >> To: curtis@occnc.com >> Cc: rtgwg@ietf.org; Sriganesh Kini >> Subject: Re: draft-kini-mpls-frr-ldp-01 for review >> >> Inline >> >> - Sri >> >> Sent from my iPad >> >> On Aug 4, 2011, at 6:13 AM, Curtis Villamizar > wrote: >> >> > >> > In message >> > >> > Sriganesh Kini writes: >> >> >> >> We are re-using whatever is available and is needed. SRLG info is >> >> needed at the nodes computing paths to protect the SRLG failure. >> >> Using an existing IGP mechanism to do just that is an option. >> >> Stretching this to imply that RSVP-TE is reinvented doesn't make >> >> sense. Many service providers who have LDP deployed simply don't > want >> >> the additional complexity of deploying RSVP-TE but they do want sub >> >> 50msec protection with full coverage. Moreover RSVP-TE doesn't > scale as >> well. >> > >> > >> > Additional complexity. >> >> No. Operationally the complexity is similar to running an LDP network. >> >> > >> > =A0Enable IGP-TE extensions and configure links, minimum is enable TE >> > per link and advertise defaults. >> > >> > =A0Define a mesh group. >> > >> > =A0Configure defaults for mesh group at zero bandwidth and use of FRR. >> > >> > Done. >> >> Full mesh is not as scalable. >> >> > >> > That is not much complexity. =A0The configuration is identical per > node, >> > except per link config since different nodes have different number > and >> > naming of links. =A0This is both easy to set up and easily manageable. >> > >> > If later TE is desired, then either set autobandwidth on the mesh >> > group or capture per LSP traffic measurements and begin configuring >> > bandwidth amounts per LSP. =A0The latter takes a small amount of work >> > but is preferred by many service providers. >> >> Maybe this is true for some providers that you are aware of. But I > have >> seen many providers prefer to run an LDP network and want full > coverage >> protection. >> >> > >> > Curtis >> > >> > >> > >> >> On Wed, Aug 3, 2011 at 4:32 PM, Curtis Villamizar > >> wrote: >> >>> >> >>> In message >> >>> > <0ED867EB33AB2B45AAB470D5A64CDBF60CCA31C45D@EUSAACMS0701.eamcs.erics >> >>> son.se> >> >>> Jeff Tantsura writes: >> >>>> >> >>>> Hi Curtis, >> >>>> >> >>>> Irrespectively of this draft thanks to GMPLS IGP extensions as > per >> >>>> RFC's 4203 & 5307 SRLG info is there, it is up to implementation >> >>>> how to use it. >> >>>> >> >>>> Regards, >> >>>> Jeff >> >>> >> >>> >> >>> Those are in the extensions for GMPLS which is a superset of > RSVP-TE >> >>> based MPLS. =A0These are sub-TLV added to the Link TLV which > provides >> >>> a good part of the TE-LSDB used by RSVP-TE. =A0With that you get >> >>> available bandwidth at each priority level, the RSVP-TE 32 bit > link >> >>> attribute vector and other niceties that should have nothing to do >> >>> with LDP. >> >>> >> >>> For example, in RFC-3060 where Link TLV is defined for OSPF. >> >>> >> >>> =A0 The following sub-TLVs of the Link TLV are defined: >> >>> >> >>> =A0 =A0 =A01 - Link type (1 octet) >> >>> =A0 =A0 =A02 - Link ID (4 octets) >> >>> =A0 =A0 =A03 - Local interface IP address (4 octets) >> >>> =A0 =A0 =A04 - Remote interface IP address (4 octets) >> >>> =A0 =A0 =A05 - Traffic engineering metric (4 octets) >> >>> =A0 =A0 =A06 - Maximum bandwidth (4 octets) >> >>> =A0 =A0 =A07 - Maximum reservable bandwidth (4 octets) >> >>> =A0 =A0 =A08 - Unreserved bandwidth (32 octets) >> >>> =A0 =A0 =A09 - Administrative group (4 octets) >> >>> >> >>> That is what is being extended in RFC4203. >> >>> >> >>> So don't run RSVP-TE, just half of it. =A0Then compute LDP paths? >> >>> Sounds too much like CR-LDP to me. >> >>> >> >>> If we reinvent half of RSVP-TE, why not all of it. =A0OTOH, why not >> >>> just run half of it. =A0Use RSVP-TE LSP with zero BW and MPLS FRR >> >>> [RFC4090] and forget LDP except for PW signaling. >> >>> >> >>> Curtis >> >>> >> >>> >> >>>> -----Original Message----- >> >>>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On >> >>>> Behalf Of Curtis Villamizar >> >>>> Sent: Wednesday, August 03, 2011 11:35 >> >>>> To: Sriganesh Kini >> >>>> Cc: rtgwg@ietf.org >> >>>> Subject: Re: draft-kini-mpls-frr-ldp-01 for review >> >>>> >> >>>> >> >>>> In message >> >>>> > > >>>> > >> >>>> Sriganesh Kini writes: >> >>>>> >> >>>>> Hello, >> >>>>> >> >>>>> Regarding draft-kini-mpls-frr-ldp-01. >> >>>>> >> >>>>> We had feedback from the mpls WG to present this draft at RTGWG. >> >>>>> Since our request for a slot was late, there is a chance that we >> >>>>> may not have adequate time at the end of the session for this >> >>>>> draft. In any case we wanted to make the WG aware of the draft > and >> >>>>> would appreciate any comments. >> >>>>> >> >>>>> Regards >> >>>>> >> >>>>> - Sri >> >>>> >> >>>> >> >>>> Protection is inherently a traffic engineering problem. =A0IPFRR >> >>>> provides mostly limited coverage protection, without the benefit > of >> >>>> signaled SRLG, and with increased potential of transient route >> >>>> loops in the abense of complete and accurate SRLG information or >> >>>> when multiple failures occur that are not covered by SRLG. >> >>>> >> >>>> LDP FRR has all the same issues as IPFRR. =A0So in general I don't >> >>>> support LDP FRR. >> >>>> >> >>>> Even if I did support an LDP FRR, I don't think this draft offers > a >> >>>> good approach to LDP FRR. >> >>>> >> >>>> Curtis >> >>> _______________________________________________ >> >>> rtgwg mailing list >> >>> rtgwg@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/rtgwg >> >>> >> >> >> >> >> >> >> >> -- >> >> - Sri >> > >> > _______________________________________________ >> > rtgwg mailing list >> > rtgwg@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtgwg >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg > --=20 Sriganesh Kini (Sri) From sriganeshkini@gmail.com Thu Aug 4 15:13:07 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB8821F8764 for ; Thu, 4 Aug 2011 15:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXZldTJKJ8oh for ; Thu, 4 Aug 2011 15:13:06 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A1FC121F86BB for ; Thu, 4 Aug 2011 15:12:47 -0700 (PDT) Received: by vws12 with SMTP id 12so1054342vws.31 for ; Thu, 04 Aug 2011 15:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=cvXlxXPvPRXueEkfa6MKc5Ig7Cq0ha713Ha/eqxIvFg=; b=TXrHnk7phJjROT8Bg24wWwdnDo+zMWjsTrufJctC9+ZpVFlUfi0IgPPVkGIiCiKjO2 V3au5WkPmrBjG/Qy7Kb8gajNF9fYajij+F4Z2vQAvrmEnlKeGc45cK92uEDf9LkROuGO LhcL+6PnabvtqxqBmb/I8u4JZg5tAsIcUNJBI= Received: by 10.52.111.161 with SMTP id ij1mr1511099vdb.126.1312495983104; Thu, 04 Aug 2011 15:13:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.68 with HTTP; Thu, 4 Aug 2011 15:12:33 -0700 (PDT) In-Reply-To: References: <201108041313.p74DDgda043410@harbor.orleans.occnc.com> <136C7651-8CCF-4CA7-814C-09F89D5C71F5@gmail.com> From: Sri Date: Thu, 4 Aug 2011 15:12:33 -0700 Message-ID: Subject: Re: draft-kini-mpls-frr-ldp-01 for review To: Alia Atlas Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 22:13:07 -0000 inline On Thu, Aug 4, 2011 at 10:22 AM, Alia Atlas wrote: > I agree that is a reasonable comparison.=A0 At least RSVP-TE has signific= ant > troubleshooting tools > and training available. LDP has that too. And it shouldn't need much change to apply that to backup LDP LSPs. > > The other question is what is your protection > time - i.e. how much time after a topology change does it take to become > fully protected? We will discuss the empirical data as it becomes available. We don't anticipate it being significant enough to be of concern. > > Alia > > On Thu, Aug 4, 2011 at 12:16 PM, Eric Osborne (eosborne) > wrote: >> >> You say that your solution is simpler than a TE deployment, but you're >> comparing the wrong things. >> >> It is possible to use LFA or something similar for the cases where it >> works and to use an explicitly routed RSVP-TE path to provide a backup >> path for cases where LFA doesn't work. =A0This is what you ought to >> compare to your solution. >> >> How much simpler is your solution than what I've described above? =A0The= y >> both need >> =A0- link-state information available for explicit paths >> =A0- srlg info available, should one want to use it >> =A0- explicit routing control, even if the paths are dynamically >> calculated per PLR >> >> At that point the only difference I see between what RSVP does and what >> you want to do with LDP is you have two different protcols. =A0If you wa= nt >> to argue that LDP is 'simple' and RSVP is 'complex' you can't take all >> the good stuff out of RSVP which gives it its complexity in the first >> place, put it in LDP and then argue that LDP is still 'simple'. >> >> Also, CR-LDP is dead. =A0rfc3468. >> What is different between your proposed changes to LDP and what CR-LDP >> did? >> >> >> >> >> eric >> >> > -----Original Message----- >> > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf >> Of >> > Sriganesh Kini >> > Sent: Thursday, August 04, 2011 12:00 PM >> > To: curtis@occnc.com >> > Cc: rtgwg@ietf.org; Sriganesh Kini >> > Subject: Re: draft-kini-mpls-frr-ldp-01 for review >> > >> > Inline >> > >> > - Sri >> > >> > Sent from my iPad >> > >> > On Aug 4, 2011, at 6:13 AM, Curtis Villamizar >> wrote: >> > >> > > >> > > In message >> > > >> > > Sriganesh Kini writes: >> > >> >> > >> We are re-using whatever is available and is needed. SRLG info is >> > >> needed at the nodes computing paths to protect the SRLG failure. >> > >> Using an existing IGP mechanism to do just that is an option. >> > >> Stretching this to imply that RSVP-TE is reinvented doesn't make >> > >> sense. Many service providers who have LDP deployed simply don't >> want >> > >> the additional complexity of deploying RSVP-TE but they do want sub >> > >> 50msec protection with full coverage. Moreover RSVP-TE doesn't >> scale as >> > well. >> > > >> > > >> > > Additional complexity. >> > >> > No. Operationally the complexity is similar to running an LDP network. >> > >> > > >> > > =A0Enable IGP-TE extensions and configure links, minimum is enable T= E >> > > per link and advertise defaults. >> > > >> > > =A0Define a mesh group. >> > > >> > > =A0Configure defaults for mesh group at zero bandwidth and use of FR= R. >> > > >> > > Done. >> > >> > Full mesh is not as scalable. >> > >> > > >> > > That is not much complexity. =A0The configuration is identical per >> node, >> > > except per link config since different nodes have different number >> and >> > > naming of links. =A0This is both easy to set up and easily manageabl= e. >> > > >> > > If later TE is desired, then either set autobandwidth on the mesh >> > > group or capture per LSP traffic measurements and begin configuring >> > > bandwidth amounts per LSP. =A0The latter takes a small amount of wor= k >> > > but is preferred by many service providers. >> > >> > Maybe this is true for some providers that you are aware of. But I >> have >> > seen many providers prefer to run an LDP network and want full >> coverage >> > protection. >> > >> > > >> > > Curtis >> > > >> > > >> > > >> > >> On Wed, Aug 3, 2011 at 4:32 PM, Curtis Villamizar >> >> > wrote: >> > >>> >> > >>> In message >> > >>> >> <0ED867EB33AB2B45AAB470D5A64CDBF60CCA31C45D@EUSAACMS0701.eamcs.erics >> > >>> son.se> >> > >>> Jeff Tantsura writes: >> > >>>> >> > >>>> Hi Curtis, >> > >>>> >> > >>>> Irrespectively of this draft thanks to GMPLS IGP extensions as >> per >> > >>>> RFC's 4203 & 5307 SRLG info is there, it is up to implementation >> > >>>> how to use it. >> > >>>> >> > >>>> Regards, >> > >>>> Jeff >> > >>> >> > >>> >> > >>> Those are in the extensions for GMPLS which is a superset of >> RSVP-TE >> > >>> based MPLS. =A0These are sub-TLV added to the Link TLV which >> provides >> > >>> a good part of the TE-LSDB used by RSVP-TE. =A0With that you get >> > >>> available bandwidth at each priority level, the RSVP-TE 32 bit >> link >> > >>> attribute vector and other niceties that should have nothing to do >> > >>> with LDP. >> > >>> >> > >>> For example, in RFC-3060 where Link TLV is defined for OSPF. >> > >>> >> > >>> =A0 The following sub-TLVs of the Link TLV are defined: >> > >>> >> > >>> =A0 =A0 =A01 - Link type (1 octet) >> > >>> =A0 =A0 =A02 - Link ID (4 octets) >> > >>> =A0 =A0 =A03 - Local interface IP address (4 octets) >> > >>> =A0 =A0 =A04 - Remote interface IP address (4 octets) >> > >>> =A0 =A0 =A05 - Traffic engineering metric (4 octets) >> > >>> =A0 =A0 =A06 - Maximum bandwidth (4 octets) >> > >>> =A0 =A0 =A07 - Maximum reservable bandwidth (4 octets) >> > >>> =A0 =A0 =A08 - Unreserved bandwidth (32 octets) >> > >>> =A0 =A0 =A09 - Administrative group (4 octets) >> > >>> >> > >>> That is what is being extended in RFC4203. >> > >>> >> > >>> So don't run RSVP-TE, just half of it. =A0Then compute LDP paths? >> > >>> Sounds too much like CR-LDP to me. >> > >>> >> > >>> If we reinvent half of RSVP-TE, why not all of it. =A0OTOH, why no= t >> > >>> just run half of it. =A0Use RSVP-TE LSP with zero BW and MPLS FRR >> > >>> [RFC4090] and forget LDP except for PW signaling. >> > >>> >> > >>> Curtis >> > >>> >> > >>> >> > >>>> -----Original Message----- >> > >>>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On >> > >>>> Behalf Of Curtis Villamizar >> > >>>> Sent: Wednesday, August 03, 2011 11:35 >> > >>>> To: Sriganesh Kini >> > >>>> Cc: rtgwg@ietf.org >> > >>>> Subject: Re: draft-kini-mpls-frr-ldp-01 for review >> > >>>> >> > >>>> >> > >>>> In message >> > >>>> >> > > >>>> > >> > >>>> Sriganesh Kini writes: >> > >>>>> >> > >>>>> Hello, >> > >>>>> >> > >>>>> Regarding draft-kini-mpls-frr-ldp-01. >> > >>>>> >> > >>>>> We had feedback from the mpls WG to present this draft at RTGWG. >> > >>>>> Since our request for a slot was late, there is a chance that we >> > >>>>> may not have adequate time at the end of the session for this >> > >>>>> draft. In any case we wanted to make the WG aware of the draft >> and >> > >>>>> would appreciate any comments. >> > >>>>> >> > >>>>> Regards >> > >>>>> >> > >>>>> - Sri >> > >>>> >> > >>>> >> > >>>> Protection is inherently a traffic engineering problem. =A0IPFRR >> > >>>> provides mostly limited coverage protection, without the benefit >> of >> > >>>> signaled SRLG, and with increased potential of transient route >> > >>>> loops in the abense of complete and accurate SRLG information or >> > >>>> when multiple failures occur that are not covered by SRLG. >> > >>>> >> > >>>> LDP FRR has all the same issues as IPFRR. =A0So in general I don'= t >> > >>>> support LDP FRR. >> > >>>> >> > >>>> Even if I did support an LDP FRR, I don't think this draft offers >> a >> > >>>> good approach to LDP FRR. >> > >>>> >> > >>>> Curtis >> > >>> _______________________________________________ >> > >>> rtgwg mailing list >> > >>> rtgwg@ietf.org >> > >>> https://www.ietf.org/mailman/listinfo/rtgwg >> > >>> >> > >> >> > >> >> > >> >> > >> -- >> > >> - Sri >> > > >> > > _______________________________________________ >> > > rtgwg mailing list >> > > rtgwg@ietf.org >> > > https://www.ietf.org/mailman/listinfo/rtgwg >> > _______________________________________________ >> > rtgwg mailing list >> > rtgwg@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtgwg >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg > > --=20 Sriganesh Kini (Sri) From eosborne@cisco.com Thu Aug 4 15:27:12 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA5E21F874C for ; Thu, 4 Aug 2011 15:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fDokrBfKdxT for ; Thu, 4 Aug 2011 15:27:11 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 774F721F8747 for ; Thu, 4 Aug 2011 15:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=8130; q=dns/txt; s=iport; t=1312496847; x=1313706447; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=tkmFPLEKPbx7Yhva4U4xoIEBygk9r3tgFqe1sW2PD98=; b=GOQut+9fT9uNkqFW5UOpMtssQzyoasXgsp74ScXFdKNZMrepEwh/MiKk Rdm7TSol7C4DJZkHM26NNofzO78NVlRar981aSRpY3YTrt7va3P+jQrlJ BaQp7auQRQuDmcilbJlmNpKFFue4/dqJuLpe+GVwd4tgvJ4IKNKnUtZ1T I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0AAOAbO06tJV2Y/2dsb2JhbABDmA6PXHeBQAEBAQECAQEBAQ8BHT4LDAQCAQgRBAEBAQoGFwEGASYfCQgBAQQTCBMHh0oEol4Bnl6FY18EhysvkDGLcg X-IronPort-AV: E=Sophos;i="4.67,320,1309737600"; d="scan'208";a="9823026" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 04 Aug 2011 22:27:26 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p74MRQ1w029250; Thu, 4 Aug 2011 22:27:26 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Aug 2011 17:27:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-kini-mpls-frr-ldp-01 for review Date: Thu, 4 Aug 2011 17:27:22 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-kini-mpls-frr-ldp-01 for review Thread-Index: AcxS8masl0lVBazpTjW+lBJfp2SpfwAAxYkw References: <201108041313.p74DDgda043410@harbor.orleans.occnc.com> <136C7651-8CCF-4CA7-814C-09F89D5C71F5@gmail.com> From: "Eric Osborne (eosborne)" To: "Sri" X-OriginalArrivalTime: 04 Aug 2011 22:27:25.0501 (UTC) FILETIME=[AFB176D0:01CC52F5] Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 22:27:12 -0000 One question inline with EO# ... > > > > How much simpler is your solution than what I've described above? > > They both need > > =A0- link-state information available for explicit paths > > =A0- srlg info available, should one want to use it > > =A0- explicit routing control, even if the paths are dynamically > > calculated per PLR >=20 > In most practical topologies we do not see the need for explicit = routing > control in LDP. As an example see the link protection topology in the > preso. In fact as we analyze more practical topologies, we are seeing > lesser need for it. So the explicit routing is more for providing a > completeness of the solution to address all topologies. ... >=20 > As stated earlier the explicit routing extension to LDP is minimal and > that too can be removed for the "simplified-version". CR-LDP can stay = as- > is ! EO# If you remove the explicit routing from LDP, aren't you just left with = an approach that looks a lot like LFA or MRT? What's unique to what = you're presenting other than the need to occasionally use = contstraint-routed LDP? eric >=20 > > > > > > > > > > eric > > > >> -----Original Message----- > >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On > >> Behalf > > Of > >> Sriganesh Kini > >> Sent: Thursday, August 04, 2011 12:00 PM > >> To: curtis@occnc.com > >> Cc: rtgwg@ietf.org; Sriganesh Kini > >> Subject: Re: draft-kini-mpls-frr-ldp-01 for review > >> > >> Inline > >> > >> - Sri > >> > >> Sent from my iPad > >> > >> On Aug 4, 2011, at 6:13 AM, Curtis Villamizar > > wrote: > >> > >> > > >> > In message > >> > = >> > > > >> > Sriganesh Kini writes: > >> >> > >> >> We are re-using whatever is available and is needed. SRLG info = is > >> >> needed at the nodes computing paths to protect the SRLG failure. > >> >> Using an existing IGP mechanism to do just that is an option. > >> >> Stretching this to imply that RSVP-TE is reinvented doesn't make > >> >> sense. Many service providers who have LDP deployed simply don't > > want > >> >> the additional complexity of deploying RSVP-TE but they do want > >> >> sub 50msec protection with full coverage. Moreover RSVP-TE = doesn't > > scale as > >> well. > >> > > >> > > >> > Additional complexity. > >> > >> No. Operationally the complexity is similar to running an LDP = network. > >> > >> > > >> > =A0Enable IGP-TE extensions and configure links, minimum is = enable TE > >> > per link and advertise defaults. > >> > > >> > =A0Define a mesh group. > >> > > >> > =A0Configure defaults for mesh group at zero bandwidth and use of = FRR. > >> > > >> > Done. > >> > >> Full mesh is not as scalable. > >> > >> > > >> > That is not much complexity. =A0The configuration is identical = per > > node, > >> > except per link config since different nodes have different = number > > and > >> > naming of links. =A0This is both easy to set up and easily = manageable. > >> > > >> > If later TE is desired, then either set autobandwidth on the mesh > >> > group or capture per LSP traffic measurements and begin = configuring > >> > bandwidth amounts per LSP. =A0The latter takes a small amount of = work > >> > but is preferred by many service providers. > >> > >> Maybe this is true for some providers that you are aware of. But I > > have > >> seen many providers prefer to run an LDP network and want full > > coverage > >> protection. > >> > >> > > >> > Curtis > >> > > >> > > >> > > >> >> On Wed, Aug 3, 2011 at 4:32 PM, Curtis Villamizar > > > >> wrote: > >> >>> > >> >>> In message > >> >>> > > <0ED867EB33AB2B45AAB470D5A64CDBF60CCA31C45D@EUSAACMS0701.eamcs.erics > >> >>> son.se> > >> >>> Jeff Tantsura writes: > >> >>>> > >> >>>> Hi Curtis, > >> >>>> > >> >>>> Irrespectively of this draft thanks to GMPLS IGP extensions as > > per > >> >>>> RFC's 4203 & 5307 SRLG info is there, it is up to = implementation > >> >>>> how to use it. > >> >>>> > >> >>>> Regards, > >> >>>> Jeff > >> >>> > >> >>> > >> >>> Those are in the extensions for GMPLS which is a superset of > > RSVP-TE > >> >>> based MPLS. =A0These are sub-TLV added to the Link TLV which > > provides > >> >>> a good part of the TE-LSDB used by RSVP-TE. =A0With that you = get > >> >>> available bandwidth at each priority level, the RSVP-TE 32 bit > > link > >> >>> attribute vector and other niceties that should have nothing to > >> >>> do with LDP. > >> >>> > >> >>> For example, in RFC-3060 where Link TLV is defined for OSPF. > >> >>> > >> >>> =A0 The following sub-TLVs of the Link TLV are defined: > >> >>> > >> >>> =A0 =A0 =A01 - Link type (1 octet) > >> >>> =A0 =A0 =A02 - Link ID (4 octets) > >> >>> =A0 =A0 =A03 - Local interface IP address (4 octets) > >> >>> =A0 =A0 =A04 - Remote interface IP address (4 octets) > >> >>> =A0 =A0 =A05 - Traffic engineering metric (4 octets) > >> >>> =A0 =A0 =A06 - Maximum bandwidth (4 octets) > >> >>> =A0 =A0 =A07 - Maximum reservable bandwidth (4 octets) > >> >>> =A0 =A0 =A08 - Unreserved bandwidth (32 octets) > >> >>> =A0 =A0 =A09 - Administrative group (4 octets) > >> >>> > >> >>> That is what is being extended in RFC4203. > >> >>> > >> >>> So don't run RSVP-TE, just half of it. =A0Then compute LDP = paths? > >> >>> Sounds too much like CR-LDP to me. > >> >>> > >> >>> If we reinvent half of RSVP-TE, why not all of it. =A0OTOH, why = not > >> >>> just run half of it. =A0Use RSVP-TE LSP with zero BW and MPLS = FRR > >> >>> [RFC4090] and forget LDP except for PW signaling. > >> >>> > >> >>> Curtis > >> >>> > >> >>> > >> >>>> -----Original Message----- > >> >>>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] = On > >> >>>> Behalf Of Curtis Villamizar > >> >>>> Sent: Wednesday, August 03, 2011 11:35 > >> >>>> To: Sriganesh Kini > >> >>>> Cc: rtgwg@ietf.org > >> >>>> Subject: Re: draft-kini-mpls-frr-ldp-01 for review > >> >>>> > >> >>>> > >> >>>> In message > >> >>>> > > >> >>>> > > >> >>>> Sriganesh Kini writes: > >> >>>>> > >> >>>>> Hello, > >> >>>>> > >> >>>>> Regarding draft-kini-mpls-frr-ldp-01. > >> >>>>> > >> >>>>> We had feedback from the mpls WG to present this draft at = RTGWG. > >> >>>>> Since our request for a slot was late, there is a chance that > >> >>>>> we may not have adequate time at the end of the session for > >> >>>>> this draft. In any case we wanted to make the WG aware of the > >> >>>>> draft > > and > >> >>>>> would appreciate any comments. > >> >>>>> > >> >>>>> Regards > >> >>>>> > >> >>>>> - Sri > >> >>>> > >> >>>> > >> >>>> Protection is inherently a traffic engineering problem. = =A0IPFRR > >> >>>> provides mostly limited coverage protection, without the = benefit > > of > >> >>>> signaled SRLG, and with increased potential of transient route > >> >>>> loops in the abense of complete and accurate SRLG information = or > >> >>>> when multiple failures occur that are not covered by SRLG. > >> >>>> > >> >>>> LDP FRR has all the same issues as IPFRR. =A0So in general I = don't > >> >>>> support LDP FRR. > >> >>>> > >> >>>> Even if I did support an LDP FRR, I don't think this draft > >> >>>> offers > > a > >> >>>> good approach to LDP FRR. > >> >>>> > >> >>>> Curtis > >> >>> _______________________________________________ > >> >>> rtgwg mailing list > >> >>> rtgwg@ietf.org > >> >>> https://www.ietf.org/mailman/listinfo/rtgwg > >> >>> > >> >> > >> >> > >> >> > >> >> -- > >> >> - Sri > >> > > >> > _______________________________________________ > >> > rtgwg mailing list > >> > rtgwg@ietf.org > >> > https://www.ietf.org/mailman/listinfo/rtgwg > >> _______________________________________________ > >> rtgwg mailing list > >> rtgwg@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtgwg > > >=20 >=20 >=20 > -- > Sriganesh Kini (Sri) From sriganeshkini@gmail.com Thu Aug 4 16:17:47 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF9221F86C4 for ; Thu, 4 Aug 2011 16:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+vIO7W3VwIT for ; Thu, 4 Aug 2011 16:17:46 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AE70121F85AC for ; Thu, 4 Aug 2011 16:17:45 -0700 (PDT) Received: by vxi40 with SMTP id 40so2257043vxi.31 for ; Thu, 04 Aug 2011 16:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=4zv5XtEQp9SfEO6ZYF9ktEdWZ57uF99VOJSqElkSnaw=; b=tl6ZDoHSehO9tcmKwrirV807ppsOFZSiUBQ5yPwBG80Z/KtoqqEigGvYoHHP2DHdD9 qW7JZQhgG471YXP+g+a2PmCWhoEd1jihTB5+M058T9O98wUuYmxzOLnnEcBlR1+5xJkR Id22ZALucxBskSrE1B/CraeJ/PN7OYXeQitGI= Received: by 10.52.70.179 with SMTP id n19mr1462964vdu.260.1312499881289; Thu, 04 Aug 2011 16:18:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.68 with HTTP; Thu, 4 Aug 2011 16:17:31 -0700 (PDT) In-Reply-To: References: <201108041313.p74DDgda043410@harbor.orleans.occnc.com> <136C7651-8CCF-4CA7-814C-09F89D5C71F5@gmail.com> From: Sri Date: Thu, 4 Aug 2011 16:17:31 -0700 Message-ID: Subject: Re: draft-kini-mpls-frr-ldp-01 for review To: "Eric Osborne (eosborne)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 23:17:47 -0000 inline On Thu, Aug 4, 2011 at 3:27 PM, Eric Osborne (eosborne) wrote: > One question inline with EO# > ... > >> > >> > How much simpler is your solution than what I've described above? >> > They both need >> > =A0- link-state information available for explicit paths >> > =A0- srlg info available, should one want to use it >> > =A0- explicit routing control, even if the paths are dynamically >> > calculated per PLR >> >> In most practical topologies we do not see the need for explicit routing >> control in LDP. As an example see the link protection topology in the >> preso. In fact as we analyze more practical topologies, we are seeing >> lesser need for it. So the explicit routing is more for providing a >> completeness of the solution to address all topologies. > > > ... > >> >> As stated earlier the explicit routing extension to LDP is minimal and >> that too can be removed for the "simplified-version". CR-LDP can stay as= - >> is ! > > EO# > If you remove the explicit routing from LDP, aren't you just left with an= approach that looks a lot like LFA or MRT? =A0What's unique to what you're= presenting other than the need to occasionally use contstraint-routed LDP? IPFRR-LFA uses only the IP(IGP) loop-free alternates. The simplified version of FRR-LDP uses LDP LSPs with stacking such that they are loop free and avoid the failure. A simple example is the link-protection case in the preso. They could also avoid SRLG failures if the appropriate shortest-path LSPs exist in that topology. MRT uses redundant trees. > > > > eric > > >> >> > >> > >> > >> > >> > eric >> > >> >> -----Original Message----- >> >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On >> >> Behalf >> > Of >> >> Sriganesh Kini >> >> Sent: Thursday, August 04, 2011 12:00 PM >> >> To: curtis@occnc.com >> >> Cc: rtgwg@ietf.org; Sriganesh Kini >> >> Subject: Re: draft-kini-mpls-frr-ldp-01 for review >> >> >> >> Inline >> >> >> >> - Sri >> >> >> >> Sent from my iPad >> >> >> >> On Aug 4, 2011, at 6:13 AM, Curtis Villamizar >> > wrote: >> >> >> >> > >> >> > In message >> >> > > >> > > >> >> > Sriganesh Kini writes: >> >> >> >> >> >> We are re-using whatever is available and is needed. SRLG info is >> >> >> needed at the nodes computing paths to protect the SRLG failure. >> >> >> Using an existing IGP mechanism to do just that is an option. >> >> >> Stretching this to imply that RSVP-TE is reinvented doesn't make >> >> >> sense. Many service providers who have LDP deployed simply don't >> > want >> >> >> the additional complexity of deploying RSVP-TE but they do want >> >> >> sub 50msec protection with full coverage. Moreover RSVP-TE doesn't >> > scale as >> >> well. >> >> > >> >> > >> >> > Additional complexity. >> >> >> >> No. Operationally the complexity is similar to running an LDP network= . >> >> >> >> > >> >> > =A0Enable IGP-TE extensions and configure links, minimum is enable = TE >> >> > per link and advertise defaults. >> >> > >> >> > =A0Define a mesh group. >> >> > >> >> > =A0Configure defaults for mesh group at zero bandwidth and use of F= RR. >> >> > >> >> > Done. >> >> >> >> Full mesh is not as scalable. >> >> >> >> > >> >> > That is not much complexity. =A0The configuration is identical per >> > node, >> >> > except per link config since different nodes have different number >> > and >> >> > naming of links. =A0This is both easy to set up and easily manageab= le. >> >> > >> >> > If later TE is desired, then either set autobandwidth on the mesh >> >> > group or capture per LSP traffic measurements and begin configuring >> >> > bandwidth amounts per LSP. =A0The latter takes a small amount of wo= rk >> >> > but is preferred by many service providers. >> >> >> >> Maybe this is true for some providers that you are aware of. But I >> > have >> >> seen many providers prefer to run an LDP network and want full >> > coverage >> >> protection. >> >> >> >> > >> >> > Curtis >> >> > >> >> > >> >> > >> >> >> On Wed, Aug 3, 2011 at 4:32 PM, Curtis Villamizar >> > >> >> wrote: >> >> >>> >> >> >>> In message >> >> >>> >> > <0ED867EB33AB2B45AAB470D5A64CDBF60CCA31C45D@EUSAACMS0701.eamcs.erics >> >> >>> son.se> >> >> >>> Jeff Tantsura writes: >> >> >>>> >> >> >>>> Hi Curtis, >> >> >>>> >> >> >>>> Irrespectively of this draft thanks to GMPLS IGP extensions as >> > per >> >> >>>> RFC's 4203 & 5307 SRLG info is there, it is up to implementation >> >> >>>> how to use it. >> >> >>>> >> >> >>>> Regards, >> >> >>>> Jeff >> >> >>> >> >> >>> >> >> >>> Those are in the extensions for GMPLS which is a superset of >> > RSVP-TE >> >> >>> based MPLS. =A0These are sub-TLV added to the Link TLV which >> > provides >> >> >>> a good part of the TE-LSDB used by RSVP-TE. =A0With that you get >> >> >>> available bandwidth at each priority level, the RSVP-TE 32 bit >> > link >> >> >>> attribute vector and other niceties that should have nothing to >> >> >>> do with LDP. >> >> >>> >> >> >>> For example, in RFC-3060 where Link TLV is defined for OSPF. >> >> >>> >> >> >>> =A0 The following sub-TLVs of the Link TLV are defined: >> >> >>> >> >> >>> =A0 =A0 =A01 - Link type (1 octet) >> >> >>> =A0 =A0 =A02 - Link ID (4 octets) >> >> >>> =A0 =A0 =A03 - Local interface IP address (4 octets) >> >> >>> =A0 =A0 =A04 - Remote interface IP address (4 octets) >> >> >>> =A0 =A0 =A05 - Traffic engineering metric (4 octets) >> >> >>> =A0 =A0 =A06 - Maximum bandwidth (4 octets) >> >> >>> =A0 =A0 =A07 - Maximum reservable bandwidth (4 octets) >> >> >>> =A0 =A0 =A08 - Unreserved bandwidth (32 octets) >> >> >>> =A0 =A0 =A09 - Administrative group (4 octets) >> >> >>> >> >> >>> That is what is being extended in RFC4203. >> >> >>> >> >> >>> So don't run RSVP-TE, just half of it. =A0Then compute LDP paths? >> >> >>> Sounds too much like CR-LDP to me. >> >> >>> >> >> >>> If we reinvent half of RSVP-TE, why not all of it. =A0OTOH, why n= ot >> >> >>> just run half of it. =A0Use RSVP-TE LSP with zero BW and MPLS FRR >> >> >>> [RFC4090] and forget LDP except for PW signaling. >> >> >>> >> >> >>> Curtis >> >> >>> >> >> >>> >> >> >>>> -----Original Message----- >> >> >>>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On >> >> >>>> Behalf Of Curtis Villamizar >> >> >>>> Sent: Wednesday, August 03, 2011 11:35 >> >> >>>> To: Sriganesh Kini >> >> >>>> Cc: rtgwg@ietf.org >> >> >>>> Subject: Re: draft-kini-mpls-frr-ldp-01 for review >> >> >>>> >> >> >>>> >> >> >>>> In message >> >> >>>> >> > > >> >>>> > >> >> >>>> Sriganesh Kini writes: >> >> >>>>> >> >> >>>>> Hello, >> >> >>>>> >> >> >>>>> Regarding draft-kini-mpls-frr-ldp-01. >> >> >>>>> >> >> >>>>> We had feedback from the mpls WG to present this draft at RTGWG= . >> >> >>>>> Since our request for a slot was late, there is a chance that >> >> >>>>> we may not have adequate time at the end of the session for >> >> >>>>> this draft. In any case we wanted to make the WG aware of the >> >> >>>>> draft >> > and >> >> >>>>> would appreciate any comments. >> >> >>>>> >> >> >>>>> Regards >> >> >>>>> >> >> >>>>> - Sri >> >> >>>> >> >> >>>> >> >> >>>> Protection is inherently a traffic engineering problem. =A0IPFRR >> >> >>>> provides mostly limited coverage protection, without the benefit >> > of >> >> >>>> signaled SRLG, and with increased potential of transient route >> >> >>>> loops in the abense of complete and accurate SRLG information or >> >> >>>> when multiple failures occur that are not covered by SRLG. >> >> >>>> >> >> >>>> LDP FRR has all the same issues as IPFRR. =A0So in general I don= 't >> >> >>>> support LDP FRR. >> >> >>>> >> >> >>>> Even if I did support an LDP FRR, I don't think this draft >> >> >>>> offers >> > a >> >> >>>> good approach to LDP FRR. >> >> >>>> >> >> >>>> Curtis >> >> >>> _______________________________________________ >> >> >>> rtgwg mailing list >> >> >>> rtgwg@ietf.org >> >> >>> https://www.ietf.org/mailman/listinfo/rtgwg >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> - Sri >> >> > >> >> > _______________________________________________ >> >> > rtgwg mailing list >> >> > rtgwg@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/rtgwg >> >> _______________________________________________ >> >> rtgwg mailing list >> >> rtgwg@ietf.org >> >> https://www.ietf.org/mailman/listinfo/rtgwg >> > >> >> >> >> -- >> Sriganesh Kini (Sri) > --=20 Sriganesh Kini (Sri) From akatlas@gmail.com Thu Aug 4 17:05:21 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D9211E8096 for ; Thu, 4 Aug 2011 17:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.519 X-Spam-Level: X-Spam-Status: No, score=-3.519 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luNPCVhlzvEN for ; Thu, 4 Aug 2011 17:05:19 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE0711E8098 for ; Thu, 4 Aug 2011 17:05:19 -0700 (PDT) Received: by yxp4 with SMTP id 4so1675178yxp.31 for ; Thu, 04 Aug 2011 17:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O3d3MaJdIfHvn7wLAJr1vkAk1pHQ/yDnBnbCw68PoHA=; b=mPBpy2CyYTqV66U4u8ie/2P2xiEYcUNNDAHLAkLa+MCaGsWnDIlEloRmQSTSxwgqAu DMeuzn9gGT8GnIO6Z/TlTRg11xw5ZVFijFteoDdadux8ZGl7344gzoRFs0Wv9ukfRcvm HE1wRqfmGiAW0WCB8SmlKqKW6WTdZ3W2yuKKw= MIME-Version: 1.0 Received: by 10.143.43.17 with SMTP id v17mr1296162wfj.56.1312502734558; Thu, 04 Aug 2011 17:05:34 -0700 (PDT) Received: by 10.68.62.162 with HTTP; Thu, 4 Aug 2011 17:05:34 -0700 (PDT) In-Reply-To: References: <201108041313.p74DDgda043410@harbor.orleans.occnc.com> <136C7651-8CCF-4CA7-814C-09F89D5C71F5@gmail.com> Date: Thu, 4 Aug 2011 20:05:34 -0400 Message-ID: Subject: Re: draft-kini-mpls-frr-ldp-01 for review From: Alia Atlas To: Sri Content-Type: multipart/alternative; boundary=001636e8ff5b4294cd04a9b6db76 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 00:05:21 -0000 --001636e8ff5b4294cd04a9b6db76 Content-Type: text/plain; charset=ISO-8859-1 Sri, It sounds like you are advocating the P-Q option that Mike & Stewart originally suggested. From the draft, I couldn't tell whether you were suggesting that or simply computing not-via alternates from the PLR and then signaling them using LDP DoD with an ERO. The key in the fast-reroute discussions is what is the algorithm to compute or create the alternates. In RTGWG, we had a long discussion about what properties we wanted for IP/LDP Fast-Reroute. At the time, of course, I was suggesting U-turn alternates; they don't require tunnels or additional signaling and increased the coverage up to 98% or so. Beyond that, minor topology changes could get a lot - and one could always go to cascaded U-turns if necessary. There was a strong push for a solution that could provide 100% coverage whenever the network couldn't be partitioned by a single failure. That is what led to not-via which gained WG consensus to become a WG draft. At this point, I think we've seen a lack of progress on not-via due to the scalability issues. The need for a solution and the scalability issues around not-via are what have motivated me to suggest MRT fast-reroute. MRT fast-reroute can provide 100% coverage regardless of topology. I'm deeply amused by having this discussion on the other side of the fence - arguing for the 100% solution. Regardless, I'd have to see some pretty convincing arguments before saying that we should compromise on something less. I haven't seen any evidence that the WG opinion has changed on this point. Alia P.S. For topology coverage, how many cases still don't require any directed forwarding once a single or multiple failures have happened to the network? On Thu, Aug 4, 2011 at 7:17 PM, Sri wrote: > inline > > On Thu, Aug 4, 2011 at 3:27 PM, Eric Osborne (eosborne) > wrote: > > One question inline with EO# > > ... > > > >> > > >> > How much simpler is your solution than what I've described above? > >> > They both need > >> > - link-state information available for explicit paths > >> > - srlg info available, should one want to use it > >> > - explicit routing control, even if the paths are dynamically > >> > calculated per PLR > >> > >> In most practical topologies we do not see the need for explicit routing > >> control in LDP. As an example see the link protection topology in the > >> preso. In fact as we analyze more practical topologies, we are seeing > >> lesser need for it. So the explicit routing is more for providing a > >> completeness of the solution to address all topologies. > > > > > > ... > > > >> > >> As stated earlier the explicit routing extension to LDP is minimal and > >> that too can be removed for the "simplified-version". CR-LDP can stay > as- > >> is ! > > > > EO# > > If you remove the explicit routing from LDP, aren't you just left with an > approach that looks a lot like LFA or MRT? What's unique to what you're > presenting other than the need to occasionally use contstraint-routed LDP? > > IPFRR-LFA uses only the IP(IGP) loop-free alternates. The simplified > version of FRR-LDP uses LDP LSPs with stacking such that they are loop > free and avoid the failure. A simple example is the link-protection > case in the preso. They could also avoid SRLG failures if the > appropriate shortest-path LSPs exist in that topology. > > MRT uses redundant trees. > > > > > > > > > eric > > > > > >> > >> > > >> > > >> > > >> > > >> > eric > >> > > >> >> -----Original Message----- > >> >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On > >> >> Behalf > >> > Of > >> >> Sriganesh Kini > >> >> Sent: Thursday, August 04, 2011 12:00 PM > >> >> To: curtis@occnc.com > >> >> Cc: rtgwg@ietf.org; Sriganesh Kini > >> >> Subject: Re: draft-kini-mpls-frr-ldp-01 for review > >> >> > >> >> Inline > >> >> > >> >> - Sri > >> >> > >> >> Sent from my iPad > >> >> > >> >> On Aug 4, 2011, at 6:13 AM, Curtis Villamizar > >> > wrote: > >> >> > >> >> > > >> >> > In message > >> >> > < > CAOndX-vC5zbnYLwKgbRz-u9yctcv7Lm-qKpB8Ly-9e-03A514A@mail.gmail.com > >> >> > > > >> >> > Sriganesh Kini writes: > >> >> >> > >> >> >> We are re-using whatever is available and is needed. SRLG info is > >> >> >> needed at the nodes computing paths to protect the SRLG failure. > >> >> >> Using an existing IGP mechanism to do just that is an option. > >> >> >> Stretching this to imply that RSVP-TE is reinvented doesn't make > >> >> >> sense. Many service providers who have LDP deployed simply don't > >> > want > >> >> >> the additional complexity of deploying RSVP-TE but they do want > >> >> >> sub 50msec protection with full coverage. Moreover RSVP-TE doesn't > >> > scale as > >> >> well. > >> >> > > >> >> > > >> >> > Additional complexity. > >> >> > >> >> No. Operationally the complexity is similar to running an LDP > network. > >> >> > >> >> > > >> >> > Enable IGP-TE extensions and configure links, minimum is enable TE > >> >> > per link and advertise defaults. > >> >> > > >> >> > Define a mesh group. > >> >> > > >> >> > Configure defaults for mesh group at zero bandwidth and use of > FRR. > >> >> > > >> >> > Done. > >> >> > >> >> Full mesh is not as scalable. > >> >> > >> >> > > >> >> > That is not much complexity. The configuration is identical per > >> > node, > >> >> > except per link config since different nodes have different number > >> > and > >> >> > naming of links. This is both easy to set up and easily > manageable. > >> >> > > >> >> > If later TE is desired, then either set autobandwidth on the mesh > >> >> > group or capture per LSP traffic measurements and begin configuring > >> >> > bandwidth amounts per LSP. The latter takes a small amount of work > >> >> > but is preferred by many service providers. > >> >> > >> >> Maybe this is true for some providers that you are aware of. But I > >> > have > >> >> seen many providers prefer to run an LDP network and want full > >> > coverage > >> >> protection. > >> >> > >> >> > > >> >> > Curtis > >> >> > > >> >> > > >> >> > > >> >> >> On Wed, Aug 3, 2011 at 4:32 PM, Curtis Villamizar > >> > > >> >> wrote: > >> >> >>> > >> >> >>> In message > >> >> >>> > >> > <0ED867EB33AB2B45AAB470D5A64CDBF60CCA31C45D@EUSAACMS0701.eamcs.erics > >> >> >>> son.se> > >> >> >>> Jeff Tantsura writes: > >> >> >>>> > >> >> >>>> Hi Curtis, > >> >> >>>> > >> >> >>>> Irrespectively of this draft thanks to GMPLS IGP extensions as > >> > per > >> >> >>>> RFC's 4203 & 5307 SRLG info is there, it is up to implementation > >> >> >>>> how to use it. > >> >> >>>> > >> >> >>>> Regards, > >> >> >>>> Jeff > >> >> >>> > >> >> >>> > >> >> >>> Those are in the extensions for GMPLS which is a superset of > >> > RSVP-TE > >> >> >>> based MPLS. These are sub-TLV added to the Link TLV which > >> > provides > >> >> >>> a good part of the TE-LSDB used by RSVP-TE. With that you get > >> >> >>> available bandwidth at each priority level, the RSVP-TE 32 bit > >> > link > >> >> >>> attribute vector and other niceties that should have nothing to > >> >> >>> do with LDP. > >> >> >>> > >> >> >>> For example, in RFC-3060 where Link TLV is defined for OSPF. > >> >> >>> > >> >> >>> The following sub-TLVs of the Link TLV are defined: > >> >> >>> > >> >> >>> 1 - Link type (1 octet) > >> >> >>> 2 - Link ID (4 octets) > >> >> >>> 3 - Local interface IP address (4 octets) > >> >> >>> 4 - Remote interface IP address (4 octets) > >> >> >>> 5 - Traffic engineering metric (4 octets) > >> >> >>> 6 - Maximum bandwidth (4 octets) > >> >> >>> 7 - Maximum reservable bandwidth (4 octets) > >> >> >>> 8 - Unreserved bandwidth (32 octets) > >> >> >>> 9 - Administrative group (4 octets) > >> >> >>> > >> >> >>> That is what is being extended in RFC4203. > >> >> >>> > >> >> >>> So don't run RSVP-TE, just half of it. Then compute LDP paths? > >> >> >>> Sounds too much like CR-LDP to me. > >> >> >>> > >> >> >>> If we reinvent half of RSVP-TE, why not all of it. OTOH, why not > >> >> >>> just run half of it. Use RSVP-TE LSP with zero BW and MPLS FRR > >> >> >>> [RFC4090] and forget LDP except for PW signaling. > >> >> >>> > >> >> >>> Curtis > >> >> >>> > >> >> >>> > >> >> >>>> -----Original Message----- > >> >> >>>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On > >> >> >>>> Behalf Of Curtis Villamizar > >> >> >>>> Sent: Wednesday, August 03, 2011 11:35 > >> >> >>>> To: Sriganesh Kini > >> >> >>>> Cc: rtgwg@ietf.org > >> >> >>>> Subject: Re: draft-kini-mpls-frr-ldp-01 for review > >> >> >>>> > >> >> >>>> > >> >> >>>> In message > >> >> >>>> > >> > >> >> >>>> > > >> >> >>>> Sriganesh Kini writes: > >> >> >>>>> > >> >> >>>>> Hello, > >> >> >>>>> > >> >> >>>>> Regarding draft-kini-mpls-frr-ldp-01. > >> >> >>>>> > >> >> >>>>> We had feedback from the mpls WG to present this draft at > RTGWG. > >> >> >>>>> Since our request for a slot was late, there is a chance that > >> >> >>>>> we may not have adequate time at the end of the session for > >> >> >>>>> this draft. In any case we wanted to make the WG aware of the > >> >> >>>>> draft > >> > and > >> >> >>>>> would appreciate any comments. > >> >> >>>>> > >> >> >>>>> Regards > >> >> >>>>> > >> >> >>>>> - Sri > >> >> >>>> > >> >> >>>> > >> >> >>>> Protection is inherently a traffic engineering problem. IPFRR > >> >> >>>> provides mostly limited coverage protection, without the benefit > >> > of > >> >> >>>> signaled SRLG, and with increased potential of transient route > >> >> >>>> loops in the abense of complete and accurate SRLG information or > >> >> >>>> when multiple failures occur that are not covered by SRLG. > >> >> >>>> > >> >> >>>> LDP FRR has all the same issues as IPFRR. So in general I don't > >> >> >>>> support LDP FRR. > >> >> >>>> > >> >> >>>> Even if I did support an LDP FRR, I don't think this draft > >> >> >>>> offers > >> > a > >> >> >>>> good approach to LDP FRR. > >> >> >>>> > >> >> >>>> Curtis > >> >> >>> _______________________________________________ > >> >> >>> rtgwg mailing list > >> >> >>> rtgwg@ietf.org > >> >> >>> https://www.ietf.org/mailman/listinfo/rtgwg > >> >> >>> > >> >> >> > >> >> >> > >> >> >> > >> >> >> -- > >> >> >> - Sri > >> >> > > >> >> > _______________________________________________ > >> >> > rtgwg mailing list > >> >> > rtgwg@ietf.org > >> >> > https://www.ietf.org/mailman/listinfo/rtgwg > >> >> _______________________________________________ > >> >> rtgwg mailing list > >> >> rtgwg@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/rtgwg > >> > > >> > >> > >> > >> -- > >> Sriganesh Kini (Sri) > > > > > > -- > Sriganesh Kini (Sri) > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > --001636e8ff5b4294cd04a9b6db76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sri,

It sounds like you are advocating the P-Q option that Mike &= ; Stewart originally suggested.=A0 From the draft, I couldn't tell whet= her you were suggesting that or simply computing not-via alternates from th= e PLR and then signaling them using LDP DoD with an ERO.

The key in the fast-reroute discussions is what is the algorithm to com= pute or create the alternates.=A0=A0

In RTGWG, we had a long discus= sion about what properties we wanted for IP/LDP Fast-Reroute.=A0 At the tim= e, of course, I was suggesting U-turn alternates; they don't require tu= nnels or additional signaling and increased the coverage up to 98% or so.= =A0 Beyond that, minor topology changes could get a lot - and one could alw= ays go to cascaded U-turns if necessary.

There was a strong push for a solution that could provide 100% coverage= whenever the network couldn't be partitioned by a single failure.=A0 T= hat is what led to not-via which gained WG consensus to become a WG draft.<= br>
At this point, I think we've seen a lack of progress on not-via due= to the scalability issues.

The need for a solution and the scalabi= lity issues around not-via are what have motivated me to suggest MRT fast-r= eroute.=A0 MRT fast-reroute can provide 100% coverage regardless of topolog= y.

I'm deeply amused by having this discussion on the other side of th= e fence - arguing for the 100% solution.=A0

Regardless, I'd hav= e to see some pretty convincing arguments before saying that we should comp= romise on something less.=A0 I haven't seen any evidence that the WG op= inion has changed on this point.

Alia

P.S.=A0 For topology coverage, how many cases still don'= ;t require any directed forwarding once a single or multiple failures have = happened to the network?

On Thu, Aug 4, 2= 011 at 7:17 PM, Sri <sriganeshkini@gmail.com> wrote:
inline

On Thu, Aug 4, 2011 at 3:27 PM, Eric Osborne (eosborne)
<eosborne@cisco.com> wrote:=
> One question inline with EO#
> ...
>
>> >
>> > How much simpler is your solution than what I've describe= d above?
>> > They both need
>> > =A0- link-state information available for explicit paths
>> > =A0- srlg info available, should one want to use it
>> > =A0- explicit routing control, even if the paths are dynamica= lly
>> > calculated per PLR
>>
>> In most practical topologies we do not see the need for explicit r= outing
>> control in LDP. As an example see the link protection topology in = the
>> preso. In fact as we analyze more practical topologies, we are see= ing
>> lesser need for it. So the explicit routing is more for providing = a
>> completeness of the solution to address all topologies.
>
>
> ...
>
>>
>> As stated earlier the explicit routing extension to LDP is minimal= and
>> that too can be removed for the "simplified-version". CR= -LDP can stay as-
>> is !
>
> EO#
> If you remove the explicit routing from LDP, aren't you just left = with an approach that looks a lot like LFA or MRT? =A0What's unique to = what you're presenting other than the need to occasionally use contstra= int-routed LDP?

IPFRR-LFA uses only the IP(IGP) loop-free alternates. The simplified<= br> version of FRR-LDP uses LDP LSPs with stacking such that they are loop
free and avoid the failure. A simple example is the link-protection
case in the preso. They could also avoid SRLG failures if the
appropriate shortest-path LSPs exist in that topology.

MRT uses redundant trees.

>
>
>
> eric
>
>
>>
>> >
>> >
>> >
>> >
>> > eric
>> >
>> >> -----Original Message-----
>> >> From: rtgwg-bou= nces@ietf.org [mailto:rtgwg-b= ounces@ietf.org] On
>> >> Behalf
>> > Of
>> >> Sriganesh Kini
>> >> Sent: Thursday, August 04, 2011 12:00 PM
>> >> To: curtis@occnc.com<= /a>
>> >> Cc: rtgwg@ietf.org;= Sriganesh Kini
>> >> Subject: Re: draft-kini-mpls-frr-ldp-01 for review
>> >>
>> >> Inline
>> >>
>> >> - Sri
>> >>
>> >> Sent from my iPad
>> >>
>> >> On Aug 4, 2011, at 6:13 AM, Curtis Villamizar <curtis@occnc.com>
>> > wrote:
>> >>
>> >> >
>> >> > In message
>> >> > <CAOndX-vC5zbnYLwKgbRz-u9yctcv7Lm-qKpB= 8Ly-9e-03A514A@mail.gmail.com
>> >> > >
>> >> > Sriganesh Kini writes:
>> >> >>
>> >> >> We are re-using whatever is available and is nee= ded. SRLG info is
>> >> >> needed at the nodes computing paths to protect t= he SRLG failure.
>> >> >> Using an existing IGP mechanism to do just that = is an option.
>> >> >> Stretching this to imply that RSVP-TE is reinven= ted doesn't make
>> >> >> sense. Many service providers who have LDP deplo= yed simply don't
>> > want
>> >> >> the additional complexity of deploying RSVP-TE b= ut they do want
>> >> >> sub 50msec protection with full coverage. Moreov= er RSVP-TE doesn't
>> > scale as
>> >> well.
>> >> >
>> >> >
>> >> > Additional complexity.
>> >>
>> >> No. Operationally the complexity is similar to running an= LDP network.
>> >>
>> >> >
>> >> > =A0Enable IGP-TE extensions and configure links, min= imum is enable TE
>> >> > per link and advertise defaults.
>> >> >
>> >> > =A0Define a mesh group.
>> >> >
>> >> > =A0Configure defaults for mesh group at zero bandwid= th and use of FRR.
>> >> >
>> >> > Done.
>> >>
>> >> Full mesh is not as scalable.
>> >>
>> >> >
>> >> > That is not much complexity. =A0The configuration is= identical per
>> > node,
>> >> > except per link config since different nodes have di= fferent number
>> > and
>> >> > naming of links. =A0This is both easy to set up and = easily manageable.
>> >> >
>> >> > If later TE is desired, then either set autobandwidt= h on the mesh
>> >> > group or capture per LSP traffic measurements and be= gin configuring
>> >> > bandwidth amounts per LSP. =A0The latter takes a sma= ll amount of work
>> >> > but is preferred by many service providers.
>> >>
>> >> Maybe this is true for some providers that you are aware = of. But I
>> > have
>> >> seen many providers prefer to run an LDP network and want= full
>> > coverage
>> >> protection.
>> >>
>> >> >
>> >> > Curtis
>> >> >
>> >> >
>> >> >
>> >> >> On Wed, Aug 3, 2011 at 4:32 PM, Curtis Villamiza= r
>> > <curtis@occnc.com&= gt;
>> >> wrote:
>> >> >>>
>> >> >>> In message
>> >> >>>
>> > <0ED867EB33AB2B45AAB470D5A64CDBF60CCA31C45D@EUSAACMS0701.e= amcs.erics
>> >> >>> = son.se>
>> >> >>> Jeff Tantsura writes:
>> >> >>>>
>> >> >>>> Hi Curtis,
>> >> >>>>
>> >> >>>> Irrespectively of this draft thanks to G= MPLS IGP extensions as
>> > per
>> >> >>>> RFC's 4203 & 5307 SRLG info is t= here, it is up to implementation
>> >> >>>> how to use it.
>> >> >>>>
>> >> >>>> Regards,
>> >> >>>> Jeff
>> >> >>>
>> >> >>>
>> >> >>> Those are in the extensions for GMPLS which = is a superset of
>> > RSVP-TE
>> >> >>> based MPLS. =A0These are sub-TLV added to th= e Link TLV which
>> > provides
>> >> >>> a good part of the TE-LSDB used by RSVP-TE. = =A0With that you get
>> >> >>> available bandwidth at each priority level, = the RSVP-TE 32 bit
>> > link
>> >> >>> attribute vector and other niceties that sho= uld have nothing to
>> >> >>> do with LDP.
>> >> >>>
>> >> >>> For example, in RFC-3060 where Link TLV is d= efined for OSPF.
>> >> >>>
>> >> >>> =A0 The following sub-TLVs of the Link TLV a= re defined:
>> >> >>>
>> >> >>> =A0 =A0 =A01 - Link type (1 octet)
>> >> >>> =A0 =A0 =A02 - Link ID (4 octets)
>> >> >>> =A0 =A0 =A03 - Local interface IP address (4= octets)
>> >> >>> =A0 =A0 =A04 - Remote interface IP address (= 4 octets)
>> >> >>> =A0 =A0 =A05 - Traffic engineering metric (4= octets)
>> >> >>> =A0 =A0 =A06 - Maximum bandwidth (4 octets)<= br> >> >> >>> =A0 =A0 =A07 - Maximum reservable bandwidth = (4 octets)
>> >> >>> =A0 =A0 =A08 - Unreserved bandwidth (32 octe= ts)
>> >> >>> =A0 =A0 =A09 - Administrative group (4 octet= s)
>> >> >>>
>> >> >>> That is what is being extended in RFC4203. >> >> >>>
>> >> >>> So don't run RSVP-TE, just half of it. = =A0Then compute LDP paths?
>> >> >>> Sounds too much like CR-LDP to me.
>> >> >>>
>> >> >>> If we reinvent half of RSVP-TE, why not all = of it. =A0OTOH, why not
>> >> >>> just run half of it. =A0Use RSVP-TE LSP with= zero BW and MPLS FRR
>> >> >>> [RFC4090] and forget LDP except for PW signa= ling.
>> >> >>>
>> >> >>> Curtis
>> >> >>>
>> >> >>>
>> >> >>>> -----Original Message-----
>> >> >>>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On
>> >> >>>> Behalf Of Curtis Villamizar
>> >> >>>> Sent: Wednesday, August 03, 2011 11:35 >> >> >>>> To: Sriganesh Kini
>> >> >>>> Cc: rt= gwg@ietf.org
>> >> >>>> Subject: Re: draft-kini-mpls-frr-ldp-01 = for review
>> >> >>>>
>> >> >>>>
>> >> >>>> In message
>> >> >>>>
>> > <CAOndX-tcB4UVQnWKKoRcdEp6h2jTRAAHFBWLqq-qwgnV5= bUD-g@mail.gmail.com
>> >> >>>> >
>> >> >>>> Sriganesh Kini writes:
>> >> >>>>>
>> >> >>>>> Hello,
>> >> >>>>>
>> >> >>>>> Regarding draft-kini-mpls-frr-ldp-01= .
>> >> >>>>>
>> >> >>>>> We had feedback from the mpls WG to = present this draft at RTGWG.
>> >> >>>>> Since our request for a slot was lat= e, there is a chance that
>> >> >>>>> we may not have adequate time at the= end of the session for
>> >> >>>>> this draft. In any case we wanted to= make the WG aware of the
>> >> >>>>> draft
>> > and
>> >> >>>>> would appreciate any comments.
>> >> >>>>>
>> >> >>>>> Regards
>> >> >>>>>
>> >> >>>>> - Sri
>> >> >>>>
>> >> >>>>
>> >> >>>> Protection is inherently a traffic engin= eering problem. =A0IPFRR
>> >> >>>> provides mostly limited coverage protect= ion, without the benefit
>> > of
>> >> >>>> signaled SRLG, and with increased potent= ial of transient route
>> >> >>>> loops in the abense of complete and accu= rate SRLG information or
>> >> >>>> when multiple failures occur that are no= t covered by SRLG.
>> >> >>>>
>> >> >>>> LDP FRR has all the same issues as IPFRR= . =A0So in general I don't
>> >> >>>> support LDP FRR.
>> >> >>>>
>> >> >>>> Even if I did support an LDP FRR, I don&= #39;t think this draft
>> >> >>>> offers
>> > a
>> >> >>>> good approach to LDP FRR.
>> >> >>>>
>> >> >>>> Curtis
>> >> >>> ____________________________________________= ___
>> >> >>> rtgwg mailing list
>> >> >>> rtgwg@ietf= .org
>> >> >>> https://www.ietf.org/mailman/listinfo/rtgwg
>> >> >>>
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> - Sri
>> >> >
>> >> > _______________________________________________
>> >> > rtgwg mailing list
>> >> > rtgwg@ietf.org=
>> >> > https://www.ietf.org/mailman/listinfo/rtgwg
>> >> _______________________________________________
>> >> rtgwg mailing list
>> >> rtgwg@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/rtgwg
>> >
>>
>>
>>
>> --
>> Sriganesh Kini (Sri)
>



--
Sriganesh Kini (Sri)
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtgwg

--001636e8ff5b4294cd04a9b6db76-- From sriganeshkini@gmail.com Thu Aug 4 17:07:00 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C920311E808D for ; Thu, 4 Aug 2011 17:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ga+nMK5ewUUH for ; Thu, 4 Aug 2011 17:07:00 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id CE21911E807C for ; Thu, 4 Aug 2011 17:06:59 -0700 (PDT) Received: by vws12 with SMTP id 12so1116418vws.31 for ; Thu, 04 Aug 2011 17:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=SNNwVXr5/Ol9RwQXnF5Ej1gFVYYFuBOlU7I54Lam/mA=; b=xpHXzO0ylf4zsIPt7OZcl4uEPdJGmUZYdlZZsaRcOFXyqnpdk+FvD8103algtHs8oW s6QcNhRJjtScVP4+P+BeIQM+LfAvJG/y6xDMEJzkF6Q/Fi0j70ZnYrmeg1qm1ot1J04Q C7xPjsYPKSsEC2o+//cdZCf5TweH+6sS6kbxQ= Received: by 10.52.31.38 with SMTP id x6mr1545498vdh.193.1312502835526; Thu, 04 Aug 2011 17:07:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.68 with HTTP; Thu, 4 Aug 2011 17:06:45 -0700 (PDT) In-Reply-To: <201108041751.p74Hp0JR058053@harbor.orleans.occnc.com> References: <136C7651-8CCF-4CA7-814C-09F89D5C71F5@gmail.com> <201108041751.p74Hp0JR058053@harbor.orleans.occnc.com> From: Sri Date: Thu, 4 Aug 2011 17:06:45 -0700 Message-ID: Subject: Re: draft-kini-mpls-frr-ldp-01 for review To: curtis@occnc.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 00:07:00 -0000 Curtis, This should not be a RSVP vs LDP debate. RSVP-TE is best positioned to do some things (e.g. TE) and this draft is not changing any of it. I agree that there are many techniques available to scale a network. But there are many existing deployments of LDP. Many of these service providers do not want to (re)design their network using RSVP. In fact they do not want to introduce RSVP anywhere in their network. But they are interested in a local repair mechanism that provides better coverage than current available without increasing complexity. Agree that depending on the part of the network the service provider may look for a different protocol/toolkit to solve his problem. Thanks On Thu, Aug 4, 2011 at 10:51 AM, Curtis Villamizar wrote= : > > Sri, > > This is turning into a RSVP-TE vs LDP debate. > > In message <136C7651-8CCF-4CA7-814C-09F89D5C71F5@gmail.com> > Sriganesh Kini writes: >> > >> > =A0Enable IGP-TE extensions and configure links, minimum is enable TE >> > =A0per link and advertise defaults. >> > >> > =A0Define a mesh group. >> > >> > =A0Configure defaults for mesh group at zero bandwidth and use of FRR. >> > >> > Done. >> >> Full mesh is not as scalable. > > > No protocol so far is infinitely scalable. > > Computation in LDP is one SPF, order(N*logN). =A0RSVP-TE needs N of > these CSPF computations, order(N^2*logN). > > LDP uses multipoint to point (P2MP) LSP, making TE impractical, but > using N labels at any given point. =A0RSVP-TE uses point to point (PTP) > LSP so it needs order N^2 total LSP of which absolut worst case is > N^2/4 crossing a thin cutset in the graph (one or two links). > > When bumping into OSPF scaling limits, use areas. =A0With ISIS use > levels. =A0Both offer a two level hierarchy with some differences. =A0If > that isn't enough, at some size neither protocol will function. > > With RSVP-TE you have to use hierarchy sooner but there are more > levels of hierarchy available. > > First make core one mesh group. =A0Make each region its own mesh group. > Some LSR sit on both core and one or more region. =A0The create a mesh > group for the edge routers which use the hierarchy in core and regions > to go edge to edge. =A0Any restoration is done in the H-LSP and not in > the edge mesh group if you just set the "resilience" parameters to > make it so. > > I don't know of anyone who took this out further to access, but add > one more layer of hierarchy and build a lot of small access mesh > groups and repeat process. > > There are five levels of hierarchy available. =A0PSC-0 (implied) and > PSC-1 to PSC-4. > > Scaling is solvable to largest networks today. =A0But the FUD remains. > > That is the short explanation without turning this email thread into a > thesis on scalability. > > >> > That is not much complexity. =A0The configuration is identical per nod= e, >> > except per link config since different nodes have different number and >> > naming of links. =A0This is both easy to set up and easily manageable. >> > >> > If later TE is desired, then either set autobandwidth on the mesh >> > group or capture per LSP traffic measurements and begin configuring >> > bandwidth amounts per LSP. =A0The latter takes a small amount of work >> > but is preferred by many service providers. >> >> Maybe this is true for some providers that you are aware of. But I >> have seen many providers prefer to run an LDP network and want full >> coverage protection. > > > It is entirely possible that RSVP-TE is used much more in core and LDP > much more in edges. =A0It could be which target market the product > focuses on. > > Regards, > > Curtis > --=20 Sriganesh Kini (Sri) From akatlas@gmail.com Fri Aug 5 07:50:48 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF69421F8C33 for ; Fri, 5 Aug 2011 07:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVT2yCsTIGwJ for ; Fri, 5 Aug 2011 07:50:48 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5420021F8B98 for ; Fri, 5 Aug 2011 07:50:48 -0700 (PDT) Received: by ywm21 with SMTP id 21so1976947ywm.31 for ; Fri, 05 Aug 2011 07:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=SvQXo+2dYEUk52j/59BP9fBniOMIwtpSefFXNrpKstE=; b=ta6hJ3du7KY7XGLgAtUfUAapCSvnw0sDuabsL16fUAD5iIiIbLGCvwik3JuuSQtEGR 2A63HvwwBKx6xikLW6j93xZoye9AurLV2u02z8RZd7MWTd3faGcYQRC9AZ+5Ktz2PAh1 xIQ4uuIaAec1vJuBRADTCEymf2PYZTZ206Av4= MIME-Version: 1.0 Received: by 10.142.82.21 with SMTP id f21mr2117123wfb.398.1312555865331; Fri, 05 Aug 2011 07:51:05 -0700 (PDT) Received: by 10.68.62.162 with HTTP; Fri, 5 Aug 2011 07:51:05 -0700 (PDT) Date: Fri, 5 Aug 2011 10:51:05 -0400 Message-ID: Subject: comments on draft-atlas-rtgwg-mrt-frr-architecture-00 From: Alia Atlas To: rtgwg@ietf.org Content-Type: multipart/alternative; boundary=001636e90ec119d96d04a9c33a37 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 14:50:49 -0000 --001636e90ec119d96d04a9c33a37 Content-Type: text/plain; charset=ISO-8859-1 (WG-chair hat off) I would be interested in comments and questions about the MRT Fast-reroute. In the meeting, there wasn't time to take many questions - and I know Gabor & I had to go fast over some parts. Thanks, Alia --001636e90ec119d96d04a9c33a37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (WG-chair hat off)

I would be interested in comments and questions a= bout the MRT Fast-reroute.=A0 In the meeting,
there wasn't time to t= ake many questions - and I know Gabor & I had to go fast over some part= s.

Thanks,
Alia
--001636e90ec119d96d04a9c33a37-- From sriganeshkini@gmail.com Fri Aug 5 15:57:47 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCCB21F86B6 for ; Fri, 5 Aug 2011 15:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7l5l4S5vlzqD for ; Fri, 5 Aug 2011 15:57:46 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C430B21F867A for ; Fri, 5 Aug 2011 15:57:45 -0700 (PDT) Received: by vxi40 with SMTP id 40so3178277vxi.31 for ; Fri, 05 Aug 2011 15:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=qb1Pac/QPj/EsPxDOSqx9q2uRrGchQF3MzDU3Y731h8=; b=BoWVLcWDXqwujpfhvv+ZPutwfyqd/QZZZHz7IHrwbXu13IV0SV4mEHdDZOd9rHF2Vk aQOMVidJifG3wzH2GZnYEIb+udZkQGNZScNC2wfarb7VeDKF12hU1pxKWRYhaAkjHqfk x4YSfVc4qa5ZNPktwY4i8vtu5CFaJiKdH5vJw= Received: by 10.52.69.179 with SMTP id f19mr37703vdu.394.1312585084071; Fri, 05 Aug 2011 15:58:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.68 with HTTP; Fri, 5 Aug 2011 15:57:34 -0700 (PDT) In-Reply-To: References: <201108041313.p74DDgda043410@harbor.orleans.occnc.com> <136C7651-8CCF-4CA7-814C-09F89D5C71F5@gmail.com> From: Sri Date: Fri, 5 Aug 2011 15:57:34 -0700 Message-ID: Subject: Re: draft-kini-mpls-frr-ldp-01 for review To: Alia Atlas Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 22:57:47 -0000 Alia, inline On Thu, Aug 4, 2011 at 5:05 PM, Alia Atlas wrote: > Sri, > > It sounds like you are advocating the P-Q option that Mike & Stewart > originally suggested.=A0 From the draft, I couldn't tell whether you were > suggesting that or simply computing not-via alternates from the PLR and t= hen > signaling them using LDP DoD with an ERO. The proposal currently has some commonality with the other work you mentioned. We had discussed with Stewart and it seems there are some differences with the way the upstream is defined in this draft versus the other drafts. Also we handle SRLGs differently. But there are overlaps too. This draft currently re-uses existing shortest-path state as far as possible and handles SRLG failures. We have also not encountered scalability issues in practical topologies that we analyzed. > > The key in the fast-reroute discussions is what is the algorithm to compu= te > or create the alternates. Is it necessary to standardize the algorithm iff it has to be executed in a distributed manner. The draft currently defines protocol extensions, but SPF algos can be re-used to find backup LSPs. The other nodes only need to signal the LSP. There should be room for better algorithms in the future. > > In RTGWG, we had a long discussion about what properties we wanted for > IP/LDP Fast-Reroute.=A0 At the time, of course, I was suggesting U-turn > alternates; they don't require tunnels or additional signaling and increa= sed > the coverage up to 98% or so.=A0 Beyond that, minor topology changes coul= d get > a lot - and one could always go to cascaded U-turns if necessary. Yes, we understand that has associated issues. > > There was a strong push for a solution that could provide 100% coverage > whenever the network couldn't be partitioned by a single failure.=A0 That= is > what led to not-via which gained WG consensus to become a WG draft. > The current proposal has full coverage. The "simplified-version" that was mentioned can be an implementation/deployment option. > At this point, I think we've seen a lack of progress on not-via due to th= e > scalability issues. > > The need for a solution and the scalability issues around not-via are wha= t > have motivated me to suggest MRT fast-reroute.=A0 MRT fast-reroute can pr= ovide > 100% coverage regardless of topology. AFAIK it does not handle SRLG failures. > > I'm deeply amused by having this discussion on the other side of the fenc= e - > arguing for the 100% solution. > > Regardless, I'd have to see some pretty convincing arguments before sayin= g > that we should compromise on something less.=A0 I haven't seen any eviden= ce > that the WG opinion has changed on this point. > > Alia > > P.S.=A0 For topology coverage, how many cases still don't require any dir= ected > forwarding once a single or multiple failures have happened to the networ= k? That depends on the topology and the failure. > > On Thu, Aug 4, 2011 at 7:17 PM, Sri wrote: >> >> inline >> >> On Thu, Aug 4, 2011 at 3:27 PM, Eric Osborne (eosborne) >> wrote: >> > One question inline with EO# >> > ... >> > >> >> > >> >> > How much simpler is your solution than what I've described above? >> >> > They both need >> >> > =A0- link-state information available for explicit paths >> >> > =A0- srlg info available, should one want to use it >> >> > =A0- explicit routing control, even if the paths are dynamically >> >> > calculated per PLR >> >> >> >> In most practical topologies we do not see the need for explicit >> >> routing >> >> control in LDP. As an example see the link protection topology in the >> >> preso. In fact as we analyze more practical topologies, we are seeing >> >> lesser need for it. So the explicit routing is more for providing a >> >> completeness of the solution to address all topologies. >> > >> > >> > ... >> > >> >> >> >> As stated earlier the explicit routing extension to LDP is minimal an= d >> >> that too can be removed for the "simplified-version". CR-LDP can stay >> >> as- >> >> is ! >> > >> > EO# >> > If you remove the explicit routing from LDP, aren't you just left with >> > an approach that looks a lot like LFA or MRT? =A0What's unique to what= you're >> > presenting other than the need to occasionally use contstraint-routed = LDP? >> >> IPFRR-LFA uses only the IP(IGP) loop-free alternates. The simplified >> version of FRR-LDP uses LDP LSPs with stacking such that they are loop >> free and avoid the failure. A simple example is the link-protection >> case in the preso. They could also avoid SRLG failures if the >> appropriate shortest-path LSPs exist in that topology. >> >> MRT uses redundant trees. >> >> > >> > >> > >> > eric >> > >> > >> >> >> >> > >> >> > >> >> > >> >> > >> >> > eric >> >> > >> >> >> -----Original Message----- >> >> >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On >> >> >> Behalf >> >> > Of >> >> >> Sriganesh Kini >> >> >> Sent: Thursday, August 04, 2011 12:00 PM >> >> >> To: curtis@occnc.com >> >> >> Cc: rtgwg@ietf.org; Sriganesh Kini >> >> >> Subject: Re: draft-kini-mpls-frr-ldp-01 for review >> >> >> >> >> >> Inline >> >> >> >> >> >> - Sri >> >> >> >> >> >> Sent from my iPad >> >> >> >> >> >> On Aug 4, 2011, at 6:13 AM, Curtis Villamizar >> >> > wrote: >> >> >> >> >> >> > >> >> >> > In message >> >> >> > >> >> >> > > >> >> > > >> >> >> > Sriganesh Kini writes: >> >> >> >> >> >> >> >> We are re-using whatever is available and is needed. SRLG info = is >> >> >> >> needed at the nodes computing paths to protect the SRLG failure= . >> >> >> >> Using an existing IGP mechanism to do just that is an option. >> >> >> >> Stretching this to imply that RSVP-TE is reinvented doesn't mak= e >> >> >> >> sense. Many service providers who have LDP deployed simply don'= t >> >> > want >> >> >> >> the additional complexity of deploying RSVP-TE but they do want >> >> >> >> sub 50msec protection with full coverage. Moreover RSVP-TE >> >> >> >> doesn't >> >> > scale as >> >> >> well. >> >> >> > >> >> >> > >> >> >> > Additional complexity. >> >> >> >> >> >> No. Operationally the complexity is similar to running an LDP >> >> >> network. >> >> >> >> >> >> > >> >> >> > =A0Enable IGP-TE extensions and configure links, minimum is enab= le >> >> >> > TE >> >> >> > per link and advertise defaults. >> >> >> > >> >> >> > =A0Define a mesh group. >> >> >> > >> >> >> > =A0Configure defaults for mesh group at zero bandwidth and use o= f >> >> >> > FRR. >> >> >> > >> >> >> > Done. >> >> >> >> >> >> Full mesh is not as scalable. >> >> >> >> >> >> > >> >> >> > That is not much complexity. =A0The configuration is identical p= er >> >> > node, >> >> >> > except per link config since different nodes have different numb= er >> >> > and >> >> >> > naming of links. =A0This is both easy to set up and easily >> >> >> > manageable. >> >> >> > >> >> >> > If later TE is desired, then either set autobandwidth on the mes= h >> >> >> > group or capture per LSP traffic measurements and begin >> >> >> > configuring >> >> >> > bandwidth amounts per LSP. =A0The latter takes a small amount of >> >> >> > work >> >> >> > but is preferred by many service providers. >> >> >> >> >> >> Maybe this is true for some providers that you are aware of. But I >> >> > have >> >> >> seen many providers prefer to run an LDP network and want full >> >> > coverage >> >> >> protection. >> >> >> >> >> >> > >> >> >> > Curtis >> >> >> > >> >> >> > >> >> >> > >> >> >> >> On Wed, Aug 3, 2011 at 4:32 PM, Curtis Villamizar >> >> > >> >> >> wrote: >> >> >> >>> >> >> >> >>> In message >> >> >> >>> >> >> > <0ED867EB33AB2B45AAB470D5A64CDBF60CCA31C45D@EUSAACMS0701.eamcs.eric= s >> >> >> >>> son.se> >> >> >> >>> Jeff Tantsura writes: >> >> >> >>>> >> >> >> >>>> Hi Curtis, >> >> >> >>>> >> >> >> >>>> Irrespectively of this draft thanks to GMPLS IGP extensions a= s >> >> > per >> >> >> >>>> RFC's 4203 & 5307 SRLG info is there, it is up to >> >> >> >>>> implementation >> >> >> >>>> how to use it. >> >> >> >>>> >> >> >> >>>> Regards, >> >> >> >>>> Jeff >> >> >> >>> >> >> >> >>> >> >> >> >>> Those are in the extensions for GMPLS which is a superset of >> >> > RSVP-TE >> >> >> >>> based MPLS. =A0These are sub-TLV added to the Link TLV which >> >> > provides >> >> >> >>> a good part of the TE-LSDB used by RSVP-TE. =A0With that you g= et >> >> >> >>> available bandwidth at each priority level, the RSVP-TE 32 bit >> >> > link >> >> >> >>> attribute vector and other niceties that should have nothing t= o >> >> >> >>> do with LDP. >> >> >> >>> >> >> >> >>> For example, in RFC-3060 where Link TLV is defined for OSPF. >> >> >> >>> >> >> >> >>> =A0 The following sub-TLVs of the Link TLV are defined: >> >> >> >>> >> >> >> >>> =A0 =A0 =A01 - Link type (1 octet) >> >> >> >>> =A0 =A0 =A02 - Link ID (4 octets) >> >> >> >>> =A0 =A0 =A03 - Local interface IP address (4 octets) >> >> >> >>> =A0 =A0 =A04 - Remote interface IP address (4 octets) >> >> >> >>> =A0 =A0 =A05 - Traffic engineering metric (4 octets) >> >> >> >>> =A0 =A0 =A06 - Maximum bandwidth (4 octets) >> >> >> >>> =A0 =A0 =A07 - Maximum reservable bandwidth (4 octets) >> >> >> >>> =A0 =A0 =A08 - Unreserved bandwidth (32 octets) >> >> >> >>> =A0 =A0 =A09 - Administrative group (4 octets) >> >> >> >>> >> >> >> >>> That is what is being extended in RFC4203. >> >> >> >>> >> >> >> >>> So don't run RSVP-TE, just half of it. =A0Then compute LDP pat= hs? >> >> >> >>> Sounds too much like CR-LDP to me. >> >> >> >>> >> >> >> >>> If we reinvent half of RSVP-TE, why not all of it. =A0OTOH, wh= y >> >> >> >>> not >> >> >> >>> just run half of it. =A0Use RSVP-TE LSP with zero BW and MPLS = FRR >> >> >> >>> [RFC4090] and forget LDP except for PW signaling. >> >> >> >>> >> >> >> >>> Curtis >> >> >> >>> >> >> >> >>> >> >> >> >>>> -----Original Message----- >> >> >> >>>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] = On >> >> >> >>>> Behalf Of Curtis Villamizar >> >> >> >>>> Sent: Wednesday, August 03, 2011 11:35 >> >> >> >>>> To: Sriganesh Kini >> >> >> >>>> Cc: rtgwg@ietf.org >> >> >> >>>> Subject: Re: draft-kini-mpls-frr-ldp-01 for review >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> In message >> >> >> >>>> >> >> > > >> >> >>>> > >> >> >> >>>> Sriganesh Kini writes: >> >> >> >>>>> >> >> >> >>>>> Hello, >> >> >> >>>>> >> >> >> >>>>> Regarding draft-kini-mpls-frr-ldp-01. >> >> >> >>>>> >> >> >> >>>>> We had feedback from the mpls WG to present this draft at >> >> >> >>>>> RTGWG. >> >> >> >>>>> Since our request for a slot was late, there is a chance tha= t >> >> >> >>>>> we may not have adequate time at the end of the session for >> >> >> >>>>> this draft. In any case we wanted to make the WG aware of th= e >> >> >> >>>>> draft >> >> > and >> >> >> >>>>> would appreciate any comments. >> >> >> >>>>> >> >> >> >>>>> Regards >> >> >> >>>>> >> >> >> >>>>> - Sri >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> Protection is inherently a traffic engineering problem. =A0IP= FRR >> >> >> >>>> provides mostly limited coverage protection, without the >> >> >> >>>> benefit >> >> > of >> >> >> >>>> signaled SRLG, and with increased potential of transient rout= e >> >> >> >>>> loops in the abense of complete and accurate SRLG information >> >> >> >>>> or >> >> >> >>>> when multiple failures occur that are not covered by SRLG. >> >> >> >>>> >> >> >> >>>> LDP FRR has all the same issues as IPFRR. =A0So in general I >> >> >> >>>> don't >> >> >> >>>> support LDP FRR. >> >> >> >>>> >> >> >> >>>> Even if I did support an LDP FRR, I don't think this draft >> >> >> >>>> offers >> >> > a >> >> >> >>>> good approach to LDP FRR. >> >> >> >>>> >> >> >> >>>> Curtis >> >> >> >>> _______________________________________________ >> >> >> >>> rtgwg mailing list >> >> >> >>> rtgwg@ietf.org >> >> >> >>> https://www.ietf.org/mailman/listinfo/rtgwg >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> - Sri >> >> >> > >> >> >> > _______________________________________________ >> >> >> > rtgwg mailing list >> >> >> > rtgwg@ietf.org >> >> >> > https://www.ietf.org/mailman/listinfo/rtgwg >> >> >> _______________________________________________ >> >> >> rtgwg mailing list >> >> >> rtgwg@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/rtgwg >> >> > >> >> >> >> >> >> >> >> -- >> >> Sriganesh Kini (Sri) >> > >> >> >> >> -- >> Sriganesh Kini (Sri) >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg > > --=20 Sriganesh Kini (Sri) From fu.xihua@zte.com.cn Sun Aug 7 19:56:47 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA7921F8556 for ; Sun, 7 Aug 2011 19:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.446 X-Spam-Level: X-Spam-Status: No, score=-98.446 tagged_above=-999 required=5 tests=[AWL=0.978, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gV-Y9lA8itfA for ; Sun, 7 Aug 2011 19:56:46 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id DE93821F8520 for ; Sun, 7 Aug 2011 19:56:42 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 152361754626705; Mon, 8 Aug 2011 10:54:23 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 22013.5723913931; Mon, 8 Aug 2011 10:56:57 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p782upmf005174; Mon, 8 Aug 2011 10:56:51 +0800 (GMT-8) (envelope-from fu.xihua@zte.com.cn) To: rtgwg@ietf.org Subject: one comment on draft-ietf-rtgwg-cl-requirement-04 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: fu.xihua@zte.com.cn Date: Mon, 8 Aug 2011 10:56:51 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-08-08 10:56:52, Serialize complete at 2011-08-08 10:56:52 Content-Type: multipart/alternative; boundary="=_alternative 001032F7482578E6_=" X-MAIL: mse01.zte.com.cn p782upmf005174 Cc: "cvillamizar@infinera.com" , "Malis, Andrew G. \(Andy\)" , "So, Ning" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 02:56:47 -0000 This is a multipart message in MIME format. --=_alternative 001032F7482578E6_= Content-Type: text/plain; charset="US-ASCII" Hi, Based on a short discussion with the authors of this draft on the requirement of adding packet loss in FR#15, FR#16 and FR#17, Authors suggested if no one objects, they can revise the text to include loss as a performance parameter. Thanks, Xihua Fu --=_alternative 001032F7482578E6_= Content-Type: text/html; charset="US-ASCII"
Hi,

Based on a short discussion with the authors of this draft on the requirement of adding packet loss in FR#15, FR#16 and FR#17,
Authors suggested if no one objects, they can revise the text to include loss as a performance parameter.

Thanks,

Xihua Fu


--=_alternative 001032F7482578E6_=-- From alvaro.retana@hp.com Mon Aug 8 14:11:25 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF0511E80D2 for ; Mon, 8 Aug 2011 14:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8hO3QxEnII8 for ; Mon, 8 Aug 2011 14:11:24 -0700 (PDT) Received: from g1t0026.austin.hp.com (g1t0026.austin.hp.com [15.216.28.33]) by ietfa.amsl.com (Postfix) with ESMTP id AAC3511E80D3 for ; Mon, 8 Aug 2011 14:11:24 -0700 (PDT) Received: from G2W1953G.americas.hpqcorp.net (g2w1953g.austin.hp.com [16.238.8.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0026.austin.hp.com (Postfix) with ESMTPS id 60FBCC22C; Mon, 8 Aug 2011 21:11:51 +0000 (UTC) Received: from G1W0396.americas.hpqcorp.net (16.236.31.9) by G2W1953G.americas.hpqcorp.net (16.238.8.185) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 8 Aug 2011 21:10:18 +0000 Received: from GVW1338EXA.americas.hpqcorp.net ([16.236.29.12]) by G1W0396.americas.hpqcorp.net ([16.236.31.9]) with mapi; Mon, 8 Aug 2011 22:10:18 +0100 From: "Retana, Alvaro" To: "rtgwg@ietf.org" Date: Mon, 8 Aug 2011 22:10:16 +0100 Subject: RE: WGLC:draft-ietf-rtgwg-lfa-applicability Thread-Topic: WGLC:draft-ietf-rtgwg-lfa-applicability Thread-Index: AcxAryLsK3gY4tzoQE2zFkxEHWc5vwVWi8UQ Message-ID: <24646CE17826CF4A8DF71F9856C7E6565929666159@GVW1338EXA.americas.hpqcorp.net> References: <24646CE17826CF4A8DF71F9856C7E6565927F837CB@GVW1338EXA.americas.hpqcorp.net> In-Reply-To: <24646CE17826CF4A8DF71F9856C7E6565927F837CB@GVW1338EXA.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_24646CE17826CF4A8DF71F9856C7E6565929666159GVW1338EXAame_" MIME-Version: 1.0 Cc: "draft-ietf-rtgwg-lfa-applicability@tools.ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 21:11:26 -0000 --_000_24646CE17826CF4A8DF71F9856C7E6565929666159GVW1338EXAame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! The last call for this draft ended last week. We only received one message= back about it...a support vote. Given that this draft has been a WG item for about a year, that it has been= presented at meetings and discussed there and on the list, and that there = has been no opposition or open items (from searching the list), we are goin= g to go ahead w/the publication as an Informational RFC. Thanks! Alvaro. From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of R= etana, Alvaro Sent: Tuesday, July 12, 2011 12:17 PM To: rtgwg@ietf.org Cc: draft-ietf-rtgwg-lfa-applicability@tools.ietf.org Subject: WGLC:draft-ietf-rtgwg-lfa-applicability Hi! This message is to start a Working Group Last Call for 'LFA applicability i= n SP networks' (http://tools.ietf.org/html/draft-ietf-rtgwg-lfa-applicabili= ty-02). To give everyone enough time, this Last Call will end on August 1, 2011. The intent is to publish this document as an Informational RFC. Please send any comments to the WG list. Thanks! Alvaro. --_000_24646CE17826CF4A8DF71F9856C7E6565929666159GVW1338EXAame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi!

 

The last call for this draft ended last week.  We o= nly received one message back about it...a support vote.<= /p>

 

Given that this d= raft has been a WG item for about a year, that it has been presented at mee= tings and discussed there and on the list, and that there has been no oppos= ition or open items (from searching the list), we are going to go ahead w/t= he publication as an Informational RFC.

 

Thanks!

 

Alvaro.

 <= /span>

From: rtgwg-bounces@ietf= .org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Retana, Alvaro
= Sent: Tuesday, July 12, 2011 12:17 PM
To: rtgwg@ietf.orgCc: draft-ietf-rtgwg-lfa-applicability@tools.ietf.org
Subjec= t: WGLC:draft-ietf-rtgwg-lfa-applicability

<= /div>

 

Hi!

 

This message is to start a Working Group Last Call for ‘LFA applicab= ility in SP networks’ (http://tool= s.ietf.org/html/draft-ietf-rtgwg-lfa-applicability-02).

 

= To give everyone enough time, this Last Call will end on August 1, 2011.

 

The intent is to publish this document as an Informational RFC.<= /o:p>

 

Please send any comments to the WG list.

 

Thanks!

 

Alvar= o.

 

= --_000_24646CE17826CF4A8DF71F9856C7E6565929666159GVW1338EXAame_-- From akatlas@gmail.com Tue Aug 9 08:11:47 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB2221F8BB2 for ; Tue, 9 Aug 2011 08:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.527 X-Spam-Level: X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxKwcIqL4NFA for ; Tue, 9 Aug 2011 08:11:44 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 327B521F8BB1 for ; Tue, 9 Aug 2011 08:11:44 -0700 (PDT) Received: by pzk33 with SMTP id 33so224581pzk.18 for ; Tue, 09 Aug 2011 08:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Xs3VnYVEUE8QsVt31tBseWOA+1mhqzi/iz8ht/KErOk=; b=RHymofM9osU+2t/WMYsyoExQn2sVOzSyxTaY+3f0DYhSuk+4x0kULznIXVlZVT/rJO bTeyr+Tqrpv+kOs+5BanxHrz65xf4bkZcHip3EEV+9YDSwW3HtDMoTtPwpypKMhC1M7C 0KbbzzxIDU7Wdycb7sdHb+tRTEIlBQNbVctYg= MIME-Version: 1.0 Received: by 10.142.226.15 with SMTP id y15mr6530540wfg.232.1312902731906; Tue, 09 Aug 2011 08:12:11 -0700 (PDT) Received: by 10.68.49.135 with HTTP; Tue, 9 Aug 2011 08:12:11 -0700 (PDT) In-Reply-To: References: <201108041313.p74DDgda043410@harbor.orleans.occnc.com> <136C7651-8CCF-4CA7-814C-09F89D5C71F5@gmail.com> Date: Tue, 9 Aug 2011 11:12:11 -0400 Message-ID: Subject: Re: draft-kini-mpls-frr-ldp-01 for review From: Alia Atlas To: Sri Content-Type: multipart/alternative; boundary=000e0cd3287ef5bef904aa13fc51 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 15:11:47 -0000 --000e0cd3287ef5bef904aa13fc51 Content-Type: text/plain; charset=ISO-8859-1 Sri, The algorithm is important to allow evaluation of the feasibility and trade-offs of this approach versus others. For instance, an algorithm for LFA is clearly defined even though the LFA computation is a purely local matter. Statements in the draft such as "An LSR computes the failures and prefixes for which it can act as a BSP MP and advertises a label mapping for the BSP LSP by including the Failure Element TLV and the Backup Path Vector TLV." are particularly unclear as to their expected algorithm and computational complexity. One of the strong reasons for 100% coverage is to handle the case where the existing network topology has already been impacted by one or more failures that haven't been repaired. An analysis of a method and claim of 100% coverage based solely on topologies as planned misses this issue - which is the strong argument for needing 100% coverage. A method that uses explicitly routed paths for the alternates can have 100%, of course, assuming that multi-homed prefixes are properly covered. Finally, the proposed mechanisms do not describe any mechanism for handling IP traffic. One of the initial goals for IP/LDP fast-reroute in RTGWG was to have mechanisms that work for IP traffic as well as LDP. I don't believe it is necessary or desirable to have different mechanisms for IP and LDP traffic. Similarly, having a common mechanism that also applies for IP and mLDP multicast is preferable. Alia On Fri, Aug 5, 2011 at 6:57 PM, Sri wrote: > Alia, > > inline > > On Thu, Aug 4, 2011 at 5:05 PM, Alia Atlas wrote: > > Sri, > > > > It sounds like you are advocating the P-Q option that Mike & Stewart > > originally suggested. From the draft, I couldn't tell whether you were > > suggesting that or simply computing not-via alternates from the PLR and > then > > signaling them using LDP DoD with an ERO. > > The proposal currently has some commonality with the other work you > mentioned. We had discussed with Stewart and it seems there are some > differences with the way the upstream is defined in this draft versus > the other drafts. Also we handle SRLGs differently. But there are > overlaps too. This draft currently re-uses existing shortest-path > state as far as possible and handles SRLG failures. We have also not > encountered scalability issues in practical topologies that we > analyzed. > > > > > The key in the fast-reroute discussions is what is the algorithm to > compute > > or create the alternates. > > Is it necessary to standardize the algorithm iff it has to be executed > in a distributed manner. The draft currently defines protocol > extensions, but SPF algos can be re-used to find backup LSPs. The > other nodes only need to signal the LSP. There should be room for > better algorithms in the future. > > > > > In RTGWG, we had a long discussion about what properties we wanted for > > IP/LDP Fast-Reroute. At the time, of course, I was suggesting U-turn > > alternates; they don't require tunnels or additional signaling and > increased > > the coverage up to 98% or so. Beyond that, minor topology changes could > get > > a lot - and one could always go to cascaded U-turns if necessary. > > Yes, we understand that has associated issues. > > > > > There was a strong push for a solution that could provide 100% coverage > > whenever the network couldn't be partitioned by a single failure. That > is > > what led to not-via which gained WG consensus to become a WG draft. > > > > The current proposal has full coverage. The "simplified-version" that > was mentioned can be an implementation/deployment option. > > > At this point, I think we've seen a lack of progress on not-via due to > the > > scalability issues. > > > > The need for a solution and the scalability issues around not-via are > what > > have motivated me to suggest MRT fast-reroute. MRT fast-reroute can > provide > > 100% coverage regardless of topology. > > AFAIK it does not handle SRLG failures. > > > > > I'm deeply amused by having this discussion on the other side of the > fence - > > arguing for the 100% solution. > > > > Regardless, I'd have to see some pretty convincing arguments before > saying > > that we should compromise on something less. I haven't seen any evidence > > that the WG opinion has changed on this point. > > > > Alia > > > > P.S. For topology coverage, how many cases still don't require any > directed > > forwarding once a single or multiple failures have happened to the > network? > > That depends on the topology and the failure. > > > > > On Thu, Aug 4, 2011 at 7:17 PM, Sri wrote: > >> > >> inline > >> > >> On Thu, Aug 4, 2011 at 3:27 PM, Eric Osborne (eosborne) > >> wrote: > >> > One question inline with EO# > >> > ... > >> > > >> >> > > >> >> > How much simpler is your solution than what I've described above? > >> >> > They both need > >> >> > - link-state information available for explicit paths > >> >> > - srlg info available, should one want to use it > >> >> > - explicit routing control, even if the paths are dynamically > >> >> > calculated per PLR > >> >> > >> >> In most practical topologies we do not see the need for explicit > >> >> routing > >> >> control in LDP. As an example see the link protection topology in the > >> >> preso. In fact as we analyze more practical topologies, we are seeing > >> >> lesser need for it. So the explicit routing is more for providing a > >> >> completeness of the solution to address all topologies. > >> > > >> > > >> > ... > >> > > >> >> > >> >> As stated earlier the explicit routing extension to LDP is minimal > and > >> >> that too can be removed for the "simplified-version". CR-LDP can stay > >> >> as- > >> >> is ! > >> > > >> > EO# > >> > If you remove the explicit routing from LDP, aren't you just left with > >> > an approach that looks a lot like LFA or MRT? What's unique to what > you're > >> > presenting other than the need to occasionally use contstraint-routed > LDP? > >> > >> IPFRR-LFA uses only the IP(IGP) loop-free alternates. The simplified > >> version of FRR-LDP uses LDP LSPs with stacking such that they are loop > >> free and avoid the failure. A simple example is the link-protection > >> case in the preso. They could also avoid SRLG failures if the > >> appropriate shortest-path LSPs exist in that topology. > >> > >> MRT uses redundant trees. > >> > >> > > >> > > >> > > >> > eric > >> > > >> > > >> >> > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > eric > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On > >> >> >> Behalf > >> >> > Of > >> >> >> Sriganesh Kini > >> >> >> Sent: Thursday, August 04, 2011 12:00 PM > >> >> >> To: curtis@occnc.com > >> >> >> Cc: rtgwg@ietf.org; Sriganesh Kini > >> >> >> Subject: Re: draft-kini-mpls-frr-ldp-01 for review > >> >> >> > >> >> >> Inline > >> >> >> > >> >> >> - Sri > >> >> >> > >> >> >> Sent from my iPad > >> >> >> > >> >> >> On Aug 4, 2011, at 6:13 AM, Curtis Villamizar > >> >> > wrote: > >> >> >> > >> >> >> > > >> >> >> > In message > >> >> >> > > >> >> >> > < > CAOndX-vC5zbnYLwKgbRz-u9yctcv7Lm-qKpB8Ly-9e-03A514A@mail.gmail.com > >> >> >> > > > >> >> >> > Sriganesh Kini writes: > >> >> >> >> > >> >> >> >> We are re-using whatever is available and is needed. SRLG info > is > >> >> >> >> needed at the nodes computing paths to protect the SRLG > failure. > >> >> >> >> Using an existing IGP mechanism to do just that is an option. > >> >> >> >> Stretching this to imply that RSVP-TE is reinvented doesn't > make > >> >> >> >> sense. Many service providers who have LDP deployed simply > don't > >> >> > want > >> >> >> >> the additional complexity of deploying RSVP-TE but they do want > >> >> >> >> sub 50msec protection with full coverage. Moreover RSVP-TE > >> >> >> >> doesn't > >> >> > scale as > >> >> >> well. > >> >> >> > > >> >> >> > > >> >> >> > Additional complexity. > >> >> >> > >> >> >> No. Operationally the complexity is similar to running an LDP > >> >> >> network. > >> >> >> > >> >> >> > > >> >> >> > Enable IGP-TE extensions and configure links, minimum is enable > >> >> >> > TE > >> >> >> > per link and advertise defaults. > >> >> >> > > >> >> >> > Define a mesh group. > >> >> >> > > >> >> >> > Configure defaults for mesh group at zero bandwidth and use of > >> >> >> > FRR. > >> >> >> > > >> >> >> > Done. > >> >> >> > >> >> >> Full mesh is not as scalable. > >> >> >> > >> >> >> > > >> >> >> > That is not much complexity. The configuration is identical per > >> >> > node, > >> >> >> > except per link config since different nodes have different > number > >> >> > and > >> >> >> > naming of links. This is both easy to set up and easily > >> >> >> > manageable. > >> >> >> > > >> >> >> > If later TE is desired, then either set autobandwidth on the > mesh > >> >> >> > group or capture per LSP traffic measurements and begin > >> >> >> > configuring > >> >> >> > bandwidth amounts per LSP. The latter takes a small amount of > >> >> >> > work > >> >> >> > but is preferred by many service providers. > >> >> >> > >> >> >> Maybe this is true for some providers that you are aware of. But I > >> >> > have > >> >> >> seen many providers prefer to run an LDP network and want full > >> >> > coverage > >> >> >> protection. > >> >> >> > >> >> >> > > >> >> >> > Curtis > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> >> On Wed, Aug 3, 2011 at 4:32 PM, Curtis Villamizar > >> >> > > >> >> >> wrote: > >> >> >> >>> > >> >> >> >>> In message > >> >> >> >>> > >> >> > > <0ED867EB33AB2B45AAB470D5A64CDBF60CCA31C45D@EUSAACMS0701.eamcs.erics > >> >> >> >>> son.se> > >> >> >> >>> Jeff Tantsura writes: > >> >> >> >>>> > >> >> >> >>>> Hi Curtis, > >> >> >> >>>> > >> >> >> >>>> Irrespectively of this draft thanks to GMPLS IGP extensions > as > >> >> > per > >> >> >> >>>> RFC's 4203 & 5307 SRLG info is there, it is up to > >> >> >> >>>> implementation > >> >> >> >>>> how to use it. > >> >> >> >>>> > >> >> >> >>>> Regards, > >> >> >> >>>> Jeff > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> Those are in the extensions for GMPLS which is a superset of > >> >> > RSVP-TE > >> >> >> >>> based MPLS. These are sub-TLV added to the Link TLV which > >> >> > provides > >> >> >> >>> a good part of the TE-LSDB used by RSVP-TE. With that you get > >> >> >> >>> available bandwidth at each priority level, the RSVP-TE 32 bit > >> >> > link > >> >> >> >>> attribute vector and other niceties that should have nothing > to > >> >> >> >>> do with LDP. > >> >> >> >>> > >> >> >> >>> For example, in RFC-3060 where Link TLV is defined for OSPF. > >> >> >> >>> > >> >> >> >>> The following sub-TLVs of the Link TLV are defined: > >> >> >> >>> > >> >> >> >>> 1 - Link type (1 octet) > >> >> >> >>> 2 - Link ID (4 octets) > >> >> >> >>> 3 - Local interface IP address (4 octets) > >> >> >> >>> 4 - Remote interface IP address (4 octets) > >> >> >> >>> 5 - Traffic engineering metric (4 octets) > >> >> >> >>> 6 - Maximum bandwidth (4 octets) > >> >> >> >>> 7 - Maximum reservable bandwidth (4 octets) > >> >> >> >>> 8 - Unreserved bandwidth (32 octets) > >> >> >> >>> 9 - Administrative group (4 octets) > >> >> >> >>> > >> >> >> >>> That is what is being extended in RFC4203. > >> >> >> >>> > >> >> >> >>> So don't run RSVP-TE, just half of it. Then compute LDP > paths? > >> >> >> >>> Sounds too much like CR-LDP to me. > >> >> >> >>> > >> >> >> >>> If we reinvent half of RSVP-TE, why not all of it. OTOH, why > >> >> >> >>> not > >> >> >> >>> just run half of it. Use RSVP-TE LSP with zero BW and MPLS > FRR > >> >> >> >>> [RFC4090] and forget LDP except for PW signaling. > >> >> >> >>> > >> >> >> >>> Curtis > >> >> >> >>> > >> >> >> >>> > >> >> >> >>>> -----Original Message----- > >> >> >> >>>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] > On > >> >> >> >>>> Behalf Of Curtis Villamizar > >> >> >> >>>> Sent: Wednesday, August 03, 2011 11:35 > >> >> >> >>>> To: Sriganesh Kini > >> >> >> >>>> Cc: rtgwg@ietf.org > >> >> >> >>>> Subject: Re: draft-kini-mpls-frr-ldp-01 for review > >> >> >> >>>> > >> >> >> >>>> > >> >> >> >>>> In message > >> >> >> >>>> > >> >> > < > CAOndX-tcB4UVQnWKKoRcdEp6h2jTRAAHFBWLqq-qwgnV5bUD-g@mail.gmail.com > >> >> >> >>>> > > >> >> >> >>>> Sriganesh Kini writes: > >> >> >> >>>>> > >> >> >> >>>>> Hello, > >> >> >> >>>>> > >> >> >> >>>>> Regarding draft-kini-mpls-frr-ldp-01. > >> >> >> >>>>> > >> >> >> >>>>> We had feedback from the mpls WG to present this draft at > >> >> >> >>>>> RTGWG. > >> >> >> >>>>> Since our request for a slot was late, there is a chance > that > >> >> >> >>>>> we may not have adequate time at the end of the session for > >> >> >> >>>>> this draft. In any case we wanted to make the WG aware of > the > >> >> >> >>>>> draft > >> >> > and > >> >> >> >>>>> would appreciate any comments. > >> >> >> >>>>> > >> >> >> >>>>> Regards > >> >> >> >>>>> > >> >> >> >>>>> - Sri > >> >> >> >>>> > >> >> >> >>>> > >> >> >> >>>> Protection is inherently a traffic engineering problem. > IPFRR > >> >> >> >>>> provides mostly limited coverage protection, without the > >> >> >> >>>> benefit > >> >> > of > >> >> >> >>>> signaled SRLG, and with increased potential of transient > route > >> >> >> >>>> loops in the abense of complete and accurate SRLG information > >> >> >> >>>> or > >> >> >> >>>> when multiple failures occur that are not covered by SRLG. > >> >> >> >>>> > >> >> >> >>>> LDP FRR has all the same issues as IPFRR. So in general I > >> >> >> >>>> don't > >> >> >> >>>> support LDP FRR. > >> >> >> >>>> > >> >> >> >>>> Even if I did support an LDP FRR, I don't think this draft > >> >> >> >>>> offers > >> >> > a > >> >> >> >>>> good approach to LDP FRR. > >> >> >> >>>> > >> >> >> >>>> Curtis > >> >> >> >>> _______________________________________________ > >> >> >> >>> rtgwg mailing list > >> >> >> >>> rtgwg@ietf.org > >> >> >> >>> https://www.ietf.org/mailman/listinfo/rtgwg > >> >> >> >>> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> -- > >> >> >> >> - Sri > >> >> >> > > >> >> >> > _______________________________________________ > >> >> >> > rtgwg mailing list > >> >> >> > rtgwg@ietf.org > >> >> >> > https://www.ietf.org/mailman/listinfo/rtgwg > >> >> >> _______________________________________________ > >> >> >> rtgwg mailing list > >> >> >> rtgwg@ietf.org > >> >> >> https://www.ietf.org/mailman/listinfo/rtgwg > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> Sriganesh Kini (Sri) > >> > > >> > >> > >> > >> -- > >> Sriganesh Kini (Sri) > >> _______________________________________________ > >> rtgwg mailing list > >> rtgwg@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtgwg > > > > > > > > -- > Sriganesh Kini (Sri) > --000e0cd3287ef5bef904aa13fc51 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sri,

The algorithm is important to allow evaluation of the feasibili= ty and trade-offs of this approach
versus others.=A0 For instance, an al= gorithm for LFA is clearly defined even though the LFA computation
is a = purely local matter.

Statements in the draft such as "An LSR computes the failures and = prefixes for which it can act as a
BSP MP and advertises a label mapping for the BSP LSP by including the Failure Element TLV and
the Backup Path Vector TLV." are pa= rticularly unclear as to their expected algorithm and computational
comp= lexity.=A0

One of the strong reasons for 100% coverage is to handle= the case where the existing network topology
has already been impacted by one or more failures that haven't been rep= aired.=A0 An analysis of a method
and claim of 100% coverage based solel= y on topologies as planned misses this issue - which is the strong
argum= ent for needing 100% coverage.=A0 A method that uses explicitly routed path= s for the alternates can have
100%, of course, assuming that multi-homed prefixes are properly covered. <= br>
Finally, the proposed mechanisms do not describe any mechanism for h= andling IP traffic.=A0 One of the initial goals
for IP/LDP fast-reroute = in RTGWG was to have mechanisms that work for IP traffic as well as LDP.=A0= =A0 I don't believe
it is necessary or desirable to have different mechanisms for IP and LDP tr= affic.

Similarly, having a common mechanism that also applies for IP= and mLDP multicast is preferable.

Alia

On Fri, Aug 5, 2011 at 6:57 PM, Sri <sriganeshkini@gmail.com> wrote:
=
Alia,

inline

On Thu, Aug 4, 2011 at 5:05 PM, Alia Atlas <akatlas@gmail.com> wrote:
> Sri,
>
> It sounds like you are advocating the P-Q option that Mike & Stewa= rt
> originally suggested.=A0 From the draft, I couldn't tell whether y= ou were
> suggesting that or simply computing not-via alternates from the PLR an= d then
> signaling them using LDP DoD with an ERO.

The proposal currently has some commonality with the other work you mentioned. We had discussed with Stewart and it seems there are some
differences with the way the upstream is defined in this draft versus
the other drafts. Also we handle SRLGs differently. But there are
overlaps too. This draft currently re-uses existing shortest-path
state as far as possible and handles SRLG failures. We have also not
encountered scalability issues in practical topologies that we
analyzed.

>
> The key in the fast-reroute discussions is what is the algorithm to co= mpute
> or create the alternates.

Is it necessary to standardize the algorithm iff it has to be execute= d
in a distributed manner. The draft currently defines protocol
extensions, but SPF algos can be re-used to find backup LSPs. The
other nodes only need to signal the LSP. There should be room for
better algorithms in the future.

>
> In RTGWG, we had a long discussion about what properties we wanted for=
> IP/LDP Fast-Reroute.=A0 At the time, of course, I was suggesting U-tur= n
> alternates; they don't require tunnels or additional signaling and= increased
> the coverage up to 98% or so.=A0 Beyond that, minor topology changes c= ould get
> a lot - and one could always go to cascaded U-turns if necessary.

Yes, we understand that has associated issues.

>
> There was a strong push for a solution that could provide 100% coverag= e
> whenever the network couldn't be partitioned by a single failure.= =A0 That is
> what led to not-via which gained WG consensus to become a WG draft. >

The current proposal has full coverage. The "simplified-version&= quot; that
was mentioned can be an implementation/deployment option.

> At this point, I think we've seen a lack of progress on not-via du= e to the
> scalability issues.
>
> The need for a solution and the scalability issues around not-via are = what
> have motivated me to suggest MRT fast-reroute.=A0 MRT fast-reroute can= provide
> 100% coverage regardless of topology.

AFAIK it does not handle SRLG failures.

>
> I'm deeply amused by having this discussion on the other side of t= he fence -
> arguing for the 100% solution.
>
> Regardless, I'd have to see some pretty convincing arguments befor= e saying
> that we should compromise on something less.=A0 I haven't seen any= evidence
> that the WG opinion has changed on this point.
>
> Alia
>
> P.S.=A0 For topology coverage, how many cases still don't require = any directed
> forwarding once a single or multiple failures have happened to the net= work?

That depends on the topology and the failure.

>
> On Thu, Aug 4, 2011 at 7:17 PM, Sri <sriganeshkini@gmail.com> wrote:
>>
>> inline
>>
>> On Thu, Aug 4, 2011 at 3:27 PM, Eric Osborne (eosborne)
>> <eosborne@cisco.com&g= t; wrote:
>> > One question inline with EO#
>> > ...
>> >
>> >> >
>> >> > How much simpler is your solution than what I've= described above?
>> >> > They both need
>> >> > =A0- link-state information available for explicit p= aths
>> >> > =A0- srlg info available, should one want to use it<= br> >> >> > =A0- explicit routing control, even if the paths are= dynamically
>> >> > calculated per PLR
>> >>
>> >> In most practical topologies we do not see the need for e= xplicit
>> >> routing
>> >> control in LDP. As an example see the link protection top= ology in the
>> >> preso. In fact as we analyze more practical topologies, w= e are seeing
>> >> lesser need for it. So the explicit routing is more for p= roviding a
>> >> completeness of the solution to address all topologies. >> >
>> >
>> > ...
>> >
>> >>
>> >> As stated earlier the explicit routing extension to LDP i= s minimal and
>> >> that too can be removed for the "simplified-version&= quot;. CR-LDP can stay
>> >> as-
>> >> is !
>> >
>> > EO#
>> > If you remove the explicit routing from LDP, aren't you j= ust left with
>> > an approach that looks a lot like LFA or MRT? =A0What's u= nique to what you're
>> > presenting other than the need to occasionally use contstrain= t-routed LDP?
>>
>> IPFRR-LFA uses only the IP(IGP) loop-free alternates. The simplifi= ed
>> version of FRR-LDP uses LDP LSPs with stacking such that they are = loop
>> free and avoid the failure. A simple example is the link-protectio= n
>> case in the preso. They could also avoid SRLG failures if the
>> appropriate shortest-path LSPs exist in that topology.
>>
>> MRT uses redundant trees.
>>
>> >
>> >
>> >
>> > eric
>> >
>> >
>> >>
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > eric
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: = rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On
>> >> >> Behalf
>> >> > Of
>> >> >> Sriganesh Kini
>> >> >> Sent: Thursday, August 04, 2011 12:00 PM
>> >> >> To: curtis@o= ccnc.com
>> >> >> Cc: rtgwg@ietf= .org; Sriganesh Kini
>> >> >> Subject: Re: draft-kini-mpls-frr-ldp-01 for revi= ew
>> >> >>
>> >> >> Inline
>> >> >>
>> >> >> - Sri
>> >> >>
>> >> >> Sent from my iPad
>> >> >>
>> >> >> On Aug 4, 2011, at 6:13 AM, Curtis Villamizar &l= t;curtis@occnc.com>
>> >> > wrote:
>> >> >>
>> >> >> >
>> >> >> > In message
>> >> >> >
>> >> >> > <CAOndX-vC5zbnYLwKgbRz-u9yctc= v7Lm-qKpB8Ly-9e-03A514A@mail.gmail.com
>> >> >> > >
>> >> >> > Sriganesh Kini writes:
>> >> >> >>
>> >> >> >> We are re-using whatever is available a= nd is needed. SRLG info is
>> >> >> >> needed at the nodes computing paths to = protect the SRLG failure.
>> >> >> >> Using an existing IGP mechanism to do j= ust that is an option.
>> >> >> >> Stretching this to imply that RSVP-TE i= s reinvented doesn't make
>> >> >> >> sense. Many service providers who have = LDP deployed simply don't
>> >> > want
>> >> >> >> the additional complexity of deploying = RSVP-TE but they do want
>> >> >> >> sub 50msec protection with full coverag= e. Moreover RSVP-TE
>> >> >> >> doesn't
>> >> > scale as
>> >> >> well.
>> >> >> >
>> >> >> >
>> >> >> > Additional complexity.
>> >> >>
>> >> >> No. Operationally the complexity is similar to r= unning an LDP
>> >> >> network.
>> >> >>
>> >> >> >
>> >> >> > =A0Enable IGP-TE extensions and configure l= inks, minimum is enable
>> >> >> > TE
>> >> >> > per link and advertise defaults.
>> >> >> >
>> >> >> > =A0Define a mesh group.
>> >> >> >
>> >> >> > =A0Configure defaults for mesh group at zer= o bandwidth and use of
>> >> >> > FRR.
>> >> >> >
>> >> >> > Done.
>> >> >>
>> >> >> Full mesh is not as scalable.
>> >> >>
>> >> >> >
>> >> >> > That is not much complexity. =A0The configu= ration is identical per
>> >> > node,
>> >> >> > except per link config since different node= s have different number
>> >> > and
>> >> >> > naming of links. =A0This is both easy to se= t up and easily
>> >> >> > manageable.
>> >> >> >
>> >> >> > If later TE is desired, then either set aut= obandwidth on the mesh
>> >> >> > group or capture per LSP traffic measuremen= ts and begin
>> >> >> > configuring
>> >> >> > bandwidth amounts per LSP. =A0The latter ta= kes a small amount of
>> >> >> > work
>> >> >> > but is preferred by many service providers.=
>> >> >>
>> >> >> Maybe this is true for some providers that you a= re aware of. But I
>> >> > have
>> >> >> seen many providers prefer to run an LDP network= and want full
>> >> > coverage
>> >> >> protection.
>> >> >>
>> >> >> >
>> >> >> > Curtis
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >> On Wed, Aug 3, 2011 at 4:32 PM, Curtis = Villamizar
>> >> > <curtis@occnc= .com>
>> >> >> wrote:
>> >> >> >>>
>> >> >> >>> In message
>> >> >> >>>
>> >> > <0ED867EB33AB2B45AAB470D5A64CDBF60CCA31C45D@EUSAA= CMS0701.eamcs.erics
>> >> >> >>> son.se>
>> >> >> >>> Jeff Tantsura writes:
>> >> >> >>>>
>> >> >> >>>> Hi Curtis,
>> >> >> >>>>
>> >> >> >>>> Irrespectively of this draft th= anks to GMPLS IGP extensions as
>> >> > per
>> >> >> >>>> RFC's 4203 & 5307 SRLG = info is there, it is up to
>> >> >> >>>> implementation
>> >> >> >>>> how to use it.
>> >> >> >>>>
>> >> >> >>>> Regards,
>> >> >> >>>> Jeff
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> Those are in the extensions for GMP= LS which is a superset of
>> >> > RSVP-TE
>> >> >> >>> based MPLS. =A0These are sub-TLV ad= ded to the Link TLV which
>> >> > provides
>> >> >> >>> a good part of the TE-LSDB used by = RSVP-TE. =A0With that you get
>> >> >> >>> available bandwidth at each priorit= y level, the RSVP-TE 32 bit
>> >> > link
>> >> >> >>> attribute vector and other niceties= that should have nothing to
>> >> >> >>> do with LDP.
>> >> >> >>>
>> >> >> >>> For example, in RFC-3060 where Link= TLV is defined for OSPF.
>> >> >> >>>
>> >> >> >>> =A0 The following sub-TLVs of the L= ink TLV are defined:
>> >> >> >>>
>> >> >> >>> =A0 =A0 =A01 - Link type (1 octet)<= br> >> >> >> >>> =A0 =A0 =A02 - Link ID (4 octets) >> >> >> >>> =A0 =A0 =A03 - Local interface IP a= ddress (4 octets)
>> >> >> >>> =A0 =A0 =A04 - Remote interface IP = address (4 octets)
>> >> >> >>> =A0 =A0 =A05 - Traffic engineering = metric (4 octets)
>> >> >> >>> =A0 =A0 =A06 - Maximum bandwidth (4= octets)
>> >> >> >>> =A0 =A0 =A07 - Maximum reservable b= andwidth (4 octets)
>> >> >> >>> =A0 =A0 =A08 - Unreserved bandwidth= (32 octets)
>> >> >> >>> =A0 =A0 =A09 - Administrative group= (4 octets)
>> >> >> >>>
>> >> >> >>> That is what is being extended in R= FC4203.
>> >> >> >>>
>> >> >> >>> So don't run RSVP-TE, just half= of it. =A0Then compute LDP paths?
>> >> >> >>> Sounds too much like CR-LDP to me.<= br> >> >> >> >>>
>> >> >> >>> If we reinvent half of RSVP-TE, why= not all of it. =A0OTOH, why
>> >> >> >>> not
>> >> >> >>> just run half of it. =A0Use RSVP-TE= LSP with zero BW and MPLS FRR
>> >> >> >>> [RFC4090] and forget LDP except for= PW signaling.
>> >> >> >>>
>> >> >> >>> Curtis
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>> -----Original Message-----
>> >> >> >>>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On
>> >> >> >>>> Behalf Of Curtis Villamizar
>> >> >> >>>> Sent: Wednesday, August 03, 201= 1 11:35
>> >> >> >>>> To: Sriganesh Kini
>> >> >> >>>> Cc: rtgwg@ietf.org
>> >> >> >>>> Subject: Re: draft-kini-mpls-fr= r-ldp-01 for review
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> In message
>> >> >> >>>>
>> >> > <CAOndX-tcB4UVQnWKKoRcdEp6h2jTRAAHFBWL= qq-qwgnV5bUD-g@mail.gmail.com
>> >> >> >>>> >
>> >> >> >>>> Sriganesh Kini writes:
>> >> >> >>>>>
>> >> >> >>>>> Hello,
>> >> >> >>>>>
>> >> >> >>>>> Regarding draft-kini-mpls-f= rr-ldp-01.
>> >> >> >>>>>
>> >> >> >>>>> We had feedback from the mp= ls WG to present this draft at
>> >> >> >>>>> RTGWG.
>> >> >> >>>>> Since our request for a slo= t was late, there is a chance that
>> >> >> >>>>> we may not have adequate ti= me at the end of the session for
>> >> >> >>>>> this draft. In any case we = wanted to make the WG aware of the
>> >> >> >>>>> draft
>> >> > and
>> >> >> >>>>> would appreciate any commen= ts.
>> >> >> >>>>>
>> >> >> >>>>> Regards
>> >> >> >>>>>
>> >> >> >>>>> - Sri
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> Protection is inherently a traf= fic engineering problem. =A0IPFRR
>> >> >> >>>> provides mostly limited coverag= e protection, without the
>> >> >> >>>> benefit
>> >> > of
>> >> >> >>>> signaled SRLG, and with increas= ed potential of transient route
>> >> >> >>>> loops in the abense of complete= and accurate SRLG information
>> >> >> >>>> or
>> >> >> >>>> when multiple failures occur th= at are not covered by SRLG.
>> >> >> >>>>
>> >> >> >>>> LDP FRR has all the same issues= as IPFRR. =A0So in general I
>> >> >> >>>> don't
>> >> >> >>>> support LDP FRR.
>> >> >> >>>>
>> >> >> >>>> Even if I did support an LDP FR= R, I don't think this draft
>> >> >> >>>> offers
>> >> > a
>> >> >> >>>> good approach to LDP FRR.
>> >> >> >>>>
>> >> >> >>>> Curtis
>> >> >> >>> ___________________________________= ____________
>> >> >> >>> rtgwg mailing list
>> >> >> >>> r= tgwg@ietf.org
>> >> >> >>> https://www.ietf.org/mailman/listinf= o/rtgwg
>> >> >> >>>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> - Sri
>> >> >> >
>> >> >> > ___________________________________________= ____
>> >> >> > rtgwg mailing list
>> >> >> > rtgwg@iet= f.org
>> >> >> > https://www.ietf.org/mailman/listinfo/rtgwg<= /a>
>> >> >> _______________________________________________<= br> >> >> >> rtgwg mailing list
>> >> >> rtgwg@ietf.org=
>> >> >> https://www.ietf.org/mailman/listinfo/rtgwg >> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Sriganesh Kini (Sri)
>> >
>>
>>
>>
>> --
>> Sriganesh Kini (Sri)
>> _______________________________________________
>> rtgwg mailing list
>> rtgwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtgwg
>
>



--
Sriganesh Kini (Sri)

--000e0cd3287ef5bef904aa13fc51-- From internet-drafts@ietf.org Wed Aug 17 05:09:35 2011 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325FD21F8B38; Wed, 17 Aug 2011 05:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SNAwjIb1FN6; Wed, 17 Aug 2011 05:09:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C806921F8AC3; Wed, 17 Aug 2011 05:09:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-lfa-applicability-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.58 Message-ID: <20110817120934.17717.55621.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2011 05:09:34 -0700 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 12:09:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Gr= oup of the IETF. Title : LFA applicability in SP networks Author(s) : Clarence Filsfils Pierre Francois Mike Shand Bruno Decraene James Uttaro Nicolai Leymann Martin Horneffer Filename : draft-ietf-rtgwg-lfa-applicability-03.txt Pages : 32 Date : 2011-08-17 In this draft, we analyze the applicability of LoopFree Alternates in both core and access parts of Service Provider networks. We provide design guides to favor their applicability where relevant, typically in the access part of the network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-lfa-applicability-03.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtgwg-lfa-applicability-03.txt