IETF Logo Mail Archive

Re: [Teas] A basic question on draft-ietf-teas-rsvp-egress-protection

Lou Berger <lberger@labn.net> Sun, 21 February 2016 12:35 UTC

Return-Path: <lberger@labn.net>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352F41B2B99 for <teas@ietfa.amsl.com>; Sun, 21 Feb 2016 04:35:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level:
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSAVPBmSrYmN for <teas@ietfa.amsl.com>; Sun, 21 Feb 2016 04:35:36 -0800 (PST)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id DE0CC1B2B93 for <teas@ietf.org>; Sun, 21 Feb 2016 04:35:35 -0800 (PST)
Received: (qmail 929 invoked by uid 0); 21 Feb 2016 12:35:28 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 21 Feb 2016 12:35:28 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id M7bG1s00Y2SSUrH017bKMv; Sun, 21 Feb 2016 12:35:25 -0700
X-Authority-Analysis: v=2.1 cv=GOWbTI9K c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=jFJIQSaiL_oA:10 a=48vgC7mUAAAA:8 a=dpONjLPLHsb_UuI35_4A:9 a=pILNOxqGKmIA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=nOTvNJxpwauMvnhFe3qrhq65atC//C0DmUyXlulKYvY=; b=XWqm8v12uCD8OIfQaXVDfWBm4R2GCsj7TQRS93YO48G7fCNFc/KXqvxvtD+6G9iq0BZMnvDSnLHVx7ZUC3mh6lhKHduue+3eH3H+QJekl5rjQefjk1D3Cpf5aVAn6IVJ;
Received: from box313.bluehost.com ([69.89.31.113]:36617 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from <lberger@labn.net>) id 1aXTEN-0003Fl-Eo; Sun, 21 Feb 2016 05:35:19 -0700
To: Huaimo Chen <huaimo.chen@huawei.com>, "draft-ietf-teas-rsvp-egress-protection@ietf.org" <draft-ietf-teas-rsvp-egress-protection@ietf.org>, TEAS WG <teas@ietf.org>
References: <56A8CF8A.6080500@labn.net> <5316A0AB3C851246A7CA5758973207D44E4D6959@SJCEML701-CHM.china.huawei.com>
From: Lou Berger <lberger@labn.net>
X-Enigmail-Draft-Status: N1110
Message-ID: <56C9AF04.5070201@labn.net>
Date: Sun, 21 Feb 2016 07:35:16 -0500
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <5316A0AB3C851246A7CA5758973207D44E4D6959@SJCEML701-CHM.china.huawei.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: <http://mailarchive.ietf.org/arch/msg/teas/uZeol08d1uttuWkTb6BQjvfIuIQ>
Subject: Re: [Teas] A basic question on draft-ietf-teas-rsvp-egress-protection
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Feb 2016 12:35:37 -0000

Huaimo,
	See below.

On 02/20/2016 05:15 PM, Huaimo Chen wrote:
> Hi Lou,
> 
>  
> 
> Thanks much for your comments.
> 
> My answer/explanation is inline below.
> 
>  
> 
> Best Regards,
> 
> Huaimo
> 
> -----Original Message-----
> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger
> Sent: Wednesday, January 27, 2016 9:09 AM
> To: draft-ietf-teas-rsvp-egress-protection@ietf.org; TEAS WG
> Subject: [Teas] A basic question on draft-ietf-teas-rsvp-egress-protection
> 
>  
> 
> Hi,
> 
>     I have a question on draft-ietf-teas-rsvp-egress-protection that is
> 
> prompted by today's interim and can be covered there and/or on list:
> 
>  
> 
> Given that the draft says:
> 
>>    The egress local protection may be generalized and used with the
> 
>>    segment protection defined in RFC 4873
> <https://tools.ietf.org/html/rfc4873>.  How it is generalized and
> 
>>    used is out of scope for this document.
> 
>> 
> 
>  
> 
> Why define a new set of formats and mechanisms when an existing set of
> 
> formats and mechanisms can be used or adapted to (a) provide the same
> 
> function and (b) do so in a more general way?
> 
>  
> 
> [Huaimo] RFC 4873 defines a segment protection, which provides a
> protection against a failure in a segment of an LSP. However, this
> segment protection can not be used or re-used to provide a protection
> against a failure in the egress of the LSP. 


> For a segment from a node B
> to the egress E of the LSP, node B creates a backup LSP to egress E, and
> switches the traffic to the backup LSP when detecting a failure in the
> segment except for a failure in egress E. When egress E fails, the
> backup LSP will fail, thus no protection is provided by the segment
> protection against egress failure. 

I'm sorry I just don't follow your argument here. Are you saying a
protected segment with a merge node which is also the egress doesn't
protect against egress failure?  If so, then yes - sure.  If not,
perhaps you can rephrase to state the point directly before jumping into
an example?

> To provide egress local (or fast)
> protection, the segment protection needs to be generalized/enhanced.

Right. So my basic question is why not reuse/build on this existing
mechanism?

For example why not just define egress protection to use an SERO with a
final subobject that is the secondary egress?

Lou

> 
>  
> 
> I look forward to hearing/discussing the rational for not not reusing
> 
> what we already have defined.
> 
>  
> 
> Thanks,
> 
> Lou
> 
>  
> 
>  
> 
> _______________________________________________
> 
> Teas mailing list
> 
> Teas@ietf.org
> 
> https://www.ietf.org/mailman/listinfo/teas
>

v2.23.0 | Report a Bug | By Email