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

"Tarek Saad (tsaad)" <> Fri, 18 March 2016 20:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 00E7212D69E; Fri, 18 Mar 2016 13:48:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8zUcgaiLiy7T; Fri, 18 Mar 2016 13:48:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC4D212D675; Fri, 18 Mar 2016 13:48:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=16707; q=dns/txt; s=iport; t=1458334096; x=1459543696; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dxZQmZBFxuhEdWA2IB0YPT9NodkOJm2LEBxO/ZPkz7M=; b=j9sUe9MADRMIyPNVMOsjwOGHI0uOHvL6lrc58EtZHcdXy+ly4yio2cYu ElMAf8zo7NYBEGoS/XSj0qCb7FFuYhw0Mao6cGxLGbsRt/NEe11K6/b43 r1VbueeGvAFfW8MsPJ31f+rjbu2+S8lOZePQkSW5l7+eAUPgV1+XEzLC6 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C3BwBmaOxW/xbLJq1egniBH3IGhBqxE?= =?us-ascii?q?IZrFwEJhWwCgX0BAQEBAQFlJ4RCAQEEAQEBZAcLEAIBCA4xBycLFBECBAENBYg?= =?us-ascii?q?nDsBmAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGHoNFf4RphSkFkwSEUwGFcIgTg?= =?us-ascii?q?WWESohYjwUBYoIDGYFJaollAX0BAQE?=
X-IronPort-AV: E=Sophos;i="5.24,356,1454976000"; d="scan'208,217";a="634567904"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Mar 2016 20:48:13 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u2IKmCK0010552 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Mar 2016 20:48:13 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 18 Mar 2016 16:48:11 -0400
Received: from ([]) by ([]) with mapi id 15.00.1104.009; Fri, 18 Mar 2016 16:48:11 -0400
From: "Tarek Saad (tsaad)" <>
To: Lou Berger <>, "" <>, "" <>
Thread-Topic: [mpls] progressing draft-mtaillon-mpls-summary-frr-rsvpte
Thread-Index: AQHQ8TXlmJdk7DAXIkSUSayQf4h+fA==
Date: Fri, 18 Mar 2016 20:48:11 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D311DF5888F62tsaadciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [mpls] progressing draft-mtaillon-mpls-summary-frr-rsvpte
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 18 Mar 2016 20:48:19 -0000

Hi Lou/WG,

We have uploaded a new revision of the draft to incorporate the change needed to carry the Summary FRR information inside the (extended) Association Object.

We also looked into your comment about considering usage of existing PRIMARY_PATH_ROUTE object in place of the newly proposed SUMMARY_FRR_BYPASS object. The only concern we had with this was the PRIMARY_PATH_ROUTE object is
defined with a class value of the form 0bbbbbbb, and receiving nodes along the path (of the bypass LSP in our case) that do not support this object MUST return a PathErr (as described in RFC4872).
This may impact backward compatibility, so we’ve kept the new SUMMARY_FRR_BYPASS  object until consensus is reached.


On 2015-10-13, 3:18 PM, "Lou Berger" <<>> wrote:

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


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.


On 2015-09-25, 8:20 AM, "Lou Berger" <<>> wrote:

    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"
<<> on behalf of<>> wrote:

I have some comments on the proposed mechanism (I have no opinion on
utility or likely implementation):


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.


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



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.


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
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 mailing list<>