RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim
Santosh P K <santoshpk@juniper.net> Sun, 23 November 2014 02:39 UTC
Return-Path: <santoshpk@juniper.net>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9E51A1A6A for <rtg-bfd@ietfa.amsl.com>; Sat, 22 Nov 2014 18:39:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 TIrh5HBfp8Dl for <rtg-bfd@ietfa.amsl.com>; Sat, 22 Nov 2014 18:39:10 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0118.outbound.protection.outlook.com [207.46.100.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455E21A1A66 for <rtg-bfd@ietf.org>; Sat, 22 Nov 2014 18:39:10 -0800 (PST)
Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB822.namprd05.prod.outlook.com (10.141.244.144) with Microsoft SMTP Server (TLS) id 15.1.26.15; Sun, 23 Nov 2014 02:39:08 +0000
Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Sun, 23 Nov 2014 02:39:08 +0000
From: Santosh P K <santoshpk@juniper.net>
To: "Nobo Akiya (nobo)" <nobo@cisco.com>, Marc Binderberger <marc@sniff.de>
Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim
Thread-Topic: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim
Thread-Index: Ac//wAdQ8oS8wTAIRaCZduflS+eKRACbC/IAAMCf94AADX0MAABVlhIAAALQ2tA=
Date: Sun, 23 Nov 2014 02:39:07 +0000
Message-ID: <4ecc79f51fdf4a59b8871dd8eed9d25d@CO2PR0501MB823.namprd05.prod.outlook.com>
References: <CECE764681BE964CBE1DFF78F3CDD3943F5279D0@xmb-aln-x01.cisco.com> <20141116220332392193.5ed69d25@sniff.de> <CECE764681BE964CBE1DFF78F3CDD3943F599138@xmb-aln-x01.cisco.com> <20141121002512713064.799b449a@sniff.de> <CECE764681BE964CBE1DFF78F3CDD3943F59FF47@xmb-aln-x01.cisco.com>
In-Reply-To: <CECE764681BE964CBE1DFF78F3CDD3943F59FF47@xmb-aln-x01.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [116.197.184.19]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB822;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB822;
x-forefront-prvs: 04041A2886
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(54094003)(24454002)(52544003)(13464003)(52604005)(199003)(51704005)(377454003)(41574002)(105586002)(106356001)(76576001)(99286002)(95666004)(21056001)(107046002)(230783001)(64706001)(561944003)(108616004)(40100003)(101416001)(93886004)(66066001)(33646002)(31966008)(120916001)(97736003)(46102003)(92566001)(20776003)(99396003)(122556002)(2656002)(86362001)(19580395003)(19580405001)(87936001)(74316001)(62966003)(77156002)(50986999)(54356999)(76176999)(4396001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB822; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/_N5GDWA3gAHjV0LHjQsRVJ8sYcw
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Sun, 23 Nov 2014 02:39:13 -0000
Nobo and Marc, I completely agree with having a separate document for alert discriminator and progress with use-case document. Thanks Santosh P K > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya > (nobo) > Sent: Sunday, November 23, 2014 6:46 AM > To: Marc Binderberger > Cc: rtg-bfd@ietf.org > Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim > > Hello BFD WG, > > Marc and I had some conversation on the topic of S-BFD alert discriminator > document structure, and converged on a direction. > > - We think that it is useful to describe both the problems and the solution for > the S-BFD alert discrimintor in a single document. > - We also think the S-BFD alert discriminator is more like an exception > mechanism, thus the mechanism should remain outside of the S-BFD base > document. > > Therefore, our converged recommendation to the WG is to keep the > extended use-cases and the alert discriminator mechanism in the draft- > akiya-bfd-seamless-alert-discrim. > > This also means that no further changes are needed in draft-ietf-bfd- > seamless-use-case, and the draft-ietf-bfd-seamless-use-case can progressed > forward if authors feel that it is ready. > > We would appreciate it if folks can chime in and state whether or not this is > an acceptable way forward. > > Thanks! > > -Nobo & Marc > > > -----Original Message----- > > From: Marc Binderberger [mailto:marc@sniff.de] > > Sent: Friday, November 21, 2014 3:25 AM > > To: Nobo Akiya (nobo) > > Cc: rtg-bfd@ietf.org > > Subject: RE: Seeking opinions on > > draft-akiya-bfd-seamless-alert-discrim > > > > Hello Nobo, > > > > (back from Hawaii or writing emails at the beach? ;-) > > > > > > > Your view is then: > > > > > > Instead of: > > > > > > (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case and > > > keep the alert discriminator mechanism in the > > > draft-akiya-bfd-seamless-alert-discrim. > > > > > > Do: > > > > > > (2) Keep the extended use-cases and alert discriminator mechanism in > > > the draft-akiya-bfd-seamless-alert-discrim. > > > > > > Or > > > > > > (3) Move the extended use-cases to draft-ietf-bfd-seamless-use-case > > > and move the alert discriminator mechanism to > > > draft-ietf-bfd-seamless- > > base. > > > > yes, exactly. > > > > > > > Whether the S-BFD packets with alert discriminator are handled in HW > > > or SW is an implementation choice. Similar to how IP router alert > > > option & router alert label are handled, I do see handling of S-BFD > > > packets with alert discriminator in the SW to be a reasonable > > > approach, in which case the HW instruction for S-BFD packets with > > > alert discriminator is to punt to SW for processing. > > > > > Personally, I tend to recommend that alert discriminators are > > > handled in the SW. Let's assume that you agree on this > > > (hypothetically). In that case, would you still recommend the alert > > > discriminator mechanism to be moved to the > > > draft-ietf-bfd-seamless-base or is it reasonable to keep it in the draft- > akiya-bfd-seamless-alert-discrim? > > > > > > That's probably where our different views come from :-) I would aim to > > simplify the main idea of the draft so it _can_ easily be implemented > > even in hardware. > > > > For the traceroute - my guess is TTL punts (if that mechanism to > > "deliver" is > > used) happen in software as many mechanism use this "trick" but if a > > hardware can handle TTL punts, it can handle the diag code as well. I > > don't see the document needs to adjust for the traceroute case. > > > > For a basic reflector task, having a zero discriminator as a default > > reflector discriminator would allow for very simple implementations > > (we discussed a while ago a fixed discriminator value for simple > > broadband modems, remember?). > > For more complex equipment and scenarios, keeping it in hardware > > instead of a software punt would maintain the ability of S-BFD to go up very > quickly. > > > > > > I tend to not see the zero discriminator as such a big exception, > > which may explain my idea to integrate it into the base document. And > > to keep it compatible to hardware implementations. > > Assuming you want to add more "special effects" in the future I can > > see why you have an extra document. I would propose to keep the > > zero-reflector mentally aligned :-) with the base document and > > accordingly designed to allow implementations to cover the zero-reflector > together with "normal" > > S-BFD > > (read: may be in hardware). > > > > > > > Ah, great catch. Yes we do not want "intermediate nodes" to pick up > > > S-BFD packets with alert discriminator. > > > > Good - makes life simpler :-) > > > > > > Regards, Marc > > > > > > On Fri, 21 Nov 2014 01:58:59 +0000, Nobo Akiya (nobo) wrote: > > > Hi Marc, > > > > > > Thanks for providing your view. > > > > > > Please see in-line. > > > > > >> -----Original Message----- > > >> From: Marc Binderberger [mailto:marc@sniff.de] > > >> Sent: Monday, November 17, 2014 1:04 AM > > >> To: Nobo Akiya (nobo) > > >> Cc: rtg-bfd@ietf.org > > >> Subject: Re: Seeking opinions on > > >> draft-akiya-bfd-seamless-alert-discrim > > >> > > >> Hello Nobo and BFD experts, > > >> > > >> giving this document a closer look for the first time (ahem ;-) I > > >> have a slightly different view. > > >> > > >> Having S-BFD use cases for the general S-BFD in an extra document > > >> does improve the overall discussion and documentation, simply > > >> because the base S-BFD is already complex enough, as are the use > cases. > > >> > > >> But for such a relatively small document splitting off the reason > > >> why the document exists is not improving the reading/understanding > > >> of this > > draft. > > >> Unless you decide to integrate the alert-discriminator document > > >> into the base document, then obviously you use the use-case > document. > > > > > > Your view is then: > > > > > > Instead of: > > > > > > (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case and > > > keep the alert discriminator mechanism in the > > > draft-akiya-bfd-seamless-alert-discrim. > > > > > > Do: > > > > > > (2) Keep the extended use-cases and alert discriminator mechanism in > > > the draft-akiya-bfd-seamless-alert-discrim. > > > > > > Or > > > > > > (3) Move the extended use-cases to draft-ietf-bfd-seamless-use-case > > > and move the alert discriminator mechanism to > > > draft-ietf-bfd-seamless- > > base. > > > > > > My thought was that (1) makes sense, but your view that (1) makes > > > all the S-BFD documents set more complex to understand is a valid > > > concern (it's always good to get fresh eyes on documents!). > > > > > >> > > >> > > >> For the integration of the technical aspect into the base document, > > >> I think this is an idea worth to discuss. At the end what you need > > >> is to add the rule for the zero discriminator to the reflector > > >> behaviour; we managed this for standard BFD, we should be able to > > >> do this for the reflector BFD as well > > >> :-) > > > > > > Whether the S-BFD packets with alert discriminator are handled in HW > > > or SW is an implementation choice. Similar to how IP router alert > > > option & router alert label are handled, I do see handling of S-BFD > > > packets with alert discriminator in the SW to be a reasonable > > > approach, in which case the HW instruction for S-BFD packets with > > > alert discriminator is to punt to SW for processing. > > > > > >> For the diagnostic codes I'm not sure; it will complicate hardware > > >> implementations (probably not a no-go problem though) and seems > > >> otherwise not add a real value IMHO. > > > > > > If one really wants to handle them in the HW, that's a possibility. > > > Although as you stated, it does complicate HW implementations and > > > this is another reason for SW based implementations. > > > > > >> > > >> So if there are already at this stage of S-BFD use case(s) for > > >> zero- discriminator to bring up (some) sessions then I would > > >> propose to consider the integration into the base document. This > > >> will also guarantee that the zero-discriminator handling is as fast > > >> as the "normal" reflection and is not on a slower exception path. > > > > > > Personally, I tend to recommend that alert discriminators are > > > handled in the SW. Let's assume that you agree on this > > > (hypothetically). In that case, would you still recommend the alert > > > discriminator mechanism to be moved to the > > > draft-ietf-bfd-seamless-base or is it reasonable to keep it in the draft- > akiya-bfd-seamless-alert-discrim? > > > > > >> > > >> > > >> > > >> I have a question: so far S-BFD packets would be received, not > > >> "picked out of the data stream". Receiving could be because the > > >> destination IP would match or would be 127/8, the TTL would be zero > > >> and so on. In the security section you say ... > > >> > > >> Conceptually the Alert Discriminator is similar to an IP Router Alert > > >> Option or an MPLS Router Alert Label. > > >> > > >> ... and I wonder if you expect a node to "pick" S-BFD traffic (to > > >> the > > >> reflector) with an alert-discriminator out of the data stream that > > >> otherwise would just pass this node? > > >> I guess you don't want but I want to make sure I understand it correctly. > > > > > > Ah, great catch. Yes we do not want "intermediate nodes" to pick up > > > S-BFD packets with alert discriminator. So the statement regarding > > > "Conceptually the Alert Discriminator is similar to an IP Router > > > Alert Option or an MPLS Router Alert Label" should be re-stated and > clarified. > > > > > > Thanks! > > > > > > -Nobo > > > > > >> > > >> > > >> Regards, Marc > > >> > > >> > > >> > > >> > > >> On Fri, 14 Nov 2014 04:04:08 +0000, Nobo Akiya (nobo) wrote: > > >>> [Speaking as an individual S-BFD contributor] > > >>> > > >>> Hi BFD WG, > > >>> > > >>> There were couple of questions I need your input on > > >>> draft-akiya-bfd-seamless-alert-discrim. > > >>> > > >>> > > >>> (1) Should the "extended" S-BFD use cases move to > > >>> draft-ietf-bfd-seamless-use-case? > > >>> > > >>> My opinion is yes. Once the "extended" S-BFD use cases have been > > >>> incorporated into draft-ietf-bfd-seamless-use-case, then we should > > >>> try to move draft-ietf-bfd-seamless-use-case forward. > > >>> > > >>> How does the WG feel about this? > > >>> > > >>> > > >>> (2) Should the alert discriminator proposal move to > > >>> draft-ietf-bfd-seamless-base? > > >>> > > >>> My opinion is no . Instead we should position this as an optional > > >>> feature of S-BFD (hence separate document than the base), > > >>> especially considering we likely need to think through additional > > >>> security concerns > > >> raised by this. > > >>> > > >>> A question was raised by Greg on how does a node find out if the > > >>> target supports the optional alert discriminator or not. We can > > >>> define a mandatory diagnostic value that must be implemented when > > >>> the alert discriminator is implemented. One can send an S-BFD > > >>> control packet with the alert discriminator with this diagnostic > > >>> value to check if the target supports the alert discriminator > mechanism. > > >>> > > >>> How does the WG feel about this? > > >>> > > >>> > > >>> Thanks! > > >>> > > >>> -Nobo > > >>> > > >
- Seeking opinions on draft-akiya-bfd-seamless-aler… Nobo Akiya (nobo)
- RE: Seeking opinions on draft-akiya-bfd-seamless-… Santosh P K
- RE: Seeking opinions on draft-akiya-bfd-seamless-… Nobo Akiya (nobo)
- RE: Seeking opinions on draft-akiya-bfd-seamless-… Gregory Mirsky
- Re: Seeking opinions on draft-akiya-bfd-seamless-… MALLIK MUDIGONDA (mmudigon)
- RE: Seeking opinions on draft-akiya-bfd-seamless-… Nobo Akiya (nobo)
- RE: Seeking opinions on draft-akiya-bfd-seamless-… Nobo Akiya (nobo)
- Re: Seeking opinions on draft-akiya-bfd-seamless-… Marc Binderberger
- RE: Seeking opinions on draft-akiya-bfd-seamless-… Nobo Akiya (nobo)
- RE: Seeking opinions on draft-akiya-bfd-seamless-… Marc Binderberger
- RE: Seeking opinions on draft-akiya-bfd-seamless-… Nobo Akiya (nobo)
- RE: Seeking opinions on draft-akiya-bfd-seamless-… Santosh P K
- RE: Seeking opinions on draft-akiya-bfd-seamless-… Gregory Mirsky
- Re: Seeking opinions on draft-akiya-bfd-seamless-… Manav Bhatia
- Re: Seeking opinions on draft-akiya-bfd-seamless-… MALLIK MUDIGONDA (mmudigon)
- RE: Seeking opinions on draft-akiya-bfd-seamless-… Mach Chen
- RE: Seeking opinions on draft-akiya-bfd-seamless-… Nobo Akiya (nobo)
- Re: Seeking opinions on draft-akiya-bfd-seamless-… Sam Aldrin
- RE: Seeking opinions on draft-akiya-bfd-seamless-… Nobo Akiya (nobo)
- Re: Seeking opinions on draft-akiya-bfd-seamless-… MALLIK MUDIGONDA (mmudigon)
- Re: Seeking opinions on draft-akiya-bfd-seamless-… Sam Aldrin
- Re: Seeking opinions on draft-akiya-bfd-seamless-… Marc Binderberger
- RE: Seeking opinions on draft-akiya-bfd-seamless-… Nobo Akiya (nobo)
- RE: Seeking opinions on draft-akiya-bfd-seamless-… Nobo Akiya (nobo)
- Re: Seeking opinions on draft-akiya-bfd-seamless-… Glen Kent
- RE: Seeking opinions on draft-akiya-bfd-seamless-… Nobo Akiya (nobo)