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

Lou Berger <lberger@labn.net> Tue, 13 October 2015 19:18 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 AE4B51A8937 for <mpls@ietfa.amsl.com>; Tue, 13 Oct 2015 12:18:56 -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 HGzncBE6OLg1 for <mpls@ietfa.amsl.com>; Tue, 13 Oct 2015 12:18:55 -0700 (PDT)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id CBD8F1A8934 for <mpls@ietf.org>; Tue, 13 Oct 2015 12:18:54 -0700 (PDT)
Received: (qmail 770 invoked by uid 0); 13 Oct 2015 19:18:53 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy5.mail.unifiedlayer.com with SMTP; 13 Oct 2015 19:18:53 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id UjJj1r00a2SSUrH01jJmgl; Tue, 13 Oct 2015 13:18:51 -0600
X-Authority-Analysis: v=2.1 cv=Jv9i8qIC 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=5lJygRwiOn0A:10 a=48vgC7mUAAAA:8 a=ZWeEEsOA0SWyfI9l6SQA:9 a=VU-pyMwvJ-SFenwX:21 a=cWembIWyJSwwr4vt: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=RIPXy4nVHd8g3EtFs9P9gLw01IwwqSxtrv1yuNOl814=; b=0Vn7Hze5M4u9drmCXYY4jSZDa77pTm3xlvE+Ne9fAp+LlMY0xJIn96shS0boixki3T8MEDEbpu5VVrsl2Xd6tLPsVPLIaKZDnqO1j4vOQWbofeNsAeL3qWP69W14q0uB;
Received: from box313.bluehost.com ([69.89.31.113]:44225 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from <lberger@labn.net>) id 1Zm55x-0002rc-0Q; Tue, 13 Oct 2015 13:18:45 -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> <56053C00.1000101@labn.net> <D242C75C.46F89%tsaad@cisco.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <561D5911.7070809@labn.net>
Date: Tue, 13 Oct 2015 15:18:41 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <D242C75C.46F89%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/Kk_j_jXfF7FJTQ7CIwij4a8bOT0>
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: Tue, 13 Oct 2015 19:18:56 -0000

Tarek,
    Thanks for the status.  I'll keep an eye out for the next rev.

Lou

On 10/13/2015 2:46 PM, Tarek Saad (tsaad) wrote:
> Hi Lou,
>
> The authors met and reviewed the proposal to use the RSVP Association
> object as a mechanism to relay the per-group bypass assignment information
> between the PLR(s) and MP(s). We agree that since the Association object
> as proposed is used to associate recovery LSP with the LSPs it is
> protecting can serve the purpose of associating a group of protected
> LSP(s) with a bypass LSP. We are looking into extending the IPv4/IPv6
> Extended ASSOCIATION Object (as defined in rfc6780) to carry the necessary
> Summary FRR information between the PLR and MP. We plan to add this in the
> next revision of the document.
>  
> Regards,
> Tarek
>
>
>
> On 2015-09-25, 8:20 AM, "Lou Berger" <lberger@labn.net> wrote:
>
>> 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
>>
>