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 18:05 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 43CF212D874; Wed, 15 Jun 2016 11:05:23 -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 IR6-6sTD95LW; Wed, 15 Jun 2016 11:05:21 -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 035DB12DAC7; Wed, 15 Jun 2016 11:05:18 -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 u5FI5GUT030256; Wed, 15 Jun 2016 19:05:16 +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 u5FI52x1030182 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 15 Jun 2016 19:05:14 +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> <061401d1c6ff$691d67f0$3b5837d0$@olddog.co.uk> <E87B771635882B4BA20096B589152EF643CFEA8F@eusaamb107.ericsson.se>
In-Reply-To: <E87B771635882B4BA20096B589152EF643CFEA8F@eusaamb107.ericsson.se>
Date: Wed, 15 Jun 2016 19:04:57 +0100
Message-ID: <06e801d1c730$76b2ec10$6418c430$@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+8rEezKmluy1aDGiAGicLx7Alc3Hyifor1+MA==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22394.001
X-TM-AS-Result: No--25.635-10.0-31-10
X-imss-scan-details: No--25.635-10.0-31-10
X-TMASE-MatchedRID: HXSqh3WYKfvDBNgbKIiiTARH1Nr7oERd/duHe/ZmXJlUjspoiX02F26T 1o/+JeeyD855hkFOPoI7Q+2cOF9ySnCbAkrOahe88eSmTJSmEv1R3sGN+j7mNFvvN5s+yN4xQaN K4ceW3Bzos4o6VBEFHcdpFXeohdg3+VdtpE9/9fZ17gHAyAFr00yQ5fRSh265YZW5+v55ji/PX0 VRgs+r+LeC0i/dYAE4vjOZZrV6XOOnykMun0J1wp4CIKY/Hg3AtOt1ofVlaoJ1wPk/GHGZA+JoF wTzAXDejaPj0W1qn0SQZS2ujCtcuA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/t8eVjHlrufQKB09Ri82qUr7vhq0>
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 18:05:23 -0000

Theoretically, only the end-points add RROs. Once an RRO is stripped it will not
be added back in (in practice, some domain boundaries might add RROs back in).
The para after the quoted one says that further refreshes should entirely remove
the RRO, but what is more likely to happen is that an alarm will be raised and
the LSP will be torn down. The operator will then go and look to see why his
signaling message grew so unbelievably large and will either fix the topology
bug, turn off some features, or shout at the vendor.

A

> -----Original Message-----
> From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com]
> Sent: 15 June 2016 18:27
> To: adrian@olddog.co.uk; 'The IESG'
> 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)
> 
> Hi Adrian,
> 
> On 06/15/2016 08:14 AM, Adrian Farrel wrote:
> > 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?
> 
> Not exactly. I had followed the same reference to this text as well. My
> question was more about what happens to the message that gets forwarded
> (due
> to the message processing continuing as normal) on the next node that gets
> the message with the SRLG collection flag set but without the RRO. Does it
> add an RRO? Does it drop the message? ...
> 
> Thanks
> Suresh
> 
> 
> =