Re: the shen-mpls-nnhop Was:(Re: thoughts on draft-bryant-shand-ipfrr-notvia-addresses-00.txt)

Stewart Bryant <stbryant@cisco.com> Wed, 18 May 2005 13:26 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYOZC-0008D7-Va; Wed, 18 May 2005 09:26:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYOZA-00089m-Pf for rtgwg@megatron.ietf.org; Wed, 18 May 2005 09:26:28 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19113 for <rtgwg@ietf.org>; Wed, 18 May 2005 09:26:26 -0400 (EDT)
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYOq7-0006Aq-3b for rtgwg@ietf.org; Wed, 18 May 2005 09:44:00 -0400
Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 18 May 2005 15:26:17 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4IDQDVe025447; Wed, 18 May 2005 15:26:14 +0200 (MEST)
Received: from cisco.com (dhcp-rea-gp250-64-103-64-205.cisco.com [64.103.64.205]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA25128; Wed, 18 May 2005 14:26:13 +0100 (BST)
Message-ID: <428B4277.6010009@cisco.com>
Date: Wed, 18 May 2005 14:26:15 +0100
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Loa Andersson <loa@pi.se>
References: <4.3.2.7.2.20050426141038.021f1a90@jaws.cisco.com> <4275DCE9.3070701@pi.se> <42764F53.40508@cisco.com> <42887E17.3020604@pi.se> <4288C28C.2020105@cisco.com> <4289D06E.2030005@pi.se> <428A2819.9020803@cisco.com> <428B05E9.2090308@pi.se>
In-Reply-To: <428B05E9.2090308@pi.se>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Content-Transfer-Encoding: 7bit
Cc: rtgwg@ietf.org
Subject: Re: the shen-mpls-nnhop Was:(Re: thoughts on draft-bryant-shand-ipfrr-notvia-addresses-00.txt)
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: rtgwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
Sender: rtgwg-bounces@ietf.org
Errors-To: rtgwg-bounces@ietf.org


Loa Andersson wrote:
> Maiming and Stewart,
> 
> you wrote - and I guess this is valid:
> 
> Naiming Shen wrote:
> 
>> I think the needs start emerging, any important services
>> riding on top of IP/MPLS transport infrastructure needs
>> fast convergence services. It's not reasonable to assume
>> only RSVP-TE LSPs need fast reroute, and other
>> network transport does not. This nnhop-ldp draft is to
>> facilitate the LDP based MPLS network for FRR with
>> node protection. I have been talking to some providers
>> in the past year, there are certainly interests in
>> this service.
> 
> 
> 
> Stewart Bryant wrote:
>  >
>  > I think the interest that we are seeing in IPFRR for LDP
>  > networks demonstrates the usefulness of this work. Sure
>  > RSVP-TE FRR exists, but some customers have expressed
>  > an interest in a solution that does not use RSVP.
>  >
> 
> However the MPLS working group need to take a decision if,
> when and how this futopicctionality should be developed.
> 
> 
> The way of doing this would be
> 
> - write down the requirements
> - send them to the mpls wg
> - we go through the moces to establish the mpls wg consensus
> 
> Comments:
> 
> - I don't think FRR for LDP based MPLS enabled IP networks
>   should not go into the rtgwg, the charter of the rtgwg seems
>   to say the rtgwg takes of everything that does not fit into
>   other routing are working groups (Alex and Bill comments on this?)

I disagree.

Whilst the MPLS WG must be engaged in this work, to do it
exclusively in MPLS WG would be a mistake.

The work that we have done to date has achieved a high degree
of commonality between the IP solution and the MPLS solution.
Maintenance of that commonality would be at risk if the
MPLS WG struck out in their own direction. This work
requires a significant knowledge of the working of routing
protocols and therefore RTGWG (or perhaps a new WG in routing)
would seem a more natural home than MPLSWG.

> 
> - my take is that for this purpose you could either document
>   the requirements in a separate document or put them into one
>   the existing documents. I've no preferences, but this should
>   be rather short.

I think that we need an FRR requirements draft.

BTW the scope is further widened by the applicability of elements
of the solution (loop free convergence) to network management.

> 
> - my preference would be to speed this up so we could have
>   a decision going into the Paris meeting.
> 
> Also I think it will be right to take this discussion to the
> mpls wg list. I will write a mail to mpls list to that effect.
> 

Certainly the MPLS WG need to be an aware and active participant
in this work, but please do not precipitate a schism.

- Stewart

> 
> /Loa
> 


_______________________________________________
Rtgwg mailing list
Rtgwg@ietf.org
https://www1.ietf.org/mailman/listinfo/rtgwg