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 17:35 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 E141012870E; Fri, 26 Oct 2018 10:35:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.971
X-Spam-Level:
X-Spam-Status: No, score=-14.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 egQZxQyGG_3A; Fri, 26 Oct 2018 10:35:08 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BED0D120072; Fri, 26 Oct 2018 10:35:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5470; q=dns/txt; s=iport; t=1540575307; x=1541784907; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nljo/WlEDaRJmdtcsWcBt3PBNysXro38ys27zTKNVms=; b=BobXjo1BKAqKdW4kKt3ZQO5+UTmTAjPhrgw2h8xXhAKGEfngRjstlI3s uVVxJDydR5Bdcu4foFky1bUTmnqD4qM5nYd1CQLjCQCb/yd+KZ6cqwYEx Syk2RxtKrJcQz7o850NmyjS/s0bFfkz7uXg847tz4X9xE8y1AKSBoIOb9 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAAChT9Nb/4wNJK1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBVS9mfygKg2uIGIwYgWglg0CTXRSBZgsBASW?= =?us-ascii?q?ERwIXgwEhNA0NAQMBAQIBAQJtHAyFOwEEASMRRRACAQgaAiYCAgIwFRACBAE?= =?us-ascii?q?NBYMhAYF5CA+mGYEuhD5AhRsFgQuKXReBQT+BEScME4JMgxsCAQIBgSoBEgE?= =?us-ascii?q?2IQKCSoJXAoh4lgcJAoZngx+GdxiBUoR3iXyMbYl+AhEUgSYdOGRYEQhwFWU?= =?us-ascii?q?BgkGCIwMXEohKhT5vAYsFgR+BHwEB?=
X-IronPort-AV: E=Sophos;i="5.54,428,1534809600"; d="scan'208";a="471909070"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2018 17:35:06 +0000
Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id w9QHZ6cL000627 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Oct 2018 17:35:06 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 26 Oct 2018 12:35:06 -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 12:35:05 -0500
From: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
To: Adam Roach <adam@nostrum.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-teas-assoc-corouted-bidir-frr@ietf.org" <draft-ietf-teas-assoc-corouted-bidir-frr@ietf.org>, Vishnu Beeram <vishnupavan@gmail.com>, "teas-chairs@ietf.org" <teas-chairs@ietf.org>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: Adam Roach's No Objection on draft-ietf-teas-assoc-corouted-bidir-frr-06: (with COMMENT)
Thread-Index: AQHUbBpbGC9w8/A56kmQwzRvrZ2uj6Ux3QWA
Date: Fri, 26 Oct 2018 17:35:05 +0000
Message-ID: <A0B90E81-AA49-4758-8A04-314020862DBB@cisco.com>
References: <154044135034.6935.9705845215648477897.idtracker@ietfa.amsl.com>
In-Reply-To: <154044135034.6935.9705845215648477897.idtracker@ietfa.amsl.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: <0020C779AC06C647AD796169E7B6EB4F@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.29, xch-aln-019.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Vur8uQWp2Aaf5d58H5Xce_5zhMY>
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 17:35:10 -0000

Thank you Adam for the review. Please see replies inline with <RG>…

On 2018-10-25, 12:22 AM, "Adam Roach" <adam@nostrum.com>; wrote:

    Adam Roach has entered the following ballot position for
    draft-ietf-teas-assoc-corouted-bidir-frr-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:
    https://datatracker.ietf.org/doc/draft-ietf-teas-assoc-corouted-bidir-frr/
    
    
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    
    Thanks for the work everyone did on this document.
    
    ---------------------------------------------------------------------------
    
    Please expand "LSP" in the abstract.
    
<RG> Added.

    ---------------------------------------------------------------------------
    
    §3.3:
    
    >  In this example, the mid-point node D may mistakenly associate LSP1
    >  with the reverse LSP4 instead of the reverse LSP3 due to the matching
    >  (Extended) ASSOCIATION Objects.
    
    This doesn't seem right to me. LSP1 and LSP3 appear to be forward direction,
    while LSP2 and LSP4 appear to be reverse direction. It's also not clear how LSP1
    would be associated with LSP3 in this scenario, which is what this sentence
    seems to be saying might happen.
    
    Did this mean to say "...instead of the reverse LSP2..."?
    
<RG> Good catch, corrected.

    ---------------------------------------------------------------------------
    
    §4.2:
    
    >  In order to associate the LSPs unambiguously at a mid-point node (see
    >  Figure 3), the endpoint node MUST signal Extended ASSOCIATION Object
    >  and add unique Extended Association ID for each associated forward
    >  and reverse LSP pair forming the bidirectional LSP.  An endpoint node
    >  MAY set the Extended Association ID to the value shown in Appendix A.
    
    This phrasing is very confusing, as it implies that Appendix A is going to
    contain a value that can be used as an ID (which would be at odds with
    "unique"). Appendix A contains a format, not a value. I think what you mean is:
    
    "...MAY set the Extended Association ID to a value formatted according to the
    structure shown in Appendix A."

<RG> Updated.
    
    ---------------------------------------------------------------------------
    
    Appendix A:
    
    >  Extended Association ID in the Extended ASSOCIATION Object [RFC6780]
    >  can be set to the value shown in the following example to uniquely
    
    Same comment as above regarding the distinction between "value" and "format".

<RG> Updated.
    
    ---------------------------------------------------------------------------
    
    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.”
    
Thanks,
Rakesh