Re: Alia Atlas' Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS and COMMENT)
"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Tue, 03 May 2016 16:13 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 4D2A612D9E2; Tue, 3 May 2016 09:13:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.516
X-Spam-Level:
X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 L5dZdZ7iztwF; Tue, 3 May 2016 09:13:17 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A18E12DA09; Tue, 3 May 2016 09:13:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45589; q=dns/txt; s=iport; t=1462291995; x=1463501595; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hdYwSzJRZGiuBrPb7UksPY1n4zLg1Ntp7L4a/h/sX08=; b=TWBjyMKinMg7FeGlx/87CYIiF7apCxXm3i8Uc2EtlUSLUg43PVpuwIyt /Vj0kBlGY4dDZ8k0RYbQB3MbVGttOyRKsK2MSDvGAtbC89j1Khzsd0CMR iI6A7zGIBRXEQR5v8v+1d6a4r8ktpf/kq0r6/Sli0knyviVwhGOmNzutZ g=;
X-Files: draft-ietf-bfd-seamless-base-alia-diff.txt, signature.asc : 11039, 841
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DCAgC7zChX/5ldJa1VCoM4U30GriqLYg6BdSKFbgKBPTgUAQEBAQEBAWUnhEEBAQEDARoBCFYFCwIBCA4KIAcDAgIhERQRAgQOBQ4Nh3oDCggOq0yMRQ2EOwEBAQEBAQEBAQEBAQEBAQEBAQEBAQ0IhiCBdgiBTIEDgkOBTgYLAYMcK4IuBYd4iyyDZF0xAYMngWdthiWBd4FohE2DKYU0h1GHYAEeAUOCNoE1bAGGfQkXBBt/AQEB
X-IronPort-AV: E=Sophos;i="5.24,573,1454976000"; d="asc'?txt'?scan'208,217";a="269053757"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2016 16:13:12 +0000
Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u43GDCvu032288 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 16:13:12 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 12:13:11 -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; Tue, 3 May 2016 12:13:11 -0400
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Alia Atlas <akatlas@gmail.com>
Subject: Re: Alia Atlas' Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS and COMMENT)
Thread-Topic: Alia Atlas' Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS and COMMENT)
Thread-Index: AQHRpLkIQl1ke+WjZEO22I9fWz1zPp+mfzmAgAERloCAABYsAA==
Date: Tue, 03 May 2016 16:13:11 +0000
Message-ID: <059ECD31-C883-4721-8FA1-3FCEE9FCE1AC@cisco.com>
References: <20160502212434.15622.98408.idtracker@ietfa.amsl.com> <E599B095-A047-4657-B068-C5647E736F34@cisco.com> <CAG4d1re6HowYY1hZ+0at4yiGaZ9kb=EvoNdKe6BBoqV++Rp=sg@mail.gmail.com>
In-Reply-To: <CAG4d1re6HowYY1hZ+0at4yiGaZ9kb=EvoNdKe6BBoqV++Rp=sg@mail.gmail.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.150.48.199]
Content-Type: multipart/signed; boundary="Apple-Mail=_31096B15-F84E-4396-939B-5F178DD052E3"; protocol="application/pgp-signature"; micalg="pgp-sha256"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-bfd/9i_IGAyV1mAf5fFJg8IEV-yDT1E>
X-Mailman-Approved-At: Tue, 03 May 2016 09:55:36 -0700
Cc: The IESG <iesg@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "draft-ietf-bfd-seamless-base@ietf.org" <draft-ietf-bfd-seamless-base@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: Tue, 03 May 2016 16:13:25 -0000
Hi, Alia, Thanks for the response! We are on the exact same page regarding items #1 and #2. For item #3, we really want to modularize the specs and not tie the -base to the transports. Note that we mention “UDP” but also “associated channel type”. For #3, here’s the change I implemented: S-BFD packet MUST be demultiplexed with lower layer information - (e.g., dedicated destination UDP port, associated channel type). - Following procedure SHOULD be executed on both initiator and - reflector. + (e.g., dedicated destination UDP port [I-D.ietf-bfd-seamless-ip], + associated channel type [I-D.ietf-pals-seamless-vccv]). Following + procedure SHOULD be executed on both initiator and reflector. And please find attached full diffs addressing all the Discuss points. Thanks! — Carlos. > On May 3, 2016, at 10:53 AM, Alia Atlas <akatlas@gmail.com> wrote: > > Hi Carlos, > > On Mon, May 2, 2016 at 6:34 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com <mailto:cpignata@cisco.com>> wrote: > Hi, Alia, > > Thanks for your review and for bringing up these issues — please see inline. > > > On May 2, 2016, at 5:24 PM, Alia Atlas <akatlas@gmail.com <mailto:akatlas@gmail.com>> wrote: > > > > Alia Atlas has entered the following ballot position for > > draft-ietf-bfd-seamless-base-09: 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 <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-base/ <https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/> > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > a) In Sec 7.2.3: "If the SBFDReflector is generating a response S-BFD > > control packet for a local entity that is in > > service, then "state" in response BFD control packets MUST be set > > to UP." > > So far, it looked like the SBFDReflector only sends BFD control > > packets in response to receiving such packets > > from SBFDInitiators. This paragraph (not just copied) does not > > clearly describe the desired behavior. If the > > monitored local entity is "temporarily out of service", does the > > SBFDReflector respond back to the SBFDInitiator > > with 2 BFD control packets - one indicating UP (as a MUST) and then > > the next indicating ADMINDOWN? Is the > > SBFDReflector expected to store a list of active SBFDInitiators and > > proactively send BFD control packets indicating > > ADMINDOWN? Please clarify in non-trivial detail. > > The way in which that particular bullet in that subsection is written can be a bit confusing. > > First, you are right that the SBFDReflector only sends packets in response to S-BFD control packets from the SBFDInitiators. This is clearly spelled out in Section 5, and in other places that explain how the reflector is stateless. > > The SBFDReflector only response and does not stores a list of SBFDInitiators to proactively send S-BFD packets (see Section 5). Further, it does not respond with two packets. (UP and ADMINDOWN). > > I think this can be rewritten to better explain what happens, as follows: > > OLD: > o If the SBFDReflector wishes to communicate to some or all > SBFDInitiators that monitored local entity is "temporarily out of > service", then S-BFD control packets with "state" set to ADMINDOWN > are sent to those SBFDInitiators. The SBFDInitiators, upon > reception of such packets, MUST NOT conclude loss of reachability > to corresponding remote entity, and MUST back off packet > transmission interval for the remote entity to an interval no > faster than 1 second. If the SBFDReflector is generating a > response S-BFD control packet for a local entity that is in > service, then "state" in response BFD control packets MUST be set > to UP. > > NEW: > o If the SBFDReflector, upon receiving an S-BFD control packet from > an SBFDInitiators, wishes to communicate to those > SBFDInitiators that a monitored local entity is "temporarily out of > service", then an S-BFD control packet with "state" set to ADMINDOWN > is sent in response to those SBFDInitiators. The SBFDInitiators, upon > reception of such packets, MUST NOT conclude loss of reachability > to corresponding remote entity, and MUST back off packet > transmission interval for the remote entity to an interval no > faster than 1 second. If, on the other hand, the SBFDReflector is generating a > response S-BFD control packet for a local entity that is in > service, then "state" in response BFD control packets MUST be set > to UP. > > Is that more clear? > > Slightly - but what about: > > "When the SBFDReflector receives an S-BFD control packet from an SBFDInitiator, > then the SBFDReflector needs to determine what state to send in the response S-BFD > control packet. If the monitored local entity is in service, then the "state" MUST be > set to UP. However, if the monitored local entity is "temporarily out of service" for > rapidly processing S-BFD packets, for instance due to an overload, then the "state" > SHOULD be set to ADMINDOWN. The SBFDReflector SHOULD send a response > S-BFD control packet. > > When an SBFDInitiator receives a response S-BFD control packet, if the state specified > is ADMINDOWN, the SBFDInitiator MUST NOT conclude loss of reachability > to corresponding remote entity, and MUST back off packet transmission interval for the > remote entity to an interval no faster than 1 second. " > > Either wording or a mixture is just fine. > > > > > b) Appendix A: The looping problem is nicely defined but the text still > > discusses three potential solutions; clearly the > > use of the D bit has been chosen. It would be much nicer to have the > > justification in line, but for this discuss - the > > unselected alternatives don't belong. > > > > Sorry I’m not sure I understand fully your point. Are you suggesting we mention in the actual reason for the D-bit procedures outside the Appendix (although the procedures for the D bit are explained in Section 6.2, 7.2.2, 7.2.3, 7.3.2, and 7.2.2), while still leave the Appendix as-is? > > If so we can do that, but want to confirm. > > I'm suggesting that you mention the reason for the D-bit procedures outside the Appendix and remove the Appendix. Alternately, keep the Appendix but remove discussion of the other ways the problem could have been solved and add a reference from the D-bit procedures to the Appendix. > > Once this is an RFC, it doesn't matter what the other possible and unselected design choices were. > > > c) Sec 7.2.1: " S-BFD packet MUST be demultiplexed with lower layer > > information > > (e.g., dedicated destination UDP port, associated channel type)." > > Where precisely is this defined or described? Is there an allocation > > for a dedicated UDP > > port for S-BFD? I don't see any normative reference to such. In > > particular, since the format > > for an S-BFD control packet is exactly the same as for BFD and since only > > this demultiplexing > > with lower layer information is used to tell the difference between S-BFD > > and BFD packets, > > this document requires more specifics. > > > > This is similar to RFC 5880 and RFC 5881. The actual S-BFD applications specify this. For example, bfd-seamless-ip defines the UDP port. We purposely do not want to have the specification (either explicitly or normatively pointed to) from this document, as this is just the base specification. > > Why? Unlike RFC 5880, this document mentions UDP ports as an example of a demultiplexer. > While I do understand that BFD can run with different transports, it is useful to clearly articulate > one use transport that has enough information to be actually implemented. In this case, that's > just a normative reference to another document progressing at the same time. > > I can't get too worked up about normative vs. informative references in general - the guideline I > use is whether an implementor would need to read the reference to properly implement the > functionality. > > If you feel extremely strongly that the reference must be informative, I'm not going to dig in my > heels - but PLEASE put a reference by the mention of the UDP port. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > 1) In the last paragraph of Sec 4.2: " Even when following the separate > > discriminator pool approach, > > collision is still possible between one S-BFD application to another > > S-BFD application, that may be using different values and algorithms > > to derive S-BFD discriminator values. If the two applications are > > using S-BFD for a same purpose (e.g., network reachability), then the > > colliding S-BFD discriminator value can be shared. If the two > > applications are using S-BFD for a different purpose, then the > > collision must be addressed. How such collisions are addressed is > > outside the scope of this document." > > > > Sec 4.1 talks about the need for the S-BFD Discriminator to be unique > > within an Administrative Domain. > > I don't see any details of that addressed here. What is addressed > > here seems to be the case for multiple > > S-BFD discriminators applying to the same node - which is specifically > > discouraged at the end of Sec 3. > > Rather than simply describing the issue as "outside the scope of this > > document", please either describe it > > as "future work and multiple S-BFD discriminators is discouraged" or > > add a reference. > > > > Good point, will do. > > > 2) In Sec 6.1: "bfd.SessionType:" is defined but the only possible values > > are for SBFD. Is it possible for a BFD > > session to still use the same bfd structure? I don't see a value for > > SessionType there; I'd expect to see at least > > a value for the original BFD session and possible an undefined or > > unspecified value for future proofing. > > > > > > Traditional BFD does not use this state variable. That’s why we don’t need to define a value for BFD. However, future specs can when it is relevant (e.g, using BFD for various types as opposed to S-BFD), as for example bfd-multipoint. > > Right - I understand that. I'm thinking a bit from the implementation perspective. If I have the same data-structures and similar logic for BFD and S-BFD, then there'll be a bfd.SessionType even for BFD sessions that don't need it. Clarifying a value of "Unused" or "Classical BFD" gives clarity that one > of the S-BFD options doesn't need to be chosen. > > This is just a comment. It's up to your best judgement. > > Thanks, > Alia > > > Please let us know your thoughts on the responses above, and we can send out diffs. > > Thanks! > > — Carlos. > > >
- Alia Atlas' Discuss on draft-ietf-bfd-seamless-ba… Alia Atlas
- Alia Atlas' Discuss on draft-ietf-bfd-seamless-ba… Alia Atlas
- Re: Alia Atlas' Discuss on draft-ietf-bfd-seamles… Carlos Pignataro (cpignata)
- Re: Alia Atlas' Discuss on draft-ietf-bfd-seamles… Alia Atlas
- Re: Alia Atlas' Discuss on draft-ietf-bfd-seamles… Alia Atlas
- Re: Alia Atlas' Discuss on draft-ietf-bfd-seamles… Carlos Pignataro (cpignata)
- Re: Alia Atlas' Discuss on draft-ietf-bfd-seamles… Carlos Pignataro (cpignata)