From exim@www1.ietf.org Wed Feb 4 02:31:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22747 for ; Wed, 4 Feb 2004 02:31:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHVT-0003Vj-9V for routing-discussion-archive@odin.ietf.org; Wed, 04 Feb 2004 02:31:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i147VV5g013424 for routing-discussion-archive@odin.ietf.org; Wed, 4 Feb 2004 02:31:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHV4-0003OX-MN; Wed, 04 Feb 2004 02:31:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHUx-0003MW-Ki for routing-discussion@optimus.ietf.org; Wed, 04 Feb 2004 02:30:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22130 for ; Wed, 4 Feb 2004 02:30:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoHUt-0006Rc-00 for routing-discussion@ietf.org; Wed, 04 Feb 2004 02:30:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoHU1-0006Fa-00 for routing-discussion@ietf.org; Wed, 04 Feb 2004 02:30:02 -0500 Received: from web60805.mail.yahoo.com ([216.155.196.68]) by ietf-mx with smtp (Exim 4.12) id 1AoHTf-0006AN-00 for routing-discussion@ietf.org; Wed, 04 Feb 2004 02:29:39 -0500 Message-ID: <20040204072910.34302.qmail@web60805.mail.yahoo.com> Received: from [218.12.196.51] by web60805.mail.yahoo.com via HTTP; Tue, 03 Feb 2004 23:29:10 PST Date: Tue, 3 Feb 2004 23:29:10 -0800 (PST) From: Josh Chu Subject: Any about MPLS( Multi-protocol Lable Swithing ) :) To: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1881820486-1075879750=:33213" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , --0-1881820486-1075879750=:33213 Content-Type: text/plain; charset=us-ascii I want to get some details about LDP, Any one can mail me about the major ? --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! --0-1881820486-1075879750=:33213 Content-Type: text/html; charset=us-ascii

I want to get some details about LDP, Any one can mail me about the major ?

Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it! --0-1881820486-1075879750=:33213-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Feb 4 11:29:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13193 for ; Wed, 4 Feb 2004 11:29:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPtc-0007cf-Vv; Wed, 04 Feb 2004 11:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPt1-0007ap-I9 for routing-discussion@optimus.ietf.org; Wed, 04 Feb 2004 11:28:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13118 for ; Wed, 4 Feb 2004 11:28:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoPt0-0006hT-00 for routing-discussion@ietf.org; Wed, 04 Feb 2004 11:28:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoPrw-0006aG-00 for routing-discussion@ietf.org; Wed, 04 Feb 2004 11:27:16 -0500 Received: from web41109.mail.yahoo.com ([66.218.93.25]) by ietf-mx with smtp (Exim 4.12) id 1AoPr0-0006Q9-00 for routing-discussion@ietf.org; Wed, 04 Feb 2004 11:26:19 -0500 Message-ID: <20040204162546.22706.qmail@web41109.mail.yahoo.com> Received: from [64.142.6.201] by web41109.mail.yahoo.com via HTTP; Wed, 04 Feb 2004 08:25:46 PST Date: Wed, 4 Feb 2004 08:25:46 -0800 (PST) From: darshan purohit Subject: RIP with multiple addresses on an interface. To: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Hi All I would like to know what is the normal behaviour for RIP running on an interface with multiple IP addresses configured on it. One way is to select one primary address and send/recv the RIP updates on that network. The other way is to send one RIP update on each configured subnet (i.e if there are two addresses 10.1.1.1/24 and 10.1.2.1/24 then send out two different updates, one to 10.1.1.255 and the other to 10.1.2.255). How do different vendors behave in this scenario. Thanks. Darshan. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Feb 4 12:16:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13195 for ; Wed, 4 Feb 2004 11:29:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPts-0007f1-2D for routing-discussion-archive@odin.ietf.org; Wed, 04 Feb 2004 11:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14GTFQG029372 for routing-discussion-archive@odin.ietf.org; Wed, 4 Feb 2004 11:29:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPtc-0007cf-Vv; Wed, 04 Feb 2004 11:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPt1-0007ap-I9 for routing-discussion@optimus.ietf.org; Wed, 04 Feb 2004 11:28:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13118 for ; Wed, 4 Feb 2004 11:28:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoPt0-0006hT-00 for routing-discussion@ietf.org; Wed, 04 Feb 2004 11:28:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoPrw-0006aG-00 for routing-discussion@ietf.org; Wed, 04 Feb 2004 11:27:16 -0500 Received: from web41109.mail.yahoo.com ([66.218.93.25]) by ietf-mx with smtp (Exim 4.12) id 1AoPr0-0006Q9-00 for routing-discussion@ietf.org; Wed, 04 Feb 2004 11:26:19 -0500 Message-ID: <20040204162546.22706.qmail@web41109.mail.yahoo.com> Received: from [64.142.6.201] by web41109.mail.yahoo.com via HTTP; Wed, 04 Feb 2004 08:25:46 PST Date: Wed, 4 Feb 2004 08:25:46 -0800 (PST) From: darshan purohit Subject: RIP with multiple addresses on an interface. To: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Hi All I would like to know what is the normal behaviour for RIP running on an interface with multiple IP addresses configured on it. One way is to select one primary address and send/recv the RIP updates on that network. The other way is to send one RIP update on each configured subnet (i.e if there are two addresses 10.1.1.1/24 and 10.1.2.1/24 then send out two different updates, one to 10.1.1.255 and the other to 10.1.2.255). How do different vendors behave in this scenario. Thanks. Darshan. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Feb 5 11:56:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23733 for ; Thu, 5 Feb 2004 11:56:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AommL-0005A6-Fv; Thu, 05 Feb 2004 11:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomlN-00055K-Sm for routing-discussion@optimus.ietf.org; Thu, 05 Feb 2004 11:54:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23685 for ; Thu, 5 Feb 2004 11:53:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AomlM-0003pd-00 for routing-discussion@ietf.org; Thu, 05 Feb 2004 11:54:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AomkN-0003jm-00 for routing-discussion@ietf.org; Thu, 05 Feb 2004 11:53:01 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1AomjP-0003aX-00; Thu, 05 Feb 2004 11:51:59 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i15GpTl63967; Thu, 5 Feb 2004 08:51:29 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (securepptp045.static.jnpr.net [172.24.253.45]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i15GpNh96529; Thu, 5 Feb 2004 08:51:23 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20040204164937.02f39950@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 05 Feb 2004 11:50:27 -0500 To: Alex Zinin , routing-discussion@ietf.org From: Ross Callon Subject: Re: Last Call: draft-jones-opsec "Operational Security Requirements for IP Network Infrastructure" Cc: iesg@ietf.org In-Reply-To: <12758206266.20040122142453@psg.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_6459388==_.ALT" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,FORGED_MUA_EUDORA, HTML_MESSAGE autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , --=====================_6459388==_.ALT Content-Type: text/plain; charset="us-ascii" I think that this is a very useful document, and is quite well done. The topic is also quite urgent. I therefore encourage publication. My comments are very minor editorial comments, and are intended only to be helpful (if any of these are controversial then "never mind"). Regarding the title: it is very clearly stated in the scope section that this document covers routers and switches. My general interpretation of the phrase "IP Network Infrastructure" tends to include servers as well. It therefore seems reasonable to change the title to "Operational Security Requirements for IP Routers and Switches". (although I wouldn't change the title if this requires any major trouble -- the stated scope is very clear, and some of these requirements might carry over to other devices). Section 1.4, second bullet item: In principle a packet could be delivered to more than one place. Thus I would be inclined to reword this bullet as: o traffic goes where its supposed to go, and only where its supposed to go (availability, confidentiality) Section 1.5, In interpret the phrase "end user" to be a person sitting at home on the other end of a dial-up or DSL connection, or perhaps a company. Thus I think that "end user" could be changed to "network operator" so that this section reads: There are two intended audiences: the network operator who selects, purchases, and operates IP network equipment, and the vendors who create them. Page 10, definition of "Single-Homed Network". Does this include a network which has two physical links to the same service provider? Does this depend upon whether this results in the network having a single address prefix that needs to be advertised? It seems to me that the issue is primarily related to addressing and routing, and the related checking of source addresses. Thus the definition looks good, but a little clarification might not hurt. This is a difficult area to get precisely the right wording, but how about a comment along the line of: Note: A single homed network may have more than one physical links to the same service provider, so long as the connection can be treated as one logical connection for the purpose of inter-domain routing and addressing. Page 27/28, section 2.5.6, discussion of anti-spoofing filters. Current text for the example says: Examples. This requirement could be satisfied in several ways. It could be satisfied by the provision of a single command that automatically generates and applies filters to an interface that implements anti-spoofing. It could be satisfied by the provision of a command that causes the return path for packets received to be checked against the current routing tables and dropped if they would not be forwarded back through the interface on which they were received. This is perhaps a nit. In the single-homed case, the text is correct as it currently stands. If we wanted this to extend to spoof checking in other cases, then you want a slightly less rigid check, in that there might be multiple paths, and you want to accept the packet if any path exists back to the source over the interface, not just the paths that you happen to have chosen. Thus we could generalize this as follows: Examples. This requirement could be satisfied in several ways. It could be satisfied by the provision of a single command that automatically generates and applies filters to an interface that implements anti-spoofing. It could be satisfied by the provision of a command that causes the return path for packets received to be checked against the current routing tables and dropped if they could not be forwarded back through the interface on which they were received (ie, if no path to the source exists over the interface). thanks, Ross At 02:24 PM 1/22/2004 -0800, Alex Zinin wrote: >Folks- > > The IESG received a request to publish draft-jones-opsec as a BCP > RFC. To ensure wide community review, we are soliciting comments on > this document from the routing community. Please send your comments > by February 5th, 2004. > > From the abstract: > > This document defines a list of operational security requirements for > the infrastructure of large IP networks (routers and switches) which > are considered to be best current practice (BCP). A framework is > defined for specifying "profiles", which are collections of > requirements applicable to certain network topology contexts (all, > core-only, edge-only...). The goal is to provide network operators a > clear, concise way of communicating their security requirements to > vendors. Comments to: "opsec-comment@ops.ietf.org". > > When commenting, please use the Routing Area mailing list > (routing-discussion@ietf.org). > >Alex Zinin >IETF Routing Area Co-Director > > >_______________________________________________ >routing-discussion mailing list >routing-discussion@ietf.org >https://www1.ietf.org/mailman/listinfo/routing-discussion --=====================_6459388==_.ALT Content-Type: text/html; charset="us-ascii" I think that this is a very useful document, and is quite well done. The
topic is also quite urgent. I therefore encourage publication.

My comments are very minor editorial comments, and are intended
only to be helpful (if any of these are controversial then "never mind").

Regarding the title: it is very clearly stated in the scope section that this
document covers routers and switches. My general interpretation of the
phrase "IP Network Infrastructure" tends to include servers as well. It
therefore seems reasonable to change the title to "Operational Security
Requirements for IP Routers and Switches". (although I wouldn't change
the title if this requires any major trouble -- the stated scope is very clear,
and some of these requirements might carry over to other devices).

Section 1.4, second bullet item: In principle a packet could be delivered
to more than one place. Thus I would be inclined to reword this bullet as:

        o traffic goes where its supposed to go, and only where its supposed
           to go (availability, confidentiality)

Section 1.5, In interpret the phrase "end user" to be a person sitting at
home on the other end of a dial-up or DSL connection, or perhaps a
company. Thus I think that "end user" could be changed to "network
operator" so that this section reads:

        There are two intended audiences: the network operator who selects,
        purchases, and operates IP network equipment, and the vendors who
        create them.

Page 10, definition of "Single-Homed Network". Does this include a network
which has two physical links to the same service provider? Does this depend
upon whether this results in the network having a single address prefix that
needs to be advertised? It seems to me that the issue is primarily related to
addressing and routing, and the related checking of source addresses. Thus
the definition looks good, but a little clarification might not hurt. This is a
difficult area to get precisely the right wording, but how about a comment
along the line of:

        Note: A single homed network may have more than one physical links
        to the same service provider, so long as the connection can be treated
        as one logical connection for the purpose of inter-domain routing and
        addressing.

Page 27/28, section 2.5.6, discussion of anti-spoofing filters. Current text
for the example says:

        Examples.
        This requirement could be satisfied in several ways. It could be
        satisfied by the provision of a single command that automatically
        generates and applies filters to an interface that implements
        anti-spoofing. It could be satisfied by the provision of a
        command that causes the return path for packets received to be
        checked against the current routing tables and dropped if they
        would not be forwarded back through the interface on which they
        were received.

This is perhaps a nit. In the single-homed case, the text is correct as
it currently stands. If we wanted this to extend to spoof checking in
other cases, then you want a slightly less rigid check, in that there
might be multiple paths, and you want to accept the packet if any
path exists back to the source over the interface, not just the paths
that you happen to have chosen. Thus we could generalize this as
follows:

        Examples.
        This requirement could be satisfied in several ways. It could be
        satisfied by the provision of a single command that automatically
        generates and applies filters to an interface that implements
        anti-spoofing. It could be satisfied by the provision of a
        command that causes the return path for packets received to be
        checked against the current routing tables and dropped if they
        could not be forwarded back through the interface on which they
        were received (ie, if no path to the source exists over the interface).

thanks, Ross

At 02:24 PM 1/22/2004 -0800, Alex Zinin wrote:

Folks-

The IESG received a request to publish draft-jones-opsec as a BCP
RFC. To ensure wide community review, we are soliciting comments on
this document from the routing community. Please send your comments
by February 5th, 2004.

From the abstract:

   This document defines a list of operational security requirements for
   the infrastructure of large IP networks (routers and switches) which
   are considered to be best current practice (BCP). A framework is
   defined for specifying "profiles", which are collections of
   requirements applicable to certain network topology contexts (all,
   core-only, edge-only...). The goal is to provide network operators a
   clear, concise way of communicating their security requirements to
   vendors. Comments to: "opsec-comment@ops.ietf.org".

When commenting, please use the Routing Area mailing list
(routing-discussion@ietf.org).

Alex Zinin
IETF Routing Area Co-Director

_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org
https://www1.ietf.org/mailman/listinfo/routing-discussion

thanks, Ross

At 02:24 PM 1/22/2004 -0800, Alex Zinin wrote:

Folks-

The IESG received a request to publish draft-jones-opsec as a BCP
RFC. To ensure wide community review, we are soliciting comments on
this document from the routing community. Please send your comments
by February 5th, 2004.

From the abstract:

   This document defines a list of operational security requirements for
   the infrastructure of large IP networks (routers and switches) which
   are considered to be best current practice (BCP). A framework is
   defined for specifying "profiles", which are collections of
   requirements applicable to certain network topology contexts (all,
   core-only, edge-only...). The goal is to provide network operators a
   clear, concise way of communicating their security requirements to
   vendors. Comments to: "opsec-comment@ops.ietf.org".

When commenting, please use the Routing Area mailing list
(routing-discussion@ietf.org).

Alex Zinin
IETF Routing Area Co-Director

_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org
https://www1.ietf.org/mailman/listinfo/routing-discussion

