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

Huaimo Chen <huaimo.chen@huawei.com> Mon, 14 March 2016 02:51 UTC

Return-Path: <huaimo.chen@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD00012D87C; Sun, 13 Mar 2016 19:51:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level:
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 VPbtiPUn6yq6; Sun, 13 Mar 2016 19:51:49 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7CD12D879; Sun, 13 Mar 2016 19:51:48 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKL27645; Mon, 14 Mar 2016 02:51:46 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.218.25.36) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 14 Mar 2016 02:51:45 +0000
Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.126]) by SJCEML703-CHM.china.huawei.com ([169.254.5.158]) with mapi id 14.03.0235.001; Sun, 13 Mar 2016 19:51:38 -0700
From: Huaimo Chen <huaimo.chen@huawei.com>
To: Lou Berger <lberger@labn.net>, "draft-ietf-teas-rsvp-egress-protection@ietf.org" <draft-ietf-teas-rsvp-egress-protection@ietf.org>, TEAS WG <teas@ietf.org>
Thread-Topic: [Teas] A basic question on draft-ietf-teas-rsvp-egress-protection
Thread-Index: AQHRWQxg4+fQ1rqBFECjimfPGfNSdp81nxwwgAF9iQCAIWOOUA==
Date: Mon, 14 Mar 2016 02:51:38 +0000
Message-ID: <5316A0AB3C851246A7CA5758973207D44E4F4ED3@SJCEML701-CHM.china.huawei.com>
References: <56A8CF8A.6080500@labn.net> <5316A0AB3C851246A7CA5758973207D44E4D6959@SJCEML701-CHM.china.huawei.com> <56C9AF04.5070201@labn.net>
In-Reply-To: <56C9AF04.5070201@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.245.236]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.56E62742.00C4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.126, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: f87721de18e2e259fa9b2e925f715ab7
Archived-At: <http://mailarchive.ietf.org/arch/msg/teas/Zxd51ZmmxOZy6nCrUWkKDB9Ug3E>
Subject: Re: [Teas] A basic question on draft-ietf-teas-rsvp-egress-protection
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 14 Mar 2016 02:51:53 -0000

Hi Lou,

    Thank you very much for your further comments.
    My answers/explanations are inline.

Best Regards,
Huaimo
-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net] 
Sent: Sunday, February 21, 2016 7:35 AM
To: Huaimo Chen; draft-ietf-teas-rsvp-egress-protection@ietf.org; TEAS WG
Subject: Re: [Teas] A basic question on draft-ietf-teas-rsvp-egress-protection

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?

[Huaimo]: Yes. 

> 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?

[Huaimo]: The SERO can be re-used for the egress protection. The final subobject in the SERO can be used to indicate the secondary/backup egress as you suggested. The advantage of re-usng the SERO is that we do not need to define a new object. But the some semantics of the SERO will be changed when it is used for the egress protection. The protection subobject will be changed or extended to include the information for the egress protection.

I will consider this in more details.

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
>