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

"Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com> Fri, 26 October 2018 19:37 UTC

Return-Path: <rgandhi@cisco.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 CAC92130E18; Fri, 26 Oct 2018 12:37:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 ZpOs-4-hNvkQ; Fri, 26 Oct 2018 12:37:49 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DC1B130E16; Fri, 26 Oct 2018 12:37:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2140; q=dns/txt; s=iport; t=1540582669; x=1541792269; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ixXckPXWslJyWPNQRGDrcU1Sx6P0Sk6lbIFvVj3Bt88=; b=jzCF4mEjFZS8GTat5lQBWm3dwm7K5108cPzc3z9605pRf/v5/KQ6CHQv qPt9dt6T/GnDWjlk0lv24eQwzmHkAKZp9Uinkjlue10k6nn2j5bXSHcg/ NGzs2sj2niSYMNAk6Xj4axYnYRL914oJ8ErRYQEWtJAclnq/pNfm96XRC A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAADja9Nb/5FdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUgMBAQEBAQsBgVUvgWUoCoNrlDGCDZcdgXoLAQGEbAI?= =?us-ascii?q?XgwEhNQwNAQMBAQIBAQJtKIU7AQUjEUUQAgEIGAICJgICAjAVEAIEAQ0FgyG?= =?us-ascii?q?CAqZygS6KH4ELilwXgUE/gREnH4JMhRUjgkoxgiYCnn8JApB9GJBFlmsCERS?= =?us-ascii?q?BJh8BNYFVcBVlAYJBgiMaEo4Ib4wfgR8BAQ?=
X-IronPort-AV: E=Sophos;i="5.54,429,1534809600"; d="scan'208";a="253994265"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2018 19:37:48 +0000
Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w9QJbmPD005367 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Oct 2018 19:37:48 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 26 Oct 2018 14:37:47 -0500
Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1395.000; Fri, 26 Oct 2018 14:37:47 -0500
From: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
To: Adam Roach <adam@nostrum.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>
Thread-Topic: Adam Roach's No Objection on draft-ietf-teas-assoc-corouted-bidir-frr-06: (with COMMENT)
Thread-Index: AQHUbBpbGC9w8/A56kmQwzRvrZ2uj6Ux3QWAgABi2oD//79tAA==
Date: Fri, 26 Oct 2018 19:37:47 +0000
Message-ID: <4556B6CE-2DB1-48B6-A2C6-242CEBE6B8FE@cisco.com>
References: <154044135034.6935.9705845215648477897.idtracker@ietfa.amsl.com> <A0B90E81-AA49-4758-8A04-314020862DBB@cisco.com> <42b42822-c9a0-bc34-c875-e4f38ca60d20@nostrum.com>
In-Reply-To: <42b42822-c9a0-bc34-c875-e4f38ca60d20@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1d.0.161209
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.249.236]
Content-Type: text/plain; charset="utf-8"
Content-ID: <FC077231AE509C4084725346BF98C867@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.30, xch-aln-020.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/KtU5UIW0EQVUO38hQcmv0oHGo2k>
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:37:51 -0000

Hi Adam,

It’s a good point and agree. Updated the draft accordingly.

Thanks,
Rakesh


On 2018-10-26, 3:28 PM, "Adam Roach" <adam@nostrum.com>; wrote:

    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