Re: [Teas] Suresh Krishnan's Discuss on draft-ietf-teas-rsvp-te-srlg-collect-06: (with DISCUSS)

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 15 June 2016 12:14 UTC

Return-Path: <adrian@olddog.co.uk>
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 732C112D512; Wed, 15 Jun 2016 05:14:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 W8qYFcbjCSzn; Wed, 15 Jun 2016 05:14:11 -0700 (PDT)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C95912D1B1; Wed, 15 Jun 2016 05:14:11 -0700 (PDT)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u5FCE7iA030624; Wed, 15 Jun 2016 13:14:07 +0100
Received: from 950129200 (jplon-nat11.juniper.net [193.110.55.11]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u5FCE5K1030611 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 15 Jun 2016 13:14:06 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Suresh Krishnan' <suresh.krishnan@ericsson.com>, 'The IESG' <iesg@ietf.org>
References: <20160615060510.31650.96154.idtracker@ietfa.amsl.com>
In-Reply-To: <20160615060510.31650.96154.idtracker@ietfa.amsl.com>
Date: Wed, 15 Jun 2016 13:14:04 +0100
Message-ID: <061401d1c6ff$691d67f0$3b5837d0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHl6l5RmNszh+8rEezKmluy1aDGiJ/CKYYw
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22392.006
X-TM-AS-Result: No--15.545-10.0-31-10
X-imss-scan-details: No--15.545-10.0-31-10
X-TMASE-MatchedRID: 1GZI+iG+Mtei+SMpuaYbak+4wmL9kCTxgQP483M95wGhp/BDk6hAwNnf JrUSEbFDoZjv0XwCLb2Ex5sfYRQJa/9GLKYqqS4o8eSmTJSmEv1R3sGN+j7mNFvvN5s+yN4xWio bvLavUWLL38Wa3RBPDLiFmZjfkzdPi2RWFwdAkVm8coKUcaOOvdTkF1o+FKN6xe3blg14hRLGHN R8XFwgT8IXl3iP70Q4EVLFfYn/K/f7OgBbxHXmX3BRIrj8R47FyeUl7aCTy8jIvQIyugvKdcHvj lW1+MPbti/1sKBS7T5rLDRAwaKhuCqZtLrLGImpqbg9uWhLYLd1k+gP1XamtJsoi2XrUn/JyeMt MD9QOgAfACoClnjRoWLHjeGkjh9X3QfwsVk0UbtuRXh7bFKB7hhYtypQF47BCn/FQUwoX6i9LrD Zr6/scohFvmvGwcu2H8FerAT0dJY=
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/bW8S0XYdM0wdS8K2-LC4CtASNRE>
Cc: teas-chairs@ietf.org, draft-ietf-teas-rsvp-te-srlg-collect@ietf.org, teas@ietf.org, vbeeram@juniper.net
Subject: Re: [Teas] Suresh Krishnan's Discuss on draft-ietf-teas-rsvp-te-srlg-collect-06: (with DISCUSS)
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: adrian@olddog.co.uk
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 12:14:14 -0000

Suresh,

I think that if an RRO causes an RSVP-TE message to get full then it is a pretty
grim situation.

However, 3209 says...

   If the newly added subobject causes the RRO to be too big to fit in a
   Path (or Resv) message, the RRO object SHALL be dropped from the
   message and message processing continues as normal. A PathErr (or
   ResvErr) message SHOULD be sent back to the sender (or receiver).  An
   error code of "Notify" and an error value of "RRO too large for MTU"
   is used.  If the receiver receives such a ResvErr, it SHOULD send a
   PathErr message with error code of "Notify" and an error value of
   "RRO notification".

Does that answer you?

Cheers,
Adrian

> -----Original Message-----
> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Suresh Krishnan
> Sent: 15 June 2016 07:05
> To: The IESG
> 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 Discuss on
draft-ietf-teas-rsvp-te-srlg-collect-
> 06: (with DISCUSS)
> 
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-teas-rsvp-te-srlg-collect-06: Discuss
> 
> 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:
> https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-collect/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 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?
> 
> 
> 
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas