[Teas] Suresh Krishnan's No Objection on draft-ietf-teas-rsvp-te-srlg-collect-06: (with COMMENT)

"Suresh Krishnan" <suresh.krishnan@ericsson.com> Wed, 15 June 2016 20:10 UTC

Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: teas@ietf.org
Delivered-To: teas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9159212DB96; Wed, 15 Jun 2016 13:10:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.22.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160615201015.26201.90263.idtracker@ietfa.amsl.com>
Date: Wed, 15 Jun 2016 13:10:15 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/UWVAsUycN3iRMOaLO6RQQPwtXHo>
Cc: teas-chairs@ietf.org, draft-ietf-teas-rsvp-te-srlg-collect@ietf.org, teas@ietf.org, vbeeram@juniper.net
Subject: [Teas] Suresh Krishnan's No Objection on draft-ietf-teas-rsvp-te-srlg-collect-06: (with COMMENT)
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 15 Jun 2016 20:10:15 -0000

Suresh Krishnan has entered the following ballot position for
draft-ietf-teas-rsvp-te-srlg-collect-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Adrian's explanation makes sense to me. I would have liked to see
something similar to be added in the draft to clarify the behavior, but I
leave it up to the authors/shepherds to decide if they want to do this or

In Section 5.1 when the SRLG collection request was contained in an
LSP_REQUIRED_ATTRIBUTES and the RRO would become too big, a node drops
the RRO from the Path message entirely. It is not clear what the next
node that receives this SRLG collection request without an RRO would need
to do as the spec only says that the RRO is inserted at the ingress. What
is the expected behavior here on the subsequent node?