--=====================_6459388==_.ALT-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Feb 11 04:33:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24456 for ; Wed, 11 Feb 2004 04:33:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqqju-0004HF-71; Wed, 11 Feb 2004 04:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqqjP-0004DK-OP for routing-discussion@optimus.ietf.org; Wed, 11 Feb 2004 04:32:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24335 for ; Wed, 11 Feb 2004 04:32:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqqjM-00051M-00 for routing-discussion@ietf.org; Wed, 11 Feb 2004 04:32:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqqiO-0004ts-00 for routing-discussion@ietf.org; Wed, 11 Feb 2004 04:31:29 -0500 Received: from [208.246.215.201] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 1AqqhW-0004cf-00 for routing-discussion@ietf.org; Wed, 11 Feb 2004 04:30:34 -0500 Received: from aatlas-lt2.avici.com (b2vpn2pc199.avici.com [10.2.104.199]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i1B9Twje030829 for ; Wed, 11 Feb 2004 04:29:58 -0500 Message-Id: <5.1.0.14.2.20040211043058.01d54dd0@10.2.0.68> X-Sender: aatlas@10.2.0.68 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 Feb 2004 04:32:40 -0500 To: routing-discussion@ietf.org From: Alia Atlas Subject: Fwd: I-D ACTION:draft-atlas-ip-local-protect-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Hi, I recently submitted draft-atlas-ip-local-protect-00.txt and would be very interested in any comments on it. Thanks, Alia >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : IP/LDP Local Protection > Author(s) : A. Atlas > Filename : draft-atlas-ip-local-protect-00.txt > Pages : 30 > Date : 2004-2-9 > >This document defines an architecture and selection process for >providing local protection for IP unicast and/or LDP traffic in the >event of a single link or node failure until the router has >converged. When computing the primary next-hop for a prefix, a >router S also determines an alternate next-hop which can be used if >the primary next-hop fails. The alternate can be either a loop-free >alternate, which goes to a neighbor whose shortest path to the prefix >does not go back through the router S, or a U-turn alternate, which >goes to a neighbor whose primary next-hop to the prefix is the router >S, and which has itself a loop-free node-protecting alternate, which >thus does not go through router S to reach the destination prefix. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-atlas-ip-local-protect-00.txt _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Feb 11 04:33:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24469 for ; Wed, 11 Feb 2004 04:33:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqqkN-0004Or-1H for routing-discussion-archive@odin.ietf.org; Wed, 11 Feb 2004 04:33:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B9XU6i016838 for routing-discussion-archive@odin.ietf.org; Wed, 11 Feb 2004 04:33:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqqju-0004HF-71; Wed, 11 Feb 2004 04:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqqjP-0004DK-OP for routing-discussion@optimus.ietf.org; Wed, 11 Feb 2004 04:32:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24335 for ; Wed, 11 Feb 2004 04:32:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqqjM-00051M-00 for routing-discussion@ietf.org; Wed, 11 Feb 2004 04:32:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqqiO-0004ts-00 for routing-discussion@ietf.org; Wed, 11 Feb 2004 04:31:29 -0500 Received: from [208.246.215.201] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 1AqqhW-0004cf-00 for routing-discussion@ietf.org; Wed, 11 Feb 2004 04:30:34 -0500 Received: from aatlas-lt2.avici.com (b2vpn2pc199.avici.com [10.2.104.199]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i1B9Twje030829 for ; Wed, 11 Feb 2004 04:29:58 -0500 Message-Id: <5.1.0.14.2.20040211043058.01d54dd0@10.2.0.68> X-Sender: aatlas@10.2.0.68 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 Feb 2004 04:32:40 -0500 To: routing-discussion@ietf.org From: Alia Atlas Subject: Fwd: I-D ACTION:draft-atlas-ip-local-protect-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Hi, I recently submitted draft-atlas-ip-local-protect-00.txt and would be very interested in any comments on it. Thanks, Alia >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : IP/LDP Local Protection > Author(s) : A. Atlas > Filename : draft-atlas-ip-local-protect-00.txt > Pages : 30 > Date : 2004-2-9 > >This document defines an architecture and selection process for >providing local protection for IP unicast and/or LDP traffic in the >event of a single link or node failure until the router has >converged. When computing the primary next-hop for a prefix, a >router S also determines an alternate next-hop which can be used if >the primary next-hop fails. The alternate can be either a loop-free >alternate, which goes to a neighbor whose shortest path to the prefix >does not go back through the router S, or a U-turn alternate, which >goes to a neighbor whose primary next-hop to the prefix is the router >S, and which has itself a loop-free node-protecting alternate, which >thus does not go through router S to reach the destination prefix. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-atlas-ip-local-protect-00.txt _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Feb 12 02:40:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12573 for ; Thu, 12 Feb 2004 02:40:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArBSS-0004vw-N5 for routing-discussion-archive@odin.ietf.org; Thu, 12 Feb 2004 02:40:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C7eOpV018876 for routing-discussion-archive@odin.ietf.org; Thu, 12 Feb 2004 02:40:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArBSE-0004t5-Dz; Thu, 12 Feb 2004 02:40:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArBRT-0004l8-JM for routing-discussion@optimus.ietf.org; Thu, 12 Feb 2004 02:39:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12537 for ; Thu, 12 Feb 2004 02:39:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArBRP-0001H1-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 02:39:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArBQW-0001B3-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 02:38:24 -0500 Received: from bay1-f142.bay1.hotmail.com ([65.54.245.142] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1ArBPv-00013y-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 02:37:47 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 11 Feb 2004 23:37:17 -0800 Received: from 63.197.79.145 by by1fd.bay1.hotmail.msn.com with HTTP; Thu, 12 Feb 2004 07:37:17 GMT X-Originating-IP: [63.197.79.145] X-Originating-Email: [rajmanibt@hotmail.com] X-Sender: rajmanibt@hotmail.com From: "Raj Mani" To: routing-discussion@ietf.org Subject: Re: Fwd: I-D ACTION:draft-atlas-ip-local-protect-00.txt Date: Thu, 12 Feb 2004 02:37:17 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Feb 2004 07:37:17.0852 (UTC) FILETIME=[0A8775C0:01C3F13B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Atlas, >I recently submitted draft-atlas-ip-local-protect-00.txt and would be very >interested in any comments on it. Good research. A few comments on this draft of local protection: It's rather confusing to talk about characterizing the neighbors, since each prefix can have it's own primary path, loop-free node-protecting alternate, loop-free link-protecting alternate, U-turn..., etc. If one has lots of prefixes, and neighbors, the combination can be rather large to keep track of. I didn't fully understand all the U-turn cases described, since they are quite involved. Not sure you have covered the cases where two nodes have multiple parallel links, even you receive from one link and forward to another link, they can still be looping; also in multi-node looping case due to asymmetrical routing, S-->B-->A-->S which can not be detected by the inbound/outbound interface lookups. The computation of this can be intensive (depends on the number of routes and number of neighbors), there are more chance nodes converge at different times. But this paper depends on every nodes are in stable condition, otherwise, some of the calculations may not be reliable. The paper mentioned LDP and node protection, I don't see how the LDP traffic can be protected using node protection with this. Can you give an example? This paper mentioned the capability need only be flooded to a node's neighbor, I don't recall there is a special mechanism defined to only flood to IGP neighbors but not further. If the paper claims the MPLS-TE FRR is complicated, This scheme is not less complicated;) They can all be accomplished by router or some server software, but at least MPLS-TE FRR is guaranteed to deliver the switch-over without depending on chance. The alternate nexthops is not completely new, probably should mention draft-kini-traf-restore-nsp-00.txt which I think was expired, but searched on web found this link: http://yen.cse.kyutech.ac.jp/~ike/I-D/OLD/draft-kini-traf-restore-nsp-00.txt that draft had some similar idea as computing primary and alternate nexthops. Regards. - r _________________________________________________________________ Check out the great features of the new MSN 9 Dial-up, with the MSN Dial-up Accelerator. http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Feb 12 02:40:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12571 for ; Thu, 12 Feb 2004 02:40:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArBSS-0004vt-KT for routing-discussion-archive@odin.ietf.org; Thu, 12 Feb 2004 02:40:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C7eOe6018875 for routing-discussion-archive@odin.ietf.org; Thu, 12 Feb 2004 02:40:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArBS7-0004r9-NE; Thu, 12 Feb 2004 02:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArBRQ-0004kQ-7U for routing-discussion@optimus.ietf.org; Thu, 12 Feb 2004 02:39:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12531 for ; Thu, 12 Feb 2004 02:39:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArBRM-0001Gd-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 02:39:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArBQS-0001AW-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 02:38:21 -0500 Received: from bay1-f129.bay1.hotmail.com ([65.54.245.129] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1ArBPe-000124-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 02:37:30 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 11 Feb 2004 23:37:00 -0800 Received: from 63.197.79.145 by by1fd.bay1.hotmail.msn.com with HTTP; Thu, 12 Feb 2004 07:37:00 GMT X-Originating-IP: [63.197.79.145] X-Originating-Email: [rajmanibt@hotmail.com] X-Sender: rajmanibt@hotmail.com From: "Raj Mani" To: routing-discussion@ietf.org Subject: Re: Fwd: I-D ACTION:draft-atlas-ip-local-protect-00.txt Date: Thu, 12 Feb 2004 02:37:00 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Feb 2004 07:37:00.0776 (UTC) FILETIME=[0059DE80:01C3F13B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Atlas, >I recently submitted draft-atlas-ip-local-protect-00.txt and would be very >interested in any comments on it. Good research. A few comments on this draft of local protection: It's rather confusing to talk about characterizing the neighbors, since each prefix can have it's own primary path, loop-free node-protecting alternate, loop-free link-protecting alternate, U-turn..., etc. If one has lots of prefixes, and neighbors, the combination can be rather large to keep track of. I didn't fully understand all the U-turn cases described, since they are quite involved. Not sure you have covered the cases where two nodes have multiple parallel links, even you receive from one link and forward to another link, they can still be looping; also in multi-node looping case due to asymmetrical routing, S-->B-->A-->S which can not be detected by the inbound/outbound interface lookups. The computation of this can be intensive (depends on the number of routes and number of neighbors), there are more chance nodes converge at different times. But this paper depends on every nodes are in stable condition, otherwise, some of the calculations may not be reliable. The paper mentioned LDP and node protection, I don't see how the LDP traffic can be protected using node protection with this. Can you give an example? This paper mentioned the capability need only be flooded to a node's neighbor, I don't recall there is a special mechanism defined to only flood to IGP neighbors but not further. If the paper claims the MPLS-TE FRR is complicated, This scheme is not less complicated;) They can all be accomplished by router or some server software, but at least MPLS-TE FRR is guaranteed to deliver the switch-over without depending on chance. The alternate nexthops is not completely new, probably should mention draft-kini-traf-restore-nsp-00.txt which I think was expired, but searched on web found this link: http://yen.cse.kyutech.ac.jp/~ike/I-D/OLD/draft-kini-traf-restore-nsp-00.txt that draft had some similar idea as computing primary and alternate nexthops. Regards. - r _________________________________________________________________ Plan your next US getaway to one of the super destinations here. http://special.msn.com/local/hotdestinations.armx _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Feb 12 02:40:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12636 for ; Thu, 12 Feb 2004 02:40:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArBSE-0004t5-Dz; Thu, 12 Feb 2004 02:40:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArBRT-0004l8-JM for routing-discussion@optimus.ietf.org; Thu, 12 Feb 2004 02:39:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12537 for ; Thu, 12 Feb 2004 02:39:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArBRP-0001H1-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 02:39:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArBQW-0001B3-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 02:38:24 -0500 Received: from bay1-f142.bay1.hotmail.com ([65.54.245.142] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1ArBPv-00013y-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 02:37:47 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 11 Feb 2004 23:37:17 -0800 Received: from 63.197.79.145 by by1fd.bay1.hotmail.msn.com with HTTP; Thu, 12 Feb 2004 07:37:17 GMT X-Originating-IP: [63.197.79.145] X-Originating-Email: [rajmanibt@hotmail.com] X-Sender: rajmanibt@hotmail.com From: "Raj Mani" To: routing-discussion@ietf.org Subject: Re: Fwd: I-D ACTION:draft-atlas-ip-local-protect-00.txt Date: Thu, 12 Feb 2004 02:37:17 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Feb 2004 07:37:17.0852 (UTC) FILETIME=[0A8775C0:01C3F13B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Atlas, >I recently submitted draft-atlas-ip-local-protect-00.txt and would be very >interested in any comments on it. Good research. A few comments on this draft of local protection: It's rather confusing to talk about characterizing the neighbors, since each prefix can have it's own primary path, loop-free node-protecting alternate, loop-free link-protecting alternate, U-turn..., etc. If one has lots of prefixes, and neighbors, the combination can be rather large to keep track of. I didn't fully understand all the U-turn cases described, since they are quite involved. Not sure you have covered the cases where two nodes have multiple parallel links, even you receive from one link and forward to another link, they can still be looping; also in multi-node looping case due to asymmetrical routing, S-->B-->A-->S which can not be detected by the inbound/outbound interface lookups. The computation of this can be intensive (depends on the number of routes and number of neighbors), there are more chance nodes converge at different times. But this paper depends on every nodes are in stable condition, otherwise, some of the calculations may not be reliable. The paper mentioned LDP and node protection, I don't see how the LDP traffic can be protected using node protection with this. Can you give an example? This paper mentioned the capability need only be flooded to a node's neighbor, I don't recall there is a special mechanism defined to only flood to IGP neighbors but not further. If the paper claims the MPLS-TE FRR is complicated, This scheme is not less complicated;) They can all be accomplished by router or some server software, but at least MPLS-TE FRR is guaranteed to deliver the switch-over without depending on chance. The alternate nexthops is not completely new, probably should mention draft-kini-traf-restore-nsp-00.txt which I think was expired, but searched on web found this link: http://yen.cse.kyutech.ac.jp/~ike/I-D/OLD/draft-kini-traf-restore-nsp-00.txt that draft had some similar idea as computing primary and alternate nexthops. Regards. - r _________________________________________________________________ Check out the great features of the new MSN 9 Dial-up, with the MSN Dial-up Accelerator. http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Feb 12 02:40:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12637 for ; Thu, 12 Feb 2004 02:40:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArBSB-0004rQ-14; Thu, 12 Feb 2004 02:40:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArBRS-0004kl-4E for routing-discussion@optimus.ietf.org; Thu, 12 Feb 2004 02:39:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12534 for ; Thu, 12 Feb 2004 02:39:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArBRO-0001Gq-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 02:39:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArBQT-0001Ae-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 02:38:22 -0500 Received: from bay1-f60.bay1.hotmail.com ([65.54.245.60] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1ArBPp-00013S-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 02:37:41 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 11 Feb 2004 23:37:12 -0800 Received: from 63.197.79.145 by by1fd.bay1.hotmail.msn.com with HTTP; Thu, 12 Feb 2004 07:37:12 GMT X-Originating-IP: [63.197.79.145] X-Originating-Email: [rajmanibt@hotmail.com] X-Sender: rajmanibt@hotmail.com From: "Raj Mani" To: routing-discussion@ietf.org Subject: Re: Fwd: I-D ACTION:draft-atlas-ip-local-protect-00.txt Date: Thu, 12 Feb 2004 02:37:12 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Feb 2004 07:37:12.0413 (UTC) FILETIME=[074988D0:01C3F13B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Atlas, >I recently submitted draft-atlas-ip-local-protect-00.txt and would be very >interested in any comments on it. Good research. A few comments on this draft of local protection: It's rather confusing to talk about characterizing the neighbors, since each prefix can have it's own primary path, loop-free node-protecting alternate, loop-free link-protecting alternate, U-turn..., etc. If one has lots of prefixes, and neighbors, the combination can be rather large to keep track of. I didn't fully understand all the U-turn cases described, since they are quite involved. Not sure you have covered the cases where two nodes have multiple parallel links, even you receive from one link and forward to another link, they can still be looping; also in multi-node looping case due to asymmetrical routing, S-->B-->A-->S which can not be detected by the inbound/outbound interface lookups. The computation of this can be intensive (depends on the number of routes and number of neighbors), there are more chance nodes converge at different times. But this paper depends on every nodes are in stable condition, otherwise, some of the calculations may not be reliable. The paper mentioned LDP and node protection, I don't see how the LDP traffic can be protected using node protection with this. Can you give an example? This paper mentioned the capability need only be flooded to a node's neighbor, I don't recall there is a special mechanism defined to only flood to IGP neighbors but not further. If the paper claims the MPLS-TE FRR is complicated, This scheme is not less complicated;) They can all be accomplished by router or some server software, but at least MPLS-TE FRR is guaranteed to deliver the switch-over without depending on chance. The alternate nexthops is not completely new, probably should mention draft-kini-traf-restore-nsp-00.txt which I think was expired, but searched on web found this link: http://yen.cse.kyutech.ac.jp/~ike/I-D/OLD/draft-kini-traf-restore-nsp-00.txt that draft had some similar idea as computing primary and alternate nexthops. Regards. - r _________________________________________________________________ Get some great ideas here for your sweetheart on Valentine's Day - and beyond. http://special.msn.com/network/celebrateromance.armx _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Feb 12 03:28:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12569 for ; Thu, 12 Feb 2004 02:40:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArBS7-0004r9-NE; Thu, 12 Feb 2004 02:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArBRQ-0004kQ-7U for routing-discussion@optimus.ietf.org; Thu, 12 Feb 2004 02:39:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12531 for ; Thu, 12 Feb 2004 02:39:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArBRM-0001Gd-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 02:39:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArBQS-0001AW-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 02:38:21 -0500 Received: from bay1-f129.bay1.hotmail.com ([65.54.245.129] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1ArBPe-000124-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 02:37:30 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 11 Feb 2004 23:37:00 -0800 Received: from 63.197.79.145 by by1fd.bay1.hotmail.msn.com with HTTP; Thu, 12 Feb 2004 07:37:00 GMT X-Originating-IP: [63.197.79.145] X-Originating-Email: [rajmanibt@hotmail.com] X-Sender: rajmanibt@hotmail.com From: "Raj Mani" To: routing-discussion@ietf.org Subject: Re: Fwd: I-D ACTION:draft-atlas-ip-local-protect-00.txt Date: Thu, 12 Feb 2004 02:37:00 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Feb 2004 07:37:00.0776 (UTC) FILETIME=[0059DE80:01C3F13B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Atlas, >I recently submitted draft-atlas-ip-local-protect-00.txt and would be very >interested in any comments on it. Good research. A few comments on this draft of local protection: It's rather confusing to talk about characterizing the neighbors, since each prefix can have it's own primary path, loop-free node-protecting alternate, loop-free link-protecting alternate, U-turn..., etc. If one has lots of prefixes, and neighbors, the combination can be rather large to keep track of. I didn't fully understand all the U-turn cases described, since they are quite involved. Not sure you have covered the cases where two nodes have multiple parallel links, even you receive from one link and forward to another link, they can still be looping; also in multi-node looping case due to asymmetrical routing, S-->B-->A-->S which can not be detected by the inbound/outbound interface lookups. The computation of this can be intensive (depends on the number of routes and number of neighbors), there are more chance nodes converge at different times. But this paper depends on every nodes are in stable condition, otherwise, some of the calculations may not be reliable. The paper mentioned LDP and node protection, I don't see how the LDP traffic can be protected using node protection with this. Can you give an example? This paper mentioned the capability need only be flooded to a node's neighbor, I don't recall there is a special mechanism defined to only flood to IGP neighbors but not further. If the paper claims the MPLS-TE FRR is complicated, This scheme is not less complicated;) They can all be accomplished by router or some server software, but at least MPLS-TE FRR is guaranteed to deliver the switch-over without depending on chance. The alternate nexthops is not completely new, probably should mention draft-kini-traf-restore-nsp-00.txt which I think was expired, but searched on web found this link: http://yen.cse.kyutech.ac.jp/~ike/I-D/OLD/draft-kini-traf-restore-nsp-00.txt that draft had some similar idea as computing primary and alternate nexthops. Regards. - r _________________________________________________________________ Plan your next US getaway to one of the super destinations here. http://special.msn.com/local/hotdestinations.armx _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Feb 12 03:28:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12574 for ; Thu, 12 Feb 2004 02:40:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArBSS-0004vx-NQ for routing-discussion-archive@odin.ietf.org; Thu, 12 Feb 2004 02:40:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C7eOIl018878 for routing-discussion-archive@odin.ietf.org; Thu, 12 Feb 2004 02:40:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArBSB-0004rQ-14; Thu, 12 Feb 2004 02:40:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArBRS-0004kl-4E for routing-discussion@optimus.ietf.org; Thu, 12 Feb 2004 02:39:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12534 for ; Thu, 12 Feb 2004 02:39:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArBRO-0001Gq-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 02:39:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArBQT-0001Ae-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 02:38:22 -0500 Received: from bay1-f60.bay1.hotmail.com ([65.54.245.60] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1ArBPp-00013S-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 02:37:41 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 11 Feb 2004 23:37:12 -0800 Received: from 63.197.79.145 by by1fd.bay1.hotmail.msn.com with HTTP; Thu, 12 Feb 2004 07:37:12 GMT X-Originating-IP: [63.197.79.145] X-Originating-Email: [rajmanibt@hotmail.com] X-Sender: rajmanibt@hotmail.com From: "Raj Mani" To: routing-discussion@ietf.org Subject: Re: Fwd: I-D ACTION:draft-atlas-ip-local-protect-00.txt Date: Thu, 12 Feb 2004 02:37:12 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Feb 2004 07:37:12.0413 (UTC) FILETIME=[074988D0:01C3F13B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Atlas, >I recently submitted draft-atlas-ip-local-protect-00.txt and would be very >interested in any comments on it. Good research. A few comments on this draft of local protection: It's rather confusing to talk about characterizing the neighbors, since each prefix can have it's own primary path, loop-free node-protecting alternate, loop-free link-protecting alternate, U-turn..., etc. If one has lots of prefixes, and neighbors, the combination can be rather large to keep track of. I didn't fully understand all the U-turn cases described, since they are quite involved. Not sure you have covered the cases where two nodes have multiple parallel links, even you receive from one link and forward to another link, they can still be looping; also in multi-node looping case due to asymmetrical routing, S-->B-->A-->S which can not be detected by the inbound/outbound interface lookups. The computation of this can be intensive (depends on the number of routes and number of neighbors), there are more chance nodes converge at different times. But this paper depends on every nodes are in stable condition, otherwise, some of the calculations may not be reliable. The paper mentioned LDP and node protection, I don't see how the LDP traffic can be protected using node protection with this. Can you give an example? This paper mentioned the capability need only be flooded to a node's neighbor, I don't recall there is a special mechanism defined to only flood to IGP neighbors but not further. If the paper claims the MPLS-TE FRR is complicated, This scheme is not less complicated;) They can all be accomplished by router or some server software, but at least MPLS-TE FRR is guaranteed to deliver the switch-over without depending on chance. The alternate nexthops is not completely new, probably should mention draft-kini-traf-restore-nsp-00.txt which I think was expired, but searched on web found this link: http://yen.cse.kyutech.ac.jp/~ike/I-D/OLD/draft-kini-traf-restore-nsp-00.txt that draft had some similar idea as computing primary and alternate nexthops. Regards. - r _________________________________________________________________ Get some great ideas here for your sweetheart on Valentine's Day - and beyond. http://special.msn.com/network/celebrateromance.armx _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Feb 12 04:07:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15394 for ; Thu, 12 Feb 2004 04:07:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArCoJ-0003Xg-LO; Thu, 12 Feb 2004 04:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArCnP-0003WD-3m for routing-discussion@optimus.ietf.org; Thu, 12 Feb 2004 04:06:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15372 for ; Thu, 12 Feb 2004 04:06:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArCnM-0002GK-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 04:06:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArCmQ-0002BX-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 04:05:07 -0500 Received: from [208.246.215.201] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 1ArCmA-00026U-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 04:04:50 -0500 Received: from aatlas-lt2.avici.com (b2vpn2pc153.avici.com [10.2.104.153]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i1C94Aje013981; Thu, 12 Feb 2004 04:04:12 -0500 Message-Id: <5.1.0.14.2.20040212034831.08de6eb0@10.2.0.68> X-Sender: aatlas@10.2.0.68 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 12 Feb 2004 04:06:48 -0500 To: "Raj Mani" From: Alia Atlas Subject: Re: Fwd: I-D ACTION:draft-atlas-ip-local-protect-00.txt Cc: routing-discussion@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Hi Raj, At 02:37 AM 2/12/2004, Raj Mani wrote: >Atlas, > >>I recently submitted draft-atlas-ip-local-protect-00.txt and would be >>very interested in any comments on it. > > Good research. A few comments on this draft of local protection: > > It's rather confusing to talk about characterizing the neighbors, > since each prefix can have it's own primary path, loop-free > node-protecting > alternate, loop-free link-protecting alternate, U-turn..., etc. If > one has lots of prefixes, and neighbors, the combination can be > rather large to keep track of. The characterization is more conceptual. In general, one determines the appropriate alternate and primary next-hop for each node in the topology. A prefix can be ECMP between two or more nodes, in which case it falls into the multiple primary neighbors case. > I didn't fully understand all the U-turn cases described, since > they are quite involved. Not sure you have covered the cases where two > nodes have multiple parallel links, even you receive from one link and > forward to another link, they can still be looping; also in > multi-node looping case due to asymmetrical routing, > S-->B-->A-->S which can not be detected by the inbound/outbound > interface lookups. Yes, this is why the check is whether the traffic was received from the same neighbor that the traffic would be sent out to and NOT whether the traffic was received on the same link on which it would be forwarded. If there were a routing loop of S->B->A->S, then B would not be a U-Turn neighbor of S and S would not sure B for a U-Turn alternate. If you look at the definition of a U-Turn neighbor, a neighbor B is a U-Turn neighbor of S if and only if S is the primary neighbor for all optimal paths from B to the destination that go through S. > The computation of this can be intensive (depends on the number > of routes and number of neighbors), there are more chance nodes > converge at different times. But this paper depends on every nodes > are in stable condition, otherwise, some of the calculations may not > be reliable. Just like the primary SPF, the computation primarily depends on the number of nodes in the network, though the number of neighbors which can provide alternates is also important. The alternates are computed to protect against a single failure. The calculations for the alternate next-hops are as reliable as the primary next-hops are; i.e. once the network has converged, there will be alternates that can be used to protect against a single failure. > The paper mentioned LDP and node protection, I don't see how the > LDP traffic can be protected using node protection with this. Can > you give an example? The issue with providing LDP with node protection is knowing the new neighbor's label. If the LSRs use downstream unsolicited and liberal label retention, then an LSR will have the label bindings for each FEC from each of its neighbors that support that FEC. As long as the label binding is known for the alternate neighbor, then the appropriate out-segment can be created beforehand based on the selected alternate next-hop. Does that make sense? It does assume that there are LDP sessions to each neighbor, but that is generally the case. > This paper mentioned the capability need only be flooded to a node's > neighbor, I don't recall there is a special mechanism defined to > only flood to IGP neighbors but not further. For OSPF, there is the ability to have a link-scope opaque TLV (type 9, I believe). The same mechanism isn't there for IS-IS. We actually decided not to use a link-scope TLV, because we wanted similar capabilities for OSPF and IS-IS, and because we wanted to define a link capabilities sub-TLV, where the other bits could be used to another purpose. Take a look at draft-atlas-ospf-local-protect-cap-00.txt and draft-martin-isis-local-protect-cap-00.txt. > If the paper claims the MPLS-TE FRR is complicated, This scheme > is not less complicated;) They can all be accomplished by router or > some server software, but at least MPLS-TE FRR is guaranteed to deliver > the switch-over without depending on chance. The question is where the complexity burden is handled. This scheme is complicated to understand and non-trivial to implement, but the complexity is primarily in the algorithm. The management for it is more straightforward; the difference between managing a connection-less network and a connect-oriented network, on some level. This scheme doesn't depend on chance; it depends upon the topology being appropriately engineered. > The alternate nexthops is not completely new, probably should > mention draft-kini-traf-restore-nsp-00.txt which I think was > expired, but searched on web found this link: > >http://yen.cse.kyutech.ac.jp/~ike/I-D/OLD/draft-kini-traf-restore-nsp-00.txt > that draft had some similar idea as computing primary and alternate > nexthops. Absolutely; it's hard to reference an expired draft. I know that the concept of alternate next-hops has been discussed before, in reference to loop-free alternates. The conclusion seems to have been that it didn't provide enough coverage. That's what the U-Turn alternates are trying to solve. Thanks, Alia _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Feb 12 04:07:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15411 for ; Thu, 12 Feb 2004 04:07:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArCoW-0003ad-V4 for routing-discussion-archive@odin.ietf.org; Thu, 12 Feb 2004 04:07:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C97F5S013719 for routing-discussion-archive@odin.ietf.org; Thu, 12 Feb 2004 04:07:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArCoJ-0003Xg-LO; Thu, 12 Feb 2004 04:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArCnP-0003WD-3m for routing-discussion@optimus.ietf.org; Thu, 12 Feb 2004 04:06:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15372 for ; Thu, 12 Feb 2004 04:06:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArCnM-0002GK-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 04:06:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArCmQ-0002BX-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 04:05:07 -0500 Received: from [208.246.215.201] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 1ArCmA-00026U-00 for routing-discussion@ietf.org; Thu, 12 Feb 2004 04:04:50 -0500 Received: from aatlas-lt2.avici.com (b2vpn2pc153.avici.com [10.2.104.153]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i1C94Aje013981; Thu, 12 Feb 2004 04:04:12 -0500 Message-Id: <5.1.0.14.2.20040212034831.08de6eb0@10.2.0.68> X-Sender: aatlas@10.2.0.68 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 12 Feb 2004 04:06:48 -0500 To: "Raj Mani" From: Alia Atlas Subject: Re: Fwd: I-D ACTION:draft-atlas-ip-local-protect-00.txt Cc: routing-discussion@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Hi Raj, At 02:37 AM 2/12/2004, Raj Mani wrote: >Atlas, > >>I recently submitted draft-atlas-ip-local-protect-00.txt and would be >>very interested in any comments on it. > > Good research. A few comments on this draft of local protection: > > It's rather confusing to talk about characterizing the neighbors, > since each prefix can have it's own primary path, loop-free > node-protecting > alternate, loop-free link-protecting alternate, U-turn..., etc. If > one has lots of prefixes, and neighbors, the combination can be > rather large to keep track of. The characterization is more conceptual. In general, one determines the appropriate alternate and primary next-hop for each node in the topology. A prefix can be ECMP between two or more nodes, in which case it falls into the multiple primary neighbors case. > I didn't fully understand all the U-turn cases described, since > they are quite involved. Not sure you have covered the cases where two > nodes have multiple parallel links, even you receive from one link and > forward to another link, they can still be looping; also in > multi-node looping case due to asymmetrical routing, > S-->B-->A-->S which can not be detected by the inbound/outbound > interface lookups. Yes, this is why the check is whether the traffic was received from the same neighbor that the traffic would be sent out to and NOT whether the traffic was received on the same link on which it would be forwarded. If there were a routing loop of S->B->A->S, then B would not be a U-Turn neighbor of S and S would not sure B for a U-Turn alternate. If you look at the definition of a U-Turn neighbor, a neighbor B is a U-Turn neighbor of S if and only if S is the primary neighbor for all optimal paths from B to the destination that go through S. > The computation of this can be intensive (depends on the number > of routes and number of neighbors), there are more chance nodes > converge at different times. But this paper depends on every nodes > are in stable condition, otherwise, some of the calculations may not > be reliable. Just like the primary SPF, the computation primarily depends on the number of nodes in the network, though the number of neighbors which can provide alternates is also important. The alternates are computed to protect against a single failure. The calculations for the alternate next-hops are as reliable as the primary next-hops are; i.e. once the network has converged, there will be alternates that can be used to protect against a single failure. > The paper mentioned LDP and node protection, I don't see how the > LDP traffic can be protected using node protection with this. Can > you give an example? The issue with providing LDP with node protection is knowing the new neighbor's label. If the LSRs use downstream unsolicited and liberal label retention, then an LSR will have the label bindings for each FEC from each of its neighbors that support that FEC. As long as the label binding is known for the alternate neighbor, then the appropriate out-segment can be created beforehand based on the selected alternate next-hop. Does that make sense? It does assume that there are LDP sessions to each neighbor, but that is generally the case. > This paper mentioned the capability need only be flooded to a node's > neighbor, I don't recall there is a special mechanism defined to > only flood to IGP neighbors but not further. For OSPF, there is the ability to have a link-scope opaque TLV (type 9, I believe). The same mechanism isn't there for IS-IS. We actually decided not to use a link-scope TLV, because we wanted similar capabilities for OSPF and IS-IS, and because we wanted to define a link capabilities sub-TLV, where the other bits could be used to another purpose. Take a look at draft-atlas-ospf-local-protect-cap-00.txt and draft-martin-isis-local-protect-cap-00.txt. > If the paper claims the MPLS-TE FRR is complicated, This scheme > is not less complicated;) They can all be accomplished by router or > some server software, but at least MPLS-TE FRR is guaranteed to deliver > the switch-over without depending on chance. The question is where the complexity burden is handled. This scheme is complicated to understand and non-trivial to implement, but the complexity is primarily in the algorithm. The management for it is more straightforward; the difference between managing a connection-less network and a connect-oriented network, on some level. This scheme doesn't depend on chance; it depends upon the topology being appropriately engineered. > The alternate nexthops is not completely new, probably should > mention draft-kini-traf-restore-nsp-00.txt which I think was > expired, but searched on web found this link: > >http://yen.cse.kyutech.ac.jp/~ike/I-D/OLD/draft-kini-traf-restore-nsp-00.txt > that draft had some similar idea as computing primary and alternate > nexthops. Absolutely; it's hard to reference an expired draft. I know that the concept of alternate next-hops has been discussed before, in reference to loop-free alternates. The conclusion seems to have been that it didn't provide enough coverage. That's what the U-Turn alternates are trying to solve. Thanks, Alia _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Feb 13 01:40:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11063 for ; Fri, 13 Feb 2004 01:40:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArWza-0005Z8-8x; Fri, 13 Feb 2004 01:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArWzW-0005YS-9a for routing-discussion@optimus.ietf.org; Fri, 13 Feb 2004 01:39:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11049 for ; Fri, 13 Feb 2004 01:39:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArWzP-0005Jw-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 01:39:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArWyS-0005EJ-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 01:38:53 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1ArWxv-00058n-00; Fri, 13 Feb 2004 01:38:20 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArWxy-000Ijt-SK; Fri, 13 Feb 2004 06:38:22 +0000 Date: Thu, 12 Feb 2004 22:38:02 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <8930684742.20040212223802@psg.com> To: routing-discussion@ietf.org CC: rtg-dir@ietf.org Subject: Comments solicited: draft-kompella-zinin-early-allocation-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- Please review draft-kompella-zinin-early-allocation-00.txt and provide your comments. We're going to discuss it at the Routing Area meeting in Seoul. Below is the abstract from the document: This memo discusses earlier allocation of code points by IANA as a remedy to the problem created by the "Standards Action" IANA policy for protocols where, by the IETF process, implementation and deployment experience is desired or required prior to publication. The document is available at: http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt Send your comments to routing-discussion@ietf.org, please. -- Alex http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Feb 13 01:40:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11065 for ; Fri, 13 Feb 2004 01:40:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArWzo-0005cE-Kd for routing-discussion-archive@odin.ietf.org; Fri, 13 Feb 2004 01:40:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D6eGsS021510 for routing-discussion-archive@odin.ietf.org; Fri, 13 Feb 2004 01:40:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArWza-0005Z8-8x; Fri, 13 Feb 2004 01:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArWzW-0005YS-9a for routing-discussion@optimus.ietf.org; Fri, 13 Feb 2004 01:39:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11049 for ; Fri, 13 Feb 2004 01:39:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArWzP-0005Jw-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 01:39:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArWyS-0005EJ-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 01:38:53 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1ArWxv-00058n-00; Fri, 13 Feb 2004 01:38:20 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArWxy-000Ijt-SK; Fri, 13 Feb 2004 06:38:22 +0000 Date: Thu, 12 Feb 2004 22:38:02 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <8930684742.20040212223802@psg.com> To: routing-discussion@ietf.org CC: rtg-dir@ietf.org Subject: Comments solicited: draft-kompella-zinin-early-allocation-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- Please review draft-kompella-zinin-early-allocation-00.txt and provide your comments. We're going to discuss it at the Routing Area meeting in Seoul. Below is the abstract from the document: This memo discusses earlier allocation of code points by IANA as a remedy to the problem created by the "Standards Action" IANA policy for protocols where, by the IETF process, implementation and deployment experience is desired or required prior to publication. The document is available at: http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt Send your comments to routing-discussion@ietf.org, please. -- Alex http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Feb 13 01:46:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11366 for ; Fri, 13 Feb 2004 01:46:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArX5P-00064e-3A; Fri, 13 Feb 2004 01:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArX5I-00063P-Jy for routing-discussion@optimus.ietf.org; Fri, 13 Feb 2004 01:45:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11341 for ; Fri, 13 Feb 2004 01:45:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArX5B-0005wd-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 01:45:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArX4Y-0005rU-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 01:45:11 -0500 Received: from bay1-f149.bay1.hotmail.com ([65.54.245.149] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1ArX3b-0005fl-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 01:44:11 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 12 Feb 2004 22:43:44 -0800 Received: from 63.197.79.145 by by1fd.bay1.hotmail.msn.com with HTTP; Fri, 13 Feb 2004 06:43:43 GMT X-Originating-IP: [63.197.79.145] X-Originating-Email: [rajmanibt@hotmail.com] X-Sender: rajmanibt@hotmail.com From: "Raj Mani" To: aatlas@avici.com Cc: routing-discussion@ietf.org Subject: Re: Fwd: I-D ACTION:draft-atlas-ip-local-protect-00.txt Date: Fri, 13 Feb 2004 01:43:43 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Feb 2004 06:43:44.0226 (UTC) FILETIME=[B978CC20:01C3F1FC] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Hi Atlas, thanks, see some comments inline. >> >> Good research. A few comments on this draft of local protection: >> >> It's rather confusing to talk about characterizing the neighbors, >> since each prefix can have it's own primary path, loop-free >>node-protecting >> alternate, loop-free link-protecting alternate, U-turn..., etc. If >> one has lots of prefixes, and neighbors, the combination can be >> rather large to keep track of. > >The characterization is more conceptual. In general, one determines the >appropriate alternate and primary next-hop for each node in the topology. >A prefix can be ECMP between two or more nodes, in which case it falls into >the multiple primary neighbors case. Yes, it's true. This should be per prefix/per next-hop based. Which was also the reason I'm puzzled by the paper most of the places treating those concept as per node basis. For example, the OSPF and ISIS signaling for the U-turn capabilities, it just announces this link as capable of performing U-turn or not, but since those concept is really prefix/destination related, you can have some prefixes having alternate paths, but other prefixes you don't have. So I'm not sure how can OSPF/ISIS flood only the capability for the links. > > >> I didn't fully understand all the U-turn cases described, since >> they are quite involved. Not sure you have covered the cases where >>two >> nodes have multiple parallel links, even you receive from one link >>and >> forward to another link, they can still be looping; also in >> multi-node looping case due to asymmetrical routing, >> S-->B-->A-->S which can not be detected by the inbound/outbound >> interface lookups. > >Yes, this is why the check is whether the traffic was received from the >same neighbor that the traffic would be sent out to and NOT whether the >traffic was received on the same link on which it would be forwarded. Since this is described as the "default" behavior; We are talking about forwarding plane or fast path. What will be the performance impact to detect which neighbor each packet is from? Even just to match inbound interface with outbound interface, I'm pretty sure that, most of the high-end routers can not even do that (without re-spining an Engine-12 for example); even for the routers are able to perform this, there can be a significant performance hit. > >If there were a routing loop of S->B->A->S, then B would not be a U-Turn >neighbor of S and S would not sure B for a U-Turn alternate. If you look >at the definition of a U-Turn neighbor, a neighbor B is a U-Turn neighbor >of S if and only if S is the primary neighbor for all optimal paths from B >to the destination that go through S. > > >> The computation of this can be intensive (depends on the number >> of routes and number of neighbors), there are more chance nodes >> converge at different times. But this paper depends on every nodes >> are in stable condition, otherwise, some of the calculations may not >> be reliable. > >Just like the primary SPF, the computation primarily depends on the number >of nodes in the network, though the number of neighbors which can provide >alternates is also important. > >The alternates are computed to protect against a single failure. The >calculations for the alternate next-hops are as reliable as the primary >next-hops are; i.e. once the network has converged, there will be >alternates that can be used to protect against a single failure. Sometimes there can be link/route flappings, sometimes there are fiber cut which may bring down more than one IP link; a node failure may also trigger multiple link failure detection by multiple nodes. > >> The paper mentioned LDP and node protection, I don't see how the >> LDP traffic can be protected using node protection with this. Can >> you give an example? > >The issue with providing LDP with node protection is knowing the new >neighbor's label. If the LSRs use downstream unsolicited and liberal label >retention, then an LSR will have the label bindings for each FEC from each >of its neighbors that support that FEC. > >As long as the label binding is known for the alternate neighbor, then the >appropriate out-segment can be created beforehand based on the selected >alternate next-hop. > >Does that make sense? It does assume that there are LDP sessions to each >neighbor, but that is generally the case. yes, this makes sense. > > >> This paper mentioned the capability need only be flooded to a node's >> neighbor, I don't recall there is a special mechanism defined to >> only flood to IGP neighbors but not further. > >For OSPF, there is the ability to have a link-scope opaque TLV (type 9, I >believe). The same mechanism isn't there for IS-IS. > >We actually decided not to use a link-scope TLV, because we wanted similar >capabilities for OSPF and IS-IS, and because we wanted to define a link >capabilities sub-TLV, where the other bits could be used to another >purpose. > >Take a look at draft-atlas-ospf-local-protect-cap-00.txt and >draft-martin-isis-local-protect-cap-00.txt. Yes, I just did. Thus I have the above mentioned question. I would think the capability is not just a node/link capability, but also related to the prefixes which may or may not use the same alternate paths or even have alternate path. > >> If the paper claims the MPLS-TE FRR is complicated, This scheme >> is not less complicated;) They can all be accomplished by router or >> some server software, but at least MPLS-TE FRR is guaranteed to >>deliver >> the switch-over without depending on chance. > >The question is where the complexity burden is handled. This scheme is >complicated to understand and non-trivial to implement, but the complexity >is primarily in the algorithm. The management for it is more >straightforward; the difference between managing a connection-less network >and a connect-oriented network, on some level. Yes, and we all know managing a connectless network can face uncertainty while connection-oriented network gives certainty. In some sense, it's also an implementation issue, the MPLS-TE FRR if without considering the TE portion, can also be setup automatically without much configuration. > >This scheme doesn't depend on chance; it depends upon the topology being >appropriately engineered. When I mentioned "by chance", I meant in this paper, you may or may not find alternate path, or find U-turn alternate; you may face two network events close enough that you don't have enough time to compute all the alternate paths before a local link/node failure; while in MPLS-TE FRR, it's almost a certainty to get switched-over correctly. > >> The alternate nexthops is not completely new, probably should >> mention draft-kini-traf-restore-nsp-00.txt which I think was >> expired, but searched on web found this link: >> >>http://yen.cse.kyutech.ac.jp/~ike/I-D/OLD/draft-kini-traf-restore-nsp-00.txt >> that draft had some similar idea as computing primary and alternate >> nexthops. > >Absolutely; it's hard to reference an expired draft. I know that the >concept of alternate next-hops has been discussed before, in reference to >loop-free alternates. The conclusion seems to have been that it didn't >provide enough coverage. That's what the U-Turn alternates are trying to >solve. this makes sense. thanks. - r > >Thanks, >Alia > > > >_______________________________________________ >routing-discussion mailing list >routing-discussion@ietf.org >https://www1.ietf.org/mailman/listinfo/routing-discussion _________________________________________________________________ Create your own personal Web page with the info you use most, at My MSN. http://click.atdmt.com/AVE/go/onm00200364ave/direct/01/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Feb 13 01:46:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11383 for ; Fri, 13 Feb 2004 01:46:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArX5P-00065O-QH; Fri, 13 Feb 2004 01:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArX5J-00063R-UN for routing-discussion@optimus.ietf.org; Fri, 13 Feb 2004 01:45:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11344 for ; Fri, 13 Feb 2004 01:45:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArX5C-0005wn-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 01:45:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArX4a-0005rk-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 01:45:13 -0500 Received: from bay1-f74.bay1.hotmail.com ([65.54.245.74] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1ArX3s-0005iN-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 01:44:28 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 12 Feb 2004 22:44:00 -0800 Received: from 63.197.79.145 by by1fd.bay1.hotmail.msn.com with HTTP; Fri, 13 Feb 2004 06:44:00 GMT X-Originating-IP: [63.197.79.145] X-Originating-Email: [rajmanibt@hotmail.com] X-Sender: rajmanibt@hotmail.com From: "Raj Mani" To: aatlas@avici.com Cc: routing-discussion@ietf.org Subject: Re: Fwd: I-D ACTION:draft-atlas-ip-local-protect-00.txt Date: Fri, 13 Feb 2004 01:44:00 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Feb 2004 06:44:00.0817 (UTC) FILETIME=[C35C6210:01C3F1FC] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Hi Atlas, thanks, see some comments inline. >> >> Good research. A few comments on this draft of local protection: >> >> It's rather confusing to talk about characterizing the neighbors, >> since each prefix can have it's own primary path, loop-free >>node-protecting >> alternate, loop-free link-protecting alternate, U-turn..., etc. If >> one has lots of prefixes, and neighbors, the combination can be >> rather large to keep track of. > >The characterization is more conceptual. In general, one determines the >appropriate alternate and primary next-hop for each node in the topology. >A prefix can be ECMP between two or more nodes, in which case it falls into >the multiple primary neighbors case. Yes, it's true. This should be per prefix/per next-hop based. Which was also the reason I'm puzzled by the paper most of the places treating those concept as per node basis. For example, the OSPF and ISIS signaling for the U-turn capabilities, it just announces this link as capable of performing U-turn or not, but since those concept is really prefix/destination related, you can have some prefixes having alternate paths, but other prefixes you don't have. So I'm not sure how can OSPF/ISIS flood only the capability for the links. > > >> I didn't fully understand all the U-turn cases described, since >> they are quite involved. Not sure you have covered the cases where >>two >> nodes have multiple parallel links, even you receive from one link >>and >> forward to another link, they can still be looping; also in >> multi-node looping case due to asymmetrical routing, >> S-->B-->A-->S which can not be detected by the inbound/outbound >> interface lookups. > >Yes, this is why the check is whether the traffic was received from the >same neighbor that the traffic would be sent out to and NOT whether the >traffic was received on the same link on which it would be forwarded. Since this is described as the "default" behavior; We are talking about forwarding plane or fast path. What will be the performance impact to detect which neighbor each packet is from? Even just to match inbound interface with outbound interface, I'm pretty sure that, most of the high-end routers can not even do that (without re-spining an Engine-12 for example); even for the routers are able to perform this, there can be a significant performance hit. > >If there were a routing loop of S->B->A->S, then B would not be a U-Turn >neighbor of S and S would not sure B for a U-Turn alternate. If you look >at the definition of a U-Turn neighbor, a neighbor B is a U-Turn neighbor >of S if and only if S is the primary neighbor for all optimal paths from B >to the destination that go through S. > > >> The computation of this can be intensive (depends on the number >> of routes and number of neighbors), there are more chance nodes >> converge at different times. But this paper depends on every nodes >> are in stable condition, otherwise, some of the calculations may not >> be reliable. > >Just like the primary SPF, the computation primarily depends on the number >of nodes in the network, though the number of neighbors which can provide >alternates is also important. > >The alternates are computed to protect against a single failure. The >calculations for the alternate next-hops are as reliable as the primary >next-hops are; i.e. once the network has converged, there will be >alternates that can be used to protect against a single failure. Sometimes there can be link/route flappings, sometimes there are fiber cut which may bring down more than one IP link; a node failure may also trigger multiple link failure detection by multiple nodes. > >> The paper mentioned LDP and node protection, I don't see how the >> LDP traffic can be protected using node protection with this. Can >> you give an example? > >The issue with providing LDP with node protection is knowing the new >neighbor's label. If the LSRs use downstream unsolicited and liberal label >retention, then an LSR will have the label bindings for each FEC from each >of its neighbors that support that FEC. > >As long as the label binding is known for the alternate neighbor, then the >appropriate out-segment can be created beforehand based on the selected >alternate next-hop. > >Does that make sense? It does assume that there are LDP sessions to each >neighbor, but that is generally the case. yes, this makes sense. > > >> This paper mentioned the capability need only be flooded to a node's >> neighbor, I don't recall there is a special mechanism defined to >> only flood to IGP neighbors but not further. > >For OSPF, there is the ability to have a link-scope opaque TLV (type 9, I >believe). The same mechanism isn't there for IS-IS. > >We actually decided not to use a link-scope TLV, because we wanted similar >capabilities for OSPF and IS-IS, and because we wanted to define a link >capabilities sub-TLV, where the other bits could be used to another >purpose. > >Take a look at draft-atlas-ospf-local-protect-cap-00.txt and >draft-martin-isis-local-protect-cap-00.txt. Yes, I just did. Thus I have the above mentioned question. I would think the capability is not just a node/link capability, but also related to the prefixes which may or may not use the same alternate paths or even have alternate path. > >> If the paper claims the MPLS-TE FRR is complicated, This scheme >> is not less complicated;) They can all be accomplished by router or >> some server software, but at least MPLS-TE FRR is guaranteed to >>deliver >> the switch-over without depending on chance. > >The question is where the complexity burden is handled. This scheme is >complicated to understand and non-trivial to implement, but the complexity >is primarily in the algorithm. The management for it is more >straightforward; the difference between managing a connection-less network >and a connect-oriented network, on some level. Yes, and we all know managing a connectless network can face uncertainty while connection-oriented network gives certainty. In some sense, it's also an implementation issue, the MPLS-TE FRR if without considering the TE portion, can also be setup automatically without much configuration. > >This scheme doesn't depend on chance; it depends upon the topology being >appropriately engineered. When I mentioned "by chance", I meant in this paper, you may or may not find alternate path, or find U-turn alternate; you may face two network events close enough that you don't have enough time to compute all the alternate paths before a local link/node failure; while in MPLS-TE FRR, it's almost a certainty to get switched-over correctly. > >> The alternate nexthops is not completely new, probably should >> mention draft-kini-traf-restore-nsp-00.txt which I think was >> expired, but searched on web found this link: >> >>http://yen.cse.kyutech.ac.jp/~ike/I-D/OLD/draft-kini-traf-restore-nsp-00.txt >> that draft had some similar idea as computing primary and alternate >> nexthops. > >Absolutely; it's hard to reference an expired draft. I know that the >concept of alternate next-hops has been discussed before, in reference to >loop-free alternates. The conclusion seems to have been that it didn't >provide enough coverage. That's what the U-Turn alternates are trying to >solve. this makes sense. thanks. - r > >Thanks, >Alia > > > >_______________________________________________ >routing-discussion mailing list >routing-discussion@ietf.org >https://www1.ietf.org/mailman/listinfo/routing-discussion _________________________________________________________________ Let the advanced features & services of MSN Internet Software maximize your online time. http://click.atdmt.com/AVE/go/onm00200363ave/direct/01/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Feb 13 01:46:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11392 for ; Fri, 13 Feb 2004 01:46:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArX5T-00066y-AB for routing-discussion-archive@odin.ietf.org; Fri, 13 Feb 2004 01:46:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D6k7C9023452 for routing-discussion-archive@odin.ietf.org; Fri, 13 Feb 2004 01:46:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArX5P-00065O-QH; Fri, 13 Feb 2004 01:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArX5J-00063R-UN for routing-discussion@optimus.ietf.org; Fri, 13 Feb 2004 01:45:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11344 for ; Fri, 13 Feb 2004 01:45:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArX5C-0005wn-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 01:45:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArX4a-0005rk-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 01:45:13 -0500 Received: from bay1-f74.bay1.hotmail.com ([65.54.245.74] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1ArX3s-0005iN-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 01:44:28 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 12 Feb 2004 22:44:00 -0800 Received: from 63.197.79.145 by by1fd.bay1.hotmail.msn.com with HTTP; Fri, 13 Feb 2004 06:44:00 GMT X-Originating-IP: [63.197.79.145] X-Originating-Email: [rajmanibt@hotmail.com] X-Sender: rajmanibt@hotmail.com From: "Raj Mani" To: aatlas@avici.com Cc: routing-discussion@ietf.org Subject: Re: Fwd: I-D ACTION:draft-atlas-ip-local-protect-00.txt Date: Fri, 13 Feb 2004 01:44:00 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Feb 2004 06:44:00.0817 (UTC) FILETIME=[C35C6210:01C3F1FC] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Hi Atlas, thanks, see some comments inline. >> >> Good research. A few comments on this draft of local protection: >> >> It's rather confusing to talk about characterizing the neighbors, >> since each prefix can have it's own primary path, loop-free >>node-protecting >> alternate, loop-free link-protecting alternate, U-turn..., etc. If >> one has lots of prefixes, and neighbors, the combination can be >> rather large to keep track of. > >The characterization is more conceptual. In general, one determines the >appropriate alternate and primary next-hop for each node in the topology. >A prefix can be ECMP between two or more nodes, in which case it falls into >the multiple primary neighbors case. Yes, it's true. This should be per prefix/per next-hop based. Which was also the reason I'm puzzled by the paper most of the places treating those concept as per node basis. For example, the OSPF and ISIS signaling for the U-turn capabilities, it just announces this link as capable of performing U-turn or not, but since those concept is really prefix/destination related, you can have some prefixes having alternate paths, but other prefixes you don't have. So I'm not sure how can OSPF/ISIS flood only the capability for the links. > > >> I didn't fully understand all the U-turn cases described, since >> they are quite involved. Not sure you have covered the cases where >>two >> nodes have multiple parallel links, even you receive from one link >>and >> forward to another link, they can still be looping; also in >> multi-node looping case due to asymmetrical routing, >> S-->B-->A-->S which can not be detected by the inbound/outbound >> interface lookups. > >Yes, this is why the check is whether the traffic was received from the >same neighbor that the traffic would be sent out to and NOT whether the >traffic was received on the same link on which it would be forwarded. Since this is described as the "default" behavior; We are talking about forwarding plane or fast path. What will be the performance impact to detect which neighbor each packet is from? Even just to match inbound interface with outbound interface, I'm pretty sure that, most of the high-end routers can not even do that (without re-spining an Engine-12 for example); even for the routers are able to perform this, there can be a significant performance hit. > >If there were a routing loop of S->B->A->S, then B would not be a U-Turn >neighbor of S and S would not sure B for a U-Turn alternate. If you look >at the definition of a U-Turn neighbor, a neighbor B is a U-Turn neighbor >of S if and only if S is the primary neighbor for all optimal paths from B >to the destination that go through S. > > >> The computation of this can be intensive (depends on the number >> of routes and number of neighbors), there are more chance nodes >> converge at different times. But this paper depends on every nodes >> are in stable condition, otherwise, some of the calculations may not >> be reliable. > >Just like the primary SPF, the computation primarily depends on the number >of nodes in the network, though the number of neighbors which can provide >alternates is also important. > >The alternates are computed to protect against a single failure. The >calculations for the alternate next-hops are as reliable as the primary >next-hops are; i.e. once the network has converged, there will be >alternates that can be used to protect against a single failure. Sometimes there can be link/route flappings, sometimes there are fiber cut which may bring down more than one IP link; a node failure may also trigger multiple link failure detection by multiple nodes. > >> The paper mentioned LDP and node protection, I don't see how the >> LDP traffic can be protected using node protection with this. Can >> you give an example? > >The issue with providing LDP with node protection is knowing the new >neighbor's label. If the LSRs use downstream unsolicited and liberal label >retention, then an LSR will have the label bindings for each FEC from each >of its neighbors that support that FEC. > >As long as the label binding is known for the alternate neighbor, then the >appropriate out-segment can be created beforehand based on the selected >alternate next-hop. > >Does that make sense? It does assume that there are LDP sessions to each >neighbor, but that is generally the case. yes, this makes sense. > > >> This paper mentioned the capability need only be flooded to a node's >> neighbor, I don't recall there is a special mechanism defined to >> only flood to IGP neighbors but not further. > >For OSPF, there is the ability to have a link-scope opaque TLV (type 9, I >believe). The same mechanism isn't there for IS-IS. > >We actually decided not to use a link-scope TLV, because we wanted similar >capabilities for OSPF and IS-IS, and because we wanted to define a link >capabilities sub-TLV, where the other bits could be used to another >purpose. > >Take a look at draft-atlas-ospf-local-protect-cap-00.txt and >draft-martin-isis-local-protect-cap-00.txt. Yes, I just did. Thus I have the above mentioned question. I would think the capability is not just a node/link capability, but also related to the prefixes which may or may not use the same alternate paths or even have alternate path. > >> If the paper claims the MPLS-TE FRR is complicated, This scheme >> is not less complicated;) They can all be accomplished by router or >> some server software, but at least MPLS-TE FRR is guaranteed to >>deliver >> the switch-over without depending on chance. > >The question is where the complexity burden is handled. This scheme is >complicated to understand and non-trivial to implement, but the complexity >is primarily in the algorithm. The management for it is more >straightforward; the difference between managing a connection-less network >and a connect-oriented network, on some level. Yes, and we all know managing a connectless network can face uncertainty while connection-oriented network gives certainty. In some sense, it's also an implementation issue, the MPLS-TE FRR if without considering the TE portion, can also be setup automatically without much configuration. > >This scheme doesn't depend on chance; it depends upon the topology being >appropriately engineered. When I mentioned "by chance", I meant in this paper, you may or may not find alternate path, or find U-turn alternate; you may face two network events close enough that you don't have enough time to compute all the alternate paths before a local link/node failure; while in MPLS-TE FRR, it's almost a certainty to get switched-over correctly. > >> The alternate nexthops is not completely new, probably should >> mention draft-kini-traf-restore-nsp-00.txt which I think was >> expired, but searched on web found this link: >> >>http://yen.cse.kyutech.ac.jp/~ike/I-D/OLD/draft-kini-traf-restore-nsp-00.txt >> that draft had some similar idea as computing primary and alternate >> nexthops. > >Absolutely; it's hard to reference an expired draft. I know that the >concept of alternate next-hops has been discussed before, in reference to >loop-free alternates. The conclusion seems to have been that it didn't >provide enough coverage. That's what the U-Turn alternates are trying to >solve. this makes sense. thanks. - r > >Thanks, >Alia > > > >_______________________________________________ >routing-discussion mailing list >routing-discussion@ietf.org >https://www1.ietf.org/mailman/listinfo/routing-discussion _________________________________________________________________ Let the advanced features & services of MSN Internet Software maximize your online time. http://click.atdmt.com/AVE/go/onm00200363ave/direct/01/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Feb 13 01:46:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11393 for ; Fri, 13 Feb 2004 01:46:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArX5T-00067f-Ch for routing-discussion-archive@odin.ietf.org; Fri, 13 Feb 2004 01:46:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D6k7pI023453 for routing-discussion-archive@odin.ietf.org; Fri, 13 Feb 2004 01:46:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArX5P-00064e-3A; Fri, 13 Feb 2004 01:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArX5I-00063P-Jy for routing-discussion@optimus.ietf.org; Fri, 13 Feb 2004 01:45:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11341 for ; Fri, 13 Feb 2004 01:45:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArX5B-0005wd-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 01:45:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArX4Y-0005rU-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 01:45:11 -0500 Received: from bay1-f149.bay1.hotmail.com ([65.54.245.149] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1ArX3b-0005fl-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 01:44:11 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 12 Feb 2004 22:43:44 -0800 Received: from 63.197.79.145 by by1fd.bay1.hotmail.msn.com with HTTP; Fri, 13 Feb 2004 06:43:43 GMT X-Originating-IP: [63.197.79.145] X-Originating-Email: [rajmanibt@hotmail.com] X-Sender: rajmanibt@hotmail.com From: "Raj Mani" To: aatlas@avici.com Cc: routing-discussion@ietf.org Subject: Re: Fwd: I-D ACTION:draft-atlas-ip-local-protect-00.txt Date: Fri, 13 Feb 2004 01:43:43 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Feb 2004 06:43:44.0226 (UTC) FILETIME=[B978CC20:01C3F1FC] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Hi Atlas, thanks, see some comments inline. >> >> Good research. A few comments on this draft of local protection: >> >> It's rather confusing to talk about characterizing the neighbors, >> since each prefix can have it's own primary path, loop-free >>node-protecting >> alternate, loop-free link-protecting alternate, U-turn..., etc. If >> one has lots of prefixes, and neighbors, the combination can be >> rather large to keep track of. > >The characterization is more conceptual. In general, one determines the >appropriate alternate and primary next-hop for each node in the topology. >A prefix can be ECMP between two or more nodes, in which case it falls into >the multiple primary neighbors case. Yes, it's true. This should be per prefix/per next-hop based. Which was also the reason I'm puzzled by the paper most of the places treating those concept as per node basis. For example, the OSPF and ISIS signaling for the U-turn capabilities, it just announces this link as capable of performing U-turn or not, but since those concept is really prefix/destination related, you can have some prefixes having alternate paths, but other prefixes you don't have. So I'm not sure how can OSPF/ISIS flood only the capability for the links. > > >> I didn't fully understand all the U-turn cases described, since >> they are quite involved. Not sure you have covered the cases where >>two >> nodes have multiple parallel links, even you receive from one link >>and >> forward to another link, they can still be looping; also in >> multi-node looping case due to asymmetrical routing, >> S-->B-->A-->S which can not be detected by the inbound/outbound >> interface lookups. > >Yes, this is why the check is whether the traffic was received from the >same neighbor that the traffic would be sent out to and NOT whether the >traffic was received on the same link on which it would be forwarded. Since this is described as the "default" behavior; We are talking about forwarding plane or fast path. What will be the performance impact to detect which neighbor each packet is from? Even just to match inbound interface with outbound interface, I'm pretty sure that, most of the high-end routers can not even do that (without re-spining an Engine-12 for example); even for the routers are able to perform this, there can be a significant performance hit. > >If there were a routing loop of S->B->A->S, then B would not be a U-Turn >neighbor of S and S would not sure B for a U-Turn alternate. If you look >at the definition of a U-Turn neighbor, a neighbor B is a U-Turn neighbor >of S if and only if S is the primary neighbor for all optimal paths from B >to the destination that go through S. > > >> The computation of this can be intensive (depends on the number >> of routes and number of neighbors), there are more chance nodes >> converge at different times. But this paper depends on every nodes >> are in stable condition, otherwise, some of the calculations may not >> be reliable. > >Just like the primary SPF, the computation primarily depends on the number >of nodes in the network, though the number of neighbors which can provide >alternates is also important. > >The alternates are computed to protect against a single failure. The >calculations for the alternate next-hops are as reliable as the primary >next-hops are; i.e. once the network has converged, there will be >alternates that can be used to protect against a single failure. Sometimes there can be link/route flappings, sometimes there are fiber cut which may bring down more than one IP link; a node failure may also trigger multiple link failure detection by multiple nodes. > >> The paper mentioned LDP and node protection, I don't see how the >> LDP traffic can be protected using node protection with this. Can >> you give an example? > >The issue with providing LDP with node protection is knowing the new >neighbor's label. If the LSRs use downstream unsolicited and liberal label >retention, then an LSR will have the label bindings for each FEC from each >of its neighbors that support that FEC. > >As long as the label binding is known for the alternate neighbor, then the >appropriate out-segment can be created beforehand based on the selected >alternate next-hop. > >Does that make sense? It does assume that there are LDP sessions to each >neighbor, but that is generally the case. yes, this makes sense. > > >> This paper mentioned the capability need only be flooded to a node's >> neighbor, I don't recall there is a special mechanism defined to >> only flood to IGP neighbors but not further. > >For OSPF, there is the ability to have a link-scope opaque TLV (type 9, I >believe). The same mechanism isn't there for IS-IS. > >We actually decided not to use a link-scope TLV, because we wanted similar >capabilities for OSPF and IS-IS, and because we wanted to define a link >capabilities sub-TLV, where the other bits could be used to another >purpose. > >Take a look at draft-atlas-ospf-local-protect-cap-00.txt and >draft-martin-isis-local-protect-cap-00.txt. Yes, I just did. Thus I have the above mentioned question. I would think the capability is not just a node/link capability, but also related to the prefixes which may or may not use the same alternate paths or even have alternate path. > >> If the paper claims the MPLS-TE FRR is complicated, This scheme >> is not less complicated;) They can all be accomplished by router or >> some server software, but at least MPLS-TE FRR is guaranteed to >>deliver >> the switch-over without depending on chance. > >The question is where the complexity burden is handled. This scheme is >complicated to understand and non-trivial to implement, but the complexity >is primarily in the algorithm. The management for it is more >straightforward; the difference between managing a connection-less network >and a connect-oriented network, on some level. Yes, and we all know managing a connectless network can face uncertainty while connection-oriented network gives certainty. In some sense, it's also an implementation issue, the MPLS-TE FRR if without considering the TE portion, can also be setup automatically without much configuration. > >This scheme doesn't depend on chance; it depends upon the topology being >appropriately engineered. When I mentioned "by chance", I meant in this paper, you may or may not find alternate path, or find U-turn alternate; you may face two network events close enough that you don't have enough time to compute all the alternate paths before a local link/node failure; while in MPLS-TE FRR, it's almost a certainty to get switched-over correctly. > >> The alternate nexthops is not completely new, probably should >> mention draft-kini-traf-restore-nsp-00.txt which I think was >> expired, but searched on web found this link: >> >>http://yen.cse.kyutech.ac.jp/~ike/I-D/OLD/draft-kini-traf-restore-nsp-00.txt >> that draft had some similar idea as computing primary and alternate >> nexthops. > >Absolutely; it's hard to reference an expired draft. I know that the >concept of alternate next-hops has been discussed before, in reference to >loop-free alternates. The conclusion seems to have been that it didn't >provide enough coverage. That's what the U-Turn alternates are trying to >solve. this makes sense. thanks. - r > >Thanks, >Alia > > > >_______________________________________________ >routing-discussion mailing list >routing-discussion@ietf.org >https://www1.ietf.org/mailman/listinfo/routing-discussion _________________________________________________________________ Create your own personal Web page with the info you use most, at My MSN. http://click.atdmt.com/AVE/go/onm00200364ave/direct/01/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Feb 13 01:47:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11488 for ; Fri, 13 Feb 2004 01:47:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArX6L-0006Dx-GQ; Fri, 13 Feb 2004 01:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArX6C-0006De-Hy for routing-discussion@optimus.ietf.org; Fri, 13 Feb 2004 01:46:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11465 for ; Fri, 13 Feb 2004 01:46:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArX65-00061w-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 01:46:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArX5E-0005xA-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 01:45:54 -0500 Received: from bay1-f109.bay1.hotmail.com ([65.54.245.109] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1ArX4i-0005p9-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 01:45:20 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 12 Feb 2004 22:44:52 -0800 Received: from 63.197.79.145 by by1fd.bay1.hotmail.msn.com with HTTP; Fri, 13 Feb 2004 06:44:52 GMT X-Originating-IP: [63.197.79.145] X-Originating-Email: [rajmanibt@hotmail.com] X-Sender: rajmanibt@hotmail.com From: "Raj Mani" To: aatlas@avici.com Cc: routing-discussion@ietf.org Subject: Re: Fwd: I-D ACTION:draft-atlas-ip-local-protect-00.txt Date: Fri, 13 Feb 2004 01:44:52 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Feb 2004 06:44:52.0995 (UTC) FILETIME=[E2761D30:01C3F1FC] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Hi Atlas, thanks, see some comments inline. >> >> Good research. A few comments on this draft of local protection: >> >> It's rather confusing to talk about characterizing the neighbors, >> since each prefix can have it's own primary path, loop-free >>node-protecting >> alternate, loop-free link-protecting alternate, U-turn..., etc. If >> one has lots of prefixes, and neighbors, the combination can be >> rather large to keep track of. > >The characterization is more conceptual. In general, one determines the >appropriate alternate and primary next-hop for each node in the topology. >A prefix can be ECMP between two or more nodes, in which case it falls into >the multiple primary neighbors case. Yes, it's true. This should be per prefix/per next-hop based. Which was also the reason I'm puzzled by the paper most of the places treating those concept as per node basis. For example, the OSPF and ISIS signaling for the U-turn capabilities, it just announces this link as capable of performing U-turn or not, but since those concept is really prefix/destination related, you can have some prefixes having alternate paths, but other prefixes you don't have. So I'm not sure how can OSPF/ISIS flood only the capability for the links. > > >> I didn't fully understand all the U-turn cases described, since >> they are quite involved. Not sure you have covered the cases where >>two >> nodes have multiple parallel links, even you receive from one link >>and >> forward to another link, they can still be looping; also in >> multi-node looping case due to asymmetrical routing, >> S-->B-->A-->S which can not be detected by the inbound/outbound >> interface lookups. > >Yes, this is why the check is whether the traffic was received from the >same neighbor that the traffic would be sent out to and NOT whether the >traffic was received on the same link on which it would be forwarded. Since this is described as the "default" behavior; We are talking about forwarding plane or fast path. What will be the performance impact to detect which neighbor each packet is from? Even just to match inbound interface with outbound interface, I'm pretty sure that, most of the high-end routers can not even do that (without re-spining an Engine-12 for example); even for the routers are able to perform this, there can be a significant performance hit. > >If there were a routing loop of S->B->A->S, then B would not be a U-Turn >neighbor of S and S would not sure B for a U-Turn alternate. If you look >at the definition of a U-Turn neighbor, a neighbor B is a U-Turn neighbor >of S if and only if S is the primary neighbor for all optimal paths from B >to the destination that go through S. > > >> The computation of this can be intensive (depends on the number >> of routes and number of neighbors), there are more chance nodes >> converge at different times. But this paper depends on every nodes >> are in stable condition, otherwise, some of the calculations may not >> be reliable. > >Just like the primary SPF, the computation primarily depends on the number >of nodes in the network, though the number of neighbors which can provide >alternates is also important. > >The alternates are computed to protect against a single failure. The >calculations for the alternate next-hops are as reliable as the primary >next-hops are; i.e. once the network has converged, there will be >alternates that can be used to protect against a single failure. Sometimes there can be link/route flappings, sometimes there are fiber cut which may bring down more than one IP link; a node failure may also trigger multiple link failure detection by multiple nodes. > >> The paper mentioned LDP and node protection, I don't see how the >> LDP traffic can be protected using node protection with this. Can >> you give an example? > >The issue with providing LDP with node protection is knowing the new >neighbor's label. If the LSRs use downstream unsolicited and liberal label >retention, then an LSR will have the label bindings for each FEC from each >of its neighbors that support that FEC. > >As long as the label binding is known for the alternate neighbor, then the >appropriate out-segment can be created beforehand based on the selected >alternate next-hop. > >Does that make sense? It does assume that there are LDP sessions to each >neighbor, but that is generally the case. yes, this makes sense. > > >> This paper mentioned the capability need only be flooded to a node's >> neighbor, I don't recall there is a special mechanism defined to >> only flood to IGP neighbors but not further. > >For OSPF, there is the ability to have a link-scope opaque TLV (type 9, I >believe). The same mechanism isn't there for IS-IS. > >We actually decided not to use a link-scope TLV, because we wanted similar >capabilities for OSPF and IS-IS, and because we wanted to define a link >capabilities sub-TLV, where the other bits could be used to another >purpose. > >Take a look at draft-atlas-ospf-local-protect-cap-00.txt and >draft-martin-isis-local-protect-cap-00.txt. Yes, I just did. Thus I have the above mentioned question. I would think the capability is not just a node/link capability, but also related to the prefixes which may or may not use the same alternate paths or even have alternate path. > >> If the paper claims the MPLS-TE FRR is complicated, This scheme >> is not less complicated;) They can all be accomplished by router or >> some server software, but at least MPLS-TE FRR is guaranteed to >>deliver >> the switch-over without depending on chance. > >The question is where the complexity burden is handled. This scheme is >complicated to understand and non-trivial to implement, but the complexity >is primarily in the algorithm. The management for it is more >straightforward; the difference between managing a connection-less network >and a connect-oriented network, on some level. Yes, and we all know managing a connectless network can face uncertainty while connection-oriented network gives certainty. In some sense, it's also an implementation issue, the MPLS-TE FRR if without considering the TE portion, can also be setup automatically without much configuration. > >This scheme doesn't depend on chance; it depends upon the topology being >appropriately engineered. When I mentioned "by chance", I meant in this paper, you may or may not find alternate path, or find U-turn alternate; you may face two network events close enough that you don't have enough time to compute all the alternate paths before a local link/node failure; while in MPLS-TE FRR, it's almost a certainty to get switched-over correctly. > >> The alternate nexthops is not completely new, probably should >> mention draft-kini-traf-restore-nsp-00.txt which I think was >> expired, but searched on web found this link: >> >>http://yen.cse.kyutech.ac.jp/~ike/I-D/OLD/draft-kini-traf-restore-nsp-00.txt >> that draft had some similar idea as computing primary and alternate >> nexthops. > >Absolutely; it's hard to reference an expired draft. I know that the >concept of alternate next-hops has been discussed before, in reference to >loop-free alternates. The conclusion seems to have been that it didn't >provide enough coverage. That's what the U-Turn alternates are trying to >solve. this makes sense. thanks. - r > >Thanks, >Alia > > > >_______________________________________________ >routing-discussion mailing list >routing-discussion@ietf.org >https://www1.ietf.org/mailman/listinfo/routing-discussion _________________________________________________________________ Choose now from 4 levels of MSN Hotmail Extra Storage - no more account overload! http://click.atdmt.com/AVE/go/onm00200362ave/direct/01/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Feb 13 02:33:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11489 for ; Fri, 13 Feb 2004 01:47:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArX6M-0006F5-2d for routing-discussion-archive@odin.ietf.org; Fri, 13 Feb 2004 01:47:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D6l137023955 for routing-discussion-archive@odin.ietf.org; Fri, 13 Feb 2004 01:47:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArX6L-0006Dx-GQ; Fri, 13 Feb 2004 01:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArX6C-0006De-Hy for routing-discussion@optimus.ietf.org; Fri, 13 Feb 2004 01:46:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11465 for ; Fri, 13 Feb 2004 01:46:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArX65-00061w-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 01:46:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArX5E-0005xA-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 01:45:54 -0500 Received: from bay1-f109.bay1.hotmail.com ([65.54.245.109] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1ArX4i-0005p9-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 01:45:20 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 12 Feb 2004 22:44:52 -0800 Received: from 63.197.79.145 by by1fd.bay1.hotmail.msn.com with HTTP; Fri, 13 Feb 2004 06:44:52 GMT X-Originating-IP: [63.197.79.145] X-Originating-Email: [rajmanibt@hotmail.com] X-Sender: rajmanibt@hotmail.com From: "Raj Mani" To: aatlas@avici.com Cc: routing-discussion@ietf.org Subject: Re: Fwd: I-D ACTION:draft-atlas-ip-local-protect-00.txt Date: Fri, 13 Feb 2004 01:44:52 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Feb 2004 06:44:52.0995 (UTC) FILETIME=[E2761D30:01C3F1FC] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Hi Atlas, thanks, see some comments inline. >> >> Good research. A few comments on this draft of local protection: >> >> It's rather confusing to talk about characterizing the neighbors, >> since each prefix can have it's own primary path, loop-free >>node-protecting >> alternate, loop-free link-protecting alternate, U-turn..., etc. If >> one has lots of prefixes, and neighbors, the combination can be >> rather large to keep track of. > >The characterization is more conceptual. In general, one determines the >appropriate alternate and primary next-hop for each node in the topology. >A prefix can be ECMP between two or more nodes, in which case it falls into >the multiple primary neighbors case. Yes, it's true. This should be per prefix/per next-hop based. Which was also the reason I'm puzzled by the paper most of the places treating those concept as per node basis. For example, the OSPF and ISIS signaling for the U-turn capabilities, it just announces this link as capable of performing U-turn or not, but since those concept is really prefix/destination related, you can have some prefixes having alternate paths, but other prefixes you don't have. So I'm not sure how can OSPF/ISIS flood only the capability for the links. > > >> I didn't fully understand all the U-turn cases described, since >> they are quite involved. Not sure you have covered the cases where >>two >> nodes have multiple parallel links, even you receive from one link >>and >> forward to another link, they can still be looping; also in >> multi-node looping case due to asymmetrical routing, >> S-->B-->A-->S which can not be detected by the inbound/outbound >> interface lookups. > >Yes, this is why the check is whether the traffic was received from the >same neighbor that the traffic would be sent out to and NOT whether the >traffic was received on the same link on which it would be forwarded. Since this is described as the "default" behavior; We are talking about forwarding plane or fast path. What will be the performance impact to detect which neighbor each packet is from? Even just to match inbound interface with outbound interface, I'm pretty sure that, most of the high-end routers can not even do that (without re-spining an Engine-12 for example); even for the routers are able to perform this, there can be a significant performance hit. > >If there were a routing loop of S->B->A->S, then B would not be a U-Turn >neighbor of S and S would not sure B for a U-Turn alternate. If you look >at the definition of a U-Turn neighbor, a neighbor B is a U-Turn neighbor >of S if and only if S is the primary neighbor for all optimal paths from B >to the destination that go through S. > > >> The computation of this can be intensive (depends on the number >> of routes and number of neighbors), there are more chance nodes >> converge at different times. But this paper depends on every nodes >> are in stable condition, otherwise, some of the calculations may not >> be reliable. > >Just like the primary SPF, the computation primarily depends on the number >of nodes in the network, though the number of neighbors which can provide >alternates is also important. > >The alternates are computed to protect against a single failure. The >calculations for the alternate next-hops are as reliable as the primary >next-hops are; i.e. once the network has converged, there will be >alternates that can be used to protect against a single failure. Sometimes there can be link/route flappings, sometimes there are fiber cut which may bring down more than one IP link; a node failure may also trigger multiple link failure detection by multiple nodes. > >> The paper mentioned LDP and node protection, I don't see how the >> LDP traffic can be protected using node protection with this. Can >> you give an example? > >The issue with providing LDP with node protection is knowing the new >neighbor's label. If the LSRs use downstream unsolicited and liberal label >retention, then an LSR will have the label bindings for each FEC from each >of its neighbors that support that FEC. > >As long as the label binding is known for the alternate neighbor, then the >appropriate out-segment can be created beforehand based on the selected >alternate next-hop. > >Does that make sense? It does assume that there are LDP sessions to each >neighbor, but that is generally the case. yes, this makes sense. > > >> This paper mentioned the capability need only be flooded to a node's >> neighbor, I don't recall there is a special mechanism defined to >> only flood to IGP neighbors but not further. > >For OSPF, there is the ability to have a link-scope opaque TLV (type 9, I >believe). The same mechanism isn't there for IS-IS. > >We actually decided not to use a link-scope TLV, because we wanted similar >capabilities for OSPF and IS-IS, and because we wanted to define a link >capabilities sub-TLV, where the other bits could be used to another >purpose. > >Take a look at draft-atlas-ospf-local-protect-cap-00.txt and >draft-martin-isis-local-protect-cap-00.txt. Yes, I just did. Thus I have the above mentioned question. I would think the capability is not just a node/link capability, but also related to the prefixes which may or may not use the same alternate paths or even have alternate path. > >> If the paper claims the MPLS-TE FRR is complicated, This scheme >> is not less complicated;) They can all be accomplished by router or >> some server software, but at least MPLS-TE FRR is guaranteed to >>deliver >> the switch-over without depending on chance. > >The question is where the complexity burden is handled. This scheme is >complicated to understand and non-trivial to implement, but the complexity >is primarily in the algorithm. The management for it is more >straightforward; the difference between managing a connection-less network >and a connect-oriented network, on some level. Yes, and we all know managing a connectless network can face uncertainty while connection-oriented network gives certainty. In some sense, it's also an implementation issue, the MPLS-TE FRR if without considering the TE portion, can also be setup automatically without much configuration. > >This scheme doesn't depend on chance; it depends upon the topology being >appropriately engineered. When I mentioned "by chance", I meant in this paper, you may or may not find alternate path, or find U-turn alternate; you may face two network events close enough that you don't have enough time to compute all the alternate paths before a local link/node failure; while in MPLS-TE FRR, it's almost a certainty to get switched-over correctly. > >> The alternate nexthops is not completely new, probably should >> mention draft-kini-traf-restore-nsp-00.txt which I think was >> expired, but searched on web found this link: >> >>http://yen.cse.kyutech.ac.jp/~ike/I-D/OLD/draft-kini-traf-restore-nsp-00.txt >> that draft had some similar idea as computing primary and alternate >> nexthops. > >Absolutely; it's hard to reference an expired draft. I know that the >concept of alternate next-hops has been discussed before, in reference to >loop-free alternates. The conclusion seems to have been that it didn't >provide enough coverage. That's what the U-Turn alternates are trying to >solve. this makes sense. thanks. - r > >Thanks, >Alia > > > >_______________________________________________ >routing-discussion mailing list >routing-discussion@ietf.org >https://www1.ietf.org/mailman/listinfo/routing-discussion _________________________________________________________________ Choose now from 4 levels of MSN Hotmail Extra Storage - no more account overload! http://click.atdmt.com/AVE/go/onm00200362ave/direct/01/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Feb 13 03:34:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28362 for ; Fri, 13 Feb 2004 03:34:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYlu-0004vc-Hc; Fri, 13 Feb 2004 03:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYlm-0004vI-89 for routing-discussion@optimus.ietf.org; Fri, 13 Feb 2004 03:33:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28325 for ; Fri, 13 Feb 2004 03:33:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYle-0007Sz-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 03:33:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArYkh-0007Ok-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 03:32:48 -0500 Received: from [208.246.215.201] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 1ArYjw-0007G1-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 03:32:00 -0500 Received: from aatlas-lt2.avici.com (b2vpn2pc123.avici.com [10.2.104.123]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i1D8VPje029033; Fri, 13 Feb 2004 03:31:25 -0500 Message-Id: <5.1.0.14.2.20040213031722.01d6e118@10.2.0.68> X-Sender: aatlas@10.2.0.68 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 13 Feb 2004 03:34:06 -0500 To: "Raj Mani" From: Alia Atlas Subject: Re: Fwd: I-D ACTION:draft-atlas-ip-local-protect-00.txt Cc: routing-discussion@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , At 01:43 AM 2/13/2004, Raj Mani wrote: >Hi Atlas, > > thanks, see some comments inline. >>> >>> Good research. A few comments on this draft of local protection: >>> >>> It's rather confusing to talk about characterizing the neighbors, >>> since each prefix can have it's own primary path, loop-free >>> node-protecting >>> alternate, loop-free link-protecting alternate, U-turn..., etc. If >>> one has lots of prefixes, and neighbors, the combination can be >>> rather large to keep track of. >> >>The characterization is more conceptual. In general, one determines the >>appropriate alternate and primary next-hop for each node in the topology. >>A prefix can be ECMP between two or more nodes, in which case it falls >>into the multiple primary neighbors case. > > Yes, it's true. This should be per prefix/per next-hop based. > Which was > also the reason I'm puzzled by the paper most of the places > treating those > concept as per node basis. For example, the OSPF and ISIS signaling > for the U-turn capabilities, it just announces this link as > capable of performing > U-turn or not, but since those concept is really > prefix/destination related, you > can have some prefixes having alternate paths, but other > prefixes you > don't have. So I'm not sure how can OSPF/ISIS flood only the > capability > for the links. First, the SPF computation is done on the topology. Then the results are inherited to the prefixes, based on which routers those prefixes are attached to. The breaking U-Turns is done on a link basis. The decision about which traffic is in a loop and therefore needs the U-Turn broken depends upon the traffic's prefix and destination. The ability to do so does not. >>> I didn't fully understand all the U-turn cases described, since >>> they are quite involved. Not sure you have covered the cases where two >>> nodes have multiple parallel links, even you receive from one link and >>> forward to another link, they can still be looping; also in >>> multi-node looping case due to asymmetrical routing, >>> S-->B-->A-->S which can not be detected by the inbound/outbound >>> interface lookups. >> >>Yes, this is why the check is whether the traffic was received from the >>same neighbor that the traffic would be sent out to and NOT whether the >>traffic was received on the same link on which it would be forwarded. > > Since this is described as the "default" behavior; We are talking > about forwarding plane or fast path. What will be the performance > impact to detect which neighbor each packet is from? Even just > to match inbound interface with outbound interface, I'm pretty > sure that, most of the high-end routers can not even do that > (without > re-spining an Engine-12 for example); even for the routers are > able to > perform this, there can be a significant performance hit. Well, I'm rather intimately familiar with a high-end router. Avici makes core routers. I would not be proposing this if we weren't capable of doing it without a performance issue. Naturally, I can't speak to the capabilities of other routers to support this today. >>If there were a routing loop of S->B->A->S, then B would not be a U-Turn >>neighbor of S and S would not sure B for a U-Turn alternate. If you look >>at the definition of a U-Turn neighbor, a neighbor B is a U-Turn neighbor >>of S if and only if S is the primary neighbor for all optimal paths from >>B to the destination that go through S. >> >> >>> The computation of this can be intensive (depends on the number >>> of routes and number of neighbors), there are more chance nodes >>> converge at different times. But this paper depends on every nodes >>> are in stable condition, otherwise, some of the calculations may not >>> be reliable. >> >>Just like the primary SPF, the computation primarily depends on the >>number of nodes in the network, though the number of neighbors which can >>provide alternates is also important. >> >>The alternates are computed to protect against a single failure. The >>calculations for the alternate next-hops are as reliable as the primary >>next-hops are; i.e. once the network has converged, there will be >>alternates that can be used to protect against a single failure. > > Sometimes there can be link/route flappings, sometimes there are > fiber > cut which may bring down more than one IP link; a node failure > may also trigger multiple link failure detection by multiple nodes. Absolutely. As proposed, this can protect against a single link or node failure. There are other cases it can be expanded to. >>> The paper mentioned LDP and node protection, I don't see how the >>> LDP traffic can be protected using node protection with this. Can >>> you give an example? >> >>The issue with providing LDP with node protection is knowing the new >>neighbor's label. If the LSRs use downstream unsolicited and liberal >>label retention, then an LSR will have the label bindings for each FEC >>from each of its neighbors that support that FEC. >> >>As long as the label binding is known for the alternate neighbor, then >>the appropriate out-segment can be created beforehand based on the >>selected alternate next-hop. >> >>Does that make sense? It does assume that there are LDP sessions to each >>neighbor, but that is generally the case. > > yes, this makes sense. > >> >> >>> This paper mentioned the capability need only be flooded to a node's >>> neighbor, I don't recall there is a special mechanism defined to >>> only flood to IGP neighbors but not further. >> >>For OSPF, there is the ability to have a link-scope opaque TLV (type 9, I >>believe). The same mechanism isn't there for IS-IS. >> >>We actually decided not to use a link-scope TLV, because we wanted >>similar capabilities for OSPF and IS-IS, and because we wanted to define >>a link capabilities sub-TLV, where the other bits could be used to >>another purpose. >> >>Take a look at draft-atlas-ospf-local-protect-cap-00.txt and >>draft-martin-isis-local-protect-cap-00.txt. > > Yes, I just did. Thus I have the above mentioned question. I would > think the capability is not just a node/link capability, but > also related > to the prefixes which may or may not use the same alternate paths > or even have alternate path. The alternate capability is saying that a router can use that particular interface as an alternate. The u-turn recipient capability is saying that the router can break U-Turns on that particular interface. If the router can break U-Turns, then it can do so for all prefixes or FECs for which that interface connects to the primary neighbor. >>> If the paper claims the MPLS-TE FRR is complicated, This scheme >>> is not less complicated;) They can all be accomplished by router or >>> some server software, but at least MPLS-TE FRR is guaranteed to >>> deliver >>> the switch-over without depending on chance. >> >>The question is where the complexity burden is handled. This scheme is >>complicated to understand and non-trivial to implement, but the >>complexity is primarily in the algorithm. The management for it is more >>straightforward; the difference between managing a connection-less >>network and a connect-oriented network, on some level. > > Yes, and we all know managing a connectless network can face > uncertainty while connection-oriented network gives certainty. > In some sense, it's also an implementation issue, the MPLS-TE > FRR if without considering the TE portion, can also be setup > automatically without much configuration. That does of course depend upon the particular implementation of FRR. If FRR is used with TE as a mesh overlay, true, but it suffers from the standard overlay scaling N^2 problems. This means that it may cover a TE core, but not all of the network which it is desirable to protect. If FRR is used to protect a particular node, one requires targeted LDP sessions to protect LDP traffic as well. If FRR is used to protect a particular link, then all traffic on that link goes to the backup path on a failure. With IP/LDP Local Protection, the traffic is spread to the various alternate next-hops, which may be more diverse. Finally, operationalizing FRR and trouble-shooting it can be complicated. >>This scheme doesn't depend on chance; it depends upon the topology being >>appropriately engineered. > > When I mentioned "by chance", I meant in this paper, you may > or may not find alternate path, or find U-turn alternate; you may > face two network events close enough that you don't have > enough time to compute all the alternate paths before a local > link/node failure; while in MPLS-TE FRR, it's almost a certainty > to get switched-over correctly. In MPLS-TE FRR, you still need to handle network changes and run a separate CSPF for every primary and every backup LSP. I would not say that it is a certainty to get switched-over correctly if there are multiple network events close enough together. As for potentially not finding an alternate path, that is part of what network engineering can help with. In the analyses I've done of coverage, I do find that some source-destination pairs are not covered in most networks, but the coverage % goes from about 79% with just loop-free alternates to over 98% with U-Turn alternates as well. Of course, that's based on source-destination coverage; when it is weighted by traffic matrices, the improvement can be more dramatic. >>> The alternate nexthops is not completely new, probably should >>> mention draft-kini-traf-restore-nsp-00.txt which I think was >>> expired, but searched on web found this link: >>> >>>http://yen.cse.kyutech.ac.jp/~ike/I-D/OLD/draft-kini-traf-restore-nsp-00.txt >>> that draft had some similar idea as computing primary and alternate >>> nexthops. >> >>Absolutely; it's hard to reference an expired draft. I know that the >>concept of alternate next-hops has been discussed before, in reference to >>loop-free alternates. The conclusion seems to have been that it didn't >>provide enough coverage. That's what the U-Turn alternates are trying to >>solve. > > this makes sense. thanks. Thanks for the interest and questions. Alia >- r > >> >>Thanks, >>Alia >> >> >> >>_______________________________________________ >>routing-discussion mailing list >>routing-discussion@ietf.org >>https://www1.ietf.org/mailman/listinfo/routing-discussion > >_________________________________________________________________ >Create your own personal Web page with the info you use most, at My MSN. >http://click.atdmt.com/AVE/go/onm00200364ave/direct/01/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Feb 13 04:23:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28366 for ; Fri, 13 Feb 2004 03:34:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYmK-00050R-02 for routing-discussion-archive@odin.ietf.org; Fri, 13 Feb 2004 03:34:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D8YRRD019242 for routing-discussion-archive@odin.ietf.org; Fri, 13 Feb 2004 03:34:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYlu-0004vc-Hc; Fri, 13 Feb 2004 03:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYlm-0004vI-89 for routing-discussion@optimus.ietf.org; Fri, 13 Feb 2004 03:33:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28325 for ; Fri, 13 Feb 2004 03:33:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYle-0007Sz-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 03:33:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArYkh-0007Ok-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 03:32:48 -0500 Received: from [208.246.215.201] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 1ArYjw-0007G1-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 03:32:00 -0500 Received: from aatlas-lt2.avici.com (b2vpn2pc123.avici.com [10.2.104.123]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i1D8VPje029033; Fri, 13 Feb 2004 03:31:25 -0500 Message-Id: <5.1.0.14.2.20040213031722.01d6e118@10.2.0.68> X-Sender: aatlas@10.2.0.68 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 13 Feb 2004 03:34:06 -0500 To: "Raj Mani" From: Alia Atlas Subject: Re: Fwd: I-D ACTION:draft-atlas-ip-local-protect-00.txt Cc: routing-discussion@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , At 01:43 AM 2/13/2004, Raj Mani wrote: >Hi Atlas, > > thanks, see some comments inline. >>> >>> Good research. A few comments on this draft of local protection: >>> >>> It's rather confusing to talk about characterizing the neighbors, >>> since each prefix can have it's own primary path, loop-free >>> node-protecting >>> alternate, loop-free link-protecting alternate, U-turn..., etc. If >>> one has lots of prefixes, and neighbors, the combination can be >>> rather large to keep track of. >> >>The characterization is more conceptual. In general, one determines the >>appropriate alternate and primary next-hop for each node in the topology. >>A prefix can be ECMP between two or more nodes, in which case it falls >>into the multiple primary neighbors case. > > Yes, it's true. This should be per prefix/per next-hop based. > Which was > also the reason I'm puzzled by the paper most of the places > treating those > concept as per node basis. For example, the OSPF and ISIS signaling > for the U-turn capabilities, it just announces this link as > capable of performing > U-turn or not, but since those concept is really > prefix/destination related, you > can have some prefixes having alternate paths, but other > prefixes you > don't have. So I'm not sure how can OSPF/ISIS flood only the > capability > for the links. First, the SPF computation is done on the topology. Then the results are inherited to the prefixes, based on which routers those prefixes are attached to. The breaking U-Turns is done on a link basis. The decision about which traffic is in a loop and therefore needs the U-Turn broken depends upon the traffic's prefix and destination. The ability to do so does not. >>> I didn't fully understand all the U-turn cases described, since >>> they are quite involved. Not sure you have covered the cases where two >>> nodes have multiple parallel links, even you receive from one link and >>> forward to another link, they can still be looping; also in >>> multi-node looping case due to asymmetrical routing, >>> S-->B-->A-->S which can not be detected by the inbound/outbound >>> interface lookups. >> >>Yes, this is why the check is whether the traffic was received from the >>same neighbor that the traffic would be sent out to and NOT whether the >>traffic was received on the same link on which it would be forwarded. > > Since this is described as the "default" behavior; We are talking > about forwarding plane or fast path. What will be the performance > impact to detect which neighbor each packet is from? Even just > to match inbound interface with outbound interface, I'm pretty > sure that, most of the high-end routers can not even do that > (without > re-spining an Engine-12 for example); even for the routers are > able to > perform this, there can be a significant performance hit. Well, I'm rather intimately familiar with a high-end router. Avici makes core routers. I would not be proposing this if we weren't capable of doing it without a performance issue. Naturally, I can't speak to the capabilities of other routers to support this today. >>If there were a routing loop of S->B->A->S, then B would not be a U-Turn >>neighbor of S and S would not sure B for a U-Turn alternate. If you look >>at the definition of a U-Turn neighbor, a neighbor B is a U-Turn neighbor >>of S if and only if S is the primary neighbor for all optimal paths from >>B to the destination that go through S. >> >> >>> The computation of this can be intensive (depends on the number >>> of routes and number of neighbors), there are more chance nodes >>> converge at different times. But this paper depends on every nodes >>> are in stable condition, otherwise, some of the calculations may not >>> be reliable. >> >>Just like the primary SPF, the computation primarily depends on the >>number of nodes in the network, though the number of neighbors which can >>provide alternates is also important. >> >>The alternates are computed to protect against a single failure. The >>calculations for the alternate next-hops are as reliable as the primary >>next-hops are; i.e. once the network has converged, there will be >>alternates that can be used to protect against a single failure. > > Sometimes there can be link/route flappings, sometimes there are > fiber > cut which may bring down more than one IP link; a node failure > may also trigger multiple link failure detection by multiple nodes. Absolutely. As proposed, this can protect against a single link or node failure. There are other cases it can be expanded to. >>> The paper mentioned LDP and node protection, I don't see how the >>> LDP traffic can be protected using node protection with this. Can >>> you give an example? >> >>The issue with providing LDP with node protection is knowing the new >>neighbor's label. If the LSRs use downstream unsolicited and liberal >>label retention, then an LSR will have the label bindings for each FEC >>from each of its neighbors that support that FEC. >> >>As long as the label binding is known for the alternate neighbor, then >>the appropriate out-segment can be created beforehand based on the >>selected alternate next-hop. >> >>Does that make sense? It does assume that there are LDP sessions to each >>neighbor, but that is generally the case. > > yes, this makes sense. > >> >> >>> This paper mentioned the capability need only be flooded to a node's >>> neighbor, I don't recall there is a special mechanism defined to >>> only flood to IGP neighbors but not further. >> >>For OSPF, there is the ability to have a link-scope opaque TLV (type 9, I >>believe). The same mechanism isn't there for IS-IS. >> >>We actually decided not to use a link-scope TLV, because we wanted >>similar capabilities for OSPF and IS-IS, and because we wanted to define >>a link capabilities sub-TLV, where the other bits could be used to >>another purpose. >> >>Take a look at draft-atlas-ospf-local-protect-cap-00.txt and >>draft-martin-isis-local-protect-cap-00.txt. > > Yes, I just did. Thus I have the above mentioned question. I would > think the capability is not just a node/link capability, but > also related > to the prefixes which may or may not use the same alternate paths > or even have alternate path. The alternate capability is saying that a router can use that particular interface as an alternate. The u-turn recipient capability is saying that the router can break U-Turns on that particular interface. If the router can break U-Turns, then it can do so for all prefixes or FECs for which that interface connects to the primary neighbor. >>> If the paper claims the MPLS-TE FRR is complicated, This scheme >>> is not less complicated;) They can all be accomplished by router or >>> some server software, but at least MPLS-TE FRR is guaranteed to >>> deliver >>> the switch-over without depending on chance. >> >>The question is where the complexity burden is handled. This scheme is >>complicated to understand and non-trivial to implement, but the >>complexity is primarily in the algorithm. The management for it is more >>straightforward; the difference between managing a connection-less >>network and a connect-oriented network, on some level. > > Yes, and we all know managing a connectless network can face > uncertainty while connection-oriented network gives certainty. > In some sense, it's also an implementation issue, the MPLS-TE > FRR if without considering the TE portion, can also be setup > automatically without much configuration. That does of course depend upon the particular implementation of FRR. If FRR is used with TE as a mesh overlay, true, but it suffers from the standard overlay scaling N^2 problems. This means that it may cover a TE core, but not all of the network which it is desirable to protect. If FRR is used to protect a particular node, one requires targeted LDP sessions to protect LDP traffic as well. If FRR is used to protect a particular link, then all traffic on that link goes to the backup path on a failure. With IP/LDP Local Protection, the traffic is spread to the various alternate next-hops, which may be more diverse. Finally, operationalizing FRR and trouble-shooting it can be complicated. >>This scheme doesn't depend on chance; it depends upon the topology being >>appropriately engineered. > > When I mentioned "by chance", I meant in this paper, you may > or may not find alternate path, or find U-turn alternate; you may > face two network events close enough that you don't have > enough time to compute all the alternate paths before a local > link/node failure; while in MPLS-TE FRR, it's almost a certainty > to get switched-over correctly. In MPLS-TE FRR, you still need to handle network changes and run a separate CSPF for every primary and every backup LSP. I would not say that it is a certainty to get switched-over correctly if there are multiple network events close enough together. As for potentially not finding an alternate path, that is part of what network engineering can help with. In the analyses I've done of coverage, I do find that some source-destination pairs are not covered in most networks, but the coverage % goes from about 79% with just loop-free alternates to over 98% with U-Turn alternates as well. Of course, that's based on source-destination coverage; when it is weighted by traffic matrices, the improvement can be more dramatic. >>> The alternate nexthops is not completely new, probably should >>> mention draft-kini-traf-restore-nsp-00.txt which I think was >>> expired, but searched on web found this link: >>> >>>http://yen.cse.kyutech.ac.jp/~ike/I-D/OLD/draft-kini-traf-restore-nsp-00.txt >>> that draft had some similar idea as computing primary and alternate >>> nexthops. >> >>Absolutely; it's hard to reference an expired draft. I know that the >>concept of alternate next-hops has been discussed before, in reference to >>loop-free alternates. The conclusion seems to have been that it didn't >>provide enough coverage. That's what the U-Turn alternates are trying to >>solve. > > this makes sense. thanks. Thanks for the interest and questions. Alia >- r > >> >>Thanks, >>Alia >> >> >> >>_______________________________________________ >>routing-discussion mailing list >>routing-discussion@ietf.org >>https://www1.ietf.org/mailman/listinfo/routing-discussion > >_________________________________________________________________ >Create your own personal Web page with the info you use most, at My MSN. >http://click.atdmt.com/AVE/go/onm00200364ave/direct/01/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Feb 13 14:11:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26475 for ; Fri, 13 Feb 2004 14:11:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ariic-0000Ia-4N for routing-discussion-archive@odin.ietf.org; Fri, 13 Feb 2004 14:11:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DJBHOJ001072 for routing-discussion-archive@odin.ietf.org; Fri, 13 Feb 2004 14:11:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriiL-0000DR-Jv; Fri, 13 Feb 2004 14:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArihX-0000Bv-7a for routing-discussion@optimus.ietf.org; Fri, 13 Feb 2004 14:10:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26413 for ; Fri, 13 Feb 2004 14:10:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArihU-0007JK-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 14:10:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArigU-0007Fk-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 14:09:06 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Arifi-0007Bz-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 14:08:18 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Arifi-000BEv-9R for routing-discussion@ietf.org; Fri, 13 Feb 2004 19:08:18 +0000 Date: Fri, 13 Feb 2004 11:07:33 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <6514363864.20040213110733@psg.com> To: routing-discussion@ietf.org Subject: RTG Area meeting in Seoul MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- We're going to have an open area meeting in Seoul on Monday evening. At this point we have two drafts to discuss: draft-atlas-ip-local-protect-00.txt draft-kompella-zinin-early-allocation-00.txt Please send me your requests if you want a slot on the agenda. We will also need a scribe. If you're good at minutes-taking and will be attending the session, please consider volunteering. Thanks. -- Alex http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Feb 13 14:40:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28235 for ; Fri, 13 Feb 2004 14:40:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjAS-0002kf-HX; Fri, 13 Feb 2004 14:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arj9c-0002gr-6L for routing-discussion@optimus.ietf.org; Fri, 13 Feb 2004 14:39:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28161 for ; Fri, 13 Feb 2004 14:39:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arj9Z-0002NW-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 14:39:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arj8b-0002JM-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 14:38:10 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1Arj8Q-0002GB-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 14:37:59 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 6D3D09DC266; Fri, 13 Feb 2004 11:37:57 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00873-01; Fri, 13 Feb 2004 11:37:57 -0800 (PST) Received: from redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 238FF9DC264; Fri, 13 Feb 2004 11:37:57 -0800 (PST) Received: from malt (localhost [127.0.0.1]) by redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) with ESMTP id LAA17825; Fri, 13 Feb 2004 11:37:56 -0800 (PST) Message-Id: <200402131937.LAA17825@redback.com> To: Alex Zinin Cc: routing-discussion@ietf.org Subject: Re: RTG Area meeting in Seoul In-reply-to: Mail from Alex Zinin dated Fri, 13 Feb 2004 11:07:33 PST <6514363864.20040213110733@psg.com> Date: Fri, 13 Feb 2004 11:37:56 -0800 From: Naiming Shen X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Alex, See if we can get a slot for draft-shen-nhop-fastreroute-00.txt. For the routing-discussion list, We have submitted the draft a while ago, and also two more related: draft-shen-mpls-ldp-nnhop-label-00.txt draft-shen-pim-nnhop-neighbor-00.txt please review and comment, thanks. ] Folks- ] ] We're going to have an open area meeting in Seoul on Monday evening. ] ] At this point we have two drafts to discuss: ] ] draft-atlas-ip-local-protect-00.txt ] draft-kompella-zinin-early-allocation-00.txt ] ] Please send me your requests if you want a slot on the agenda. ] ] We will also need a scribe. If you're good at minutes-taking and will ] be attending the session, please consider volunteering. ] ] Thanks. ] ] -- ] Alex ] http://www.psg.com/~zinin/ ] ] ] _______________________________________________ ] routing-discussion mailing list ] routing-discussion@ietf.org ] https://www1.ietf.org/mailman/listinfo/routing-discussion - Naiming _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Feb 13 14:40:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28252 for ; Fri, 13 Feb 2004 14:40:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjAb-0002n2-W8 for routing-discussion-archive@odin.ietf.org; Fri, 13 Feb 2004 14:40:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DJeDrb010643 for routing-discussion-archive@odin.ietf.org; Fri, 13 Feb 2004 14:40:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjAS-0002kf-HX; Fri, 13 Feb 2004 14:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arj9c-0002gr-6L for routing-discussion@optimus.ietf.org; Fri, 13 Feb 2004 14:39:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28161 for ; Fri, 13 Feb 2004 14:39:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arj9Z-0002NW-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 14:39:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arj8b-0002JM-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 14:38:10 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1Arj8Q-0002GB-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 14:37:59 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 6D3D09DC266; Fri, 13 Feb 2004 11:37:57 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00873-01; Fri, 13 Feb 2004 11:37:57 -0800 (PST) Received: from redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 238FF9DC264; Fri, 13 Feb 2004 11:37:57 -0800 (PST) Received: from malt (localhost [127.0.0.1]) by redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) with ESMTP id LAA17825; Fri, 13 Feb 2004 11:37:56 -0800 (PST) Message-Id: <200402131937.LAA17825@redback.com> To: Alex Zinin Cc: routing-discussion@ietf.org Subject: Re: RTG Area meeting in Seoul In-reply-to: Mail from Alex Zinin dated Fri, 13 Feb 2004 11:07:33 PST <6514363864.20040213110733@psg.com> Date: Fri, 13 Feb 2004 11:37:56 -0800 From: Naiming Shen X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Alex, See if we can get a slot for draft-shen-nhop-fastreroute-00.txt. For the routing-discussion list, We have submitted the draft a while ago, and also two more related: draft-shen-mpls-ldp-nnhop-label-00.txt draft-shen-pim-nnhop-neighbor-00.txt please review and comment, thanks. ] Folks- ] ] We're going to have an open area meeting in Seoul on Monday evening. ] ] At this point we have two drafts to discuss: ] ] draft-atlas-ip-local-protect-00.txt ] draft-kompella-zinin-early-allocation-00.txt ] ] Please send me your requests if you want a slot on the agenda. ] ] We will also need a scribe. If you're good at minutes-taking and will ] be attending the session, please consider volunteering. ] ] Thanks. ] ] -- ] Alex ] http://www.psg.com/~zinin/ ] ] ] _______________________________________________ ] routing-discussion mailing list ] routing-discussion@ietf.org ] https://www1.ietf.org/mailman/listinfo/routing-discussion - Naiming _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Feb 13 14:58:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26473 for ; Fri, 13 Feb 2004 14:11:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriiL-0000DR-Jv; Fri, 13 Feb 2004 14:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArihX-0000Bv-7a for routing-discussion@optimus.ietf.org; Fri, 13 Feb 2004 14:10:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26413 for ; Fri, 13 Feb 2004 14:10:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArihU-0007JK-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 14:10:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArigU-0007Fk-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 14:09:06 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Arifi-0007Bz-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 14:08:18 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Arifi-000BEv-9R for routing-discussion@ietf.org; Fri, 13 Feb 2004 19:08:18 +0000 Date: Fri, 13 Feb 2004 11:07:33 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <6514363864.20040213110733@psg.com> To: routing-discussion@ietf.org Subject: RTG Area meeting in Seoul MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- We're going to have an open area meeting in Seoul on Monday evening. At this point we have two drafts to discuss: draft-atlas-ip-local-protect-00.txt draft-kompella-zinin-early-allocation-00.txt Please send me your requests if you want a slot on the agenda. We will also need a scribe. If you're good at minutes-taking and will be attending the session, please consider volunteering. Thanks. -- Alex http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Feb 13 16:03:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03297 for ; Fri, 13 Feb 2004 16:03:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkSj-0002n5-D8; Fri, 13 Feb 2004 16:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkRx-0002fA-Vk for routing-discussion@optimus.ietf.org; Fri, 13 Feb 2004 16:02:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03124 for ; Fri, 13 Feb 2004 16:02:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArkRw-0001Ol-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 16:02:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArkR8-0001KK-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 16:01:23 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1ArkQH-0001Fe-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 16:00:29 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArkQH-0002Rc-BS; Fri, 13 Feb 2004 21:00:29 +0000 Date: Fri, 13 Feb 2004 12:59:32 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <18521083396.20040213125932@psg.com> To: Naiming Shen CC: routing-discussion@ietf.org Subject: Re: RTG Area meeting in Seoul In-Reply-To: <200402131937.LAA17825@redback.com> References: <200402131937.LAA17825@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Naiming, I'll put you on the agenda. Thanks. -- Alex http://www.psg.com/~zinin/ Friday, February 13, 2004, 11:37:56 AM, Naiming Shen wrote: > Alex, > See if we can get a slot for draft-shen-nhop-fastreroute-00.txt. > For the routing-discussion list, > We have submitted the draft a while ago, and also two more related: > draft-shen-mpls-ldp-nnhop-label-00.txt > draft-shen-pim-nnhop-neighbor-00.txt > please review and comment, > thanks. > ] Folks- > ] > ] We're going to have an open area meeting in Seoul on Monday evening. > ] > ] At this point we have two drafts to discuss: > ] > ] draft-atlas-ip-local-protect-00.txt > ] draft-kompella-zinin-early-allocation-00.txt > ] > ] Please send me your requests if you want a slot on the agenda. > ] > ] We will also need a scribe. If you're good at minutes-taking and will > ] be attending the session, please consider volunteering. > ] > ] Thanks. > ] > ] -- > ] Alex > ] http://www.psg.com/~zinin/ > ] > ] > ] _______________________________________________ > ] routing-discussion mailing list > ] routing-discussion@ietf.org > ] https://www1.ietf.org/mailman/listinfo/routing-discussion > - Naiming _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Feb 13 16:48:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03298 for ; Fri, 13 Feb 2004 16:03:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkSq-0002pX-BX for routing-discussion-archive@odin.ietf.org; Fri, 13 Feb 2004 16:03:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DL38w4010847 for routing-discussion-archive@odin.ietf.org; Fri, 13 Feb 2004 16:03:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkSj-0002n5-D8; Fri, 13 Feb 2004 16:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkRx-0002fA-Vk for routing-discussion@optimus.ietf.org; Fri, 13 Feb 2004 16:02:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03124 for ; Fri, 13 Feb 2004 16:02:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArkRw-0001Ol-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 16:02:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArkR8-0001KK-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 16:01:23 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1ArkQH-0001Fe-00 for routing-discussion@ietf.org; Fri, 13 Feb 2004 16:00:29 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArkQH-0002Rc-BS; Fri, 13 Feb 2004 21:00:29 +0000 Date: Fri, 13 Feb 2004 12:59:32 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <18521083396.20040213125932@psg.com> To: Naiming Shen CC: routing-discussion@ietf.org Subject: Re: RTG Area meeting in Seoul In-Reply-To: <200402131937.LAA17825@redback.com> References: <200402131937.LAA17825@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Naiming, I'll put you on the agenda. Thanks. -- Alex http://www.psg.com/~zinin/ Friday, February 13, 2004, 11:37:56 AM, Naiming Shen wrote: > Alex, > See if we can get a slot for draft-shen-nhop-fastreroute-00.txt. > For the routing-discussion list, > We have submitted the draft a while ago, and also two more related: > draft-shen-mpls-ldp-nnhop-label-00.txt > draft-shen-pim-nnhop-neighbor-00.txt > please review and comment, > thanks. > ] Folks- > ] > ] We're going to have an open area meeting in Seoul on Monday evening. > ] > ] At this point we have two drafts to discuss: > ] > ] draft-atlas-ip-local-protect-00.txt > ] draft-kompella-zinin-early-allocation-00.txt > ] > ] Please send me your requests if you want a slot on the agenda. > ] > ] We will also need a scribe. If you're good at minutes-taking and will > ] be attending the session, please consider volunteering. > ] > ] Thanks. > ] > ] -- > ] Alex > ] http://www.psg.com/~zinin/ > ] > ] > ] _______________________________________________ > ] routing-discussion mailing list > ] routing-discussion@ietf.org > ] https://www1.ietf.org/mailman/listinfo/routing-discussion > - Naiming _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Sat Feb 14 12:54:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25255 for ; Sat, 14 Feb 2004 12:54:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3zN-0006mt-2J; Sat, 14 Feb 2004 12:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3yW-0006bg-Ta for routing-discussion@optimus.ietf.org; Sat, 14 Feb 2004 12:53:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25122 for ; Sat, 14 Feb 2004 12:53:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As3yV-00059E-00 for routing-discussion@ietf.org; Sat, 14 Feb 2004 12:53:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As3xb-00053c-00 for routing-discussion@ietf.org; Sat, 14 Feb 2004 12:52:12 -0500 Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1As3wv-0004xf-00; Sat, 14 Feb 2004 12:51:29 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i1EHpRes024590; Sat, 14 Feb 2004 18:51:27 +0100 Received: from alcatel.be ([138.203.137.2]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004021418512710:1193 ; Sat, 14 Feb 2004 18:51:27 +0100 Message-ID: <402E6073.1090407@alcatel.be> Date: Sat, 14 Feb 2004 18:52:51 +0100 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin Cc: routing-discussion@ietf.org, rtg-dir@ietf.org Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt References: <8930684742.20040212223802@psg.com> In-Reply-To: <8930684742.20040212223802@psg.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/14/2004 18:51:27, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/14/2004 18:51:28, Serialize complete at 02/14/2004 18:51:28 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi alex, kireeti, all, would it be possible to detail the difference in procedure between a refresh, a renewal and a re-allocation "3.3. Expiry If early allocations expire before the document progresses to the point where IANA normally makes allocations, the authors and WG chairs may follow an abbreviated version of the process in section x.2 to request renewal of the code points. At most one renewal request may be made; thus, authors should choose carefully when the original request is to be made." the reason being that you're proposing "at most one renew" and i'd like to know if this means i can refresh at most once ? or that i may ask only once for a different code- point value - definition(s) may help here thanks for the clarification(s) - dimitri. Alex Zinin wrote: > Folks- > > Please review draft-kompella-zinin-early-allocation-00.txt and > provide your comments. We're going to discuss it at the Routing > Area meeting in Seoul. Below is the abstract from the document: > > This memo discusses earlier allocation of code points by IANA as a > remedy to the problem created by the "Standards Action" IANA policy > for protocols where, by the IETF process, implementation and > deployment experience is desired or required prior to publication. > > The document is available at: > > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt > > Send your comments to routing-discussion@ietf.org, please. > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Sat Feb 14 12:54:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25261 for ; Sat, 14 Feb 2004 12:54:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3zf-0006t8-8M for routing-discussion-archive@odin.ietf.org; Sat, 14 Feb 2004 12:54:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1EHsJRb026402 for routing-discussion-archive@odin.ietf.org; Sat, 14 Feb 2004 12:54:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3zN-0006mt-2J; Sat, 14 Feb 2004 12:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3yW-0006bg-Ta for routing-discussion@optimus.ietf.org; Sat, 14 Feb 2004 12:53:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25122 for ; Sat, 14 Feb 2004 12:53:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As3yV-00059E-00 for routing-discussion@ietf.org; Sat, 14 Feb 2004 12:53:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As3xb-00053c-00 for routing-discussion@ietf.org; Sat, 14 Feb 2004 12:52:12 -0500 Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1As3wv-0004xf-00; Sat, 14 Feb 2004 12:51:29 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i1EHpRes024590; Sat, 14 Feb 2004 18:51:27 +0100 Received: from alcatel.be ([138.203.137.2]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004021418512710:1193 ; Sat, 14 Feb 2004 18:51:27 +0100 Message-ID: <402E6073.1090407@alcatel.be> Date: Sat, 14 Feb 2004 18:52:51 +0100 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin Cc: routing-discussion@ietf.org, rtg-dir@ietf.org Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt References: <8930684742.20040212223802@psg.com> In-Reply-To: <8930684742.20040212223802@psg.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/14/2004 18:51:27, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/14/2004 18:51:28, Serialize complete at 02/14/2004 18:51:28 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi alex, kireeti, all, would it be possible to detail the difference in procedure between a refresh, a renewal and a re-allocation "3.3. Expiry If early allocations expire before the document progresses to the point where IANA normally makes allocations, the authors and WG chairs may follow an abbreviated version of the process in section x.2 to request renewal of the code points. At most one renewal request may be made; thus, authors should choose carefully when the original request is to be made." the reason being that you're proposing "at most one renew" and i'd like to know if this means i can refresh at most once ? or that i may ask only once for a different code- point value - definition(s) may help here thanks for the clarification(s) - dimitri. Alex Zinin wrote: > Folks- > > Please review draft-kompella-zinin-early-allocation-00.txt and > provide your comments. We're going to discuss it at the Routing > Area meeting in Seoul. Below is the abstract from the document: > > This memo discusses earlier allocation of code points by IANA as a > remedy to the problem created by the "Standards Action" IANA policy > for protocols where, by the IETF process, implementation and > deployment experience is desired or required prior to publication. > > The document is available at: > > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt > > Send your comments to routing-discussion@ietf.org, please. > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Feb 16 16:14:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25545 for ; Mon, 16 Feb 2004 16:14:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asq4O-0006kc-Go for routing-discussion-archive@odin.ietf.org; Mon, 16 Feb 2004 16:14:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GLEOh4025872 for routing-discussion-archive@odin.ietf.org; Mon, 16 Feb 2004 16:14:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asq41-0006cs-Eo; Mon, 16 Feb 2004 16:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asq37-0006ZT-GP for routing-discussion@optimus.ietf.org; Mon, 16 Feb 2004 16:13:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25190 for ; Mon, 16 Feb 2004 16:13:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asq35-0000Aq-00 for routing-discussion@ietf.org; Mon, 16 Feb 2004 16:13:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asq0q-0007UU-00 for routing-discussion@ietf.org; Mon, 16 Feb 2004 16:10:46 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Aspyb-00071T-00 for routing-discussion@ietf.org; Mon, 16 Feb 2004 16:08:25 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aspya-0003if-Rn for routing-discussion@ietf.org; Mon, 16 Feb 2004 21:08:24 +0000 Date: Mon, 16 Feb 2004 13:07:36 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <175280766941.20040216130736@psg.com> To: routing-discussion@ietf.org Subject: Re: RTG Area meeting in Seoul In-Reply-To: <6514363864.20040213110733@psg.com> References: <6514363864.20040213110733@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit FYI, it is very likely that the meeting day and time will change. The final agenda will have the right time. -- Alex http://www.psg.com/~zinin/ Friday, February 13, 2004, 11:07:33 AM, Alex Zinin wrote: > Folks- > We're going to have an open area meeting in Seoul on Monday evening. > At this point we have two drafts to discuss: > draft-atlas-ip-local-protect-00.txt > draft-kompella-zinin-early-allocation-00.txt > Please send me your requests if you want a slot on the agenda. > We will also need a scribe. If you're good at minutes-taking and will > be attending the session, please consider volunteering. > Thanks. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Feb 16 17:04:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25540 for ; Mon, 16 Feb 2004 16:14:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asq41-0006cs-Eo; Mon, 16 Feb 2004 16:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asq37-0006ZT-GP for routing-discussion@optimus.ietf.org; Mon, 16 Feb 2004 16:13:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25190 for ; Mon, 16 Feb 2004 16:13:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asq35-0000Aq-00 for routing-discussion@ietf.org; Mon, 16 Feb 2004 16:13:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asq0q-0007UU-00 for routing-discussion@ietf.org; Mon, 16 Feb 2004 16:10:46 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Aspyb-00071T-00 for routing-discussion@ietf.org; Mon, 16 Feb 2004 16:08:25 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aspya-0003if-Rn for routing-discussion@ietf.org; Mon, 16 Feb 2004 21:08:24 +0000 Date: Mon, 16 Feb 2004 13:07:36 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <175280766941.20040216130736@psg.com> To: routing-discussion@ietf.org Subject: Re: RTG Area meeting in Seoul In-Reply-To: <6514363864.20040213110733@psg.com> References: <6514363864.20040213110733@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit FYI, it is very likely that the meeting day and time will change. The final agenda will have the right time. -- Alex http://www.psg.com/~zinin/ Friday, February 13, 2004, 11:07:33 AM, Alex Zinin wrote: > Folks- > We're going to have an open area meeting in Seoul on Monday evening. > At this point we have two drafts to discuss: > draft-atlas-ip-local-protect-00.txt > draft-kompella-zinin-early-allocation-00.txt > Please send me your requests if you want a slot on the agenda. > We will also need a scribe. If you're good at minutes-taking and will > be attending the session, please consider volunteering. > Thanks. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Feb 17 10:41:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06478 for ; Tue, 17 Feb 2004 10:41:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7IV-0001jV-LO; Tue, 17 Feb 2004 10:38:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7Hg-0001Ld-Hq for routing-discussion@optimus.ietf.org; Tue, 17 Feb 2004 10:37:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05852 for ; Tue, 17 Feb 2004 10:37:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7He-00016a-00 for routing-discussion@ietf.org; Tue, 17 Feb 2004 10:37:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7Gl-00012h-00 for routing-discussion@ietf.org; Tue, 17 Feb 2004 10:36:19 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1At7Fy-0000yj-00; Tue, 17 Feb 2004 10:35:30 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1At7Fx-000512-8B; Tue, 17 Feb 2004 15:35:29 +0000 Date: Tue, 17 Feb 2004 07:35:03 -0800 From: Alex Zinin