IETF Logo Mail Archive

Re: [Teas] Adam Roach's No Objection on draft-ietf-teas-assoc-corouted-bidir-frr-06: (with COMMENT)

Adam Roach <adam@nostrum.com> Fri, 26 October 2018 19:29 UTC

Return-Path: <adam@nostrum.com>
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 91A9D130DFC; Fri, 26 Oct 2018 12:29:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 vEpMCHmREnjE; Fri, 26 Oct 2018 12:29:14 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E59E1130DF3; Fri, 26 Oct 2018 12:29:10 -0700 (PDT)
Received: from Svantevit.attlocal.net (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w9QJSxdT031595 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 26 Oct 2018 14:29:00 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.attlocal.net
To: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>, The IESG <iesg@ietf.org>
Cc: "teas-chairs@ietf.org" <teas-chairs@ietf.org>, "draft-ietf-teas-assoc-corouted-bidir-frr@ietf.org" <draft-ietf-teas-assoc-corouted-bidir-frr@ietf.org>, "teas@ietf.org" <teas@ietf.org>, Vishnu Beeram <vishnupavan@gmail.com>
References: <154044135034.6935.9705845215648477897.idtracker@ietfa.amsl.com> <A0B90E81-AA49-4758-8A04-314020862DBB@cisco.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <42b42822-c9a0-bc34-c875-e4f38ca60d20@nostrum.com>
Date: Fri, 26 Oct 2018 14:28:53 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <A0B90E81-AA49-4758-8A04-314020862DBB@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/dBt4RjCVEPvKcaYl9zPJJtDJ1A4>
Subject: Re: [Teas] Adam Roach's No Objection on draft-ietf-teas-assoc-corouted-bidir-frr-06: (with COMMENT)
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Fri, 26 Oct 2018 19:29:16 -0000

On 10/26/18 12:35 PM, Rakesh Gandhi (rgandhi) wrote:
>      Appendix A:
>      
>      >     0                   1                   2                   3
>      >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      >    |                    IPv4 LSP Source Address                    |
>      >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      >    |           Reserved            |            LSP-ID             |
>      >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      
>      What are implementors expected to set the "Reserved" bytes to?
>      
> <RG> Added: “The Reserved flags MUST be set to 0 on transmission and ignored when received.”


Are you sure that's right? If so, it's not clear how the recipient knows 
whether the Extended Association ID is in this format (as its use is a 
"may"), and whether it's safe to ignore them.  I would expect this to 
simply say that the Reserved bits are set to 0 on transmission without 
saying anything about reception. This isn't as much for the sake of the 
protocol (since the value doesn't really matter) as it is to help 
implementors out.

/a

v2.23.0 | Report a Bug | By Email