Re: AD Review of draft-ietf-bfd-seamless-base
Manav Bhatia <manavbhatia@gmail.com> Tue, 22 December 2015 15:05 UTC
Return-Path: <manavbhatia@gmail.com>
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 1E59C1A1A32; Tue, 22 Dec 2015 07:05:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 gDOnRm8hPeXW; Tue, 22 Dec 2015 07:05:55 -0800 (PST)
Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BC851A1A31; Tue, 22 Dec 2015 07:05:55 -0800 (PST)
Received: by mail-yk0-x232.google.com with SMTP id p130so166203025yka.1; Tue, 22 Dec 2015 07:05:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LshEnI47RH60cPiXX6nw+SojrhLPvNUtnhwD7f2Mrzk=; b=E7oYQsXym99VhvvtPW1eB+X/J5kg9aSI2n6CDQIZnbWFC6Ltplgl1DqwKVuMfdWgHJ Cx7mBoT/Ev35IFNX7IrQ+2vqHZaSzuuuGXQWzE3LhVXJwQVCxv+0Y1wm0hJD7YrN6ADc 1J+x8zDCja4xB5XLJW1YWA/MbOXQCCnINWKRcvXQwm6HRKvcc3gDkBfOBJjTa5GBJuut DugnN46/nW/d7x1HuKbr+xO05+3QN5W3O2rxr0iewTLY8ogSu7oAXUwfZqmhmIqx2yAq C6A4gabMIG7OHAFt9PkgzOVPbWK8SyfQG81j52DWdfBCX3jxMyDxDnEDm6jBtCXwZpjO F/XQ==
MIME-Version: 1.0
X-Received: by 10.129.72.130 with SMTP id v124mr19419562ywa.87.1450796754874; Tue, 22 Dec 2015 07:05:54 -0800 (PST)
Received: by 10.129.98.138 with HTTP; Tue, 22 Dec 2015 07:05:54 -0800 (PST)
In-Reply-To: <f46e3858dfef412d99dfd223f0840e9a@XCH-ALN-001.cisco.com>
References: <D22876B0.D338D%aretana@cisco.com> <SN1PR0501MB21420F68EA29F1FA425AB295B30A0@SN1PR0501MB2142.namprd05.prod.outlook.com> <D28B4E76.ED8A5%aretana@cisco.com> <D28C6D0D.EDC23%aretana@cisco.com> <20151214000245520882.14fa350b@sniff.de> <SN1PR0501MB2142004E7430F3A5F64AC202B3E10@SN1PR0501MB2142.namprd05.prod.outlook.com> <D29978F4.F453D%aretana@cisco.com> <20151219013323973354.b44d7a1b@sniff.de> <b61f5ea7dbd94badac7544c07543d1ba@XCH-ALN-001.cisco.com> <CAG1kdoikns-v9dSLTQdPdpdQY99on+6vhpE0+GeJ5hgvoO_=0g@mail.gmail.com> <20151221230913162917.3e88c932@sniff.de> <f46e3858dfef412d99dfd223f0840e9a@XCH-ALN-001.cisco.com>
Date: Tue, 22 Dec 2015 20:35:54 +0530
Message-ID: <CAG1kdoj3xGzTGCR5QEZ59Ly8yPv_WCwLUnOCCm_jo=cDeVQKXw@mail.gmail.com>
Subject: Re: AD Review of draft-ietf-bfd-seamless-base
From: Manav Bhatia <manavbhatia@gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Content-Type: multipart/alternative; boundary="001a114dc5723739de05277df119"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-bfd/j3M_f03wC4vTu9glVLQJkrULsV8>
Cc: "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.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: <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, 22 Dec 2015 15:05:59 -0000
Les, > > > So OSPF, IS-IS, L2TP could transport a single discriminator instead of a > list? > > [Les:] Perhaps - or we could leave these drafts as is - allowing the > possibility of sending multiple discriminators in the future. The key would > be for the base S-BFD draft to say something like "currently only support > for a single discriminator per node is defined". > The problem as i see is this: 1. The use case for supporting multiple discriminators per node imo is pretty contrived. I havent yet heard a compelling argument of why we need to support that. 2. The bigger problem is to see how the multiple discriminators can be mapped to the respective end-points. If IGPs advertise multiple discriminators, then we would map all those to the same node, and you cannot support the use case defined in the use-case document, which currently is the only case that requires multiple discriminators to be advertised. > If in the future support for multiple discriminators is required and > defined then the IGP/L2TP drafts could either: > > o Be left alone - a simple list is all that is required > o Be revised to carry whatever additional info S-BFD requires In future when we are revising the IGP drafts to carry the additional information then why dont we change the drafts then to advertise multiple discriminators? > My point is that since we have no idea what additional info might be > required in the future leaving the IGP/L2TP drafts in their current state > does no harm - and restricting them to one discriminator only provides no > benefit. > I would not argue against this. > > That said, if folks feel strongly that we should restrict the IGP/L2TP > advertisement format to one discriminator I would find that acceptable. > Likewise, if folks feel that we should keep the IGP drafts as is, i would find that acceptable. Cheers, Manav > > Les > > > > > > > Regards, Marc > > > > > > > > > > On Mon, 21 Dec 2015 09:36:12 +0530, Manav Bhatia wrote: > > > Hi Les, > > > > > > I had asked the exact same question in an offline email that i did not > > > get a reply for. > > > > > > I can say, as the primary co-author of the base S-BFD draft that the > > > case for multiple SBFD discriminators stands on very tenuous grounds. > > > The idea was very weird and i had argued that it really was an > > > architectural/implementation limitation that was being addressed by > > > way of supporting multiple discriminators per node. Given that there > > > are others that share this concern I would recommend striking that off > > > from the base S-BFD draft. You can look at Sec 3.8 of > > > https://tools.ietf.org/html/draft-ietf-bfd-seamless-use-case-03#page-7 > > > to understand why we may want to support multiple discriminators per > > node. > > > > > > I had conceded to that being added since i did not want to preclude > > > the possibility of adding that mechanism in the future. And it was > > > felt that this would get debated in the WG and we would go based on the > > consensus. > > > > > > My considered opinion is to strike that off from the base draft and > > > move on, since S-BFD solves a real problem and should not be stalled > > > for something that may never end up getting implemented. > > > > > > Cheers, Manav > > > > > > > > > On Mon, Dec 21, 2015 at 5:55 AM, Les Ginsberg (ginsberg) > > > <ginsberg@cisco.com> wrote: > > >> I certainly agree with everyone that the IGPs are merely a transport > > >> and do not "allocate" reflector discriminators nor - for the purposes > > >> of advertising S-BFD discriminators - do they have any understanding > > >> of how S-BFD discriminators are to be used. > > >> > > >> However, before we rush off in a direction which will invalidate any > > >> early implementations of the IGP drafts, I would like to see a > > >> justification of the need for a given node to require multiple > > >> reflector S-BFD discriminators and an explanation of what criteria > > >> would be used to determine whether the reflector should/should not > > >> respond to an Initiator S-BFD packet to a particular S-BFD reflector > > >> discriminator. Perhaps I have missed it, but to date I am not aware > > >> of any cogent explanation of this capability. The desire for multiple > > >> S-BFD discriminators seems to be made out of either: > > >> > > >> o An abundance of caution ("We don't know why we would need them - > > >> but if we come up with something in the future it would be nice if we > > >> didn't preclude it.") > > >> > > >> o Use cases which no one knows how to support (e.g. mapping a > > >> particular discriminator to a particular incoming interface or line > > >> card) > > >> > > >> What are the requirements and what about them necessitates multiple > > >> S-BFD discriminators? > > >> > > >> Les > > >> > > >> > > >>> -----Original Message----- > > >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc > > >>> Binderberger > > >>> Sent: Saturday, December 19, 2015 1:33 AM > > >>> To: Alvaro Retana (aretana); Santosh P K > > >>> Cc: rtg-bfd@ietf.org; draft-ietf-bfd-seamless-base@ietf.org; bfd- > > >>> chairs@ietf.org > > >>> Subject: Re: AD Review of draft-ietf-bfd-seamless-base > > >>> > > >>> Hello Santosh, Alvaro et al., > > >>> > > >>> >> [SPK] This is implementation specific right? Do we need this to > > >>> >> be captured in document? > > >>> > > >>> we could make it "just a TLV" which the IGP/L2TP transports to other > > >> S-BFD > > >>> modules. The transport mechanism then would not need to know the > > >>> inner structure, e.g. [type, discriminator], to function correctly. > > >>> > > >>> But for S-BFD modules to interoperate we would need to define the > > >>> inner structure of the "V" in the TLV. > > >>> > > >>> Implementation specific could be if you want to have awareness of > > >>> the > > >> inner > > >>> structure in the IGP/L2TP code already, e.g. when the IGP wants to > > >>> make > > >> use > > >>> of S-BFD information it transports, for it's own purpose > > >>> (shortcutting > > >> some > > >>> API calls). > > >>> > > >>> > > >>> We have to ask the L2TP, OSPF, IS-IS authors if they would be fine > > >>> with > > >> this > > >>> change :-) > > >>> > > >>> > > >>> Regards, Marc > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> On Fri, 18 Dec 2015 14:00:16 +0000, Alvaro Retana (aretana) wrote: > > >>> > On 12/18/15, 4:30 AM, "Santosh P K" <santoshpk@juniper.net> wrote: > > >>> > > > >>> > Santosh: > > >>> > > > >>> > Hi! > > >>> > > > >>> >>> There is another aspect: the protocols (OSPF, IS-IS, L2TP) plan > > >>> >>> to transport a list of discriminators. Okay ... but how is the > > >>> >>> receiver S-BFD > > >> module > > >>> >>> making sense out of this list? Would have expected something > > >>> >>> like > > >>> (type, > > >>> >>> discriminator). The protocols don't need to understand the > > >>> >>> details, > > >> only > > >>> >>> that > > >>> >>> the API transports one or more of these tuples in/out of the > > >>> >>> protocol module. > > >>> >>> S-BFD would know/define what a particular type means. > > >>> >>> Just asking before we send OSPF, IS-IS, L2TP into the wrong > > >> direction :-) > > >>> >> > > >>> >> [SPK] This is implementation specific right? Do we need this to > > >>> >> be captured in document? > > >>> > > > >>> > What is implementation specific? > > >>> > > > >>> > Right now the IGPs (generalizing: ISIS, OSPF, L2TP, etc.) are > > >> developing > > >>> > drafts to only carry the discriminators. If, as Mark suggests, > > >>> > the > > >> IGPs > > >>> > also transport something like "type", then S-BFD would know what > > >>> > each discriminator is for. > > >>> > > > >>> > Several questions: Is this (transporting [type, discriminator]) > > >>> > what > > >> is > > >>> > expected from the IGPs? If so, I assume the S-BFD module on the > > >>> > nodes assigns those values for transportation, right? How does a > > >>> > receiver > > >> know > > >>> > what a particular type means? > > >>> > > > >>> > Maybe the expectation from S-BFD is different...?? That is > > >>> > something > > >> that > > >>> > needs to be clarified so the IGP work can proceed. > > >>> > > > >>> > Thanks! > > >>> > > > >>> > Alvaro. > > >>> > > > >> > > > >
- AD Review of draft-ietf-bfd-seamless-base Alvaro Retana (aretana)
- Re: AD Review of draft-ietf-bfd-seamless-base Carlos Pignataro (cpignata)
- Re: AD Review of draft-ietf-bfd-seamless-base Carlos Pignataro (cpignata)
- RE: AD Review of draft-ietf-bfd-seamless-base Santosh P K
- Re: AD Review of draft-ietf-bfd-seamless-base Alvaro Retana (aretana)
- Re: AD Review of draft-ietf-bfd-seamless-base Jeffrey Haas
- Re: AD Review of draft-ietf-bfd-seamless-base Carlos Pignataro (cpignata)
- Re: AD Review of draft-ietf-bfd-seamless-base Carlos Pignataro (cpignata)
- Re: AD Review of draft-ietf-bfd-seamless-base Alvaro Retana (aretana)
- Re: AD Review of draft-ietf-bfd-seamless-base Carlos Pignataro (cpignata)
- Re: AD Review of draft-ietf-bfd-seamless-base Alvaro Retana (aretana)
- Re: AD Review of draft-ietf-bfd-seamless-base Alvaro Retana (aretana)
- Re: AD Review of draft-ietf-bfd-seamless-base Sam Aldrin
- Re: AD Review of draft-ietf-bfd-seamless-base Marc Binderberger
- RE: AD Review of draft-ietf-bfd-seamless-base Santosh P K
- RE: AD Review of draft-ietf-bfd-seamless-base Santosh P K
- Re: AD Review of draft-ietf-bfd-seamless-base Alvaro Retana (aretana)
- RE: AD Review of draft-ietf-bfd-seamless-base Santosh P K
- Re: AD Review of draft-ietf-bfd-seamless-base Alvaro Retana (aretana)
- Re: AD Review of draft-ietf-bfd-seamless-base Marc Binderberger
- RE: AD Review of draft-ietf-bfd-seamless-base Les Ginsberg (ginsberg)
- Re: AD Review of draft-ietf-bfd-seamless-base Manav Bhatia
- Re: AD Review of draft-ietf-bfd-seamless-base Marc Binderberger
- RE: AD Review of draft-ietf-bfd-seamless-base Les Ginsberg (ginsberg)
- Re: AD Review of draft-ietf-bfd-seamless-base Manav Bhatia
- Re: AD Review of draft-ietf-bfd-seamless-base Manav Bhatia
- RE: AD Review of draft-ietf-bfd-seamless-base Les Ginsberg (ginsberg)
- Re: AD Review of draft-ietf-bfd-seamless-base Manav Bhatia
- RE: AD Review of draft-ietf-bfd-seamless-base Mach Chen
- RE: AD Review of draft-ietf-bfd-seamless-base Marc Binderberger
- Re: AD Review of draft-ietf-bfd-seamless-base Manav Bhatia
- Re: AD Review of draft-ietf-bfd-seamless-base Carlos Pignataro (cpignata)
- Re: AD Review of draft-ietf-bfd-seamless-base Carlos Pignataro (cpignata)
- Re: AD Review of draft-ietf-bfd-seamless-base Carlos Pignataro (cpignata)
- Re: AD Review of draft-ietf-bfd-seamless-base Carlos Pignataro (cpignata)
- Re: AD Review of draft-ietf-bfd-seamless-base Marc Binderberger