Re: Alia Atlas' Discuss on draft-ietf-bfd-seamless-ip-04: (with DISCUSS)

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Mon, 02 May 2016 23:22 UTC

Return-Path: <cpignata@cisco.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10BF12D67B; Mon, 2 May 2016 16:22:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Level:
X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 864kOqBcMPLn; Mon, 2 May 2016 16:22:31 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1106B12D111; Mon, 2 May 2016 16:22:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5069; q=dns/txt; s=iport; t=1462231351; x=1463440951; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zfy5nBjlGR2e7ZVXdztBQ0K7B3FU6JQKX/qzO/TqCyE=; b=ecMO2D3/M/QXaPesghaQQijQx0o/AmYDpf4mDN2qEmUSLfXgftS8O8ZF 26ZCNUkWHgXxKnfTKpE+FWfz/9D6N9o2sLhBiDKYqMNJKYubzIK4ePJXo NPEorTgDlv1aJ6TXKkOuxBc++sN2uuynUMuoNakLYhEXeYurcFFlnS6IN U=;
X-Files: signature.asc : 841
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DUAgB14CdX/40NJK1UCoM4U30GrhSJUoIPDoF2IoVuAoE3OBQBAQEBAQEBZSeEQQEBAQMBI1YFCwIBCA4KKgICIRElAgQOBQ6IBwMKCA6qCow+DYROAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQQEhiGBdgiCToJBgU4GCwFOgk4rgisFh3ePbDEBgyeBZ22GJYF3gWeETYhdh1GHXwEeAUODa2wBh0oHFwcYfwEBAQ
X-IronPort-AV: E=Sophos;i="5.24,569,1454976000"; d="asc'?scan'208";a="268096778"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 May 2016 23:22:30 +0000
Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u42NMTcp023281 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 May 2016 23:22:30 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 May 2016 19:22:29 -0400
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Mon, 2 May 2016 19:22:28 -0400
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Alia Atlas <akatlas@gmail.com>
Subject: Re: Alia Atlas' Discuss on draft-ietf-bfd-seamless-ip-04: (with DISCUSS)
Thread-Topic: Alia Atlas' Discuss on draft-ietf-bfd-seamless-ip-04: (with DISCUSS)
Thread-Index: AQHRpMGsMRcZflh1j0ieWahk11MJYJ+mjIiA
Date: Mon, 02 May 2016 23:22:28 +0000
Message-ID: <52C94004-5548-4701-AA81-EBF8D5EC1BDD@cisco.com>
References: <20160502222627.15846.1446.idtracker@ietfa.amsl.com>
In-Reply-To: <20160502222627.15846.1446.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.169.162]
Content-Type: multipart/signed; boundary="Apple-Mail=_553E4443-2F42-4011-AA25-417653C74BEC"; protocol="application/pgp-signature"; micalg="pgp-sha256"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-bfd/JD_Q6cescU6ZKsmvpZlIr8dmc90>
Cc: "draft-ietf-bfd-seamless-ip@ietf.org" <draft-ietf-bfd-seamless-ip@ietf.org>, The IESG <iesg@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "bfd-chairs@ietf.org" <bfd-chairs@ietf.org>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 May 2016 23:22:32 -0000

Hi Alia,

Thanks for the review and for these! Please see inline.

> On May 2, 2016, at 6:26 PM, Alia Atlas <akatlas@gmail.com> wrote:
> 
> Alia Atlas has entered the following ballot position for
> draft-ietf-bfd-seamless-ip-04: 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-bfd-seamless-ip/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I think that these are both simple fast issues to resolve.
> 
> 1) Sec 3: "This document defines only the UDP port value
>   for the S-BFD Echo function.  The source port and the procedures for
>   the S-BFD Echo function are outside the scope of this document."
> Please add a reference to the S-BFD base document for defining where the
> procedures are found.
> 
> Where, precisely, is the source port defined?  It wasn't in the S-BFD
> base
> document.  This seems like a hole.  Can you please clarify?

This is done exactly as in RFC 5881, purposefully. I can add a clarifying sentence like:

OLD:
   This document defines only the UDP port value
   for the S-BFD Echo function.  The source port and the procedures for
   the S-BFD Echo function are outside the scope of this document.

NEW:
   S-BFD echo follows the BFD echo definitions of [RFC 5881].
   Consequently, this document defines only the UDP port value
   for the S-BFD Echo function; the source port and the procedures for
   the S-BFD Echo function are outside the scope of this document.


> 
> 2) Sec 4:  " If the port is not 7784, then the packet MUST be looked up
> to locate
>   a corresponding SBFDInitiator session or classical BFD session based
>   on the value from the "your discriminator" field in the table
>   describing BFD discriminators. "
> 
> I assume that you mean that UDP source port is used to look up the
> appropriate receiver.
> If that receiver handles BFD and S-BFD packets, then the "your
> discriminator" field is used
> to identify the BFD session.   PLEASE clarify that because this reads as
> if BFD is the only
> application that uses UDP.
> 

Indeed, very much so. I suggest:

OLD:
   If the port is not 7784, then the packet MUST be looked up to locate
   a corresponding SBFDInitiator session or classical BFD session based
   on the value from the "your discriminator" field in the table
   describing BFD discriminators.  If the located session is an
   SBFDInitiator, then the destination IP address of the packet SHOULD
   be validated to be for self.  If the packet is a classical BFD
   session, then the procedures from [RFC5880] apply.

NEW:
   If the port is not 7784, but the packet is demultiplexed to be for an
   SBFDInitiator, then the packet MUST be looked up to locate
   a corresponding SBFDInitiator session based
   on the value from the "your discriminator" field in the table
   describing BFD discriminators.  In that case,
   then the destination IP address of the packet SHOULD
   be validated to be for itself.  If the packet demultiplexes to a classical BFD
   session, then the procedures from [RFC5880] apply.

Would that work?

Thanks,

— Carlos.

> 
> 
>