Re: [mpls] progressing draft-mtaillon-mpls-summary-frr-rsvpte

Lou Berger <lberger@labn.net> Fri, 25 September 2015 12:20 UTC

Return-Path: <lberger@labn.net>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999081B3113 for <mpls@ietfa.amsl.com>; Fri, 25 Sep 2015 05:20:39 -0700 (PDT)
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 5Kykv6kbuAdt for <mpls@ietfa.amsl.com>; Fri, 25 Sep 2015 05:20:38 -0700 (PDT)
Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id CD7FA1B310B for <mpls@ietf.org>; Fri, 25 Sep 2015 05:20:37 -0700 (PDT)
Received: (qmail 3980 invoked by uid 0); 25 Sep 2015 12:20:37 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy6.mail.unifiedlayer.com with SMTP; 25 Sep 2015 12:20:37 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id MWLR1r0062SSUrH01WLUiC; Fri, 25 Sep 2015 12:20:36 -0600
X-Authority-Analysis: v=2.1 cv=GpXRpCFC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ff-B7xzCdYMA:10 a=48vgC7mUAAAA:8 a=ps-5Fq3lIZCQuZ2Q7NoA:9 a=52Ht3WTU7g9lv51L:21 a=AvU-4f6WizeO_BLt:21 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:Cc:References:To:Subject; bh=g+6UBalK5pNFieLRY0q88/W2IiIi8QPs9LY1+H073J4=; b=E8muD7rLyscwK8jBYmE8Ta9pby+8xGPz+njopA5Du4UEi7SOLJ7pSy42x6QQjz+pA5rDNatj9YEWDRFs2TgIpY7ADNVH8QxCcZV005J05jXMo8XPzOqxWvSRWUp2v0x3;
Received: from box313.bluehost.com ([69.89.31.113]:33070 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from <lberger@labn.net>) id 1ZfRzG-0007g8-5z; Fri, 25 Sep 2015 06:20:26 -0600
To: "Tarek Saad (tsaad)" <tsaad@cisco.com>, "mpls@ietf.org" <mpls@ietf.org>, "draft-mtaillon-mpls-summary-frr-rsvpte@ietf.org" <draft-mtaillon-mpls-summary-frr-rsvpte@ietf.org>
References: <55FA9994.5000304@pi.nu> <55FADA66.4080709@labn.net> <D224DFD2.40F4E%tsaad@cisco.com>
From: Lou Berger <lberger@labn.net>
X-Enigmail-Draft-Status: N1110
Message-ID: <56053C00.1000101@labn.net>
Date: Fri, 25 Sep 2015 08:20:16 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <D224DFD2.40F4E%tsaad@cisco.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/mpls/_YfkraXlVq4dZmWzpZwhRillGow>
Cc: "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "teas-chairs@tools.ietf.org" <teas-chairs@tools.ietf.org>
Subject: Re: [mpls] progressing draft-mtaillon-mpls-summary-frr-rsvpte
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Sep 2015 12:20:40 -0000

Tarek,
    Thanks for the response, see below.

On 9/20/2015 10:39 PM, Tarek Saad (tsaad) wrote:
> Thanks Lou for your review and comments. Inline for responses.
>
> On 2015-09-17, 11:21 AM, "mpls on behalf of Lou Berger"
> <mpls-bounces@ietf.org on behalf of lberger@labn.net> wrote:
>
>> I have some comments on the proposed mechanism (I have no opinion on
>> utility or likely implementation):
>>
>> 1. WRT SUMMARY_FRR_BYPASS_ACTIVE object
>>
>> RSVP object space is a pretty scarce resource and it seems we have a
>> number of existing objects that could be reused to support transport of
>> the required information.  Some candidates include: the Association
>> object with a new association type; or perhaps the PRIMARY_PATH_ROUTE
>> Object with a new C-type.
> [TS]: seems reasonable, we will discuss this among the authors for a
> suitable extension.
great.

>
>> 2. SUMMARY_FRR_BYPASS_ASSIGNMENT subobjects
>>
>> While RFC4090 makes use of RRO carried information, it does so without
>> changing the RRO format.  (At the time, I recall some used this as
>> justification for RRO usage vs introducing new formats.)  The new SOs
>> introduce new information and don't seem to be particularly linked to
>> normal RRO operation -- and more significantly really defining new
>> transit-node to transit-node signaling semantics:
> [TS]: the new SO, is recording local information that if intercepted by
> another LSR (PLR or MP that understands it) can use it for further summary
> FRR processing. This resembles to an extent what other RRO SOs do today
> (e.g. node-id and label Sos) for regular FRR.

The point was that those SOs serve their original purpose of being
useful in constructing EROs, while the new SOs really have entirely
different semantics -- for example what does it mean if an ingress
includes the new SOs for a transit node?

>>   The PLR notifies the MP of the bypass tunnel assignment via adding a
>>   SUMMARY_FRR_BYPASS_ASSIGNMENT subobject to the RSVP Path message
>>   RECORD_ROUTE object ...
>>
>>   The MP acknowledges the PLR's assignment by signalling a
>>   SUMMARY_FRR_BYPASS_ASSIGNMENT subobject within the RSVP Resv messsage
>>   RECORD_ROUTE object.
>>
>> IMO this usage of RRO is really wrong (and is easily broken by
>> application of RRO policies).  I think extending an existing object
> [TS]: yes, the comment (about RRO policies) is rightfully correct. .. but
> also applicable to existing RRO/SO(s) (e.g. node-id and/or label SO)
> needed for proper FRR too. 
Again, this was leveraging SOs that were defined & used for other
purposes and overloading their semantics.

> That said, will discuss extension of an
> existing (FRR) object amongst the authors for (dis)advantages.

That would be great and will be very interested in hearing your thoughts.

Thanks,
Lou

>
> Regards,
> Tarek
>
>
>> class is a better approach. Extending one of the existing FRR objects
>> would probably be cleanest, but think the authors should consider and
>> propose their preference.
>>
>> Lou
>>
>> On 9/17/2015 6:44 AM, Loa Andersson wrote:
>>> Working Groups,
>>>
>>> The mpls and teas working group chairs discussed the home working
>>> group for draft-mtaillon-mpls-summary-frr-rsvpte. Since the is entirely
>>> the choice fell on the mpls working group. We also decided to keep
>>> the teas wg in the loop.
>>>
>>> We have just initiated the mpls review team (MPLS-RT) review if this
>>> draft. This review is focused on if we want to accept the document as
>>> a working group draft, and if it is in shape for us to do so.
>>>
>>> The MPLS-RT reviewers are picked by the mpls chair that will shepherd
>>> the document.
>>>
>>> This also mean that this is a good time for anyone, from both working
>>> groups, to review the document. Please send your reviews to the mpls
>>> working group mailing list (mpls@ietf.org).
>>>
>>> /Loa
>>>
>>
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>