From nobody Sun Jan 3 02:12:51 2016 Return-Path: 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 1CFD01A916D; Sun, 3 Jan 2016 02:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.612 X-Spam-Level: X-Spam-Status: No, score=-12.612 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 ralxt29rAPDw; Sun, 3 Jan 2016 02:12:46 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4E41A916C; Sun, 3 Jan 2016 02:12:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9296; q=dns/txt; s=iport; t=1451815966; x=1453025566; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GuQQ74bJjkPXXl8vVbMMHu3iPwrcIU+N2NCykdZfhKE=; b=XwOLYtcUpeBbS6X2LDBZHpNTOFwJ3MStPNtNUnFF+AfU2Yig9uzfTvst WJi58Ab/0wVQt9xRHhKVvbdWUmNhSqrGx/FcMpdffZ7Dfnwp9Kcdb/+L+ 25XuhDGYbvidNlv/+SiGDj5sR7NdyTyLlYO/fgb2gi371G+cVrV1zCVzj M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlAgAK84hW/4kNJK1egzpSXg+IWbNwA?= =?us-ascii?q?Q2BZCKFbQKBEjgUAQEBAQEBAYEKhDQBAQEDATo/BQcEAgEIEQQBAQEeCQcyFAk?= =?us-ascii?q?IAgQOBYgnCA6/TgEBAQEBAQEBAQEBAQEBAQEBAQEBARQEhlaCD4JwhCYRAR2DT?= =?us-ascii?q?IEbBZMKg3wBhT+CLIVlgVyNH4VYiGEBIAEBQoIRHIFdcoNOgUIBAQE?= X-IronPort-AV: E=Sophos;i="5.20,515,1444694400"; d="scan'208";a="223880034" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Jan 2016 10:12:45 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u03ACixF007779 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 3 Jan 2016 10:12:44 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; Sun, 3 Jan 2016 05:12:44 -0500 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; Sun, 3 Jan 2016 05:12:43 -0500 From: "Carlos Pignataro (cpignata)" To: "Les Ginsberg (ginsberg)" Subject: Re: AD Review of draft-ietf-bfd-seamless-base Thread-Topic: AD Review of draft-ietf-bfd-seamless-base Thread-Index: AQHQ97IkT4lFfvKt5Uasfc9mskhFeZ6+GxXwgAOR6gCAACS1gIAIyoiAgAZgJDCAAF3TgIABitaAgAKLpgCAAD2ZAIABxXiAgABo1oCAElKYEg== Date: Sun, 3 Jan 2016 10:12:43 +0000 Message-ID: <2B252CB3-02C7-40C4-A9CF-38BBE3DD946D@cisco.com> References: <20151214000245520882.14fa350b@sniff.de> <20151219013323973354.b44d7a1b@sniff.de> <20151221230913162917.3e88c932@sniff.de>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2016 10:12:49 -0000 Hi! Happy New Year! I strongly agree with Les' perspective here, as that was also the way I was= trying to write the spec. =20 As we design a spec, it is important that we, simultaneously: 1. Provide future growth capability and forward compatibility, and not corn= er ourselves being too stringent in design considerations. 2. Specify clearly the current set of interoperable options.=20 The healthy tension between these two calls for: 1. Let the transport/discovery drafts (IGPs, L2TP) have the option of carry= ing multiple disc 2. Expand S3.8 in the base document to say that, today, the app is to have = a single disc and if in the future multiple are needed, then the procedures= need to update this spec clearly scoping both endpoints' behavior.=20 Concerns with this approach? It allows for well defined current behavior an= d maximum forward compatibility and growth potential.=20 Thumb typed by Carlos Pignataro. Excuze typofraphicak errows > On Dec 22, 2015, at 08:24, Les Ginsberg (ginsberg) w= rote: >=20 > Marc - >=20 >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de] >> Sent: Monday, December 21, 2015 11:09 PM >> To: Manav Bhatia; Les Ginsberg (ginsberg) >> Cc: Alvaro Retana (aretana); Santosh P K; rtg-bfd@ietf.org; draft-ietf-b= fd- >> seamless-base@ietf.org; bfd-chairs@ietf.org >> Subject: Re: AD Review of draft-ietf-bfd-seamless-base >>=20 >> Hello Manav! >>=20 >>> 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. >>=20 >> ah, that problem :-) >>=20 >>> 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. >>=20 >> So OSPF, IS-IS, L2TP could transport a single discriminator instead of a= list? >=20 > [Les:] Perhaps - or we could leave these drafts as is - allowing the poss= ibility 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". >=20 > If in the future support for multiple discriminators is required and defi= ned then the IGP/L2TP drafts could either: >=20 > o Be left alone - a simple list is all that is required > o Be revised to carry whatever additional info S-BFD requires >=20 > My point is that since we have no idea what additional info might be requ= ired in the future leaving the IGP/L2TP drafts in their current state does = no harm - and restricting them to one discriminator only provides no benefi= t. >=20 > That said, if folks feel strongly that we should restrict the IGP/L2TP ad= vertisement format to one discriminator I would find that acceptable. >=20 > Les >=20 >>=20 >>=20 >> Regards, Marc >>=20 >>=20 >>=20 >>=20 >>> On Mon, 21 Dec 2015 09:36:12 +0530, Manav Bhatia wrote: >>> Hi Les, >>>=20 >>> I had asked the exact same question in an offline email that i did not >>> get a reply for. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Cheers, Manav >>>=20 >>>=20 >>> On Mon, Dec 21, 2015 at 5:55 AM, Les Ginsberg (ginsberg) >>> 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. >>>>=20 >>>> 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: >>>>=20 >>>> 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.") >>>>=20 >>>> o Use cases which no one knows how to support (e.g. mapping a >>>> particular discriminator to a particular incoming interface or line >>>> card) >>>>=20 >>>> What are the requirements and what about them necessitates multiple >>>> S-BFD discriminators? >>>>=20 >>>> Les >>>>=20 >>>>=20 >>>>> -----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 >>>>>=20 >>>>> Hello Santosh, Alvaro et al., >>>>>=20 >>>>>>> [SPK] This is implementation specific right? Do we need this to >>>>>>> be captured in document? >>>>>=20 >>>>> 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. >>>>>=20 >>>>> But for S-BFD modules to interoperate we would need to define the >>>>> inner structure of the "V" in the TLV. >>>>>=20 >>>>> 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). >>>>>=20 >>>>>=20 >>>>> We have to ask the L2TP, OSPF, IS-IS authors if they would be fine >>>>> with >>>> this >>>>> change :-) >>>>>=20 >>>>>=20 >>>>> Regards, Marc >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On Fri, 18 Dec 2015 14:00:16 +0000, Alvaro Retana (aretana) wrote: >>>>>> On 12/18/15, 4:30 AM, "Santosh P K" wrote: >>>>>>=20 >>>>>> Santosh: >>>>>>=20 >>>>>> Hi! >>>>>>=20 >>>>>>>> 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 :-) >>>>>>>=20 >>>>>>> [SPK] This is implementation specific right? Do we need this to >>>>>>> be captured in document? >>>>>>=20 >>>>>> What is implementation specific? >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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? >>>>>>=20 >>>>>> Maybe the expectation from S-BFD is different...?? That is >>>>>> something >>>> that >>>>>> needs to be clarified so the IGP work can proceed. >>>>>>=20 >>>>>> Thanks! >>>>>>=20 >>>>>> Alvaro. >>>=20 From nobody Sun Jan 3 02:32:12 2016 Return-Path: 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 77B2C1A92B5; Sun, 3 Jan 2016 02:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 EWsnkx1-c1bI; Sun, 3 Jan 2016 02:32:06 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E6291A9039; Sun, 3 Jan 2016 02:32:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26864; q=dns/txt; s=iport; t=1451817126; x=1453026726; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7ShAdbjEz0Ig1zC1kTRAigdTztT+XiQbwBMAVoBIdhs=; b=GEBQlDSVfBIleZuQWqYSH7Q69MsnXc2L2UeAeSVe7QrxwN4WvLGDDqhh qGM/VEY6lxTnbA/4jtNsUtxuHs/HkvkRa0EbOf3MiZ7DqryDva3HRcd3z DPs8r2hpVcqNN6zpWbyYM3hE9sFOntaMWhs1JFhSUO9OruK15y1zTgf/1 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlAgCJ94hW/4MNJK1egzpSbYhZs3ABD?= =?us-ascii?q?YFkIoVtAoESOBQBAQEBAQEBgQqENAEBAQMBeQwEAgEIEQQBAQEgBwchERQJCAI?= =?us-ascii?q?EDgWIGgMKCA68Gg2DHgEBAQEBAQEBAQEBAQEBAQEBAQEBARQEhlaCDwiCaIJPg?= =?us-ascii?q?VcRAUyDHYEbBZMKg3wBhT+GGYF4gVyERohZhViBCYNmg3IBIAEBQoIRHIFdcoN?= =?us-ascii?q?OgUIBAQE?= X-IronPort-AV: E=Sophos; i="5.20,515,1444694400"; d="scan'208,217"; a="63921073" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Jan 2016 10:32:04 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u03AW4AL025906 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 3 Jan 2016 10:32:04 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; Sun, 3 Jan 2016 05:32:03 -0500 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; Sun, 3 Jan 2016 05:32:03 -0500 From: "Carlos Pignataro (cpignata)" To: Manav Bhatia Subject: Re: AD Review of draft-ietf-bfd-seamless-base Thread-Topic: AD Review of draft-ietf-bfd-seamless-base Thread-Index: AQHQ97IkT4lFfvKt5Uasfc9mskhFeZ6+GxXwgAOR6gCAACS1gIAIyoiAgAZgJDCAAF3TgIABitaAgAKLpgCAAD2ZAIABxXiAgABo1oCAABxZAIASO6VY Date: Sun, 3 Jan 2016 10:32:03 +0000 Message-ID: <598615FF-8151-44B1-99F9-0277B417EBE9@cisco.com> References: <20151214000245520882.14fa350b@sniff.de> <20151219013323973354.b44d7a1b@sniff.de> <20151221230913162917.3e88c932@sniff.de> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_598615FF815144B199F90277B417EBE9ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Les Ginsberg \(ginsberg\)" , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2016 10:32:10 -0000 --_000_598615FF815144B199F90277B417EBE9ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Manav, Thanks for the discussion. Let's not cripple the spec before its out. Saying "let's update 5 RFCs when I understand the use case" is not forward = compatibility and artificially constrain the spec :-) Please find some comments inline. Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Dec 22, 2015, at 10:06, Manav Bhatia > wrote: 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 possib= ility of sending multiple discriminators in the future. The key would be fo= r 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 pret= ty contrived. I havent yet heard a compelling argument of why we need to su= pport that. I am also looking at use cases for it. I won't pass judgement on how contri= ved they are or not, but to me they will be compelling to customers. But even without this, a protocol spec need not artificially block progress= based on your current understanding of use cases. There's a lot of creativ= ity to be applied here. Net-net, allow the possibility for the transport to carry multiple disc (th= at's 3 specs!) while put the constrain in the sbfd-ip/base spec for the cur= rent use case. That way, when the future catches up, we do not need to rewr= ite RFCs. 2. The bigger problem is to see how the multiple discriminators can be mapp= ed to the respective end-points. This is solvable, but I fully agree with you it needs to be specified expli= citly. If IGPs advertise multiple discriminators, then we would map all those to t= he same node, and you cannot support the use case defined in the use-case d= ocument, which currently is the only case that requires multiple discrimina= tors to be advertised. Like I said, let the discovery/transport capability of multi disc, even if = today we only use single one. I very highly suspect multiple disc will beco= me common in these contexts. If in the future support for multiple discriminators is required and define= d 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 info= rmation then why dont we change the drafts then to advertise multiple discr= iminators? If we are already planning on revising a spec that is not even printed, we = might be short-sighted into its real use. My point is that since we have no idea what additional info might be requir= ed 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 adve= rtisement format to one discriminator I would find that acceptable. Likewise, if folks feel that we should keep the IGP drafts as is, i would f= ind that acceptable. That would be my preference. However, as you said, we need to tight S3.8 of the base. Thanks! Carlos. 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) > > > 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-seamles= s-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" > 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. > >>> > > >> > > --_000_598615FF815144B199F90277B417EBE9ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Manav,

Thanks for the discussion. 

Let's not cripple the spec before its out.&n= bsp;

Saying "let's update 5 RFCs when I unde= rstand the use case" is not forward compatibility and artificially con= strain the spec :-)

Please find some comments inline. 

Excuze typofraphicak errows

On Dec 22, 2015, at 10:06, Manav Bhatia <manavbhatia@gmail.com> wrote:

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 woul= d be for the base S-BFD draft to say something like "currently only su= pport 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.


I am also looking at use cases for it. I won't pass judgement on how c= ontrived they are or not, but to me they will be compelling to customers.&n= bsp;

But even without this, a protocol spec need not artificially block pro= gress based on your current understanding of use cases. There's a lot of cr= eativity to be applied here. 

Net-net, allow the possibility for the transport to carry multiple dis= c (that's 3 specs!) while put the constrain in the sbfd-ip/base spec for th= e current use case. That way, when the future catches up, we do not need to= rewrite RFCs. 

2. The bigger problem is to see how the multiple discriminators can be= mapped to the respective end-points.

This is solvable, but I fully agree with you it needs to be specified expli= citly. 

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-c= ase document, which currently is the only case that requires multiple discr= iminators to be advertised. 

Like I said, let the discovery/transport capability of multi disc, eve= n if today we only use single one. I very highly suspect multiple disc will= become common in these contexts. 

 
If in the future support for multiple discriminators is required and define= d 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<= /blockquote>
 
In future when we are revising  the IGP drafts to carry the addit= ional information then why dont we change the drafts then to advertise mult= iple discriminators?

If we are already planning on revising a spec that is not even printed= , we might be short-sighted into its real use. 



My point is that since we have no idea what additional info might be requir= ed 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 adve= rtisement format to one discriminator I would find that acceptable.

Likewise, if folks feel that we should keep the IGP drafts as is, i wo= uld find that acceptable.


That would be my preference. 

However, as you said, we need to tight S3.8 of the base. 

Thanks!

Carlos. 

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 di= d 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 grou= nds.
> > 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 th= ere
> > are others that share this concern I would recommend striking tha= t 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<= br> > > 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 preclu= de
> > the possibility of adding that mechanism in the future. And it wa= s
> > 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 a= nd
> > move on, since S-BFD solves a real problem and should not be stal= led
> > for something that may never end up getting implemented.
> >
> > Cheers, Manav
> >
> >
> > On Mon, Dec 21, 2015 at 5:55 AM, Les Ginsberg (ginsberg)
> > <ginsb= erg@cisco.com> wrote:
> >> I certainly agree with everyone that the IGPs are merely a tr= ansport
> >> and do not "allocate" reflector discriminators nor = - for the purposes
> >> of advertising S-BFD discriminators - do they have any unders= tanding
> >> of how S-BFD discriminators are to be used.
> >>
> >> However, before we rush off in a direction which will invalid= ate any
> >> early implementations of the IGP drafts, I would like to see = a
> >> justification of the need for a given node to require multipl= e
> >> reflector S-BFD discriminators and an explanation of what cri= teria
> >> would be used to determine whether the reflector should/shoul= d not
> >> respond to an Initiator S-BFD packet to a particular S-BFD re= flector
> >> 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 w= hy we would need them -
> >> but if we come up with something in the future it would be ni= ce 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 o= r line
> >> card)
> >>
> >> What are the requirements and what about them necessitates mu= ltiple
> >> S-BFD discriminators?
> >>
> >>    Les
> >>
> >>
> >>> -----Original Message-----
> >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc<= br> > >>> 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-
> >>> chai= rs@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/L2T= P transports to other
> >> S-BFD
> >>> modules. The transport mechanism then would not need to k= now the
> >>> inner structure, e.g. [type, discriminator], to function = correctly.
> >>>
> >>> But for S-BFD modules to interoperate we would need to de= fine the
> >>> inner structure of the "V" in the TLV.
> >>>
> >>> Implementation specific could be if you want to have awar= eness 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<= br> > >>> (shortcutting
> >> some
> >>> API calls).
> >>>
> >>>
> >>> We have to ask the L2TP, OSPF, IS-IS authors if they woul= d be fine
> >>> with
> >> this
> >>> change :-)
> >>>
> >>>
> >>> Regards, Marc
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Fri, 18 Dec 2015 14:00:16 +0000, Alvaro Retana (ar= etana) 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 h= ave expected something
> >>> >>> like
> >>> (type,
> >>> >>> discriminator). The protocols don't need to = understand the
> >>> >>> details,
> >> only
> >>> >>> that
> >>> >>> the API transports one or more of these tupl= es in/out of the
> >>> >>> protocol module.
> >>> >>> S-BFD would know/define what a particular ty= pe 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, a= s 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...??&n= bsp; That is
> >>> > something
> >> that
> >>> > needs to be clarified so the IGP work can proceed. > >>> >
> >>> > Thanks!
> >>> >
> >>> > Alvaro.
> >>> >
> >>
> >

--_000_598615FF815144B199F90277B417EBE9ciscocom_-- From nobody Sun Jan 3 02:34:09 2016 Return-Path: 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 8038E1A92BA; Sun, 3 Jan 2016 02:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 u3JuFLTkDSq6; Sun, 3 Jan 2016 02:34:04 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D0F11A92B8; Sun, 3 Jan 2016 02:34:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31340; q=dns/txt; s=iport; t=1451817244; x=1453026844; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=G0vdS8s2Nh6gVBHJy3r0QALeAemlU6DBSo9U9BcCJq8=; b=BG5m0cUgLTMQJvFQ/4Uv5e+q+m7cNkbWELY6diGUA5DPJgd+wTX5uNhB ws7bRwQcfxpJlkB4Wnssg9/oexzBV92JtjZ/Z/ALS3wD8LiZU/MKNr+Rk ds5Q17V4+qhAFVXl85FffTq7zzyCBx4gHmssFLbs5Kcyfn5IQDQ6HJa5k A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlAgAo+IhW/40NJK1egm5MUm2IWbNwA?= =?us-ascii?q?Q2BZCKFbQKBEjgUAQEBAQEBAYEKhDQBAQEDAXkMBAIBCBEEAQEBIAcHIREUCQg?= =?us-ascii?q?CBA4FiBoDCggOvBsNgx4BAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZWgg8IgmiCT?= =?us-ascii?q?4FXEQFMCYMUgRsFkwqDfAGFP4YZgXiOe4Zhh1gBIAEBQoIRHIFdcoNOgUIBAQE?= X-IronPort-AV: E=Sophos; i="5.20,515,1444694400"; d="scan'208,217"; a="60247205" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Jan 2016 10:34:00 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u03AY0QN009153 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 3 Jan 2016 10:34:00 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 3 Jan 2016 05:33:59 -0500 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; Sun, 3 Jan 2016 05:33:59 -0500 From: "Carlos Pignataro (cpignata)" To: Manav Bhatia Subject: Re: AD Review of draft-ietf-bfd-seamless-base Thread-Topic: AD Review of draft-ietf-bfd-seamless-base Thread-Index: AQHQ97IkT4lFfvKt5Uasfc9mskhFeZ6+GxXwgAOR6gCAACS1gIAIyoiAgAZgJDCAAF3TgIABitaAgAKLpgCAAD2ZAIABxXiAgABo1oCAABxZAIAAMBoAgABuFQCAEZ4BIQ== Date: Sun, 3 Jan 2016 10:33:59 +0000 Message-ID: <8A1E50D5-EB6D-4135-AB93-353E866F47D8@cisco.com> References: <20151214000245520882.14fa350b@sniff.de> <20151219013323973354.b44d7a1b@sniff.de> <20151221230913162917.3e88c932@sniff.de> <6230dc8de0a24fd1b7576d2f1749d908@XCH-ALN-001.cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_8A1E50D5EB6D4135AB93353E866F47D8ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Les Ginsberg \(ginsberg\)" , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2016 10:34:08 -0000 --_000_8A1E50D5EB6D4135AB93353E866F47D8ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Manav and Les, and sorry for the delay in pitching in. I like the proposal below with one difference: 1. Instead of removing, let's say it's for future study, leave the current = use case but say this spec allows for one only. 2. And 3. Yes! Thanks! Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Dec 22, 2015, at 19:32, Manav Bhatia > wrote: Les, I am fine with this as well. Can we hear what others think on this issue and move on? In the absence of = a clear majority i would like to go ahead with the changes that you propose= , which are: 1. Remove the multiple sessions terminating on the same target example from= the use-case document. 2. Change the base s-bfd draft to only advertise 1 discriminator 3. Leave the IGP drafts as is. Cheers, Manav On Tue, Dec 22, 2015 at 11:28 PM, Les Ginsberg (ginsberg) > wrote: Manav =96 We are mainly in agreement I think. Inline. From: Manav Bhatia [mailto:manavbhatia@gmail.com] Sent: Tuesday, December 22, 2015 7:06 AM To: Les Ginsberg (ginsberg) Cc: Marc Binderberger; Alvaro Retana (aretana); Santosh P K; rtg-bfd@ietf.o= rg; draft-ietf-bfd-seamless-base@ietf.org; bfd-chairs@ietf.org Subject: Re: AD Review of draft-ietf-bfd-seamless-base 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 possib= ility of sending multiple discriminators in the future. The key would be fo= r 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 pret= ty contrived. I havent yet heard a compelling argument of why we need to su= pport that. 2. The bigger problem is to see how the multiple discriminators can be mapp= ed 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 u= se case defined in the use-case document, which currently is the only case = that requires multiple discriminators to be advertised. [Les:] If base S-BFD draft says =93only one discriminator is supported=94 t= hen IGPs will never be asked to send multiple discriminators (even though t= hey can). If in the future support for multiple discriminators is required and define= d 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 info= rmation then why dont we change the drafts then to advertise multiple discr= iminators? [Les:] LES: I am just trying to avoid modifying the IGP/L2TP drafts at this= time unnecessarily. And since S-BFD will never ask to advertise multiple d= iscriminators this seems safe. My point is that since we have no idea what additional info might be requir= ed 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 adve= rtisement format to one discriminator I would find that acceptable. Likewise, if folks feel that we should keep the IGP drafts as is, i would f= ind that acceptable. [Les:] Either way I think we are both OK. :) Les 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) > > > 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-seamles= s-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" > 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. > >>> > > >> > > --_000_8A1E50D5EB6D4135AB93353E866F47D8ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Thanks Manav and Les, and sorry for the delay in pitching in. 

I like the proposal below with one differenc= e:
1. Instead of removing, let's say it's for f= uture study, leave the current use case but say this spec allows for one on= ly. 
2. And 3. Yes!

Thanks!

Excuze typofraphicak errows

On Dec 22, 2015, at 19:32, Manav Bhatia <manavbhatia@gmail.com> wrote:

Les, 

I am fine with this as well.

Can we hear what others think on this issue and move on? In the absenc= e of a clear majority i would like to go ahead with the changes that you pr= opose, which are:

1. Remove the multiple sessions terminating on the same target example= from the use-case document.
2. Change the base s-bfd draft to only advertise 1 discriminator
3. Leave the IGP drafts as is.

Cheers, Manav

On Tue, Dec 22, 2015 at 11:28 PM, Les Ginsberg (= ginsberg) <ginsberg@cisco.com> wrote:

Manav =96

 

We are mainly in agreemen= t I think.

Inline.

 

From: Manav Bh= atia [mailto:man= avbhatia@gmail.com]
Sent: Tuesday, December 22, 2015 7:06 AM
To: Les Ginsberg (ginsberg)
Cc: Marc Binderberger; Alvaro Retana (aretana); Santosh P K; 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=

 

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 possib= ility of sending multiple discriminators in the future. The key would be fo= r the base S-BFD draft to say something like "currently only support f= or a single discriminator per node is defined".

 

The problem as i see is this:

 

1. The use case for supporting multiple discriminato= rs per node imo is pretty contrived. I havent yet heard a compelling argume= nt of why we need to support that.

 

2. The bigger problem is to see how the multiple dis= criminators can be mapped to the respective end-points. If IGPs advertise m= ultiple discriminators, then we would map all those to the same node, and y= ou cannot support the use case defined in the use-case document, which currently is the only case that requires m= ultiple discriminators to be advertised. 

 

[Les:] If base S-BF= D draft says =93only one discriminator is supported=94 then IGPs will never= be asked to send multiple discriminators (even though they can).

 

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<= u>

 

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?

 

[Les:] LES: I am ju= st trying to avoid modifying the IGP/L2TP drafts at this time unnecessarily= . And since S-BFD will never ask to advertise multiple discriminators this seems safe.


My point is that since we have no idea what additional info might be requir= ed 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 adve= rtisement format to one discriminator I would find that acceptable.<= u>

 

Likewise, if folks feel that we should keep the IGP = drafts as is, i would find that acceptable.

 

[Les:] Either way I= think we are both OK. J

 

   Les=

 

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 di= d 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 grou= nds.
> > 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 th= ere
> > are others that share this concern I would recommend striking tha= t 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<= br> > > 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 preclu= de
> > the possibility of adding that mechanism in the future. And it wa= s
> > 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 a= nd
> > move on, since S-BFD solves a real problem and should not be stal= led
> > for something that may never end up getting implemented.
> >
> > Cheers, Manav
> >
> >
> > On Mon, Dec 21, 2015 at 5:55 AM, Les Ginsberg (ginsberg)
> > <ginsb= erg@cisco.com> wrote:
> >> I certainly agree with everyone that the IGPs are merely a tr= ansport
> >> and do not "allocate" reflector discriminators nor = - for the purposes
> >> of advertising S-BFD discriminators - do they have any unders= tanding
> >> of how S-BFD discriminators are to be used.
> >>
> >> However, before we rush off in a direction which will invalid= ate any
> >> early implementations of the IGP drafts, I would like to see = a
> >> justification of the need for a given node to require multipl= e
> >> reflector S-BFD discriminators and an explanation of what cri= teria
> >> would be used to determine whether the reflector should/shoul= d not
> >> respond to an Initiator S-BFD packet to a particular S-BFD re= flector
> >> 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 w= hy we would need them -
> >> but if we come up with something in the future it would be ni= ce 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 o= r line
> >> card)
> >>
> >> What are the requirements and what about them necessitates mu= ltiple
> >> S-BFD discriminators?
> >>
> >>    Les
> >>
> >>
> >>> -----Original Message-----
> >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc<= br> > >>> 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-
> >>> chai= rs@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/L2T= P transports to other
> >> S-BFD
> >>> modules. The transport mechanism then would not need to k= now the
> >>> inner structure, e.g. [type, discriminator], to function = correctly.
> >>>
> >>> But for S-BFD modules to interoperate we would need to de= fine the
> >>> inner structure of the "V" in the TLV.
> >>>
> >>> Implementation specific could be if you want to have awar= eness 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<= br> > >>> (shortcutting
> >> some
> >>> API calls).
> >>>
> >>>
> >>> We have to ask the L2TP, OSPF, IS-IS authors if they woul= d be fine
> >>> with
> >> this
> >>> change :-)
> >>>
> >>>
> >>> Regards, Marc
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Fri, 18 Dec 2015 14:00:16 +0000, Alvaro Retana (ar= etana) 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 h= ave expected something
> >>> >>> like
> >>> (type,
> >>> >>> discriminator). The protocols don't need to = understand the
> >>> >>> details,
> >> only
> >>> >>> that
> >>> >>> the API transports one or more of these tupl= es in/out of the
> >>> >>> protocol module.
> >>> >>> S-BFD would know/define what a particular ty= pe 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, a= s 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...??&n= bsp; That is
> >>> > something
> >> that
> >>> > needs to be clarified so the IGP work can proceed. > >>> >
> >>> > Thanks!
> >>> >
> >>> > Alvaro.
> >>> >
> >>
> >

 


--_000_8A1E50D5EB6D4135AB93353E866F47D8ciscocom_-- From nobody Sun Jan 3 02:34:57 2016 Return-Path: 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 BFC9D1A92BB; Sun, 3 Jan 2016 02:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 iyZarHRWjV83; Sun, 3 Jan 2016 02:34:55 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 551F31A92BA; Sun, 3 Jan 2016 02:34:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4027; q=dns/txt; s=iport; t=1451817295; x=1453026895; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IoPmOhJSE3pttsyXl8c/B3a1xD1iV5RJaWXIj6zh3NU=; b=if1jrVy4atJGjyT02IjvubRldaEQD2y8i4AVXTYCNk3iFqkZFsq1H7Yr MoAhD1uKad1VTkkLSZCdoQuG6oV5rT92cDzoupleamOMakqvMr7QqKKIj 6Bm15YZ75+PZdW5i+Nx/aeuNvqdn7abLr3rNbpqTtfLDCIJb+EKYvbzkt E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkAgDu+IhW/5pdJa1egzqBP4hZs3ABD?= =?us-ascii?q?YFkhg8CgRI4FAEBAQEBAQGBCoQ1AQEDAXkFCwIBCAQ7ByERFBECBA4FiBoDCgi?= =?us-ascii?q?8IA2DHgEBAQEBAQEBAQEBAQEBAQEBAQEBARiGVoIPgnCCT4VSgRsFkwqDfAGLW?= =?us-ascii?q?IF4jnuGYYdYASABAUKECnKFEAEBAQ?= X-IronPort-AV: E=Sophos; i="5.20,515,1444694400"; d="scan'208,217"; a="60316392" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jan 2016 10:34:54 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u03AYs49019729 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 3 Jan 2016 10:34:54 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 3 Jan 2016 05:34:53 -0500 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; Sun, 3 Jan 2016 05:34:53 -0500 From: "Carlos Pignataro (cpignata)" To: Manav Bhatia Subject: Re: AD Review of draft-ietf-bfd-seamless-base Thread-Topic: AD Review of draft-ietf-bfd-seamless-base Thread-Index: AQHQ97IkT4lFfvKt5Uasfc9mskhFeZ6+GxXwgAOR6gCAACS1gIAIyoiAgAZgJDCAAF3TgIABitaAgAKLpgCAAD2ZAIABxXiAgABo1oCAABxZAIAAMBoAgABuFQCAADMBgIABo0AAgAACoYCAD8VeTQ== Date: Sun, 3 Jan 2016 10:34:53 +0000 Message-ID: <9546A9BD-488A-4A66-B641-9819FD327E7E@cisco.com> References: <20151214000245520882.14fa350b@sniff.de> <20151219013323973354.b44d7a1b@sniff.de> <20151221230913162917.3e88c932@sniff.de> <6230dc8de0a24fd1b7576d2f1749d908@XCH-ALN-001.cisco.com> <20151223203510463926.94eddf06@sniff.de>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_9546A9BD488A4A66B6419819FD327E7Eciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Les Ginsberg \(ginsberg\)" , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2016 10:34:56 -0000 --_000_9546A9BD488A4A66B6419819FD327E7Eciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Manav! Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Dec 23, 2015, at 23:44, Manav Bhatia > wrote: > 1. Remove the multiple sessions terminating on the same target example fr= om > the use-case document. > 2. Change the base s-bfd draft to only advertise 1 discriminator > 3. Leave the IGP drafts as is. as we have to do point (2) in any case, if the IGP drafts are changed or remain, I would think this is the most efficient way to get out of the troubles. Great. Will do that. Makes a nice test case: send multiple S-BFD discriminators in the subtlv an= d see how the test unit behaves ;-) > And i was convinced by some folks working for the same vendor to include = the > possibility of supporting multiple discriminators per node since the > line cards can keep conking off ! ;-) well, they can ;-) but the way it is implemented right now I think we can solve the problem without a 2nd discriminator. Wow. Some serious architectural changes have gone in since then and now, eh= ? ;-) Cheers, Manav --_000_9546A9BD488A4A66B6419819FD327E7Eciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks Manav!

Excuze typofraphicak errows

On Dec 23, 2015, at 23:44, Manav Bhatia <manavbhatia@gmail.com> wrote:

> 1. Remove the multiple sessions terminating on the sa= me target example from
> the use-case document.
> 2. Change the base s-bfd draft to only advertise 1 discriminator
> 3. Leave the IGP drafts as is.


as we have to do point (2) in any case, if the IGP drafts are change= d or
remain, I would think this is the most efficient way to get out of the
troubles.

Great. Will do that.
 

Makes a nice test case: send multiple S-BFD discriminators in the subtlv an= d
see how the  test unit behaves ;-)


> And i was convinced by some folks working for the same vendor to inclu= de the
> possibility of supporting multiple discriminators per node since the > line cards can keep conking off ! ;-)

well, they can ;-) but the way it is implemented right now I think w= e can
solve the problem without a 2nd discriminator.

Wow. Some serious architectural changes have gone in since then and no= w, eh?  ;-)

Cheers, Manav

--_000_9546A9BD488A4A66B6419819FD327E7Eciscocom_-- From nobody Wed Jan 6 10:06:10 2016 Return-Path: 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 0F07B1A0056 for ; Wed, 6 Jan 2016 10:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 fB7zUXRx6q05 for ; Wed, 6 Jan 2016 10:06:07 -0800 (PST) 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 EF0961A0083 for ; Wed, 6 Jan 2016 10:05:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2639; q=dns/txt; s=iport; t=1452103524; x=1453313124; h=from:to:subject:date:message-id:mime-version; bh=Htz5M3DRVoa8bE6S1xSe06fAue64vQv+rAF0syMwdkE=; b=f/eWbkMAlevs7XHYY5kxXq+rJlFyNdrvSwBUdP+8ysI8QwWf0kyyVk8E sULZG3EFL/dO9RAaxgJevKpC7HMpd+zJl0OaD9re+ryb37C3CEyZnpltt kydAvIjDjDqJDDKDcCUabeAe0RgZ0w5ebPPESX4kf4G71lTFSk7GI55V2 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AhAgBzVo1W/49dJa1egm5MUm0GiFOxR?= =?us-ascii?q?IITAQ2BZCKFbYEnOBQBAQEBAQEBfwuEO4ELAQx0DxgEiEIOoT+gPAEBAQcBAQE?= =?us-ascii?q?BGwSGVooDhDgFjXOJFwGFQYgTjnqORgEgAQFChApzhFgBgQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,530,1444694400"; d="scan'208,217";a="224172788" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jan 2016 18:05:23 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u06I5Nkd010213 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 6 Jan 2016 18:05:23 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 6 Jan 2016 12:05:22 -0600 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.009; Wed, 6 Jan 2016 12:05:22 -0600 From: "Reshad Rahman (rrahman)" To: "rtg-bfd@ietf.org" Subject: IETF 95 Thread-Topic: IETF 95 Thread-Index: AQHRSKzPirE8vzIMpka4g9hzJUts8A== Date: Wed, 6 Jan 2016 18:05:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.105] Content-Type: multipart/alternative; boundary="_000_D2B2C198111011rrahmanciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 18:06:09 -0000 --_000_D2B2C198111011rrahmanciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Working Group, Here is the BFD WG work on which we need to make progress. There doesn't ap= pear to be a need to meet based on this, does anyone have agenda items that= requires in-person discussion? - BFD multipoint. Needs WG feedback. - S-BFD is done, AD comments being addressed. - BFD security optimizations. Needs WG feedback. - YANG work, new draft to be submitted before IETF95 BFD wiki @ https://wiki.tools.ietf.org/wg/bfd/trac/wiki Regards, Jeff & Reshad. --_000_D2B2C198111011rrahmanciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <547675CC7F6F6A4498008D5050C1F401@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hello Working Group,

Here is t= he BFD WG work on which we need to make progress. There doesn’t appea= r to be a need to meet based on this, does anyone have agenda items that re= quires in-person discussion?

- BFD multipoint.  Needs WG feedback.
- S-BFD is done, AD comments being addressed.
- BFD security optimizations. Needs WG feedback.
- YANG work, new dr= aft to be submitted before IETF95

 
Regards,<= /div>
Jeff &= ; Reshad.


--_000_D2B2C198111011rrahmanciscocom_-- From nobody Sat Jan 16 09:25:23 2016 Return-Path: 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 7C5AE1ACD3F; Wed, 13 Jan 2016 01:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 IDMFHYZ4N5F3; Wed, 13 Jan 2016 01:31:31 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935911ACD3E; Wed, 13 Jan 2016 01:31:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2254; q=dns/txt; s=iport; t=1452677491; x=1453887091; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9rYGX0lQFYMH2GV7vLw9N0i90bLNkNvCPN3V0NnDmr0=; b=kHsbnJK8rJlU4jJo1O6B+XByzCrRygn6hX/oE4FWJyj4s6uUwyBePpXm 7TpEnU7YNwp7yq8GwFQaE3vbiZCgakMxHpu+HqtnFmTTNkx2120TXEYHS JZZEFmDLwpQUfsMB1GdBfDdeRFiYUyWdDheYefElWg8+ALID9/oDEhFpQ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAgAlGZZW/5BdJa1egzpSbQaIU7McA?= =?us-ascii?q?Q2BZCKFbQKBKzgUAQEBAQEBAYEKhDUBAQQ6PQIQAgEINhAyJQIEAQ0FiC4Ov3A?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEYhlaEf4k9BY1BiVQBhUKIF4FeSoN6iF6OU?= =?us-ascii?q?wEgAQFChApyAYUTgQgBAQE?= X-IronPort-AV: E=Sophos;i="5.22,288,1449532800"; d="scan'208";a="65798378" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jan 2016 09:31:30 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u0D9VUac024389 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Jan 2016 09:31:30 GMT Received: from xch-rtp-003.cisco.com (64.101.220.143) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Jan 2016 04:31:29 -0500 Received: from xch-rtp-003.cisco.com ([64.101.220.143]) by XCH-RTP-003.cisco.com ([64.101.220.143]) with mapi id 15.00.1104.009; Wed, 13 Jan 2016 04:31:29 -0500 From: "Nitish Gupta (nitisgup)" To: "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYiTS9LHO0Rck2198aSpBcKKZ5+EmUAgHxbjAA= Date: Wed, 13 Jan 2016 09:31:29 +0000 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.232.34.49] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sat, 16 Jan 2016 09:25:22 -0800 Cc: "jhaas@juniper.net" , "colin@doch.org.uk" , "Aditya Dogra \(addogra\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 09:31:33 -0000 Hi, We had presented the Draft for VRRP BFD integration in IETF 93 and we had taken care of all the comments that came as part of the WG meeting. We had also merged the two drafts as per the comments in IETF 93: http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 We had presented the merged draft in IETF 94 and there were no specific comments on the draft. We would like to ask the RTGWG to adopt the Draft as a WG document. Thanks, Nitish On 26/10/15 11:57 am, "Nitish Gupta (nitisgup)" wrote: >Hi, > >We have submitted a new version of the draft. As discussed in IETF 93 at >prague. > >We have merged the following drafts: >http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 > >https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 > > > >We have also taken care of all the comments that were discussed in the >RTGWG meeting. >We welcome any comments and suggestions on the draft. > >Thanks, >Nitish > >On 13/10/15 9:09 pm, "internet-drafts@ietf.org" >wrote: > >> >>A new version of I-D, draft-nitish-vrrp-bfd-02.txt >>has been successfully submitted by Nitish Gupta and posted to the >>IETF repository. >> >>Name: draft-nitish-vrrp-bfd >>Revision: 02 >>Title: Fast failure detection in VRRP with BFD >>Document date: 2015-10-13 >>Group: Individual Submission >>Pages: 10 >>URL: =20 >>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt >>Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ >>Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 >>Diff: =20 >>https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02 >> >>Abstract: >> This document describes how Bidirectional Forwarding Detection (BFD) >> can be used to support sub-second detection of a Master Router >> failure in the Virtual Router Redundancy Protocol (VRRP). >> >> =20 >> =20 >> >> >>Please note that it may take a couple of minutes from the time of >>submission >>until the htmlized version and diff are available at tools.ietf.org. >> >>The IETF Secretariat >> > From nobody Sun Jan 17 02:04:59 2016 Return-Path: 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 4787E1B2F2B; Sun, 17 Jan 2016 02:04:57 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 1mj4YdYAWHpv; Sun, 17 Jan 2016 02:04:54 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0093.outbound.protection.outlook.com [104.47.1.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5641B2F2C; Sun, 17 Jan 2016 02:04:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=R+UkqflSEq3M4WCtFr8diFe2eQUxNl21uv8nhQWRXHU=; b=Iv5Is3YbVkC2yw5awIpMrBoZS0tTuOfbOiGn9IBEEme0MIviB2QJgFEC8J6OdoG+dRSmWHAsk0+EI7CBLQgwIRc5XbWQ7Yyec94DTgSSRb8iTliZC1l4lVcH2pusI8hsewZElo/Ypjjk6bGAitbPUF9PaLm2Xz4LgbOKekxTGsA= Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0779.eurprd03.prod.outlook.com (10.161.55.11) with Microsoft SMTP Server (TLS) id 15.1.365.19; Sun, 17 Jan 2016 10:04:49 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0365.023; Sun, 17 Jan 2016 10:04:49 +0000 From: Alexander Vainshtein To: "Nitish Gupta (nitisgup)" , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYiTS9LHO0Rck2198aSpBcKKZ5+EmUAgHxbjACABaF0QA== Date: Sun, 17 Jan 2016 10:04:49 +0000 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; x-originating-ip: [147.234.241.1] x-microsoft-exchange-diagnostics: 1; DB3PR03MB0779; 5:/mPBV0hzEUSwIS8CkX+j2l3LSNpLbOl1GbA+exRqdfsjgJSF0zFtxH0kHx6Ae7hhDr+yJTR1SQFJpHRo8B1hgdZnG58Kz4ih929p2H4R7QNq+E1S+mRfbCTG8uX4haw4m5vCKli+B8cuxQ/yqvD0Yg==; 24:NgrjrHk38C5ENJrQT5rkfeasAAALPsBn3/V0nAnfpRXtD9RCOoyTkRVhCVOqqm6Yf3FVks+EH4+9BhzGtMfmNXHJ9+O44MFQfYF100fM/HA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0779; x-ms-office365-filtering-correlation-id: 60f2bd5a-4012-498b-ae51-08d31f25a302 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001); SRVR:DB3PR03MB0779; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0779; x-forefront-prvs: 082465FB26 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(164054003)(53754006)(252514010)(479174004)(377424004)(199003)(189002)(377454003)(19580395003)(15975445007)(74316001)(4001150100001)(5001960100002)(6116002)(105586002)(4326007)(11100500001)(586003)(106116001)(101416001)(106356001)(2900100001)(5008740100001)(1720100001)(2950100001)(102836003)(19580405001)(5004730100002)(3846002)(54356999)(76176999)(87936001)(50986999)(66066001)(5003600100002)(5002640100001)(230783001)(1096002)(76576001)(1220700001)(33656002)(5001770100001)(97736004)(81156007)(92566002)(77096005)(10710500007)(10400500002)(2420400006)(2201001)(189998001)(122556002)(86362001)(2906002)(7110500001)(40100003)(2501003)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0779; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2016 10:04:49.5829 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0779 Archived-At: Cc: "jhaas@juniper.net" , "colin@doch.org.uk" , "Aditya Dogra \(addogra\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 10:04:57 -0000 Hi all, I have read the draft and I have one (presumably, minor) comment: - The IANA Considerations section of says that there are no IANA request. - At the same time the draft defines a new type of VRRP messages (2 - Backu= p Advertisement). As long as here was just one type of VRRP messages (1 - Advertisement), we = could avoid setting up a IANA registry for VRRP message types. If we are go= ing to have two, does not this justify setting up such a registry? Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nitish Gupta (= nitisgup) Sent: Wednesday, January 13, 2016 11:31 AM To: rtgwg@ietf.org; rtg-bfd@ietf.org Cc: jhaas@juniper.net; colin@doch.org.uk; Aditya Dogra (addogra) Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Hi, We had presented the Draft for VRRP BFD integration in IETF 93 and we had t= aken care of all the comments that came as part of the WG meeting. We had also merged the two drafts as per the comments in IETF 93: http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 We had presented the merged draft in IETF 94 and there were no specific com= ments on the draft. We would like to ask the RTGWG to adopt the Draft as a WG document. Thanks, Nitish On 26/10/15 11:57 am, "Nitish Gupta (nitisgup)" wrote: >Hi, > >We have submitted a new version of the draft. As discussed in IETF 93=20 >at prague. > >We have merged the following drafts: >http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 > >https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 > > > >We have also taken care of all the comments that were discussed in the=20 >RTGWG meeting. >We welcome any comments and suggestions on the draft. > >Thanks, >Nitish > >On 13/10/15 9:09 pm, "internet-drafts@ietf.org"=20 > >wrote: > >> >>A new version of I-D, draft-nitish-vrrp-bfd-02.txt has been=20 >>successfully submitted by Nitish Gupta and posted to the IETF=20 >>repository. >> >>Name: draft-nitish-vrrp-bfd >>Revision: 02 >>Title: Fast failure detection in VRRP with BFD >>Document date: 2015-10-13 >>Group: Individual Submission >>Pages: 10 >>URL: =20 >>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt >>Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ >>Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 >>Diff: =20 >>https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02 >> >>Abstract: >> This document describes how Bidirectional Forwarding Detection (BFD) >> can be used to support sub-second detection of a Master Router >> failure in the Virtual Router Redundancy Protocol (VRRP). >> >> =20 >> =20 >> >> >>Please note that it may take a couple of minutes from the time of=20 >>submission until the htmlized version and diff are available at=20 >>tools.ietf.org. >> >>The IETF Secretariat >> > From nobody Sun Jan 17 20:10:41 2016 Return-Path: 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 015971AD09C; Sun, 17 Jan 2016 20:10:39 -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 Xe4j9vOYn6XY; Sun, 17 Jan 2016 20:10:37 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::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 0B7991AD09A; Sun, 17 Jan 2016 20:10:37 -0800 (PST) Received: by mail-pa0-x232.google.com with SMTP id ho8so166084734pac.2; Sun, 17 Jan 2016 20:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=l8kE3X6k3znlLuMJvuH2hZe+k0vr/aSWYRvsVlAAYoo=; b=SrJEA4El9yc7tpj71a+RL1uh2EPN1edi7ln/YVc0vgtUPZMCv0rohdqEsXBfrIzg4Z Uv1eCLwqDqYdVU+gmHt8PZQ3DiPdvOrNT/NSGTL0WUg+LnUGTFanSfRurc12cEnHoF6q NlgCGTa9/FjsiYeJcOUAlCLFiudkIZXyB/AGPB/zIHvqleYe/52KOquEPbJvKwlZqevJ LJ1cz0qZhw+C56NTGUHFKXyFiSByKswJpDoLGKVP4hvs0PgICRr8FuyIcM4RV5YviIuL 72mdg7qJGmOqKk5v6DLG4dzI4hc2DV7gKZAOb67tJ5BmaGwBLAbi9b8KowNDfrUDelZ2 Ew/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=l8kE3X6k3znlLuMJvuH2hZe+k0vr/aSWYRvsVlAAYoo=; b=MejfCRkCDPDddHRAog1N+Cdboi4tag7BTN2gkdjWHy4De3hTh2wfMrcanOePUmqEa4 aeawP4g/41/U3VFtOCr/+SU63SNzwksGFB5RfTR+0bSWWqi4yixheRd5SjL+GnDXd8Cd rjgVDvf8COvzxmYoW+gBVQmMNuaQvq24RwJkBUMLu3L/8Y4jK8zcplB5SK8qQWd6zUE1 TJ3UXGdr45nznUyO+uasfaQv9v+QmT/sDC67LNkz0XEDaAyzvsxBQ+NfOx+ciNdIeEsA BOiFKVxMjjV0Wrm3ulYBMIWBtYYqNv/9JHhQn3OYtCP/xPvg0Z1swF61KsHe3t2yyps6 XcBA== X-Gm-Message-State: ALoCoQmsnhrBNImcMZiW3Rrd3u3GFtK8aMpkA5soIjZfTB3LYDfdvrPq4Hh/N4YxFLWrwlzYQy8dplrwaDHyGclcqaXR7vKErQ== X-Received: by 10.66.219.38 with SMTP id pl6mr33607384pac.147.1453090236719; Sun, 17 Jan 2016 20:10:36 -0800 (PST) Received: from ?IPv6:2001:420:c0c8:1003::227? ([2001:420:c0c8:1003::227]) by smtp.gmail.com with ESMTPSA id l73sm30049479pfi.37.2016.01.17.20.10.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 17 Jan 2016 20:10:35 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_38BC93E6-13F0-40D6-B3EB-067C5247136A" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt From: Mahesh Jethanandani In-Reply-To: Date: Sun, 17 Jan 2016 20:10:31 -0800 Message-Id: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> To: "Nitish Gupta (nitisgup)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "jhaas@juniper.net" , "rtg-bfd@ietf.org" , "Aditya Dogra \(addogra\)" , "colin@doch.org.uk" , "rtgwg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 04:10:39 -0000 --Apple-Mail=_38BC93E6-13F0-40D6-B3EB-067C5247136A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Shouldn=E2=80=99t the draft be named draft-nitish-bfd-vrrp or something = like that to follow the naming convention described in RFC 7221? > On Oct 25, 2015, at 11:27 PM, Nitish Gupta (nitisgup) = wrote: >=20 > Hi, >=20 > We have submitted a new version of the draft. As discussed in IETF 93 = at > prague. >=20 > We have merged the following drafts: > http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 >=20 > https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 >=20 >=20 >=20 > We have also taken care of all the comments that were discussed in the > RTGWG meeting. > We welcome any comments and suggestions on the draft. >=20 > Thanks, > Nitish >=20 > On 13/10/15 9:09 pm, "internet-drafts@ietf.org" = > wrote: >=20 >>=20 >> A new version of I-D, draft-nitish-vrrp-bfd-02.txt >> has been successfully submitted by Nitish Gupta and posted to the >> IETF repository. >>=20 >> Name: draft-nitish-vrrp-bfd >> Revision: 02 >> Title: Fast failure detection in VRRP with BFD >> Document date: 2015-10-13 >> Group: Individual Submission >> Pages: 10 >> URL: =20 >> https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt >> Status: = https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ >> Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 >> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02 >>=20 >> Abstract: >> This document describes how Bidirectional Forwarding Detection (BFD) >> can be used to support sub-second detection of a Master Router >> failure in the Virtual Router Redundancy Protocol (VRRP). >>=20 >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_38BC93E6-13F0-40D6-B3EB-067C5247136A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Shouldn=E2=80=99t the draft be named draft-nitish-bfd-vrrp or = something like that to follow the naming convention described in RFC = 7221?

On Oct 25, 2015, at 11:27 PM, Nitish Gupta = (nitisgup) <nitisgup@cisco.com> wrote:

Hi,

We have submitted a new version of the draft. As discussed in = IETF 93 at
prague.

We have = merged the following drafts:
http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01

https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case= -00



We have = also taken care of all the comments that were discussed in the
RTGWG meeting.
We welcome any comments and = suggestions on the draft.

Thanks,
Nitish

On 13/10/15 9:09 pm, = "internet-drafts@ietf.org" <internet-drafts@ietf.org>
wrote:


A new version of I-D, = draft-nitish-vrrp-bfd-02.txt
has been successfully = submitted by Nitish Gupta and posted to the
IETF = repository.

Name: = draft-nitish-vrrp-bfd
Revision: 02
Title:= = Fast failure detection in VRRP with BFD
Document = date: = 2015-10-13
Group: Individual Submission
Pages:= = 10
URL: =            
https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.t= xt
Status: =         https://datatracker.ietf.o= rg/doc/draft-nitish-vrrp-bfd/
Htmlized: =       https://tools.ietf.org/html/draft-niti= sh-vrrp-bfd-02
Diff: =           https://www.ie= tf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02

Abstract:
 This document describes how = Bidirectional Forwarding Detection (BFD)
 can be = used to support sub-second detection of a Master Router
=  failure in the Virtual Router Redundancy Protocol (VRRP).




Please note that it may take a couple of minutes from the = time of
submission
until the htmlized = version and diff are available at tools.ietf.org.

The IETF Secretariat



Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_38BC93E6-13F0-40D6-B3EB-067C5247136A-- From nobody Mon Jan 18 11:19:28 2016 Return-Path: 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 1945F1B3B71; Mon, 18 Jan 2016 10:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 2IBGFDngy5zk; Mon, 18 Jan 2016 10:38:46 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0108.outbound.protection.outlook.com [65.55.169.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC1001B3B73; Mon, 18 Jan 2016 10:38:45 -0800 (PST) Received: from DM2PR05MB623.namprd05.prod.outlook.com (10.141.157.24) by BLUPR0501MB1809.namprd05.prod.outlook.com (10.163.121.144) with Microsoft SMTP Server (TLS) id 15.1.365.19; Mon, 18 Jan 2016 18:38:41 +0000 Received: from DM2PR05MB623.namprd05.prod.outlook.com ([10.141.157.24]) by DM2PR05MB623.namprd05.prod.outlook.com ([10.141.157.24]) with mapi id 15.01.0361.006; Mon, 18 Jan 2016 18:38:41 +0000 From: Chris Bowers To: Mahesh Jethanandani , "Nitish Gupta (nitisgup)" Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYiTS9LHO0Rck2198aSpBcKKZ5+EmUAgIMthoCAAOOy8A== Date: Mon, 18 Jan 2016 18:38:40 +0000 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net; x-originating-ip: [66.129.239.14] x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1809; 5:RLPdjFPIUWnF4AVk6C7Qyj9GthdbSb4O8C5s1WAkYjV0VAk4PRymTrD1AbUus2KFcu9/JESjtwiS5YT97VZw7+Ero2UYYNd71JDhy5NH4F5rEslbuWbkIrFQQ+RmAijBWw7Z/HaKBprH0pn6X2R8ug==; 24:grt4AI3uMjUcgwHaLjz6F9O0XYWSluJDMuq6QWJYvUCOUoQOPrNK6BAQG3vi62S9DN6XmOU+HfjIX3qrOEO0qFjc/JdsjZzYLyR1A07dN18= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1809; x-ms-office365-filtering-correlation-id: d5222864-002e-447c-ca3d-08d32036967c x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BLUPR0501MB1809; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1809; x-forefront-prvs: 08252193F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(189002)(199003)(377454003)(479174004)(377424004)(24454002)(230783001)(19609705001)(1220700001)(5002640100001)(2950100001)(586003)(790700001)(97736004)(122556002)(5001770100001)(101416001)(81156007)(1096002)(10710500007)(102836003)(11100500001)(76576001)(4001150100001)(3846002)(4326007)(76176999)(5008740100001)(66066001)(19617315012)(5001960100002)(86362001)(19580395003)(10400500002)(2900100001)(33656002)(2420400006)(54356999)(50986999)(6116002)(92566002)(105586002)(77096005)(7110500001)(19580405001)(87936001)(99286002)(5004730100002)(15975445007)(19300405004)(2906002)(16236675004)(40100003)(106356001)(74316001)(5003600100002)(189998001)(19625215002)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1809; H:DM2PR05MB623.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_DM2PR05MB623370167984E7B510B3712A9C00DM2PR05MB623namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2016 18:38:40.9455 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1809 Archived-At: X-Mailman-Approved-At: Mon, 18 Jan 2016 11:19:27 -0800 Cc: Jeff Haas , "colin@doch.org.uk" , "rtg-bfd@ietf.org" , "Aditya Dogra \(addogra\)" , "rtgwg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 18:38:49 -0000 --_000_DM2PR05MB623370167984E7B510B3712A9C00DM2PR05MB623namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFoZXNoLA0KDQpBcyBJIHVuZGVyc3RhbmQgaXQsIHRoZSBhdXRob3JzIGV2ZW50dWFsbHkgd2Fu dCB0aGlzIGRyYWZ0IHRvIGJlIGFkb3B0ZWQgYnkgdGhlIFJUR1dHLiAgVGhpcyBtYWtlcyBzZW5z ZSBiZWNhdXNlIGl0IGluY2x1ZGVzIFZSUlAgcHJvdG9jb2wgZXh0ZW5zaW9ucywgc28gaXQgd291 bGQgbm9ybWFsbHkgZ28gdG8gdGhlIFZSUlAgV0cuICAgU2luY2UgdGhlIFZSUlAgV0cgaXMgY29u Y2x1ZGVkLCB0aGUgUlRHV0cgaXMgYSByZWFzb25hYmxlIHBsYWNlIHRvIGRvIHRoaXMgd29yay4N Cg0KT25lIG1pZ2h0IGFsc28gY29uc2lkZXIgZG9pbmcgdGhpcyB3b3JrIGluIHRoZSBCRkQgV0cg dG8gdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIGNvbmNlbnRyYXRpb24gb2YgQkZEIGV4cGVydGlzZSB0 aGVyZS4gIEhvd2V2ZXIsIHNpbmNlIHRoZSBtYWluIGNvbnRlbnQgb2YgdGhlIGRvY3VtZW50IGRl YWxzIHdpdGggVlJSUCBiZWhhdmlvciBhbmQgZGVmaW5pbmcgYSBuZXcgVlJSUCBwYWNrZXQgdHlw ZSwgaXQgc2VlbXMgbGlrZSBpdCBtaWdodCBiZSBhIGRpdmVyc2lvbiBmcm9tIHRoZSBtYWluIHdv cmsgb2YgdGhlIEJGRCBXRy4NCg0KSWYgdGhlIFJUR1dHIGRvZXMgYWRvcHQgdGhlIGRyYWZ0LCB0 aGUgbmFtZSBvZiB0aGUgYWRvcHRlZCBkcmFmdCBzaG91bGQgc3RhcnQgd2l0aCBkcmFmdC1pZXRm LXJ0Z3dnIChhcyB5b3UgcG9pbnQgb3V0LCBmb2xsb3dpbmcgUkZDNzIyMSkuDQoNCkFzIGFuIGlu ZGl2aWR1YWwgc3VibWlzc2lvbiBhdCB0aGlzIHBvaW50LCB0aGVyZSBhcmUgbm8gaGFyZCByZXF1 aXJlbWVudHMgb24gdGhlIG5hbWUgb2YgdGhlIGRyYWZ0LCBleGNlcHQgdGhhdCBpdCBub3Qgc3Rh cnQgd2l0aCBkcmFmdC1pZXRmLiAgSG93ZXZlciwgd2hlbiBhdXRob3JzIGFyZSBzdWJtaXR0aW5n IGRyYWZ0cyB0aGF0IHRoZXkgaW50ZW5kIHRvIGV2ZW50dWFsbHkgYmUgY29uc2lkZXJlZCBmb3Ig YWRvcHRpb24gYnkgdGhlIFJUR1dHLCBpdCBpcyBxdWl0ZSB1c2VmdWwgdG8gbmFtZSB0aGVtIGRy YWZ0LWF1dGhvcm5hbWUtcnRnd2cteXl5eSwgc28gdGhhdCB0aGV5IGF1dG9tYXRpY2FsbHkgc2hv dyB1cCBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3J0Z3dnL2RvY3VtZW50cy8g YXQgdGhlIGJvdHRvbSB1bmRlciB0aGUgaGVhZGVyIG9mIOKAnFJlbGF0ZWQgSW50ZXJuZXQtRHJh ZnRz4oCdLg0KDQpUaGFua3MsDQpDaHJpcw0KDQpGcm9tOiBydGd3ZyBbbWFpbHRvOnJ0Z3dnLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYWhlc2ggSmV0aGFuYW5kYW5pDQpTZW50OiBT dW5kYXksIEphbnVhcnkgMTcsIDIwMTYgMTA6MTEgUE0NClRvOiBOaXRpc2ggR3VwdGEgKG5pdGlz Z3VwKSA8bml0aXNndXBAY2lzY28uY29tPg0KQ2M6IEplZmYgSGFhcyA8amhhYXNAanVuaXBlci5u ZXQ+OyBydGctYmZkQGlldGYub3JnOyBBZGl0eWEgRG9ncmEgKGFkZG9ncmEpIDxhZGRvZ3JhQGNp c2NvLmNvbT47IGNvbGluQGRvY2gub3JnLnVrOyBydGd3Z0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbml0aXNoLXZycnAtYmZkLTAyLnR4 dA0KDQpTaG91bGRu4oCZdCB0aGUgZHJhZnQgYmUgbmFtZWQgZHJhZnQtbml0aXNoLWJmZC12cnJw IG9yIHNvbWV0aGluZyBsaWtlIHRoYXQgdG8gZm9sbG93IHRoZSBuYW1pbmcgY29udmVudGlvbiBk ZXNjcmliZWQgaW4gUkZDIDcyMjE/DQoNCk9uIE9jdCAyNSwgMjAxNSwgYXQgMTE6MjcgUE0sIE5p dGlzaCBHdXB0YSAobml0aXNndXApIDxuaXRpc2d1cEBjaXNjby5jb208bWFpbHRvOm5pdGlzZ3Vw QGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpIaSwNCg0KV2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVy c2lvbiBvZiB0aGUgZHJhZnQuIEFzIGRpc2N1c3NlZCBpbiBJRVRGIDkzIGF0DQpwcmFndWUuDQoN CldlIGhhdmUgbWVyZ2VkIHRoZSBmb2xsb3dpbmcgZHJhZnRzOg0KaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtbml0aXNoLXZycnAtYmZkLTAxDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1taXJza3ktYmZkLXAybXAtdnJycC11c2UtY2FzZS0wMA0KDQoNCg0KV2Ug aGF2ZSBhbHNvIHRha2VuIGNhcmUgb2YgYWxsIHRoZSBjb21tZW50cyB0aGF0IHdlcmUgZGlzY3Vz c2VkIGluIHRoZQ0KUlRHV0cgbWVldGluZy4NCldlIHdlbGNvbWUgYW55IGNvbW1lbnRzIGFuZCBz dWdnZXN0aW9ucyBvbiB0aGUgZHJhZnQuDQoNClRoYW5rcywNCk5pdGlzaA0KDQpPbiAxMy8xMC8x NSA5OjA5IHBtLCAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+IiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc+Pg0Kd3JvdGU6DQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtbml0aXNoLXZycnAtYmZkLTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBOaXRpc2ggR3VwdGEgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0K TmFtZTogICAgICAgICAgICAgIGRyYWZ0LW5pdGlzaC12cnJwLWJmZA0KUmV2aXNpb246ICAgICAg ICAgMDINClRpdGxlOiAgICAgICAgICAgICAgICBGYXN0IGZhaWx1cmUgZGV0ZWN0aW9uIGluIFZS UlAgd2l0aCBCRkQNCkRvY3VtZW50IGRhdGU6ICAgICAgICAgIDIwMTUtMTAtMTMNCkdyb3VwOiAg ICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAgICAgMTAN ClVSTDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1uaXRpc2gt dnJycC1iZmQtMDIudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtbml0aXNoLXZycnAtYmZkLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1uaXRpc2gtdnJycC1iZmQtMDINCkRpZmY6ICAgICAg ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbml0aXNoLXZycnAt YmZkLTAyDQoNCkFic3RyYWN0Og0KIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyBCaWRpcmVj dGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpDQogY2FuIGJlIHVzZWQgdG8gc3VwcG9y dCBzdWItc2Vjb25kIGRldGVjdGlvbiBvZiBhIE1hc3RlciBSb3V0ZXINCiBmYWlsdXJlIGluIHRo ZSBWaXJ0dWFsIFJvdXRlciBSZWR1bmRhbmN5IFByb3RvY29sIChWUlJQKS4NCg0KDQoNCg0KDQpQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZg0Kc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQN Cg0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86 bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQoNCg0KDQoNCg== --_000_DM2PR05MB623370167984E7B510B3712A9C00DM2PR05MB623namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmFwcGxlLXRhYi1zcGFu DQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5NYWhlc2gsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5BcyBJIHVuZGVyc3RhbmQgaXQsIHRoZSBhdXRob3JzIGV2ZW50dWFsbHkgd2FudCB0 aGlzIGRyYWZ0IHRvIGJlIGFkb3B0ZWQgYnkgdGhlIFJUR1dHLiZuYnNwOyBUaGlzIG1ha2VzIHNl bnNlIGJlY2F1c2UgaXQgaW5jbHVkZXMgVlJSUCBwcm90b2NvbCBleHRlbnNpb25zLCBzbyBpdCB3 b3VsZA0KIG5vcm1hbGx5IGdvIHRvIHRoZSBWUlJQIFdHLiAmbmJzcDsmbmJzcDtTaW5jZSB0aGUg VlJSUCBXRyBpcyBjb25jbHVkZWQsIHRoZSBSVEdXRyBpcyBhIHJlYXNvbmFibGUgcGxhY2UgdG8g ZG8gdGhpcyB3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ T25lIG1pZ2h0IGFsc28gY29uc2lkZXIgZG9pbmcgdGhpcyB3b3JrIGluIHRoZSBCRkQgV0cgdG8g dGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIGNvbmNlbnRyYXRpb24gb2YgQkZEIGV4cGVydGlzZSB0aGVy ZS4mbmJzcDsgSG93ZXZlciwgc2luY2UgdGhlIG1haW4gY29udGVudCBvZiB0aGUgZG9jdW1lbnQN CiBkZWFscyB3aXRoIFZSUlAgYmVoYXZpb3IgYW5kIGRlZmluaW5nIGEgbmV3IFZSUlAgcGFja2V0 IHR5cGUsIGl0IHNlZW1zIGxpa2UgaXQgbWlnaHQgYmUgYSBkaXZlcnNpb24gZnJvbSB0aGUgbWFp biB3b3JrIG9mIHRoZSBCRkQgV0cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JZiB0aGUgUlRHV0cgZG9lcyBhZG9wdCB0aGUgZHJhZnQsIHRoZSBuYW1lIG9mIHRo ZSBhZG9wdGVkIGRyYWZ0IHNob3VsZCBzdGFydCB3aXRoIGRyYWZ0LWlldGYtcnRnd2cgKGFzIHlv dSBwb2ludCBvdXQsIGZvbGxvd2luZyBSRkM3MjIxKS4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QXMgYW4gaW5kaXZpZHVhbCBzdWJtaXNzaW9uIGF0 IHRoaXMgcG9pbnQsIHRoZXJlIGFyZSBubyBoYXJkIHJlcXVpcmVtZW50cyBvbiB0aGUgbmFtZSBv ZiB0aGUgZHJhZnQsIGV4Y2VwdCB0aGF0IGl0IG5vdCBzdGFydCB3aXRoIGRyYWZ0LWlldGYuJm5i c3A7IEhvd2V2ZXIsIHdoZW4gYXV0aG9ycw0KIGFyZSBzdWJtaXR0aW5nIGRyYWZ0cyB0aGF0IHRo ZXkgaW50ZW5kIHRvIGV2ZW50dWFsbHkgYmUgY29uc2lkZXJlZCBmb3IgYWRvcHRpb24gYnkgdGhl IFJUR1dHLCBpdCBpcyBxdWl0ZSB1c2VmdWwgdG8gbmFtZSB0aGVtIGRyYWZ0LWF1dGhvcm5hbWUt cnRnd2cteXl5eSwgc28gdGhhdCB0aGV5IGF1dG9tYXRpY2FsbHkgc2hvdyB1cCBhdA0KPGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9ydGd3Zy9kb2N1bWVudHMvIj5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3J0Z3dnL2RvY3VtZW50cy88L2E+IGF0IHRoZSBi b3R0b20gdW5kZXIgdGhlIGhlYWRlciBvZiDigJxSZWxhdGVkIEludGVybmV0LURyYWZ0c+KAnS4m bmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5DaHJpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4gcnRnd2cgW21haWx0bzpydGd3Zy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5NYWhlc2ggSmV0aGFuYW5kYW5pPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRh eSwgSmFudWFyeSAxNywgMjAxNiAxMDoxMSBQTTxicj4NCjxiPlRvOjwvYj4gTml0aXNoIEd1cHRh IChuaXRpc2d1cCkgJmx0O25pdGlzZ3VwQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEpl ZmYgSGFhcyAmbHQ7amhhYXNAanVuaXBlci5uZXQmZ3Q7OyBydGctYmZkQGlldGYub3JnOyBBZGl0 eWEgRG9ncmEgKGFkZG9ncmEpICZsdDthZGRvZ3JhQGNpc2NvLmNvbSZndDs7IGNvbGluQGRvY2gu b3JnLnVrOyBydGd3Z0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1uaXRpc2gtdnJycC1iZmQtMDIudHh0PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2hvdWxkbuKAmXQgdGhlIGRy YWZ0IGJlIG5hbWVkIGRyYWZ0LW5pdGlzaC1iZmQtdnJycCBvciBzb21ldGhpbmcgbGlrZSB0aGF0 IHRvIGZvbGxvdyB0aGUgbmFtaW5nIGNvbnZlbnRpb24gZGVzY3JpYmVkIGluIFJGQyA3MjIxPzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE9jdCAyNSwg MjAxNSwgYXQgMTE6MjcgUE0sIE5pdGlzaCBHdXB0YSAobml0aXNndXApICZsdDs8YSBocmVmPSJt YWlsdG86bml0aXNndXBAY2lzY28uY29tIj5uaXRpc2d1cEBjaXNjby5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPGJyPg0KPGJyPg0K V2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQuIEFzIGRpc2N1c3Nl ZCBpbiBJRVRGIDkzIGF0PGJyPg0KcHJhZ3VlLjxicj4NCjxicj4NCldlIGhhdmUgbWVyZ2VkIHRo ZSBmb2xsb3dpbmcgZHJhZnRzOjxicj4NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LW5pdGlzaC12cnJwLWJmZC0wMSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtbml0aXNoLXZycnAtYmZkLTAxPC9hPjxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1taXJza3ktYmZkLXAybXAtdnJycC11c2UtY2FzZS0w MCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1pcnNreS1iZmQtcDJtcC12cnJw LXVzZS1jYXNlLTAwPC9hPjxicj4NCjxicj4NCjxicj4NCjxicj4NCldlIGhhdmUgYWxzbyB0YWtl biBjYXJlIG9mIGFsbCB0aGUgY29tbWVudHMgdGhhdCB3ZXJlIGRpc2N1c3NlZCBpbiB0aGU8YnI+ DQpSVEdXRyBtZWV0aW5nLjxicj4NCldlIHdlbGNvbWUgYW55IGNvbW1lbnRzIGFuZCBzdWdnZXN0 aW9ucyBvbiB0aGUgZHJhZnQuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCk5pdGlzaDxicj4NCjxi cj4NCk9uIDEzLzEwLzE1IDk6MDkgcG0sICZxdW90OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0Kd3JvdGU6PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW5pdGlzaC12cnJwLWJmZC0wMi50eHQ8 YnI+DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE5pdGlzaCBHdXB0YSBhbmQg cG9zdGVkIHRvIHRoZTxicj4NCklFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOjxzcGFu IGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5kcmFm dC1uaXRpc2gtdnJycC1iZmQ8YnI+DQpSZXZpc2lvbjo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNw YW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3Nw YW4+MDI8YnI+DQpUaXRsZTo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+RmFzdCBmYWlsdXJlIGRldGVjdGlvbiBpbiBW UlJQIHdpdGggQkZEPGJyPg0KRG9jdW1lbnQgZGF0ZTo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNw YW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8L3NwYW4+MjAxNS0xMC0xMzxicj4NCkdyb3VwOjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3Bh biI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5JbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQpQYWdl czo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3Nw YW4+MTA8YnI+DQpVUkw6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1uaXRpc2gtdnJycC1iZmQtMDIudHh0Ij5odHRwczov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbml0aXNoLXZycnAtYmZkLTAyLnR4 dDwvYT48YnI+DQpTdGF0dXM6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LW5pdGlzaC12cnJwLWJmZC8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LW5pdGlzaC12cnJwLWJmZC88L2E+PGJyPg0KSHRtbGl6ZWQ6ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1uaXRpc2gtdnJycC1iZmQtMDIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1u aXRpc2gtdnJycC1iZmQtMDI8L2E+PGJyPg0KRGlmZjogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW5pdGlzaC12cnJwLWJmZC0wMiI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW5pdGlzaC12cnJwLWJmZC0wMjwvYT48YnI+ DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQombmJzcDtUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cg QmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKTxicj4NCiZuYnNwO2NhbiBi ZSB1c2VkIHRvIHN1cHBvcnQgc3ViLXNlY29uZCBkZXRlY3Rpb24gb2YgYSBNYXN0ZXIgUm91dGVy PGJyPg0KJm5ic3A7ZmFpbHVyZSBpbiB0aGUgVmlydHVhbCBSb3V0ZXIgUmVkdW5kYW5jeSBQcm90 b2NvbCAoVlJSUCkuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Y8 YnI+DQpzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNy ZXRhcmlhdDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5NYWhlc2ggSmV0aGFuYW5kYW5pPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBo cmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iPm1qZXRoYW5hbmRhbmlAZ21haWwu Y29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM2PR05MB623370167984E7B510B3712A9C00DM2PR05MB623namprd_-- From nobody Mon Jan 18 11:19:29 2016 Return-Path: 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 5FDFC1B3C08; Mon, 18 Jan 2016 11:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 f1_6dth-mDCm; Mon, 18 Jan 2016 11:13:27 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 098861B3C06; Mon, 18 Jan 2016 11:13:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23723; q=dns/txt; s=iport; t=1453144407; x=1454354007; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1ZVHV+RkMiwTZDNh7VaFUg1KI47+ZFvoGgxJKcpVUjQ=; b=CpijbAxNWUlpSw0cuzApu1XAYY9Fzmxp+XDRYtl09JUcgwK5lEw7TOTi E5nEEIKNhXFInxxdlQURu60RAGK0JobJvUWXa/0X6NyHYkMCeSk2rriq3 EXlo0LcBcdC1DLHOGxhj6GMs7iiFfze4J6Q7KebSR7XP8R471FOC+BhfZ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5AQCdOJ1W/4YNJK1egm5MUm0GiFCzR?= =?us-ascii?q?QENgWMihW0CHIEbOBQBAQEBAQEBgQqENAEBAQQjCj4MAhACAQgOAwMBAQEoAwI?= =?us-ascii?q?CAh8RFAkIAgQBDQWIBgMSDq8TjDUNg0cBAQEBAQEBAQEBAQEBAQEBAQEBAQEYi?= =?us-ascii?q?1SCT4IeCg0JCIJfgUkFjUKJWAGFR4YfgXiBXkqDeohfhn+HXQERDwEBQoQLcgG?= =?us-ascii?q?GM4EIAQEB?= X-IronPort-AV: E=Sophos; i="5.22,313,1449532800"; d="scan'208,217"; a="68140074" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jan 2016 19:13:25 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u0IJDPcl003959 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Jan 2016 19:13:25 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 18 Jan 2016 14:13:24 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Mon, 18 Jan 2016 14:13:24 -0500 From: "Acee Lindem (acee)" To: Chris Bowers , Mahesh Jethanandani , "Nitish Gupta (nitisgup)" Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRUaYrTS9LHO0Rck2198aSpBcKKZ8B72sA//+13AA= Date: Mon, 18 Jan 2016 19:13:24 +0000 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.205] Content-Type: multipart/alternative; boundary="_000_D2C2A3524A104aceeciscocom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 18 Jan 2016 11:19:27 -0800 Cc: Jeff Haas , "colin@doch.org.uk" , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" , "Aditya Dogra \(addogra\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 19:13:30 -0000 --_000_D2C2A3524A104aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2hyaXMsIE1haGVzaCwNCkkgYWdyZWUgd2l0aCB0aGlzIGNoYXJhY3Rlcml6YXRpb24gb2YgdGhl IGRyYWZ0IGFuZCBiZWxpZXZlIHRoYXQsIGlmIGFkb3B0ZWQsIGl0IGJlbG9uZ3MgaW4gdGhlIFJU RyBXRy4NClRoYW5rcywNCkFjZWUNCg0KDQpGcm9tOiBydGd3ZyA8cnRnd2ctYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86cnRnd2ctYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBDaHJpcyBC b3dlcnMgPGNib3dlcnNAanVuaXBlci5uZXQ8bWFpbHRvOmNib3dlcnNAanVuaXBlci5uZXQ+Pg0K RGF0ZTogTW9uZGF5LCBKYW51YXJ5IDE4LCAyMDE2IGF0IDE6MzggUE0NClRvOiBNYWhlc2ggSmV0 aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBn bWFpbC5jb20+PiwgIk5pdGlzaCBHdXB0YSAobml0aXNndXApIiA8bml0aXNndXBAY2lzY28uY29t PG1haWx0bzpuaXRpc2d1cEBjaXNjby5jb20+Pg0KQ2M6IEplZmYgSGFhcyA8amhhYXNAanVuaXBl ci5uZXQ8bWFpbHRvOmpoYWFzQGp1bmlwZXIubmV0Pj4sICJjb2xpbkBkb2NoLm9yZy51azxtYWls dG86Y29saW5AZG9jaC5vcmcudWs+IiA8Y29saW5AZG9jaC5vcmcudWs8bWFpbHRvOmNvbGluQGRv Y2gub3JnLnVrPj4sICJydGctYmZkQGlldGYub3JnPG1haWx0bzpydGctYmZkQGlldGYub3JnPiIg PHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+PiwgIkFkaXR5YSBEb2dy YSAoYWRkb2dyYSkiIDxhZGRvZ3JhQGNpc2NvLmNvbTxtYWlsdG86YWRkb2dyYUBjaXNjby5jb20+ PiwgUm91dGluZyBXRyA8cnRnd2dAaWV0Zi5vcmc8bWFpbHRvOnJ0Z3dnQGlldGYub3JnPj4NClN1 YmplY3Q6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW5pdGlzaC12cnJw LWJmZC0wMi50eHQNCg0KTWFoZXNoLA0KDQpBcyBJIHVuZGVyc3RhbmQgaXQsIHRoZSBhdXRob3Jz IGV2ZW50dWFsbHkgd2FudCB0aGlzIGRyYWZ0IHRvIGJlIGFkb3B0ZWQgYnkgdGhlIFJUR1dHLiAg VGhpcyBtYWtlcyBzZW5zZSBiZWNhdXNlIGl0IGluY2x1ZGVzIFZSUlAgcHJvdG9jb2wgZXh0ZW5z aW9ucywgc28gaXQgd291bGQgbm9ybWFsbHkgZ28gdG8gdGhlIFZSUlAgV0cuICAgU2luY2UgdGhl IFZSUlAgV0cgaXMgY29uY2x1ZGVkLCB0aGUgUlRHV0cgaXMgYSByZWFzb25hYmxlIHBsYWNlIHRv IGRvIHRoaXMgd29yay4NCg0KT25lIG1pZ2h0IGFsc28gY29uc2lkZXIgZG9pbmcgdGhpcyB3b3Jr IGluIHRoZSBCRkQgV0cgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIGNvbmNlbnRyYXRpb24gb2Yg QkZEIGV4cGVydGlzZSB0aGVyZS4gIEhvd2V2ZXIsIHNpbmNlIHRoZSBtYWluIGNvbnRlbnQgb2Yg dGhlIGRvY3VtZW50IGRlYWxzIHdpdGggVlJSUCBiZWhhdmlvciBhbmQgZGVmaW5pbmcgYSBuZXcg VlJSUCBwYWNrZXQgdHlwZSwgaXQgc2VlbXMgbGlrZSBpdCBtaWdodCBiZSBhIGRpdmVyc2lvbiBm cm9tIHRoZSBtYWluIHdvcmsgb2YgdGhlIEJGRCBXRy4NCg0KSWYgdGhlIFJUR1dHIGRvZXMgYWRv cHQgdGhlIGRyYWZ0LCB0aGUgbmFtZSBvZiB0aGUgYWRvcHRlZCBkcmFmdCBzaG91bGQgc3RhcnQg d2l0aCBkcmFmdC1pZXRmLXJ0Z3dnIChhcyB5b3UgcG9pbnQgb3V0LCBmb2xsb3dpbmcgUkZDNzIy MSkuDQoNCkFzIGFuIGluZGl2aWR1YWwgc3VibWlzc2lvbiBhdCB0aGlzIHBvaW50LCB0aGVyZSBh cmUgbm8gaGFyZCByZXF1aXJlbWVudHMgb24gdGhlIG5hbWUgb2YgdGhlIGRyYWZ0LCBleGNlcHQg dGhhdCBpdCBub3Qgc3RhcnQgd2l0aCBkcmFmdC1pZXRmLiAgSG93ZXZlciwgd2hlbiBhdXRob3Jz IGFyZSBzdWJtaXR0aW5nIGRyYWZ0cyB0aGF0IHRoZXkgaW50ZW5kIHRvIGV2ZW50dWFsbHkgYmUg Y29uc2lkZXJlZCBmb3IgYWRvcHRpb24gYnkgdGhlIFJUR1dHLCBpdCBpcyBxdWl0ZSB1c2VmdWwg dG8gbmFtZSB0aGVtIGRyYWZ0LWF1dGhvcm5hbWUtcnRnd2cteXl5eSwgc28gdGhhdCB0aGV5IGF1 dG9tYXRpY2FsbHkgc2hvdyB1cCBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3J0 Z3dnL2RvY3VtZW50cy8gYXQgdGhlIGJvdHRvbSB1bmRlciB0aGUgaGVhZGVyIG9mIOKAnFJlbGF0 ZWQgSW50ZXJuZXQtRHJhZnRz4oCdLg0KDQpUaGFua3MsDQpDaHJpcw0KDQpGcm9tOiBydGd3ZyBb bWFpbHRvOnJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYWhlc2ggSmV0aGFu YW5kYW5pDQpTZW50OiBTdW5kYXksIEphbnVhcnkgMTcsIDIwMTYgMTA6MTEgUE0NClRvOiBOaXRp c2ggR3VwdGEgKG5pdGlzZ3VwKSA8bml0aXNndXBAY2lzY28uY29tPG1haWx0bzpuaXRpc2d1cEBj aXNjby5jb20+Pg0KQ2M6IEplZmYgSGFhcyA8amhhYXNAanVuaXBlci5uZXQ8bWFpbHRvOmpoYWFz QGp1bmlwZXIubmV0Pj47IHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+ OyBBZGl0eWEgRG9ncmEgKGFkZG9ncmEpIDxhZGRvZ3JhQGNpc2NvLmNvbTxtYWlsdG86YWRkb2dy YUBjaXNjby5jb20+PjsgY29saW5AZG9jaC5vcmcudWs8bWFpbHRvOmNvbGluQGRvY2gub3JnLnVr PjsgcnRnd2dAaWV0Zi5vcmc8bWFpbHRvOnJ0Z3dnQGlldGYub3JnPg0KU3ViamVjdDogUmU6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbml0aXNoLXZycnAtYmZkLTAyLnR4dA0K DQpTaG91bGRu4oCZdCB0aGUgZHJhZnQgYmUgbmFtZWQgZHJhZnQtbml0aXNoLWJmZC12cnJwIG9y IHNvbWV0aGluZyBsaWtlIHRoYXQgdG8gZm9sbG93IHRoZSBuYW1pbmcgY29udmVudGlvbiBkZXNj cmliZWQgaW4gUkZDIDcyMjE/DQoNCk9uIE9jdCAyNSwgMjAxNSwgYXQgMTE6MjcgUE0sIE5pdGlz aCBHdXB0YSAobml0aXNndXApIDxuaXRpc2d1cEBjaXNjby5jb208bWFpbHRvOm5pdGlzZ3VwQGNp c2NvLmNvbT4+IHdyb3RlOg0KDQpIaSwNCg0KV2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lv biBvZiB0aGUgZHJhZnQuIEFzIGRpc2N1c3NlZCBpbiBJRVRGIDkzIGF0DQpwcmFndWUuDQoNCldl IGhhdmUgbWVyZ2VkIHRoZSBmb2xsb3dpbmcgZHJhZnRzOg0KaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtbml0aXNoLXZycnAtYmZkLTAxDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1taXJza3ktYmZkLXAybXAtdnJycC11c2UtY2FzZS0wMA0KDQoNCg0KV2UgaGF2 ZSBhbHNvIHRha2VuIGNhcmUgb2YgYWxsIHRoZSBjb21tZW50cyB0aGF0IHdlcmUgZGlzY3Vzc2Vk IGluIHRoZQ0KUlRHV0cgbWVldGluZy4NCldlIHdlbGNvbWUgYW55IGNvbW1lbnRzIGFuZCBzdWdn ZXN0aW9ucyBvbiB0aGUgZHJhZnQuDQoNClRoYW5rcywNCk5pdGlzaA0KDQpPbiAxMy8xMC8xNSA5 OjA5IHBtLCAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc+IiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+Pg0Kd3JvdGU6DQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt bml0aXNoLXZycnAtYmZkLTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBOaXRpc2ggR3VwdGEgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFt ZTogICAgICAgICAgICAgIGRyYWZ0LW5pdGlzaC12cnJwLWJmZA0KUmV2aXNpb246ICAgICAgICAg MDINClRpdGxlOiAgICAgICAgICAgICAgICBGYXN0IGZhaWx1cmUgZGV0ZWN0aW9uIGluIFZSUlAg d2l0aCBCRkQNCkRvY3VtZW50IGRhdGU6ICAgICAgICAgIDIwMTUtMTAtMTMNCkdyb3VwOiAgICAg ICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAgICAgMTANClVS TDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1uaXRpc2gtdnJy cC1iZmQtMDIudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtbml0aXNoLXZycnAtYmZkLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1uaXRpc2gtdnJycC1iZmQtMDINCkRpZmY6ICAgICAgICAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbml0aXNoLXZycnAtYmZk LTAyDQoNCkFic3RyYWN0Og0KIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyBCaWRpcmVjdGlv bmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpDQogY2FuIGJlIHVzZWQgdG8gc3VwcG9ydCBz dWItc2Vjb25kIGRldGVjdGlvbiBvZiBhIE1hc3RlciBSb3V0ZXINCiBmYWlsdXJlIGluIHRoZSBW aXJ0dWFsIFJvdXRlciBSZWR1bmRhbmN5IFByb3RvY29sIChWUlJQKS4NCg0KDQoNCg0KDQpQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZg0Kc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K DQpNYWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpl dGhhbmFuZGFuaUBnbWFpbC5jb20+DQoNCg0KDQoNCg== --_000_D2C2A3524A104aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <87419EF930490F41BEAB99E8CBF74C6D@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5DaHJpcywgTWFo ZXNoLCZuYnNwOzwvZGl2Pg0KPGRpdj5JIGFncmVlIHdpdGggdGhpcyBjaGFyYWN0ZXJpemF0aW9u IG9mIHRoZSBkcmFmdCBhbmQgYmVsaWV2ZSB0aGF0LCBpZiBhZG9wdGVkLCBpdCBiZWxvbmdzIGlu IHRoZSBSVEcgV0cuJm5ic3A7PC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+QWNlZTwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xL X1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9u dC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006 IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAw aW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNi NWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDog M3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+cnRnd2cg Jmx0OzxhIGhyZWY9Im1haWx0bzpydGd3Zy1ib3VuY2VzQGlldGYub3JnIj5ydGd3Zy1ib3VuY2Vz QGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIENocmlzIEJvd2VycyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmNib3dlcnNAanVuaXBlci5uZXQiPmNib3dlcnNAanVuaXBlci5uZXQ8L2E+Jmd0Ozxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+TW9uZGF5LCBK YW51YXJ5IDE4LCAyMDE2IGF0IDE6MzggUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+VG86IDwvc3Bhbj5NYWhlc2ggSmV0aGFuYW5kYW5pICZsdDs8YSBocmVmPSJtYWlsdG86 bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPiZndDss ICZxdW90O05pdGlzaCBHdXB0YSAobml0aXNndXApJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 bml0aXNndXBAY2lzY28uY29tIj5uaXRpc2d1cEBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPkplZmYgSGFhcyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmpoYWFzQGp1bmlwZXIubmV0Ij5qaGFhc0BqdW5pcGVyLm5ldDwvYT4mZ3Q7LCAm cXVvdDs8YSBocmVmPSJtYWlsdG86Y29saW5AZG9jaC5vcmcudWsiPmNvbGluQGRvY2gub3JnLnVr PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvbGluQGRvY2gub3JnLnVrIj5jb2xpbkBk b2NoLm9yZy51azwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9y ZyI+cnRnLWJmZEBpZXRmLm9yZzwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1i ZmRAaWV0Zi5vcmciPnJ0Zy1iZmRAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7QWRpdHlhIERvZ3Jh IChhZGRvZ3JhKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkZG9ncmFAY2lzY28uY29tIj5h ZGRvZ3JhQGNpc2NvLmNvbTwvYT4mZ3Q7LCBSb3V0aW5nIFdHICZsdDs8YSBocmVmPSJtYWlsdG86 cnRnd2dAaWV0Zi5vcmciPnJ0Z3dnQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJFOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LW5pdGlzaC12cnJwLWJmZC0wMi50eHQ8YnI+DQo8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxP Q0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAw IDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9m ZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8bWV0YSBuYW1lPSJHZW5l cmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS10YWIt c3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUx OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5NYWhlc2gsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5BcyBJIHVuZGVyc3RhbmQgaXQsIHRoZSBhdXRob3JzIGV2ZW50dWFsbHkgd2FudCB0aGlzIGRy YWZ0IHRvIGJlIGFkb3B0ZWQgYnkgdGhlIFJUR1dHLiZuYnNwOyBUaGlzIG1ha2VzIHNlbnNlIGJl Y2F1c2UgaXQgaW5jbHVkZXMgVlJSUCBwcm90b2NvbCBleHRlbnNpb25zLCBzbyBpdCB3b3VsZA0K IG5vcm1hbGx5IGdvIHRvIHRoZSBWUlJQIFdHLiAmbmJzcDsmbmJzcDtTaW5jZSB0aGUgVlJSUCBX RyBpcyBjb25jbHVkZWQsIHRoZSBSVEdXRyBpcyBhIHJlYXNvbmFibGUgcGxhY2UgdG8gZG8gdGhp cyB3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+T25lIG1p Z2h0IGFsc28gY29uc2lkZXIgZG9pbmcgdGhpcyB3b3JrIGluIHRoZSBCRkQgV0cgdG8gdGFrZSBh ZHZhbnRhZ2Ugb2YgdGhlIGNvbmNlbnRyYXRpb24gb2YgQkZEIGV4cGVydGlzZSB0aGVyZS4mbmJz cDsgSG93ZXZlciwgc2luY2UgdGhlIG1haW4gY29udGVudCBvZiB0aGUgZG9jdW1lbnQNCiBkZWFs cyB3aXRoIFZSUlAgYmVoYXZpb3IgYW5kIGRlZmluaW5nIGEgbmV3IFZSUlAgcGFja2V0IHR5cGUs IGl0IHNlZW1zIGxpa2UgaXQgbWlnaHQgYmUgYSBkaXZlcnNpb24gZnJvbSB0aGUgbWFpbiB3b3Jr IG9mIHRoZSBCRkQgV0cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5JZiB0aGUgUlRHV0cgZG9lcyBhZG9wdCB0aGUgZHJhZnQsIHRoZSBuYW1lIG9mIHRoZSBhZG9w dGVkIGRyYWZ0IHNob3VsZCBzdGFydCB3aXRoIGRyYWZ0LWlldGYtcnRnd2cgKGFzIHlvdSBwb2lu dCBvdXQsIGZvbGxvd2luZyBSRkM3MjIxKS4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+QXMgYW4gaW5kaXZpZHVhbCBzdWJtaXNzaW9uIGF0IHRoaXMg cG9pbnQsIHRoZXJlIGFyZSBubyBoYXJkIHJlcXVpcmVtZW50cyBvbiB0aGUgbmFtZSBvZiB0aGUg ZHJhZnQsIGV4Y2VwdCB0aGF0IGl0IG5vdCBzdGFydCB3aXRoIGRyYWZ0LWlldGYuJm5ic3A7IEhv d2V2ZXIsIHdoZW4gYXV0aG9ycw0KIGFyZSBzdWJtaXR0aW5nIGRyYWZ0cyB0aGF0IHRoZXkgaW50 ZW5kIHRvIGV2ZW50dWFsbHkgYmUgY29uc2lkZXJlZCBmb3IgYWRvcHRpb24gYnkgdGhlIFJUR1dH LCBpdCBpcyBxdWl0ZSB1c2VmdWwgdG8gbmFtZSB0aGVtIGRyYWZ0LWF1dGhvcm5hbWUtcnRnd2ct eXl5eSwgc28gdGhhdCB0aGV5IGF1dG9tYXRpY2FsbHkgc2hvdyB1cCBhdA0KPGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9ydGd3Zy9kb2N1bWVudHMvIj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL3dnL3J0Z3dnL2RvY3VtZW50cy88L2E+IGF0IHRoZSBib3R0b20g dW5kZXIgdGhlIGhlYWRlciBvZiDigJxSZWxhdGVkIEludGVybmV0LURyYWZ0c+KAnS4mbmJzcDsN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5DaHJpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gcnRnd2cgWzxhIGhyZWY9Im1haWx0bzpydGd3Zy1ib3VuY2VzQGlldGYub3JnIj5tYWls dG86cnRnd2ctYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1haGVz aCBKZXRoYW5hbmRhbmk8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBKYW51YXJ5IDE3LCAyMDE2 IDEwOjExIFBNPGJyPg0KPGI+VG86PC9iPiBOaXRpc2ggR3VwdGEgKG5pdGlzZ3VwKSAmbHQ7PGEg aHJlZj0ibWFpbHRvOm5pdGlzZ3VwQGNpc2NvLmNvbSI+bml0aXNndXBAY2lzY28uY29tPC9hPiZn dDs8YnI+DQo8Yj5DYzo8L2I+IEplZmYgSGFhcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpoYWFzQGp1 bmlwZXIubmV0Ij5qaGFhc0BqdW5pcGVyLm5ldDwvYT4mZ3Q7OyA8YSBocmVmPSJtYWlsdG86cnRn LWJmZEBpZXRmLm9yZyI+DQpydGctYmZkQGlldGYub3JnPC9hPjsgQWRpdHlhIERvZ3JhIChhZGRv Z3JhKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkZG9ncmFAY2lzY28uY29tIj5hZGRvZ3JhQGNpc2Nv LmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmNvbGluQGRvY2gub3JnLnVrIj5jb2xpbkBk b2NoLm9yZy51azwvYT47IDxhIGhyZWY9Im1haWx0bzpydGd3Z0BpZXRmLm9yZyI+DQpydGd3Z0Bp ZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtbml0aXNoLXZycnAtYmZkLTAyLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNob3VsZG7igJl0IHRoZSBkcmFmdCBiZSBuYW1l ZCBkcmFmdC1uaXRpc2gtYmZkLXZycnAgb3Igc29tZXRoaW5nIGxpa2UgdGhhdCB0byBmb2xsb3cg dGhlIG5hbWluZyBjb252ZW50aW9uIGRlc2NyaWJlZCBpbiBSRkMgNzIyMT88bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBPY3QgMjUsIDIwMTUsIGF0IDEx OjI3IFBNLCBOaXRpc2ggR3VwdGEgKG5pdGlzZ3VwKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5pdGlz Z3VwQGNpc2NvLmNvbSI+bml0aXNndXBAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxicj4NCjxicj4NCldlIGhhdmUgc3Vi bWl0dGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0LiBBcyBkaXNjdXNzZWQgaW4gSUVURiA5 MyBhdDxicj4NCnByYWd1ZS48YnI+DQo8YnI+DQpXZSBoYXZlIG1lcmdlZCB0aGUgZm9sbG93aW5n IGRyYWZ0czo8YnI+DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1u aXRpc2gtdnJycC1iZmQtMDEiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW5pdGlz aC12cnJwLWJmZC0wMTwvYT48YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtbWlyc2t5LWJmZC1wMm1wLXZycnAtdXNlLWNhc2UtMDAiPmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1taXJza3ktYmZkLXAybXAtdnJycC11c2UtY2FzZS0w MDwvYT48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpXZSBoYXZlIGFsc28gdGFrZW4gY2FyZSBvZiBh bGwgdGhlIGNvbW1lbnRzIHRoYXQgd2VyZSBkaXNjdXNzZWQgaW4gdGhlPGJyPg0KUlRHV0cgbWVl dGluZy48YnI+DQpXZSB3ZWxjb21lIGFueSBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgb24gdGhl IGRyYWZ0Ljxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpOaXRpc2g8YnI+DQo8YnI+DQpPbiAxMy8x MC8xNSA5OjA5IHBtLCAmcXVvdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCndyb3RlOjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCkEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1uaXRpc2gtdnJycC1iZmQtMDIudHh0PGJyPg0KaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBOaXRpc2ggR3VwdGEgYW5kIHBvc3RlZCB0byB0 aGU8YnI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTo8c3BhbiBjbGFzcz0iYXBw bGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+ZHJhZnQtbml0aXNoLXZy cnAtYmZkPGJyPg0KUmV2aXNpb246PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjAyPGJyPg0K VGl0bGU6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPC9zcGFuPkZhc3QgZmFpbHVyZSBkZXRlY3Rpb24gaW4gVlJSUCB3aXRoIEJG RDxicj4NCkRvY3VtZW50IGRhdGU6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjIw MTUtMTAtMTM8YnI+DQpHcm91cDo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8L3NwYW4+SW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KUGFnZXM6PHNwYW4gY2xh c3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjEwPGJyPg0K VVJMOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtbml0aXNoLXZycnAtYmZkLTAyLnR4dCI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW5pdGlzaC12cnJwLWJmZC0wMi50eHQ8L2E+PGJyPg0K U3RhdHVzOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1uaXRpc2gtdnJy cC1iZmQvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1uaXRpc2gtdnJy cC1iZmQvPC9hPjxicj4NCkh0bWxpemVkOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbml0aXNoLXZy cnAtYmZkLTAyIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbml0aXNoLXZycnAt YmZkLTAyPC9hPjxicj4NCkRpZmY6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1uaXRpc2gtdnJycC1iZmQtMDIiPmh0dHBzOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1uaXRpc2gtdnJycC1iZmQtMDI8L2E+PGJyPg0KPGJyPg0KQWJz dHJhY3Q6PGJyPg0KJm5ic3A7VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IEJpZGlyZWN0aW9u YWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCk8YnI+DQombmJzcDtjYW4gYmUgdXNlZCB0byBz dXBwb3J0IHN1Yi1zZWNvbmQgZGV0ZWN0aW9uIG9mIGEgTWFzdGVyIFJvdXRlcjxicj4NCiZuYnNw O2ZhaWx1cmUgaW4gdGhlIFZpcnR1YWwgUm91dGVyIFJlZHVuZGFuY3kgUHJvdG9jb2wgKFZSUlAp Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mPGJyPg0Kc3VibWlz c2lvbjxicj4NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmcuPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TWFoZXNo IEpldGhhbmFuZGFuaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRv Om1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_D2C2A3524A104aceeciscocom_-- From nobody Mon Jan 18 22:14:00 2016 Return-Path: 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 D2FDF1AC3B1; Mon, 18 Jan 2016 22:13: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 yZQrGYxoIjc7; Mon, 18 Jan 2016 22:13:57 -0800 (PST) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 0E9D71AC3B7; Mon, 18 Jan 2016 22:13:57 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id 65so169727116pff.2; Mon, 18 Jan 2016 22:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=25aOxGMsyUoQrdgb/HJ+Rjl1YGaoeMXOP3mSDyAOc+Q=; b=kdybrUp6RhQV6iira1dbXI9sTFlbSb3p4fAzRwk+mLXV/XfqgmZt+mfNnsLzjcqDs1 /vFmijCPGrAkM6GBMrqvFshsiCz/oAwx7D8FsATFGPrGP0ExQrJTN8T1FEq0z10fMRXz hGzLCDpsLqGfdSrKAPfhAIqtnkoXMEeMkQRD9Ww0Siof5X1nX6ZDpLU3cPN0eqFnuoAC yHT919J8OHm1coKHOVf6bIWrttmPo34krW4OB1DaxcVylf3Ri+4rxcwizr//RDsOmSkL 4gVbgsFSngpiOlH74jMis0nnZUtydFw5Mu2pvIGXbCG9Vf5kV9da7be92KzQFsdVdXhB xMrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=25aOxGMsyUoQrdgb/HJ+Rjl1YGaoeMXOP3mSDyAOc+Q=; b=mFCMEp4j+IdbqeD/QQEte9+rUn2uaDdyAI9CVOytyimgoHNx75Eo/dkQIbuXlMv/ze 00HGftP2YuTu+Enzw6gKUruqW9ywm7FFlFERbDGsJ/x2YIpPauXIdzqoWYhPsJFftXK3 IEJeaCrMTaQ1u4ytb6Gwh4UWNYkDCQR0BivG92mHhkeH7kMRjEtuhfzfKUkeo0X2n8sD Sg98Sj7CkBmvypJ43vZHDT16qdRFlGzTetfp5VOV2wpjTWbQ5obXDULlTxcCNRwaHn+K OQF2F6FpCv5LC4F1zJMo0JsWzWUiaSeXxhMSnKGTJoIjtkzos24gyVZ4bkKRTFGZLqwF xD7w== X-Gm-Message-State: ALoCoQkUCdNejUFtoHavf9sRz4wGml5BS/QgqkG1Pm8um5kgphzvVn7rfzS3rjcBbDaJFAl3i5WcE4L065qA0EP03k0S6hA6hA== X-Received: by 10.98.68.199 with SMTP id m68mr41763029pfi.6.1453184036686; Mon, 18 Jan 2016 22:13:56 -0800 (PST) Received: from ?IPv6:2001:420:c0c8:1004::254? ([2001:420:c0c8:1004::254]) by smtp.gmail.com with ESMTPSA id cl3sm38476044pad.11.2016.01.18.22.13.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 18 Jan 2016 22:13:55 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_645A0B16-3D48-404C-A13B-96FE9B1CEE98" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt From: Mahesh Jethanandani In-Reply-To: Date: Mon, 18 Jan 2016 22:13:49 -0800 Message-Id: <6B91DFE6-1CC9-4D17-BD19-8D3F1FDBF365@gmail.com> References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> To: Chris Bowers X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "Nitish Gupta \(nitisgup\)" , Jeff Haas , "Aditya Dogra \(addogra\)" , "rtg-bfd@ietf.org" , "colin@doch.org.uk" , "rtgwg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 06:14:00 -0000 --Apple-Mail=_645A0B16-3D48-404C-A13B-96FE9B1CEE98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Chris, Thanks for the clarification. Please cross-post the draft to rtg-bfd (as = you have been doing) to make sure you get the BFD experts to review the = draft. One clarification and then a question in section 3 of the document. You = say that BFD requires that a session be formed by both peers. You can = very well form a one way session from the VRRP Master router to your = Backup router. When the Backup Router detects loss of 3 BFD packets, it = can declare the Master as Down and take over as the new Master router. = The question is why do you need a BFD session from the Backup router to = the Master router? The other thing I want to make sure if there is any particular = configuration requirement from a BFD YANG model perspective. I = understand that you are using the fast timer in BFD to detect next-hop = IP address liveliness check. We address that configuration in the BFD = YANG model today. However, we have not addressed the issue of p2mp BFD = configuration as yet. Depending on how that discussion proceeds we might = want to look at that also. Cheers. > On Jan 18, 2016, at 10:38 AM, Chris Bowers = wrote: >=20 > Mahesh, > =20 > As I understand it, the authors eventually want this draft to be = adopted by the RTGWG. This makes sense because it includes VRRP = protocol extensions, so it would normally go to the VRRP WG. Since the = VRRP WG is concluded, the RTGWG is a reasonable place to do this work. > =20 > One might also consider doing this work in the BFD WG to take = advantage of the concentration of BFD expertise there. However, since = the main content of the document deals with VRRP behavior and defining a = new VRRP packet type, it seems like it might be a diversion from the = main work of the BFD WG. > =20 > If the RTGWG does adopt the draft, the name of the adopted draft = should start with draft-ietf-rtgwg (as you point out, following = RFC7221).=20 > =20 > As an individual submission at this point, there are no hard = requirements on the name of the draft, except that it not start with = draft-ietf. However, when authors are submitting drafts that they = intend to eventually be considered for adoption by the RTGWG, it is = quite useful to name them draft-authorname-rtgwg-yyyy, so that they = automatically show up athttps://datatracker.ietf.org/wg/rtgwg/documents/ = at the bottom under = the header of =E2=80=9CRelated Internet-Drafts=E2=80=9D.=20 > =20 > Thanks, > Chris > =20 > From: rtgwg [mailto:rtgwg-bounces@ietf.org = ] On Behalf Of Mahesh Jethanandani > Sent: Sunday, January 17, 2016 10:11 PM > To: Nitish Gupta (nitisgup) > > Cc: Jeff Haas >; = rtg-bfd@ietf.org ; Aditya Dogra (addogra) = >; colin@doch.org.uk = ; rtgwg@ietf.org > Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt > =20 > Shouldn=E2=80=99t the draft be named draft-nitish-bfd-vrrp or = something like that to follow the naming convention described in RFC = 7221? > =20 > On Oct 25, 2015, at 11:27 PM, Nitish Gupta (nitisgup) = > wrote: > =20 > Hi, >=20 > We have submitted a new version of the draft. As discussed in IETF 93 = at > prague. >=20 > We have merged the following drafts: > http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 = >=20 > https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 = >=20 >=20 >=20 > We have also taken care of all the comments that were discussed in the > RTGWG meeting. > We welcome any comments and suggestions on the draft. >=20 > Thanks, > Nitish >=20 > On 13/10/15 9:09 pm, "internet-drafts@ietf.org = " > > wrote: >=20 >=20 >=20 > A new version of I-D, draft-nitish-vrrp-bfd-02.txt > has been successfully submitted by Nitish Gupta and posted to the > IETF repository. >=20 > Name: draft-nitish-vrrp-bfd > Revision: 02 > Title: Fast failure detection in VRRP with BFD > Document date: 2015-10-13 > Group: Individual Submission > Pages: 10 > URL: =20 > https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt = > Status: = https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ = > Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 = > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02 = >=20 > Abstract: > This document describes how Bidirectional Forwarding Detection (BFD) > can be used to support sub-second detection of a Master Router > failure in the Virtual Router Redundancy Protocol (VRRP). >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org = . >=20 > The IETF Secretariat >=20 > =20 > =20 > Mahesh Jethanandani > mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_645A0B16-3D48-404C-A13B-96FE9B1CEE98 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Chris,

Thanks for the clarification. Please cross-post the draft to = rtg-bfd (as you have been doing) to make sure you get the BFD experts to = review the draft.

One clarification and then a question in section 3 of the = document. You say that BFD requires that a session be formed by both = peers. You can very well form a one way session from the VRRP Master = router to your Backup router. When the Backup Router detects loss of 3 = BFD packets, it can declare the Master as Down and take over as the new = Master router. The question is why do you need a BFD session from the = Backup router to the Master router?

The other thing I want to make sure if = there is any particular configuration requirement from a BFD YANG model = perspective. I understand that you are using the fast timer in BFD to = detect next-hop IP address liveliness check. We address that = configuration in the BFD YANG model today. However, we have not = addressed the issue of p2mp BFD configuration as yet. Depending on how = that discussion proceeds we might want to look at that also.

Cheers.

On Jan 18, 2016, at 10:38 AM, Chris Bowers <cbowers@juniper.net>= wrote:

Mahesh,
 
As I understand it, the = authors eventually want this draft to be adopted by the RTGWG.  = This makes sense because it includes VRRP protocol extensions, so it = would normally go to the VRRP WG.   Since the VRRP WG is = concluded, the RTGWG is a reasonable place to do this work.
 
One might also consider = doing this work in the BFD WG to take advantage of the concentration of = BFD expertise there.  However, since the main content of the = document deals with VRRP behavior and defining a new VRRP packet type, = it seems like it might be a diversion from the main work of the BFD = WG.
 
If = the RTGWG does adopt the draft, the name of the adopted draft should = start with draft-ietf-rtgwg (as you point out, following = RFC7221). 
 
As = an individual submission at this point, there are no hard requirements = on the name of the draft, except that it not start with = draft-ietf.  However, when authors are submitting drafts that they = intend to eventually be considered for adoption by the RTGWG, it is = quite useful to name them draft-authorname-rtgwg-yyyy, so that they = automatically show up athttps://datatracker.ietf.org/wg/rtgwg/documents/ at the bottom under the = header of =E2=80=9CRelated Internet-Drafts=E2=80=9D. 
 
Thanks,
Chris
 
From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf = Of Mahesh = Jethanandani
Sent: Sunday, January 17, 2016 = 10:11 PM
To: Nitish Gupta (nitisgup) = <nitisgup@cisco.com>
Cc: Jeff Haas <jhaas@juniper.net>; rtg-bfd@ietf.org; Aditya = Dogra (addogra) <addogra@cisco.com>; colin@doch.org.uk; rtgwg@ietf.org
Subject: Re: New Version = Notification for draft-nitish-vrrp-bfd-02.txt
 
Shouldn=E2=80=99t the draft be named draft-nitish-bfd-vrrp or = something like that to follow the naming convention described in RFC = 7221?
 
On = Oct 25, 2015, at 11:27 PM, Nitish Gupta (nitisgup) <nitisgup@cisco.com> = wrote:
 
Hi,

We have = submitted a new version of the draft. As discussed in IETF 93 at
prague.

We have merged the = following drafts:
http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01

https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case= -00



We = have also taken care of all the comments that were discussed in the
RTGWG meeting.
We welcome any comments and = suggestions on the draft.

Thanks,
Nitish

On 13/10/15 9:09 pm, "internet-drafts@ietf.org" = <internet-drafts@ietf.org>
wrote:



A new version of I-D, = draft-nitish-vrrp-bfd-02.txt
has been successfully = submitted by Nitish Gupta and posted to the
IETF = repository.

Name:        &= nbsp;     draft-nitish-vrrp-bfd<= br class=3D"">Revision:        <= span class=3D"Apple-converted-space"> 02
Title:        &= nbsp;       Fast failure = detection in VRRP with BFD
Document date:        &= nbsp; 2015-10-13
Group:        &= nbsp;    Individual = Submission
Pages:        &= nbsp;     10
URL: =            
https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.t= xt
Status: =         https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/
Htmlized:       https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02

Abstract:
 This = document describes how Bidirectional Forwarding Detection (BFD)
 can be used to support sub-second detection of a Master = Router
 failure in the Virtual Router Redundancy = Protocol (VRRP).





Please note that it may take a = couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

 
 
Mahesh = Jethanandani
mjethanandani@gmail.com

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_645A0B16-3D48-404C-A13B-96FE9B1CEE98-- From nobody Tue Jan 19 06:36:55 2016 Return-Path: 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 15DDE1B2FA2; Tue, 19 Jan 2016 06:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 J01ipk3geocl; Tue, 19 Jan 2016 06:36:53 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6819A1B2F67; Tue, 19 Jan 2016 06:36:53 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 72C741E7DC; Tue, 19 Jan 2016 09:39:05 -0500 (EST) Date: Tue, 19 Jan 2016 09:39:05 -0500 From: Jeffrey Haas To: Chris Bowers Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Message-ID: <20160119143904.GA28732@pfrc.org> References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "Nitish Gupta \(nitisgup\)" , Jeff Haas , "Aditya Dogra \(addogra\)" , "colin@doch.org.uk" , "rtg-bfd@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 14:36:54 -0000 [Wearing my BFD co-chair hat.] On Mon, Jan 18, 2016 at 06:38:40PM +0000, Chris Bowers wrote: > One might also consider doing this work in the BFD WG to take advantage of > the concentration of BFD expertise there. However, since the main content > of the document deals with VRRP behavior and defining a new VRRP packet > type, it seems like it might be a diversion from the main work of the BFD > WG. The general policy of the BFD Working Group has been that protocol changes to BFD belong in the BFD working group. Uses of BFD should be carried out in the Working Group that carries the appropriate expertise, but BFD is chartered to help with review of uses of BFD elsewhere. Thus, rtgwg is a perfectly fine place for this draft. If the rtgwg chairs think it's appropriate, last call can occur also in BFD for additional review. -- Jeff From nobody Tue Jan 19 11:54:18 2016 Return-Path: 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 95C551B3514; Tue, 19 Jan 2016 11:54:16 -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, 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 0bKtnq-S8JaT; Tue, 19 Jan 2016 11:54:12 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0717.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:717]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 682401B3511; Tue, 19 Jan 2016 11:54:12 -0800 (PST) Received: from DM2PR05MB623.namprd05.prod.outlook.com (10.141.157.24) by SN1PR0501MB1822.namprd05.prod.outlook.com (10.163.131.145) with Microsoft SMTP Server (TLS) id 15.1.365.19; Tue, 19 Jan 2016 19:53:50 +0000 Received: from DM2PR05MB623.namprd05.prod.outlook.com ([10.141.157.24]) by DM2PR05MB623.namprd05.prod.outlook.com ([10.141.157.24]) with mapi id 15.01.0361.006; Tue, 19 Jan 2016 19:53:50 +0000 From: Chris Bowers To: "Nitish Gupta (nitisgup)" , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYiTS9LHO0Rck2198aSpBcKKZ5+EmUAgHxbjACACWswAA== Date: Tue, 19 Jan 2016 19:53:49 +0000 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net; x-originating-ip: [66.129.239.14] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1822; 5:3lNtDE8CXgs68MjXyozeE9W5UNhn8IGIiWP+9Y4nz3Wyt7lb6FMGO9AJ2I+VcHZtNa3RItYeWPvP9AmK1V8Jefe6Ya2o8xuvZxb0ubvN0wlQctnW4S1glSz6S02rNG4yP9rTHsUQfQY7471NGm25kw==; 24:plgw35mYzvtDZoE4XNvNsbmVTfAIU2N3ey8ayZlOiZAlsIqdz/29R0z/v51UeuJEgfROLCZgPGRbPF9xAAZa3WCNCU67o/x2rF1U/VRZU1Y= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1822; x-ms-office365-filtering-correlation-id: 443e74ce-0219-4cfe-c53d-08d3210a4053 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046); SRVR:SN1PR0501MB1822; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1822; x-forefront-prvs: 0826B2F01B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(13464003)(24454002)(189002)(377424004)(199003)(164054003)(377454003)(2201001)(19580405001)(19580395003)(2501003)(15975445007)(33656002)(66066001)(54356999)(2950100001)(99286002)(101416001)(76176999)(77096005)(5002640100001)(7110500001)(105586002)(2420400006)(5003600100002)(106116001)(5004730100002)(4001150100001)(97736004)(230783001)(106356001)(189998001)(122556002)(5001960100002)(40100003)(11100500001)(74316001)(76576001)(5001770100001)(4326007)(50986999)(81156007)(6116002)(2900100001)(86362001)(10400500002)(5008740100001)(2906002)(1220700001)(3846002)(10710500007)(1096002)(102836003)(586003)(92566002)(1720100001)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1822; H:DM2PR05MB623.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2016 19:53:50.0587 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1822 Archived-At: Cc: Jeff Haas , "colin@doch.org.uk" , "Aditya Dogra \(addogra\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 19:54:16 -0000 Nitish and co-authors, I have read this draft and have several comments below. In general, I pref= er that authors address outstanding comments in a new revision before we co= nduct a poll for adoption in RTGWG. Since an adoption poll usually trigger= s quite a few people read a draft in detail, it makes better use of the wor= king groups time to have them reading the most up-to-date version. However= , an argument could also be made for filling in some of the additional deta= il that I am asking for below after WG adoption (assuming it is adopted), w= hen the WG has more direct control of the document. So I am open to eithe= r approach.=20 So please respond to the feedback below and tell me if you would like to ad= dress some of it in a new revision before I conduct a poll for WG adoption,= or if you would prefer to do the WG adoption poll using the current revisi= on. There has also been feedback from others on this draft in response to = your email, so you should respond to that as well. In general, I think the draft would benefit from specifying the VRRP state = machine for this BFD mode of operation at the same level of detail that RFC= 5798 specifies the existing VRRP state machine. There are several places = where it is probably possible to infer the correct behavior, but making it = very explicit will make for a better document. 1) Section 3.5 of this draft defines the Critical BFD session which is the = BFD session between the VRRP Master and the next best VRRP backup. In the = existing VRRP state machine, a VRRP router in the backup state is not able = to determine if it is the next best VRRP backup. Presumably, in the VRRP s= tate machine for the BFD mode of operation, a VRRP router in the backup sta= te will look at the peer table populated by the Backup Advertisements and f= igure out which router is the next best VRRP router based on highest priori= ty value with highest IPvX address as tie breaker. However, it would be be= tter to be as explicit as RFC5798 about how this new state machine operates= .=20 2) Section 5 says that "To reduce the number of packets generated at a regu= lar interval, Backup Advert packets may be sent at a reduced rate as compar= ed to Advert packets sent by the VRRP Master." It seems that the state mac= hine for VRRP BFD mode will have to be enhanced in some way to support this= . One way to do this would be for each router to have a Backup_Advertisem= ent_Interval which it uses to populate the Maximum Advertisement Interval i= n the BACKUP ADVERTISEMENT, and have each receiving router maintain a Peer_= Advert_Interval(P) for each peer(P), and remove a peer entry when a BACKUP = ADVERTISEMENT is not received from P for 3* Peer_Advert_Interval(P). But t= his is just one possible approach. In any case, it would be good to choos= e a mechanism and describe the corresponding state machine. 3) The text should clarify how the VRRP state machine interacts with the BF= D state machine. One can imagine scenarios where a BFD session stays up b= ut the VRRP advertisements stop being received, or vice versa. This scenar= io is not very far-fetched because BFD may use unicast and VRRP uses multic= ast. Behavior can probably be inferred from existing text, but I think mor= e precision is better here. 4) I don't understand Section 4 which describes how to use p2mp BFD. =20 A) The text says that "The Master router starts transmitting BFD control pa= ckets with VRID as source IP address." According to RFC5798, the VRID is a= n integer in the range from 1-255. Is the idea to encode the integer VRID = as an IP address? Or should the BFD control packets be sent with the sour= ce IP address set to an IPvX address associated with the virtual router? O= r are both used? In any case, it seems like this needs clarification. B) What is the destination IP address of the p2mp BFD control packet? Is i= t 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IPv4 and IPv6 multicast addresses= for VRRP? If so, this should be made explicit. C) Again, a state machine description would help readers and future impleme= nters understand exactly what is intended. Thanks, Chris -----Original Message----- From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Nitish Gupta (niti= sgup) Sent: Wednesday, January 13, 2016 3:31 AM To: rtgwg@ietf.org; rtg-bfd@ietf.org Cc: Gregory Mirsky ; Jeff Haas ; colin@doch.org.uk; Aditya Dogra (addogra) Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Hi, We had presented the Draft for VRRP BFD integration in IETF 93 and we had t= aken care of all the comments that came as part of the WG meeting. We had also merged the two drafts as per the comments in IETF 93: http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 We had presented the merged draft in IETF 94 and there were no specific com= ments on the draft. We would like to ask the RTGWG to adopt the Draft as a WG document. Thanks, Nitish On 26/10/15 11:57 am, "Nitish Gupta (nitisgup)" wrote: >Hi, > >We have submitted a new version of the draft. As discussed in IETF 93=20 >at prague. > >We have merged the following drafts: >http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 > >https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 > > > >We have also taken care of all the comments that were discussed in the=20 >RTGWG meeting. >We welcome any comments and suggestions on the draft. > >Thanks, >Nitish > >On 13/10/15 9:09 pm, "internet-drafts@ietf.org"=20 > >wrote: > >> >>A new version of I-D, draft-nitish-vrrp-bfd-02.txt has been=20 >>successfully submitted by Nitish Gupta and posted to the IETF=20 >>repository. >> >>Name: draft-nitish-vrrp-bfd >>Revision: 02 >>Title: Fast failure detection in VRRP with BFD >>Document date: 2015-10-13 >>Group: Individual Submission >>Pages: 10 >>URL: =20 >>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt >>Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ >>Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 >>Diff: =20 >>https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02 >> >>Abstract: >> This document describes how Bidirectional Forwarding Detection (BFD) >> can be used to support sub-second detection of a Master Router >> failure in the Virtual Router Redundancy Protocol (VRRP). >> >> =20 >> =20 >> >> >>Please note that it may take a couple of minutes from the time of=20 >>submission until the htmlized version and diff are available at=20 >>tools.ietf.org. >> >>The IETF Secretariat >> > _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From nobody Tue Jan 19 21:11:19 2016 Return-Path: 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 952BB1A1EB7; Tue, 19 Jan 2016 21:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 wRPoX05qm2bx; Tue, 19 Jan 2016 21:11:16 -0800 (PST) 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 9ABB61A1E0F; Tue, 19 Jan 2016 21:11:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3563; q=dns/txt; s=iport; t=1453266676; x=1454476276; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nBs4D1I1Ql6jbVp+RzzWUm2kCdvgvFNV2BAc5ZKuMY0=; b=mnD/BQB6IMqcxH8/plJkrFhmJCqZw2ci1gX426qKkz51ezVrQ26bvB26 98vkgS2yFpoCgIqOtMaJiVpHfFq8uSkpvn5bia5FSLgvwQBhI7y2/F2F2 /sA6+d5crzf45XikQ7X2JtbttTTtbQ2tVzcuhbYp51MJCzLpxwXbS7/2s M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgA4Fp9W/51dJa1egzpSbQaIUbJyA?= =?us-ascii?q?Q2BYyKFbQKBRzgUAQEBAQEBAYEKhDQBAQEEOj0CDAICAgEIEQQBAR8JBxYcFAk?= =?us-ascii?q?IAgQBDQWIGw6/SAEBAQEBAQEBAQEBAQEBAQEBAQEBARUEhjaEdIQYCREBJIRaB?= =?us-ascii?q?Y1CiVgBhUeIF4FeSoN6gyuFNIpsg28BIAEBQoQJcgGFbzqBCAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,319,1449532800"; d="scan'208";a="229370339" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jan 2016 05:11:15 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u0K5BF6u032015 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jan 2016 05:11:15 GMT Received: from xch-rtp-003.cisco.com (64.101.220.143) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Jan 2016 00:11:14 -0500 Received: from xch-rtp-003.cisco.com ([64.101.220.143]) by XCH-RTP-003.cisco.com ([64.101.220.143]) with mapi id 15.00.1104.009; Wed, 20 Jan 2016 00:11:14 -0500 From: "Nitish Gupta (nitisgup)" To: Alexander Vainshtein , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYiTS9LHO0Rck2198aSpBcKKZ5+EmUAgHxbjACABaF0QIAFFiWA Date: Wed, 20 Jan 2016 05:11:14 +0000 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.232.12.195] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "jhaas@juniper.net" , "colin@doch.org.uk" , "Aditya Dogra \(addogra\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 05:11:18 -0000 Hi Alexander, Thanks for your comments. We would be adding the IANA considerations in the next version of the draft for setting up a registry for VRRP Advert types. Thanks, Nitish On 17/01/16 3:34 pm, "Alexander Vainshtein" wrote: >Hi all, >I have read the draft and I have one (presumably, minor) comment: >- The IANA Considerations section of says that there are no IANA request. >- At the same time the draft defines a new type of VRRP messages (2 - >Backup Advertisement). > >As long as here was just one type of VRRP messages (1 - Advertisement), >we could avoid setting up a IANA registry for VRRP message types. If we >are going to have two, does not this justify setting up such a registry? > >Regards, >Sasha > >Office: +972-39266302 >Cell: +972-549266302 >Email: Alexander.Vainshtein@ecitele.com > >-----Original Message----- >From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nitish Gupta >(nitisgup) >Sent: Wednesday, January 13, 2016 11:31 AM >To: rtgwg@ietf.org; rtg-bfd@ietf.org >Cc: jhaas@juniper.net; colin@doch.org.uk; Aditya Dogra (addogra) >Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt > >Hi, > >We had presented the Draft for VRRP BFD integration in IETF 93 and we had >taken care of all the comments that came as part of the WG meeting. >We had also merged the two drafts as per the comments in IETF 93: >http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 >https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 > >We had presented the merged draft in IETF 94 and there were no specific >comments on the draft. >We would like to ask the RTGWG to adopt the Draft as a WG document. > >Thanks, >Nitish > > >On 26/10/15 11:57 am, "Nitish Gupta (nitisgup)" >wrote: > >>Hi, >> >>We have submitted a new version of the draft. As discussed in IETF 93 >>at prague. >> >>We have merged the following drafts: >>http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 >> >>https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 >> >> >> >>We have also taken care of all the comments that were discussed in the >>RTGWG meeting. >>We welcome any comments and suggestions on the draft. >> >>Thanks, >>Nitish >> >>On 13/10/15 9:09 pm, "internet-drafts@ietf.org" >> >>wrote: >> >>> >>>A new version of I-D, draft-nitish-vrrp-bfd-02.txt has been >>>successfully submitted by Nitish Gupta and posted to the IETF >>>repository. >>> >>>Name: draft-nitish-vrrp-bfd >>>Revision: 02 >>>Title: Fast failure detection in VRRP with BFD >>>Document date: 2015-10-13 >>>Group: Individual Submission >>>Pages: 10 >>>URL: =20 >>>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt >>>Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ >>>Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 >>>Diff: =20 >>>https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02 >>> >>>Abstract: >>> This document describes how Bidirectional Forwarding Detection (BFD) >>> can be used to support sub-second detection of a Master Router >>> failure in the Virtual Router Redundancy Protocol (VRRP). >>> >>> =20 >>> =20 >>> >>> >>>Please note that it may take a couple of minutes from the time of >>>submission until the htmlized version and diff are available at >>>tools.ietf.org. >>> >>>The IETF Secretariat >>> >> > From nobody Tue Jan 19 21:32:55 2016 Return-Path: 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 B63251A6EF9; Tue, 19 Jan 2016 21:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 2LiWbhEJ3IdP; Tue, 19 Jan 2016 21:32:51 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C3AC1A6EF2; Tue, 19 Jan 2016 21:32:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28849; q=dns/txt; s=iport; t=1453267971; x=1454477571; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4OF+DNh/0cxok/lnEG6qZWweYYRIps/q6msKqoYRD44=; b=mN5qTfDlhZ9laDEhZqfv9UT0YgPu2NBZ45P5st0j4cprTLkrteo8u+s2 JBqakzFGfrHT8k/s0muKUx9bTdK8gqspRdgi15bN1dB1iBI9k3mIt1pJK KIQT0/KMk5ChjcOWRp2Q2LjesyJdUwkUACOLakt07ZZTOTv6OAOWCbwwo w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgBjG59W/5RdJa1egm5MUm0GiFGyc?= =?us-ascii?q?gENgWMihBaBVwKBSDgUAQEBAQEBAYEKhDQBAQEEawwCEAIBCA4DAwEBASEHByE?= =?us-ascii?q?RFAkIAgQBDQWIBgMSDrtsDYNMAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYY6hHSCT?= =?us-ascii?q?oFKWQ0JCIQiBY1ChVGEBwGFR4YfgXiBXkqDeohfhn+DbYNvAREPAQFChAlyAYY?= =?us-ascii?q?pgQgBAQE?= X-IronPort-AV: E=Sophos; i="5.22,319,1449532800"; d="scan'208,217"; a="68911684" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jan 2016 05:32:49 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u0K5WnAT002295 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jan 2016 05:32:50 GMT Received: from xch-rtp-003.cisco.com (64.101.220.143) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Jan 2016 00:32:48 -0500 Received: from xch-rtp-003.cisco.com ([64.101.220.143]) by XCH-RTP-003.cisco.com ([64.101.220.143]) with mapi id 15.00.1104.009; Wed, 20 Jan 2016 00:32:48 -0500 From: "Nitish Gupta (nitisgup)" To: Mahesh Jethanandani , Chris Bowers Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYiTS9LHO0Rck2198aSpBcKKZ5+EmUAgIOBV4CAAPKPAIAAwjmAgAHjCoA= Date: Wed, 20 Jan 2016 05:32:48 +0000 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> <6B91DFE6-1CC9-4D17-BD19-8D3F1FDBF365@gmail.com> In-Reply-To: <6B91DFE6-1CC9-4D17-BD19-8D3F1FDBF365@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.232.12.195] Content-Type: multipart/alternative; boundary="_000_D2C514DF5CE46nitisgupciscocom_" MIME-Version: 1.0 Archived-At: Cc: Jeff Haas , "Aditya Dogra \(addogra\)" , "colin@doch.org.uk" , "rtg-bfd@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 05:32:54 -0000 --_000_D2C514DF5CE46nitisgupciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Mahesh, Thanks for your comments please see inline. Thanks, Nitish From: Mahesh Jethanandani > Date: Tuesday, 19 January 2016 11:43 am To: Chris Bowers > Cc: Nitish Gupta >, Jeff Haas= >, "rtg-bfd@ietf.org" >, "Aditya Dogra= (addogra)" >, "colin@doch.org.= uk" >= , "rtgwg@ietf.org" > Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Chris, Thanks for the clarification. Please cross-post the draft to rtg-bfd (as yo= u have been doing) to make sure you get the BFD experts to review the draft= . One clarification and then a question in section 3 of the document. You say= that BFD requires that a session be formed by both peers. You can very wel= l form a one way session from the VRRP Master router to your Backup router.= When the Backup Router detects loss of 3 BFD packets, it can declare the M= aster as Down and take over as the new Master router. The question is why d= o you need a BFD session from the Backup router to the Master router? [nitish] I just want to clarify one point that there will be only one sessi= on between a pair of VRRP router instance for example in this case if there= is only one VRRP Master and one VRRP backup Router there will be only one = BFD session. Though both the devices would require to initiate BFD bootup = sequence but there will be only one BFD session formed between them. As Sec= tion 3 of RFC 5881 (Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) ) mandates that the session be initiated by both the participating peers fo= r a session to be formed between them. Hence the Backup router needs to kno= w the Master IPVX address to initiate a BFD session. The other thing I want to make sure if there is any particular configuratio= n requirement from a BFD YANG model perspective. I understand that you are = using the fast timer in BFD to detect next-hop IP address liveliness check.= We address that configuration in the BFD YANG model today. However, we hav= e not addressed the issue of p2mp BFD configuration as yet. Depending on ho= w that discussion proceeds we might want to look at that also. [nitish] There is no particular requirement that we can see from BFD YANG m= odel perspective. As VRRP should interface with BFD as another protocol usi= ng BFD as a means of fast failure detection of its peer. Cheers. On Jan 18, 2016, at 10:38 AM, Chris Bowers > wrote: Mahesh, As I understand it, the authors eventually want this draft to be adopted by= the RTGWG. This makes sense because it includes VRRP protocol extensions,= so it would normally go to the VRRP WG. Since the VRRP WG is concluded, = the RTGWG is a reasonable place to do this work. One might also consider doing this work in the BFD WG to take advantage of = the concentration of BFD expertise there. However, since the main content = of the document deals with VRRP behavior and defining a new VRRP packet typ= e, it seems like it might be a diversion from the main work of the BFD WG. If the RTGWG does adopt the draft, the name of the adopted draft should sta= rt with draft-ietf-rtgwg (as you point out, following RFC7221). As an individual submission at this point, there are no hard requirements o= n the name of the draft, except that it not start with draft-ietf. However= , when authors are submitting drafts that they intend to eventually be cons= idered for adoption by the RTGWG, it is quite useful to name them draft-aut= horname-rtgwg-yyyy, so that they automatically show up athttps://datatracke= r.ietf.org/wg/rtgwg/documents/ at the bottom under the header of =93Related= Internet-Drafts=94. Thanks, Chris From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Mahesh Jethanandan= i Sent: Sunday, January 17, 2016 10:11 PM To: Nitish Gupta (nitisgup) > Cc: Jeff Haas >; rtg-bfd@ietf.o= rg; Aditya Dogra (addogra) >; colin@doch.org.uk; rtgwg@= ietf.org Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Shouldn=92t the draft be named draft-nitish-bfd-vrrp or something like that= to follow the naming convention described in RFC 7221? On Oct 25, 2015, at 11:27 PM, Nitish Gupta (nitisgup) > wrote: Hi, We have submitted a new version of the draft. As discussed in IETF 93 at prague. We have merged the following drafts: http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 We have also taken care of all the comments that were discussed in the RTGWG meeting. We welcome any comments and suggestions on the draft. Thanks, Nitish On 13/10/15 9:09 pm, "internet-drafts@ietf.org" > wrote: A new version of I-D, draft-nitish-vrrp-bfd-02.txt has been successfully submitted by Nitish Gupta and posted to the IETF repository. Name: draft-nitish-vrrp-bfd Revision: 02 Title: Fast failure detection in VRRP with BFD Document date: 2015-10-13 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-0= 2 Abstract: This document describes how Bidirectional Forwarding Detection (BFD) can be used to support sub-second detection of a Master Router failure in the Virtual Router Redundancy Protocol (VRRP). Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat Mahesh Jethanandani mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com --_000_D2C514DF5CE46nitisgupciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2AB9819CFE9B4E40AF22EADBBA303D49@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Mahesh,

Thanks for your comments please see inline.

Thanks,
Nitish

From: Mahesh Jethanandani <mjethanandani@gmail.com>
Date: Tuesday, 19 January 2016 11:4= 3 am
To: Chris Bowers <cbowers@juniper.net>
Cc: Nitish Gupta <nitisgup@cisco.com>, Jeff Haas <jhaas@juniper.net>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "Aditya Dogra (addogra)" <addogra@cisco.com>, "col= in@doch.org.uk" <colin@doc= h.org.uk>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: Re: New Version Notificati= on for draft-nitish-vrrp-bfd-02.txt

Chris,

Thanks for the clarification. Please cross-post the draft t= o rtg-bfd (as you have been doing) to make sure you get the BFD experts to = review the draft.

One clarification and then a question in section 3 of the d= ocument. You say that BFD requires that a session be formed by both peers. = You can very well form a one way session from the VRRP Master router to you= r Backup router. When the Backup Router detects loss of 3 BFD packets, it can declare the Master as Down and take = over as the new Master router. The question is why do you need a BFD sessio= n from the Backup router to the Master router?

[nitish] I just want to clarify one point that there will be only one = session between a pair of VRRP router instance for example in this case if = there is only one VRRP Master and one VRRP backup Router there will be only= one BFD session.  Though both the devices would require to initiate BFD bootup sequence but there will be on= ly one BFD session formed between them. As Section 3 of RFC 5881 (Bidi= rectional Forwarding Detection (BFD)

for IPv4 a= nd IPv6 (Single Hop)

) mandates that the session be initiated by both the participating p= eers for a session to be formed between them. Hence the Backup router needs= to know the Master IPVX address to initiate a BFD session.

The other thing I want to make sure if there is any particu= lar configuration requirement from a BFD YANG model perspective. I understa= nd that you are using the fast timer in BFD to detect next-hop IP address l= iveliness check. We address that configuration in the BFD YANG model today. However, we have not addressed the issue of p= 2mp BFD configuration as yet. Depending on how that discussion proceeds we = might want to look at that also.

[nitish] There is no particular requirement that we can see= from BFD YANG model perspective. As VRRP should interface with BFD as anot= her protocol using BFD as a means of fast failure detection of its peer.

Cheers.

On Jan 18, 2016, at 10:38 AM, Chris Bowers <cbowers@juniper.net> wrote:
Mahesh,
 
As I understand it, the authors eventually want= this draft to be adopted by the RTGWG.  This makes sense because it i= ncludes VRRP protocol extensions, so it would normally go to the VRRP WG.   Since the VRRP WG is concluded, th= e RTGWG is a reasonable place to do this work.=
 
One might also consider doing this work in the = BFD WG to take advantage of the concentration of BFD expertise there. = However, since the main content of the document deals with VRRP behavior and defining a new VRRP packet type, it seems lik= e it might be a diversion from the main work of the BFD WG.=
 
If the RTGWG does adopt the draft, the name of = the adopted draft should start with draft-ietf-rtgwg (as you point out, fol= lowing RFC7221). 
 
As an individual submission at this point, ther= e are no hard requirements on the name of the draft, except that it not sta= rt with draft-ietf.  However, when authors are submitting drafts that they intend to eventually be considered for ado= ption by the RTGWG, it is quite useful to name them draft-authorname-rtgwg-= yyyy, so that they automatically show up athttps://datatracker.ietf.org/wg/rtgwg/documents/ at the bottom under the header of =93Related Internet-Drafts=94. 
 
Thanks,
Chris
 
From:&= nbsp;rtgwg [mailto:rtgwg-bounces@ietf= .org] O= n Behalf Of Mahesh Jet= hanandani
Sent: S= unday, January 17, 2016 10:11 PM
To: Nit= ish Gupta (nitisgup) <nitisgup@cisco.com&= gt;
Cc: Jef= f Haas <jhaas@juniper.net>; rtg-bfd@ie= tf.org; Aditya Dogra (addogra) <addogra@cisco.com= >; colin@doch.org.uk; rtgwg@ietf.org
Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt
 
Shouldn=92t the draft be named draft-nitish-bfd-vrrp or something like that= to follow the naming convention described in RFC 7221?
 
On Oct 25, 2015, at 11:27 PM, Nitish Gupta (nitisgup) <nitisgup@cisco.com> wrote:
 
Hi,

We have submitted a new version of the draft. As discussed in IETF 93 at prague.

We have merged the following drafts:
http://tools.ietf.org/= html/draft-nitish-vrrp-bfd-01

https:/= /tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00



We have also taken care of all the comments that were discussed in the
RTGWG meeting.
We welcome any comments and suggestions on the draft.

Thanks,
Nitish

On 13/10/15 9:09 pm, "internet-drafts= @ietf.org" <internet-drafts@= ietf.org>
wrote:



A new version of I-D, draft-nitish-vrrp-bfd-02.txt
has been successfully submitted by Nitish Gupta and posted to the
IETF repository.

Name:      &nb= sp;       draft-nitish-vrrp-bfd
Revision:      = ;   02 Title:      &n= bsp;         Fast failure detection in VRRP with BFD<= br class=3D""> Document date:     =      = 2015-10-13
Group:      &n= bsp;     &nb= sp;Individual Submission
Pages:      &n= bsp;       10
URL:            
https://= www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt
Status:         https://datatracker.ietf.org/doc/draf= t-nitish-vrrp-bfd/
Htmlized:       https://tools.ietf.org/html/draft-nitish-vrrp-bfd-= 02
Diff:           https://www.ietf.org= /rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02

Abstract:
 This document describes how Bidirectional Forwarding Detection (BFD)<= br class=3D"">  can be used to support sub-second detection of a Master Router
 failure in the Virtual Router Redundancy Protocol (VRRP).





Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

 
 
Mahesh Jethanandani
mjethanandani@g= mail.com

Mahesh Jethanandani
mjeth= anandani@gmail.com





 --_000_D2C514DF5CE46nitisgupciscocom_-- From nobody Tue Jan 19 23:06:27 2016 Return-Path: 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 745BA1A8703; Tue, 19 Jan 2016 23:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 hh4fcUHan0bk; Tue, 19 Jan 2016 23:06:20 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B71561A86E3; Tue, 19 Jan 2016 23:06:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7343; q=dns/txt; s=iport; t=1453273580; x=1454483180; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=t/xVzZ9Etkms2HS7xL6Y5KNG6pTeWc3hKkhBc2Kxeuk=; b=MO3maKc3o/VKXBaOTBjDK+TX/R19n8uZuKVjGkEJ63N2YJTFAxcFAS5K mWsJDrTBEOGTyOwTzKPQ7VL9RzAXDDyNNCCqYN2NSUXKlNjf8RaKAWd4n t1vCl1Y6YuCaiMAJlEnAJEvvkhDBC08w0zMEJMef+nA1ue1R3n/yuEzvL A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgBxMZ9W/5tdJa1egzpSbQaIUbJyA?= =?us-ascii?q?Q2BYxgKhW0CgUE4FAEBAQEBAQGBCoQ0AQEBBAEBATc0CQIMBAIBCA4DBAEBHwk?= =?us-ascii?q?HJwsUCQgCBAENBYgbDr9OAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYY6g3CBBIQYC?= =?us-ascii?q?REBhH4FjUKJWAGFR4gXgV5Kg3qDK4U0imyDbwEgAQFCghEbgV1yAYVvOoEIAQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.22,320,1449532800"; d="scan'208";a="227616537" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jan 2016 07:06:18 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0K76ISn024713 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jan 2016 07:06:18 GMT Received: from xch-rtp-003.cisco.com (64.101.220.143) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Jan 2016 02:06:17 -0500 Received: from xch-rtp-003.cisco.com ([64.101.220.143]) by XCH-RTP-003.cisco.com ([64.101.220.143]) with mapi id 15.00.1104.009; Wed, 20 Jan 2016 02:06:17 -0500 From: "Nitish Gupta (nitisgup)" To: Chris Bowers , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYiTS9LHO0Rck2198aSpBcKKZ5+EmUAgHxbjACACWswAIABbJEA Date: Wed, 20 Jan 2016 07:06:17 +0000 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.232.12.195] Content-Type: text/plain; charset="us-ascii" Content-ID: <32EEA8A063007C4FB002A374F8B4811D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Jeff Haas , "colin@doch.org.uk" , "Aditya Dogra \(addogra\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 07:06:23 -0000 Hi Chris, Thanks for your comments. We would like to take care of the comments you have given before we ask the WG for adoption. Thanks, Nitish On 20/01/16 1:23 am, "Chris Bowers" wrote: >Nitish and co-authors, > >I have read this draft and have several comments below. In general, I >prefer that authors address outstanding comments in a new revision before >we conduct a poll for adoption in RTGWG. Since an adoption poll usually >triggers quite a few people read a draft in detail, it makes better use >of the working groups time to have them reading the most up-to-date >version. However, an argument could also be made for filling in some of >the additional detail that I am asking for below after WG adoption >(assuming it is adopted), when the WG has more direct control of the >document. So I am open to either approach. > >So please respond to the feedback below and tell me if you would like to >address some of it in a new revision before I conduct a poll for WG >adoption, or if you would prefer to do the WG adoption poll using the >current revision. There has also been feedback from others on this draft >in response to your email, so you should respond to that as well. > >In general, I think the draft would benefit from specifying the VRRP >state machine for this BFD mode of operation at the same level of detail >that RFC5798 specifies the existing VRRP state machine. There are >several places where it is probably possible to infer the correct >behavior, but making it very explicit will make for a better document. > >1) Section 3.5 of this draft defines the Critical BFD session which is >the BFD session between the VRRP Master and the next best VRRP backup. >In the existing VRRP state machine, a VRRP router in the backup state is >not able to determine if it is the next best VRRP backup. Presumably, in >the VRRP state machine for the BFD mode of operation, a VRRP router in >the backup state will look at the peer table populated by the Backup >Advertisements and figure out which router is the next best VRRP router >based on highest priority value with highest IPvX address as tie breaker. > However, it would be better to be as explicit as RFC5798 about how this >new state machine operates. > >2) Section 5 says that "To reduce the number of packets generated at a >regular interval, Backup Advert packets may be sent at a reduced rate as >compared to Advert packets sent by the VRRP Master." It seems that the >state machine for VRRP BFD mode will have to be enhanced in some way to >support this. One way to do this would be for each router to have a >Backup_Advertisement_Interval which it uses to populate the Maximum >Advertisement Interval in the BACKUP ADVERTISEMENT, and have each >receiving router maintain a Peer_Advert_Interval(P) for each peer(P), and >remove a peer entry when a BACKUP ADVERTISEMENT is not received from P >for 3* Peer_Advert_Interval(P). But this is just one possible approach. >In any case, it would be good to choose a mechanism and describe the >corresponding state machine. > >3) The text should clarify how the VRRP state machine interacts with the >BFD state machine. One can imagine scenarios where a BFD session stays >up but the VRRP advertisements stop being received, or vice versa. This >scenario is not very far-fetched because BFD may use unicast and VRRP >uses multicast. Behavior can probably be inferred from existing text, >but I think more precision is better here. > >4) I don't understand Section 4 which describes how to use p2mp BFD. > >A) The text says that "The Master router starts transmitting BFD control >packets with VRID as source IP address." According to RFC5798, the VRID >is an integer in the range from 1-255. Is the idea to encode the integer >VRID as an IP address? Or should the BFD control packets be sent with >the source IP address set to an IPvX address associated with the virtual >router? Or are both used? In any case, it seems like this needs >clarification. > >B) What is the destination IP address of the p2mp BFD control packet? Is >it 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IPv4 and IPv6 multicast >addresses for VRRP? If so, this should be made explicit. > >C) Again, a state machine description would help readers and future >implementers understand exactly what is intended. > >Thanks, >Chris > >-----Original Message----- >From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Nitish Gupta >(nitisgup) >Sent: Wednesday, January 13, 2016 3:31 AM >To: rtgwg@ietf.org; rtg-bfd@ietf.org >Cc: Gregory Mirsky ; Jeff Haas >; colin@doch.org.uk; Aditya Dogra (addogra) > >Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt > >Hi, > >We had presented the Draft for VRRP BFD integration in IETF 93 and we had >taken care of all the comments that came as part of the WG meeting. >We had also merged the two drafts as per the comments in IETF 93: >http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 >https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 > >We had presented the merged draft in IETF 94 and there were no specific >comments on the draft. >We would like to ask the RTGWG to adopt the Draft as a WG document. > >Thanks, >Nitish > > >On 26/10/15 11:57 am, "Nitish Gupta (nitisgup)" >wrote: > >>Hi, >> >>We have submitted a new version of the draft. As discussed in IETF 93 >>at prague. >> >>We have merged the following drafts: >>http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 >> >>https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 >> >> >> >>We have also taken care of all the comments that were discussed in the >>RTGWG meeting. >>We welcome any comments and suggestions on the draft. >> >>Thanks, >>Nitish >> >>On 13/10/15 9:09 pm, "internet-drafts@ietf.org" >> >>wrote: >> >>> >>>A new version of I-D, draft-nitish-vrrp-bfd-02.txt has been >>>successfully submitted by Nitish Gupta and posted to the IETF >>>repository. >>> >>>Name: draft-nitish-vrrp-bfd >>>Revision: 02 >>>Title: Fast failure detection in VRRP with BFD >>>Document date: 2015-10-13 >>>Group: Individual Submission >>>Pages: 10 >>>URL: =20 >>>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt >>>Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ >>>Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 >>>Diff: =20 >>>https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02 >>> >>>Abstract: >>> This document describes how Bidirectional Forwarding Detection (BFD) >>> can be used to support sub-second detection of a Master Router >>> failure in the Virtual Router Redundancy Protocol (VRRP). >>> >>> =20 >>> =20 >>> >>> >>>Please note that it may take a couple of minutes from the time of >>>submission until the htmlized version and diff are available at >>>tools.ietf.org. >>> >>>The IETF Secretariat >>> >> > >_______________________________________________ >rtgwg mailing list >rtgwg@ietf.org >https://www.ietf.org/mailman/listinfo/rtgwg From nobody Wed Jan 20 07:10:43 2016 Return-Path: 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 C89B81A8AAD; Wed, 20 Jan 2016 07:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 fu9jpFJpfZy4; Wed, 20 Jan 2016 07:10:41 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0145.outbound.protection.outlook.com [207.46.100.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30491A8AAC; Wed, 20 Jan 2016 07:10:39 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jhaas@juniper.net; Received: from [172.29.32.70] (66.129.241.13) by CY1PR0501MB1817.namprd05.prod.outlook.com (10.163.141.143) with Microsoft SMTP Server (TLS) id 15.1.365.19; Wed, 20 Jan 2016 15:10:35 +0000 Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_5E83A4DA-8974-4C69-8E36-FB15AF2E2A89" From: Jeff Haas In-Reply-To: Date: Wed, 20 Jan 2016 10:10:29 -0500 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> <6B91DFE6-1CC9-4D17-BD19-8D3F1FDBF365@gmail.com> To: "Nitish Gupta (nitisgup)" X-Mailer: Apple Mail (2.2104) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BY1PR18CA0028.namprd18.prod.outlook.com (25.162.126.38) To CY1PR0501MB1817.namprd05.prod.outlook.com (25.163.141.143) X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1817; 2:zokglNlVTSMt+vQ7/YWpzEXBuLr+zI6iqKaZhKuyL6m5KzzJrK6svBxtxVaYU9ojBDsAUD6rJ/G3f2n0VUzPwc9FgmJ5SoaHO4qD9f4YNsGwMUC6QVDytjPVECJ0I9ieHum24+mvOqQaTf8RZAkhrg==; 3:CT1DeSiBXR/1y3BmIigzplTuL51WrmZ38JvEzKVICa/wkkqEH8d59S85kzBHSvk/xpqcYo2dO8uYUAoMGwX+wHPF4vC9x4/CfTox5Yx8t2RnbmHj6YQ7GZ5HLRH00T1n; 25:Ms9sF08wrgXkXmtPLrqpzx9lpjjWtv7xBiOnWdRT3HmQUwOpbgjDLL0eDl7qaKEAm25F/jK0vDb1CD4WDma8rPRO8KdpnnEztBla7TjFc7eDCGrng1fZTzGjYh1lhwtRDAY5rZ7R7IRVZAbpJGJA86SiKq/2IWe5A3uqmA20dqPhLtx0tgQXYbcUfUI1qI5oZ0D+G9vdpH/G/XjI8t/xEy297LMuhyfyx/i8DnpUjzvU95prXi1IUDWOkHY0OFrq X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1817; X-MS-Office365-Filtering-Correlation-Id: 1d2b4209-2659-474d-7808-08d321abda88 X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1817; 20:CWBCC1Ca+fMS40Em4/Z72WHQLfMr1jaxlLpMJIi5HuOl/6p4pRWcivjFtTTjX/KpEETVcvU2Mu1tXDOxWJrtCZaKoBEWQhdbSsXYCBIV1RsWGeWsP+zmZY3vHK7rjaU7jsf0JKNuaUHRF4iR1aIZTRhuYg7XS9rsPXvJGtg7vcy0nNIKMuK7OeKFY8W+FWQl4fe6ulL3vIn3rd5R8TU1q/xJr87OZev0FCiiUcd4LvMiO+X33Vb83Erj4EZsvKjg1LSILKu9nx8GsV+U+yj6bmyh63sfU/5dHA0dlj+gjeW94Ks9OWPaj5+BmyH8xj/kPG2XHG23DAsFa7xVjhp2dJMTKLvl6YSRRnVdaERRM7BjWmBxXS5bXAcDe+WaobwqJzMePZ0sKRSXIrLhlkAF39q6mOBCPpsmV0wgRHYYhzGS/zfL0hPPGvt04GtMStAUpvd9KnE6IiZFSOM3Iy7tjIF9REh3tKA/VDHIr9NGF5B5WrGbpxPL/cePukzWJIFB; 4:b43piWshfJTm9E+kLmapC4SxG4FQ1i4x+kciVdBngQXhkSPt0b9CAK4ObS5fvU94PTDLRPI0Rbi6UsyQz0PlotN43ptULxyAcAD5CMv4rnpA0cHdg4eKgQarfVC3211yNIFm9Ep2p+nrUDgz3BBqkofhdwYJjJjQxv1aEGMa7gto/BYfRc4502Wcs8kAdaf32fNCrya5yqroYJKd80AQ4wvmfuV8ALWaVyGkXO/gd0cwEdNFzkPyH80/9Rtj96kwabsHACwmvHllJKubS7KRBLqySOrsm/0OCDQlAv9UF4HCLr7Xl2Soy6MVIVgRepSSuTuhuFScY7XzhlDVHMmvr00B7FwxNzv2h1y8NmZsBkjlMIp8aLAk5nPGWgcFiGurinSeKZd1R8yA4lRfHf7iai6RRnNelKBkNv3T5UBKnBk= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR0501MB1817; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1817; X-Forefront-PRVS: 0827D7ACB9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(24454002)(199003)(377454003)(189002)(106356001)(92566002)(1096002)(77096005)(4326007)(82746002)(86362001)(93886004)(230783001)(19580395003)(2950100001)(5004730100002)(5008740100001)(19580405001)(3846002)(512944002)(6116002)(40100003)(76176999)(66066001)(50986999)(122386002)(101416001)(33656002)(69556001)(189998001)(84326002)(5001960100002)(110136002)(87976001)(36756003)(83716003)(97736004)(81156007)(105586002)(42186005)(57306001)(2906002)(50226001)(586003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1817; H:[172.29.32.70]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; CY1PR0501MB1817; 23:pD9Q8efwz4hkY9WnCTi8sSCyRHBnL0yvTSf?= =?Windows-1252?Q?U0ysHwWDmf8Izv8EE/fa4zMf4GyjbwtmxSNbEv/0S5hrLjBRhlyJBOCR?= =?Windows-1252?Q?F3VDeI/odhYqW9s9ER/8Pi+3rWEja3Zs2AORlhli8D89xoyMobyP3Fun?= =?Windows-1252?Q?Ss2VO0utxc6SWk4yAIq7PR2VQOunxahYyu+sxk8a89lw+Css797yGvyB?= =?Windows-1252?Q?Sri5zwRaQysIoU+lx50aBWTgLbyMBcJhfVQVmjaeltm/8sTW1uYkGRhH?= =?Windows-1252?Q?Q2DXFh8MDWxaNJ/YXYvdOxDYWcbxLpfpExYgxow1XDdQSRH6Kgot0NFR?= =?Windows-1252?Q?zlti0lUkLp1Xp6uMIzYsHNlLYBnlXdfCwSaO7wYB9MSI8F5ld+t2OZQc?= =?Windows-1252?Q?7lU02X4VR2bIUIfHn1YKTOyPz3OZ3b1K5EbSk3YlDJUGDnqeV6P/1zoa?= =?Windows-1252?Q?PsgTAUjcC0z+J1lSqJO0bmping21cs9dAKAlFGcRmyeZd0JI6Gu9P134?= =?Windows-1252?Q?xcjD8AxFaoO4lOOplK7p90V29/Ti5k+Wrs6QcCVSg+2Pd5PrT+47OydA?= =?Windows-1252?Q?3sAC10wpkHwCH8yby2qQLBikTo3JWAU+xbkJYuTXg5WMdDQAU85qAHTn?= =?Windows-1252?Q?AuV7JFK3jYzwPXogyU3FnLWJawsMeaPFdJGMPc1JToClrIozFIF9d5gT?= =?Windows-1252?Q?/Z/7r9j9k7Hmatwi5K7oR0rlHEKO1SL4IibzLKhvk0aBGA6i4bSYHMLg?= =?Windows-1252?Q?qVAxpRB0h8vxaJ+R7i29mVS/9gppTOgv6nyTqutIv02CMJRFozqrb5aO?= =?Windows-1252?Q?1mkor0+8Q5OjWTNyf+rhj8kwB3MvFc8GDRYb1ZNwR96pgDyS3/2QcDcx?= =?Windows-1252?Q?h70Voegb3MeYIEt84jA2XE3D8FZGqoNxLDPN4A9L372g7iKd4RLzg0DU?= =?Windows-1252?Q?Ep7mGvfMa7pGdYrIlNEPfaw7x3gdCoO7QVqSMDW/fadx+cUbYDnHKVNJ?= =?Windows-1252?Q?NGHkuez/cTXJzvNUDfdnDyZqjJ6jUyDsioA9XbUsrrVEmdT2Quv3dnsJ?= =?Windows-1252?Q?4asVRfebHxcJ2H7NiCx/t6AWGELN/s8pxsGV/UiNMj63E/0ubqmf7OJo?= =?Windows-1252?Q?/ydDDDooLHEMYTpzZJmXDlNGYUNQ5jo3/7cqp03TqmtcYE9cN/5PIJwF?= =?Windows-1252?Q?pkYyf22r7vM8JyCPen5tKY2EPjh/P4QbWPsDrj/51n2Ym0blypTIvYz5?= =?Windows-1252?Q?QI8Qaw6KaNYGNnevH1u/XTEgb2BJ+t+jQx3sqoqA=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1817; 5:5PpSl9t8Te6hgS7pF/aTWfDHl8MGMquAyInd/p28QvMDOWIFoqvrODy/yYVDx3n/bEspsc1zT1BM7j9BI2fd6Ada3p0FV+iesz6C3NkfPbAKnVQlRiYG1bL9N07bsB2Eni7WwvNSaFr+VOQD64/flQ==; 24:+FqY28Dx0xs2/syzyPmJn4shfRAOnjHkkXwP8PsE3v8OKJJFFt4ml7WACoav9W2tchAEXdFUURTkFsA1eLbQTZoTeitgaPqB1ObGzVJTpqo= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2016 15:10:35.9496 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1817 Archived-At: Cc: "Aditya Dogra \(addogra\)" , "colin@doch.org.uk" , "rtg-bfd@ietf.org" , "rtgwg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 15:10:42 -0000 --Apple-Mail=_5E83A4DA-8974-4C69-8E36-FB15AF2E2A89 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" > On Jan 20, 2016, at 12:32 AM, Nitish Gupta (nitisgup) = wrote: >=20 > The other thing I want to make sure if there is any particular = configuration requirement from a BFD YANG model perspective. I = understand that you are using the fast timer in BFD to detect next-hop = IP address liveliness check. We address that configuration in the BFD = YANG model today. However, we have not addressed the issue of p2mp BFD = configuration as yet. Depending on how that discussion proceeds we might = want to look at that also. >=20 > [nitish] There is no particular requirement that we can see from BFD = YANG model perspective. As VRRP should interface with BFD as another = protocol using BFD as a means of fast failure detection of its peer. The desired behavior we're looking for in yang is ideally making use of = the groupings exported by the BFD yang module. This permits a simple = maintainable place to put BFD session parameters. There are two issues Mahesh is alluding to: 1. Multipoint is currently not in the BFD yang spec. Thus, the BFD yang = team has homework to provide support for that option to allow modules = such as a vrrp module supporting this feature to import it. 2. VRRP would only utilize this in *some* circumstances; namely the = master/backup scenario rather than each backup. Configuration state = would likely be consistent, but ti does make the operational state a bit = trickier. The session is provisioned, but may not be started - and it = may not even be *instantiated* depending on the implementation and = whether the priority of the VRRP router is lower than the first = available backup. -- Jeff --Apple-Mail=_5E83A4DA-8974-4C69-8E36-FB15AF2E2A89 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="windows-1252"
On Jan 20, 2016, at 12:32 AM, Nitish Gupta (nitisgup) <nitisgup@cisco.com> = wrote:

The other thing I want to make sure if there is any = particular configuration requirement from a BFD YANG model perspective. = I understand that you are using the fast timer in BFD to detect next-hop = IP address liveliness check. We address that configuration in the BFD YANG model today. However, we have not addressed the issue = of p2mp BFD configuration as yet. Depending on how that discussion = proceeds we might want to look at that also.

[nitish] There is no particular requirement that we can = see from BFD YANG model perspective. As VRRP should interface with BFD = as another protocol using BFD as a means of fast failure detection of = its peer.

The desired behavior we're looking for in yang is = ideally making use of the groupings exported by the BFD yang module. =  This permits a simple maintainable place to put BFD session = parameters.

There are two issues = Mahesh is alluding to:
1. Multipoint is currently not in the = BFD yang spec.  Thus, the BFD yang team has homework to provide = support for that option to allow modules such as a vrrp module = supporting this feature to import it.
2. VRRP would only = utilize this in *some* circumstances; namely the master/backup scenario = rather than each backup.  Configuration state would likely be = consistent, but ti does make the operational state a bit trickier. =  The session is provisioned, but may not be started - and it may = not even be *instantiated* depending on the implementation and whether = the priority of the VRRP router is lower than the first available = backup.

-- Jeff

= --Apple-Mail=_5E83A4DA-8974-4C69-8E36-FB15AF2E2A89-- From nobody Thu Jan 21 10:56:46 2016 Return-Path: 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 D6A461A8A6C; Thu, 21 Jan 2016 10:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 mZ3n2fYDGJRg; Thu, 21 Jan 2016 10:56:40 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72B41A8A68; Thu, 21 Jan 2016 10:56:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8375; q=dns/txt; s=iport; t=1453402600; x=1454612200; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Z6eg6J2pxk5OYdWjI0tJyOf1evLN8ddWGF8XExQq7/M=; b=L2CMVmoJ8GUUiFR1tW6p8RrPh71dCWveaEazgYBLdsdSPIQNQcaSH+ID 6uscltO6pwwZZy8HlKnV5bMAVCgP8pvZivyn2df31zFu3QfFQy/TKJe8I Ut6ATLfDOKQMv3zW9I8KkrSyEEGk7XJPdxMzmJODuwfZj7vojyVwQdX6A c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAgAKKaFW/5xdJa1egm5MgT8GiFGyH?= =?us-ascii?q?wENgWKGDwKBPzgUAQEBAQEBAYEKhDQBAQEEdwIQAgEIDgMDAQIoBzIUCQgCBAE?= =?us-ascii?q?NBYgbvhsBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhjiEdIQUWYQbBY1hhRGEAwGNV?= =?us-ascii?q?o55jjsBHgEBQoNmaoYnfAEBAQ?= X-IronPort-AV: E=Sophos; i="5.22,326,1449532800"; d="scan'208,217"; a="63864337" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jan 2016 18:56:39 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u0LIudxf001716 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Jan 2016 18:56:39 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 21 Jan 2016 12:56:38 -0600 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.009; Thu, 21 Jan 2016 12:56:38 -0600 From: "Reshad Rahman (rrahman)" To: Jeff Haas , "Nitish Gupta (nitisgup)" Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYiTS9LHO0Rck2198aSpBcKKZ5+EmUAgIOSG4CAAPKPAIAAwjmAgAGG3wCAAKFngIABfbcA Date: Thu, 21 Jan 2016 18:56:38 +0000 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> <6B91DFE6-1CC9-4D17-BD19-8D3F1FDBF365@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.242.102] Content-Type: multipart/alternative; boundary="_000_D2C511E71132E6rrahmanciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" , "colin@doch.org.uk" , "Aditya Dogra \(addogra\)" , "rtgwg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 18:56:44 -0000 --_000_D2C511E71132E6rrahmanciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable BFD YANG spec doesn't currently support multipoint, what I recall is that t= he DT had agreed to wait for the multipoint draft to become RFC. I assume the YANG model in draft-liu-rtgwg-yang-vrrp would need to be modif= ied/augmented to support this capability? Regards, Reshad. From: Rtg-bfd > o= n behalf of Jeff Haas > Date: Wednesday, January 20, 2016 at 10:10 AM To: "Nitish Gupta (nitisgup)" > Cc: "Aditya Dogra (addogra)" >,= "colin@doch.org.uk" >, "rtg-bfd@ietf.org" >, "rtgwg@ietf.org" > Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt On Jan 20, 2016, at 12:32 AM, Nitish Gupta (nitisgup) > wrote: The other thing I want to make sure if there is any particular configuratio= n requirement from a BFD YANG model perspective. I understand that you are = using the fast timer in BFD to detect next-hop IP address liveliness check.= We address that configuration in the BFD YANG model today. However, we hav= e not addressed the issue of p2mp BFD configuration as yet. Depending on ho= w that discussion proceeds we might want to look at that also. [nitish] There is no particular requirement that we can see from BFD YANG m= odel perspective. As VRRP should interface with BFD as another protocol usi= ng BFD as a means of fast failure detection of its peer. The desired behavior we're looking for in yang is ideally making use of the= groupings exported by the BFD yang module. This permits a simple maintain= able place to put BFD session parameters. There are two issues Mahesh is alluding to: 1. Multipoint is currently not in the BFD yang spec. Thus, the BFD yang te= am has homework to provide support for that option to allow modules such as= a vrrp module supporting this feature to import it. 2. VRRP would only utilize this in *some* circumstances; namely the master/= backup scenario rather than each backup. Configuration state would likely = be consistent, but ti does make the operational state a bit trickier. The = session is provisioned, but may not be started - and it may not even be *in= stantiated* depending on the implementation and whether the priority of the= VRRP router is lower than the first available backup. -- Jeff --_000_D2C511E71132E6rrahmanciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <0EC4112B08DD5E4CAA12C12D7E55B01E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
<Speaking as individual contributor>

BFD YANG spec doesn’t currently support multipoint, what I recal= l is that the DT had agreed to wait for the multipoint draft to become RFC.=  

I assume the YANG model in draft-liu-rtgwg-yang-vrrp would need to be = modified/augmented to support this capability?

Regards,
Reshad.

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Je= ff Haas <jhaas@juniper.net><= br> Date: Wednesday, January 20, 2016 a= t 10:10 AM
To: "Nitish Gupta (nitisgup)&q= uot; <nitisgup@cisco.com> Cc: "Aditya Dogra (addogra)&qu= ot; <addogra@cisco.com>, &qu= ot;colin@doch.org.uk" <colin@doch.org.uk>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: Re: New Version Notificati= on for draft-nitish-vrrp-bfd-02.txt


On Jan 20, 2016, at 12:32 AM, Nitish Gupta (nitisgup) <<= a href=3D"mailto:nitisgup@cisco.com" class=3D"">nitisgup@cisco.com> = wrote:

The other thing I want to make sure if there is any particu= lar configuration requirement from a BFD YANG model perspective. I understa= nd that you are using the fast timer in BFD to detect next-hop IP address l= iveliness check. We address that configuration in the BFD YANG model today. However, we have not addressed the issue of p= 2mp BFD configuration as yet. Depending on how that discussion proceeds we = might want to look at that also.

[nitish] There is no particular requirement that we can see= from BFD YANG model perspective. As VRRP should interface with BFD as anot= her protocol using BFD as a means of fast failure detection of its peer.

The desired behavior we're looking for in yang is ideally making use of the= groupings exported by the BFD yang module.  This permits a simple mai= ntainable place to put BFD session parameters.

There are two issues Mahesh is alluding to:
1. Multipoint is currently not in the BFD yang spec.  Thus, the B= FD yang team has homework to provide support for that option to allow modul= es such as a vrrp module supporting this feature to import it.
2. VRRP would only utilize this in *some* circumstances; namely the ma= ster/backup scenario rather than each backup.  Configuration state wou= ld likely be consistent, but ti does make the operational state a bit trick= ier.  The session is provisioned, but may not be started - and it may not even be *instantiated* depending on th= e implementation and whether the priority of the VRRP router is lower than = the first available backup.

-- Jeff

 --_000_D2C511E71132E6rrahmanciscocom_-- From nobody Wed Jan 27 06:45:34 2016 Return-Path: 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 B5CDD1B326E; Tue, 26 Jan 2016 14:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, TVD_SPACE_RATIO=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 ya6p7x0CUKzJ; Tue, 26 Jan 2016 14:31:23 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 80E881B2BE4; Tue, 26 Jan 2016 14:31:23 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id n5so154714091wmn.0; Tue, 26 Jan 2016 14:31:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=dLPdsmhYvKoVSNoxyfXI/y7jPrA+u2QKFEJKcNVawa0=; b=Yw5n5osbGFC6Ttyaug0lT1rU0q4fqADorGgxfg4gykOTQMstPu0vukAY3FF4QqA9nq fEuY53b+CxoSgOzeI4x/GFUA5OH2tzasGXcAXW7ZuWAF+2jOht/7D9wBBuwg2d1SefLa zpe5O+FpcIpaLpTjs/pWVeo6EnFoq63Vex00/YA7XUpJ3qlfuryE7nqnOql7UG88qiHM qv3R4slhqdKzqyf0/NSfoIVbnPGv6Y3iy8LEJfBo78rb29iJckgjWlegk0uqRC2qDt8t Su0319L8GjtP9eBAWVup22yQzdDf6EZOQbkUA2kwGTSnBmXoieQDVTS+sLs8BMXzUSh2 JE7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=dLPdsmhYvKoVSNoxyfXI/y7jPrA+u2QKFEJKcNVawa0=; b=Xktn760Qc2lLdv7qB1MWBdc0b14QfFQRwAC9OWYzP/gxWr/gM2MNb5R5YkSBiw3Kqp LorYyghSg1KIe/tBxZWXogZzgRdQbQMLqFde7KgwHX2h2nprVbeCzG/ziza3taUtLhQ4 12L2VS3RMsD4goLDzaOazk+AzlghE6GSuFdjDq2BD0TlOYHhI3GudjfGefvay7ov2vg/ gemfY0vR5QTEDKSEns1GXY/B5LJo0hXHAdQ8HFiaXqgHOwzrUIDVWVbCumuHJ8/Jjq0Z AWwAbFEO4ZvT3nT8NDczJKEK3VZ9/5mDpjadw96oiGZ82Qc5TvjxlBdjwxRiAVZZS+sz aiHg== X-Gm-Message-State: AG10YOSpgYdj9ahiryiNheMpVCSnloZ5gS/sNab3NAy8T9ksWDhvIlF8UtdN6gPgxvTlkteQe2+zHMNjelpRHw== MIME-Version: 1.0 X-Received: by 10.28.19.76 with SMTP id 73mr27802587wmt.24.1453847482149; Tue, 26 Jan 2016 14:31:22 -0800 (PST) Received: by 10.194.30.65 with HTTP; Tue, 26 Jan 2016 14:31:22 -0800 (PST) Date: Tue, 26 Jan 2016 17:31:22 -0500 Message-ID: Subject: Subscribe From: George Swallow To: rtg-bfd@ietf.org, isis-wg@ietf.org, wg-chairs@ietf.org Content-Type: multipart/alternative; boundary=001a1145b8d8bb3844052a443e90 Archived-At: X-Mailman-Approved-At: Wed, 27 Jan 2016 06:45:33 -0800 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 22:31:24 -0000 --001a1145b8d8bb3844052a443e90 Content-Type: text/plain; charset=UTF-8 subscribe --001a1145b8d8bb3844052a443e90 Content-Type: text/html; charset=UTF-8
subscribe
--001a1145b8d8bb3844052a443e90-- From nobody Wed Jan 27 17:42:52 2016 Return-Path: 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 C96361A01EC; Wed, 27 Jan 2016 17:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 mEIgGEbGTcQd; Wed, 27 Jan 2016 17:42:42 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B96181A0262; Wed, 27 Jan 2016 17:42:41 -0800 (PST) X-AuditID: c6180641-f799c6d000007d66-64-56a971fe66ee Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id C5.6C.32102.EF179A65; Thu, 28 Jan 2016 02:42:22 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0248.002; Wed, 27 Jan 2016 20:42:40 -0500 From: Gregory Mirsky To: Chris Bowers , "Nitish Gupta (nitisgup)" , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYpHSG9NZLZk0mhGks73w62U559pVgAgHxsaYCAChvegIAMmnag Date: Thu, 28 Jan 2016 01:42:39 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221996661@eusaamb103.ericsson.se> References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221996661eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOIsWRmVeSWpSXmKPExsUyuXSPn+6/wpVhBo8+Slqcv7+Z0eLHeleL fVNfM1psm25hceLhRSaLz3+2MVpcePOb2YHdY8rvjawer3+sZfZYsuQnk8f1pqvsASxRXDYp qTmZZalF+nYJXBl9fa8ZC778ZKzY0jiXuYFx0zXGLkZODgkBE4nPv7vZIGwxiQv31gPZXBxC AkcYJaYtO8wM4SxnlLj06TZYB5uAkcSLjT3sILaIwBJGiePXE0FsZoEqiZPf21lBbGEBN4nb D48xQtS4S0y5uxzI5gCy3SRmbwQLswioSix/PAHM5hXwleiff5wdYtcdRolzX/ewgCQ4BaIl Wp5sACtiBLru+6k1TBC7xCVuPZnPBHG1gMSSPeeZIWxRiZeP/7FC2EoSk5aeY4Woz5e439vO DLFMUOLkzCcsExhFZyEZNQtJ2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0VI0dp cUFObrqR4SZGYHQek2Bz3MG4t9fzEKMAB6MSD6/BoeVhQqyJZcWVuYcYJTiYlUR4ZyWvDBPi TUmsrEotyo8vKs1JLT7EKM3BoiTOu4V/UZiQQHpiSWp2ampBahFMlomDU6qBsUtX8K3h23rX q+L3ZPL5zmRsemledqR2SlD+h3XzunobGOZ9s4w+OXu1IZuU8OKAOPvPbiu5w648st3etyvs us7q331PdNeIn7yxvkjlc5Js4MyohAlLXGeWzxE7I/D1k+3uxYILoxczus5M2+Y2w/mjU83/ XW5HVz0OlLsvd1M7Pb5n/8ZzqkosxRmJhlrMRcWJAG8+DBTKAgAA Archived-At: Cc: Jeff Haas , "colin@doch.org.uk" , "Aditya Dogra \(addogra\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 01:42:50 -0000 --_000_7347100B5761DC41A166AC17F22DF11221996661eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Chris, greatly appreciate your thorough review and the most detailed comments. As = we've contributed p2mp BFD applicability to VRRP part of the draft I'll add= ress your comments, that I've copied below, to Section 4. Please find my no= tes tagged GIM>> 4) I don't understand Section 4 which describes how to use p2mp BFD. GIM>> Hope that will be clearer once I address your questions to the Secti= on 4 below. A) The text says that "The Master router starts transmitting BFD control pa= ckets with VRID as source IP address." According to RFC5798, the VRID is a= n integer in the range from 1-255. Is the idea to encode the integer VRID = as an IP address? Or should the BFD control packets be sent with the sour= ce IP address set to an IPvX address associated with the virtual router? O= r are both used? In any case, it seems like this needs clarification. GIM>> Very good catch. Indeed, the idea is to use IPvX address associated w= ith the particular VRID. Would the following change clarify selection of so= urce IP address: The Master router starts transmitting BFD control packets with IPvX address= associated with the VRID as source IP address. Backup router demultiplexes= p2mp BFD test sessions based on IP source address associated with the virt= ual router that it been configured with. B) What is the destination IP address of the p2mp BFD control packet? Is i= t 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IPv4 and IPv6 multicast addresses= for VRRP? If so, this should be made explicit. GIM>> I think that VRRP multicast address MAY be used as destination IP add= ress for p2mp BFD which has VRRP as its client. I think that subnet broadca= st address SHOULD be used as destination IP address. I'll add the text to t= he Section 4. C) Again, a state machine description would help readers and future impleme= nters understand exactly what is intended. GIM>> p2mp BFD, as I think, does not change VRRP state machine. I'll add st= atement to that to the text for the next version. -----Original Message----- From: Chris Bowers [mailto:cbowers@juniper.net] Sent: Tuesday, January 19, 2016 11:54 AM To: Nitish Gupta (nitisgup); rtgwg@ietf.org; rtg-bfd@ietf.org Cc: Gregory Mirsky; Jeff Haas; colin@doch.org.uk; Aditya Dogra (addogra) Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Nitish and co-authors, I have read this draft and have several comments below. In general, I pref= er that authors address outstanding comments in a new revision before we co= nduct a poll for adoption in RTGWG. Since an adoption poll usually trigger= s quite a few people read a draft in detail, it makes better use of the wor= king groups time to have them reading the most up-to-date version. However= , an argument could also be made for filling in some of the additional deta= il that I am asking for below after WG adoption (assuming it is adopted), w= hen the WG has more direct control of the document. So I am open to eithe= r approach. So please respond to the feedback below and tell me if you would like to ad= dress some of it in a new revision before I conduct a poll for WG adoption,= or if you would prefer to do the WG adoption poll using the current revisi= on. There has also been feedback from others on this draft in response to = your email, so you should respond to that as well. In general, I think the draft would benefit from specifying the VRRP state = machine for this BFD mode of operation at the same level of detail that RFC= 5798 specifies the existing VRRP state machine. There are several places = where it is probably possible to infer the correct behavior, but making it = very explicit will make for a better document. 1) Section 3.5 of this draft defines the Critical BFD session which is the = BFD session between the VRRP Master and the next best VRRP backup. In the = existing VRRP state machine, a VRRP router in the backup state is not able = to determine if it is the next best VRRP backup. Presumably, in the VRRP s= tate machine for the BFD mode of operation, a VRRP router in the backup sta= te will look at the peer table populated by the Backup Advertisements and f= igure out which router is the next best VRRP router based on highest priori= ty value with highest IPvX address as tie breaker. However, it would be be= tter to be as explicit as RFC5798 about how this new state machine operates= . 2) Section 5 says that "To reduce the number of packets generated at a regu= lar interval, Backup Advert packets may be sent at a reduced rate as compar= ed to Advert packets sent by the VRRP Master." It seems that the state mac= hine for VRRP BFD mode will have to be enhanced in some way to support this= . One way to do this would be for each router to have a Backup_Advertisem= ent_Interval which it uses to populate the Maximum Advertisement Interval i= n the BACKUP ADVERTISEMENT, and have each receiving router maintain a Peer_= Advert_Interval(P) for each peer(P), and remove a peer entry when a BACKUP = ADVERTISEMENT is not received from P for 3* Peer_Advert_Interval(P). But t= his is just one possible approach. In any case, it would be good to choos= e a mechanism and describe the corresponding state machine. 3) The text should clarify how the VRRP state machine interacts with the BF= D state machine. One can imagine scenarios where a BFD session stays up b= ut the VRRP advertisements stop being received, or vice versa. This scenar= io is not very far-fetched because BFD may use unicast and VRRP uses multic= ast. Behavior can probably be inferred from existing text, but I think mor= e precision is better here. 4) I don't understand Section 4 which describes how to use p2mp BFD. A) The text says that "The Master router starts transmitting BFD control pa= ckets with VRID as source IP address." According to RFC5798, the VRID is a= n integer in the range from 1-255. Is the idea to encode the integer VRID = as an IP address? Or should the BFD control packets be sent with the sour= ce IP address set to an IPvX address associated with the virtual router? O= r are both used? In any case, it seems like this needs clarification. B) What is the destination IP address of the p2mp BFD control packet? Is i= t 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IPv4 and IPv6 multicast addresses= for VRRP? If so, this should be made explicit. C) Again, a state machine description would help readers and future impleme= nters understand exactly what is intended. Thanks, Chris -----Original Message----- From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Nitish Gupta (niti= sgup) Sent: Wednesday, January 13, 2016 3:31 AM To: rtgwg@ietf.org; rtg-bfd@ietf.org Cc: Gregory Mirsky >; Jeff Haas >; colin@d= och.org.uk; Aditya Dogra (addogra) > Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Hi, We had presented the Draft for VRRP BFD integration in IETF 93 and we had t= aken care of all the comments that came as part of the WG meeting. We had also merged the two drafts as per the comments in IETF 93: http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 We had presented the merged draft in IETF 94 and there were no specific com= ments on the draft. We would like to ask the RTGWG to adopt the Draft as a WG document. Thanks, Nitish On 26/10/15 11:57 am, "Nitish Gupta (nitisgup)" > wrote: >Hi, > >We have submitted a new version of the draft. As discussed in IETF 93 >at prague. > >We have merged the following drafts: >http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 > >https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 > > > >We have also taken care of all the comments that were discussed in the >RTGWG meeting. >We welcome any comments and suggestions on the draft. > >Thanks, >Nitish > >On 13/10/15 9:09 pm, "internet-drafts@ietf.org" >> >wrote: > >> >>A new version of I-D, draft-nitish-vrrp-bfd-02.txt has been >>successfully submitted by Nitish Gupta and posted to the IETF >>repository. >> >>Name: draft-nitish-vrrp-bfd >>Revision: 02 >>Title: Fast failure detection in VRRP with BFD >>Document date: 2015-10-13 >>Group: Individual Submission >>Pages: 10 >>URL: >>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt >>Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ >>Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 >>Diff: >>https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02 >> >>Abstract: >> This document describes how Bidirectional Forwarding Detection (BFD) >> can be used to support sub-second detection of a Master Router >> failure in the Virtual Router Redundancy Protocol (VRRP). >> >> >> >> >> >>Please note that it may take a couple of minutes from the time of >>submission until the htmlized version and diff are available at >>tools.ietf.org. >> >>The IETF Secretariat >> > _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg --_000_7347100B5761DC41A166AC17F22DF11221996661eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Chris,

greatly appreciate your thorough review and the m= ost detailed comments. As we've contributed p2mp BFD applicability to VRRP = part of the draft I'll address your comments, that I've copied below, to Se= ction 4. Please find my notes tagged GIM>>

 

4) I don't understand Section 4 which describes h= ow to use p2mp BFD.   

GIM>>  Hope that will be clearer once = I address your questions to the Section 4 below.

 

A) The text says that "The Master router sta= rts transmitting BFD control packets with VRID as source IP address."&= nbsp; According to RFC5798, the VRID is an integer in the range from 1-255.=   Is the idea to encode the integer VRID as an IP address?   Or should the BFD control packets be sent with the so= urce IP address set to an IPvX address associated with the virtual router?&= nbsp; Or are both used?  In any case, it seems like this needs clarifi= cation.

GIM>> Very good catch. Indeed, the idea is = to use IPvX address associated with the particular VRID. Would the followin= g change clarify selection of source IP address:

The Master router star= ts transmitting BFD control packets with IPvX address associated with the V= RID as source IP address. Backup router demultiplexes p2mp BFD test session= s based on IP source address associated with the virtual router that it been configured with.

 

B) What is the destination IP address of the p2mp= BFD control packet?  Is it 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IP= v4 and IPv6 multicast addresses for VRRP?  If so, this should be made = explicit.

GIM>> I think that VRRP multicast address M= AY be used as destination IP address for p2mp BFD which has VRRP as its cli= ent. I think that subnet broadcast address SHOULD be used as destination IP= address. I’ll add the text to the Section 4.

 

C) Again, a state machine description would help = readers and future implementers understand exactly what is intended.

GIM>> p2mp BFD, as I think, does not change= VRRP state machine. I’ll add statement to that to the text for the n= ext version.

 

-----Original Message-----
From: Chris Bowers [mailto:cbowers@juniper.net]
Sent: Tuesday, January 19, 2016 11:54 AM
To: Nitish Gupta (nitisgup); rtgwg@ietf.org; rtg-bfd@ietf.org
Cc: Gregory Mirsky; Jeff Haas; colin@doch.org.uk; Aditya Dogra (addogra) Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt

 

Nitish and co-authors,

 

I have read this draft and have several comments = below.  In general, I prefer that authors address outstanding comments= in a new revision before we conduct a poll for adoption in RTGWG.  Si= nce an adoption poll usually triggers quite a few people read a draft in detail, it makes better use of the working gr= oups time to have them reading the most up-to-date version.  However, = an argument could also be made for filling in some of the additional detail= that I am asking for below after WG adoption (assuming it is adopted), when the WG has more direct control of = the document.   So I am open to either approach.

 

So please respond to the feedback below and tell = me if you would like to address some of it in a new revision before I condu= ct a poll for WG adoption, or if you would prefer to do the WG adoption pol= l using the current revision.  There has also been feedback from others on this draft in response to your email= , so you should respond to that as well.

 

In general, I think the draft would benefit from = specifying the VRRP state machine for this BFD mode of operation at the sam= e level of detail that RFC5798 specifies the existing VRRP state machine.&n= bsp;  There are several places where it is probably possible to infer the correct behavior, but making it very exp= licit will make for a better document.

 

1) Section 3.5 of this draft defines the Critical= BFD session which is the BFD session between the VRRP Master and the next = best VRRP backup.  In the existing VRRP state machine, a VRRP router i= n the backup state is not able to determine if it is the next best VRRP backup.  Presumably, in the VRRP state ma= chine for the BFD mode of operation, a VRRP router in the backup state will= look at the peer table populated by the Backup Advertisements and figure o= ut which router is the next best VRRP router based on highest priority value with highest IPvX address as tie br= eaker.  However, it would be better to be as explicit as RFC5798 about= how this new state machine operates.

 

2) Section 5 says that "To reduce the number= of packets generated at a regular interval, Backup Advert packets may be s= ent at a reduced rate as compared to Advert packets sent by the VRRP Master= ."  It seems that the state machine for VRRP BFD mode will have to be enhanced in some way to support this.  = One  way to do this would be for each router to have a Backup_Advertis= ement_Interval which it uses to populate the Maximum Advertisement Interval= in the BACKUP ADVERTISEMENT, and have each receiving router maintain a Peer_Advert_Interval(P) for each peer(P), and = remove a peer entry when a BACKUP ADVERTISEMENT is not received from P for = 3* Peer_Advert_Interval(P).  But this is just one possible approach.&n= bsp; In any case,  it would be good to choose a mechanism and describe the corresponding state machine.

 

3) The text should clarify how the VRRP state mac= hine interacts with the BFD state machine.   One can imagine scen= arios where a BFD session stays up but the VRRP advertisements stop being r= eceived, or vice versa.  This scenario is not very far-fetched because BFD may use unicast and VRRP uses multicast. = ; Behavior can probably be inferred from existing text, but I think more pr= ecision is better here.

 

4) I don't understand Section 4 which describes h= ow to use p2mp BFD.   

 

A) The text says that "The Master router sta= rts transmitting BFD control packets with VRID as source IP address."&= nbsp; According to RFC5798, the VRID is an integer in the range from 1-255.=   Is the idea to encode the integer VRID as an IP address?   Or should the BFD control packets be sent with the so= urce IP address set to an IPvX address associated with the virtual router?&= nbsp; Or are both used?  In any case, it seems like this needs clarifi= cation.

 

B) What is the destination IP address of the p2mp= BFD control packet?  Is it 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IP= v4 and IPv6 multicast addresses for VRRP?  If so, this should be made = explicit.

 

C) Again, a state machine description would help = readers and future implementers understand exactly what is intended.

 

Thanks,

Chris

 

-----Original Message-----

From: rtgwg [mailto:rtgwg-bo= unces@ietf.org] On Behalf Of Nitish Gupta (nitisgup)<= /p>

Sent: Wednesday, January 13, 2016 3:31 AM

To: rtgwg@ietf.org; rtg-bfd@ietf.org

Cc: Gregory Mirsky <= gregory.mirsky@ericsson.com>; Jeff Haas <j= haas@juniper.net>; colin@doch.org.uk; Aditya Dogra (addogra) <addogra@cisco.com>

Subject: Re: New Version Notification for draft-n= itish-vrrp-bfd-02.txt

 

Hi,

 

We had presented the Draft for VRRP BFD integrati= on in IETF 93 and we had taken care of all the comments that came as part o= f the WG meeting.

We had also merged the two drafts as per the comm= ents in IETF 93:

http:/= /tools.ietf.org/html/draft-nitish-vrrp-bfd-01

https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00=

 

We had presented the merged draft in IETF 94 and = there were no specific comments on the draft.

We would like to ask the RTGWG to adopt the Draft= as a WG document.

 

Thanks,

Nitish

 

 

On 26/10/15 11:57 am, "Nitish Gupta (nitisgu= p)" <nitisgup@cisco.com> wrote:=

 

>Hi,

> 

>We have submitted a new version of the draft.= As discussed in IETF 93

>at prague.

> 

>We have merged the following drafts:

>ht= tp://tools.ietf.org/html/draft-nitish-vrrp-bfd-01

> 

>https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-cas= e-00

> 

> 

> 

>We have also taken care of all the comments t= hat were discussed in the

>RTGWG meeting.

>We welcome any comments and suggestions on th= e draft.

> 

>Thanks,

>Nitish

> 

>On 13/10/15 9:09 pm, "internet-drafts@ietf.org"

><internet-drafts@ie= tf.org>

>wrote:

> 

>> 

>>A new version of I-D, draft-nitish-vrrp-b= fd-02.txt has been

>>successfully submitted by Nitish Gupta an= d posted to the IETF

>>repository.

>> 

>>Name:      =             &nb= sp;          draft-nitish-vrrp= -bfd

>>Revision:     &n= bsp;  02

>>Title:      = ;           Fast failure = detection in VRRP with BFD

>>Document date:    &nb= sp;     2015-10-13

>>Group:      = ;            &n= bsp;         Individual Submission<= o:p>

>>Pages:      = ;            &n= bsp;          10

>>URL:      &= nbsp;    

>>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-= 02.txt

>>Status:     &nbs= p;   https://datatracker.i= etf.org/doc/draft-nitish-vrrp-bfd/

>>Htmlized:     &n= bsp; https://tools.ietf.or= g/html/draft-nitish-vrrp-bfd-02

>>Diff:      =     

>>https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02

>> 

>>Abstract:

>>   This document describes how = Bidirectional Forwarding Detection (BFD)

>>   can be used to support sub-s= econd detection of a Master Router

>>   failure in the Virtual Route= r Redundancy Protocol (VRRP).

>> 

>>       = ;         

>>       = ;

>> 

>> 

>>Please note that it may take a couple of = minutes from the time of

>>submission until the htmlized version and= diff are available at

>>tools.ietf.org.

>> 

>>The IETF Secretariat

>> 

> 

 

_______________________________________________

rtgwg mailing list

rtgwg@ietf.org=

https://www.ie= tf.org/mailman/listinfo/rtgwg

--_000_7347100B5761DC41A166AC17F22DF11221996661eusaamb103erics_-- From nobody Thu Jan 28 07:40:33 2016 Return-Path: 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 BC9DB1A8A3D; Thu, 28 Jan 2016 07:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 dVhVZ-PP1DR6; Thu, 28 Jan 2016 07:40:22 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0114.outbound.protection.outlook.com [65.55.169.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4FC1A8A42; Thu, 28 Jan 2016 07:40:21 -0800 (PST) Received: from DM2PR05MB623.namprd05.prod.outlook.com (10.141.157.24) by BY2PR0501MB1813.namprd05.prod.outlook.com (10.163.155.143) with Microsoft SMTP Server (TLS) id 15.1.390.13; Thu, 28 Jan 2016 15:40:18 +0000 Received: from DM2PR05MB623.namprd05.prod.outlook.com ([10.141.157.24]) by DM2PR05MB623.namprd05.prod.outlook.com ([10.141.157.24]) with mapi id 15.01.0390.016; Thu, 28 Jan 2016 15:40:18 +0000 From: Chris Bowers To: Gregory Mirsky , "Nitish Gupta (nitisgup)" , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYiTS9LHO0Rck2198aSpBcKKZ5+EmUAgHxbjACACWswAIAM9MqAgADbUEA= Date: Thu, 28 Jan 2016 15:40:17 +0000 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF11221996661@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221996661@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net; x-originating-ip: [66.129.239.15] x-microsoft-exchange-diagnostics: 1; BY2PR0501MB1813; 5:i24hHtIn0bc0YJrUDxFIixTrDeiHstaY6THt5AJ3L4dABkQXvvVCWpYkbNhqiIyE58RLTD1kHczuRZDTCGEzr5x6DTLVTdu8tC2KL9mj0apgbzaDtqyLMWUkO+Zo9yO1JZ0KPBZTDIyzJzhOVYeQMg==; 24:fHIiqzyJvy5u0AFwqoLAka8hZ6PnCjoMHzNOCRtchO/V2xyNk/y7P7+FZnYjUl/TAiEw8zKwjhSlCn3ft32pFTPz8fIMOQz8AQnqk9b240s= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0501MB1813; x-ms-office365-filtering-correlation-id: d3791911-58d4-49a0-11f9-08d327f952e5 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BY2PR0501MB1813; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB1813; x-forefront-prvs: 083526BF8A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377424004)(13464003)(189002)(164054003)(51444003)(377454003)(24454002)(199003)(479174004)(11100500001)(33656002)(2501003)(5008740100001)(101416001)(5003600100002)(3660700001)(1220700001)(3470700001)(3846002)(790700001)(102836003)(6116002)(40100003)(19300405004)(1096002)(92566002)(3280700002)(586003)(4326007)(122556002)(74316001)(2906002)(10710500007)(76576001)(54356999)(76176999)(19609705001)(230783001)(50986999)(93886004)(19580395003)(19580405001)(5001770100001)(97736004)(16236675004)(81156007)(87936001)(4001150100001)(5002640100001)(19625215002)(2420400006)(15975445007)(10400500002)(2201001)(5001960100002)(2900100001)(86362001)(99286002)(106356001)(106116001)(2950100001)(189998001)(105586002)(66066001)(19617315012)(77096005)(5004730100002)(7110500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB1813; H:DM2PR05MB623.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_DM2PR05MB6238B357B0163E8E079558EA9DA0DM2PR05MB623namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2016 15:40:17.7174 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB1813 Archived-At: Cc: Jeff Haas , "colin@doch.org.uk" , "Aditya Dogra \(addogra\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 15:40:31 -0000 --_000_DM2PR05MB6238B357B0163E8E079558EA9DA0DM2PR05MB623namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, Thanks. Those clarifications seem reasonable. Draft authors, I do have another general comment about the current text of the draft. Th= e current text discusses two different approaches to doing fast failure det= ection in VRRP with BFD, using p2p BFD or p2mp BFD. The first uses existin= g BFD p2p sessions and enhances VRRP to use the p2p BFD sessions. The seco= nd requires less enhancement of VRRP, but relies on enhanced functionality = in BFD. If this is correct, it would be good for the text to explicitly s= tate that these are two distinct approaches, to help the readers during the= poll for WG adoption. If this work is adopted by RTGWG, one could imagine a scenario where the wo= rking group decides to document both approaches in the final version. Howe= ver, it is usually more desirable for the working group to evaluate the dif= ferent approaches and choose one. It would also be useful for the text to = explicitly state the authors' thoughts and intentions with respect to how t= he document should evolve. Should it ultimately document one solution, sho= uld it document multiple solutions, or should more work be done to determin= e if there are compelling reasons to document multiple solutions? If adop= ted, it will ultimately be up to the WG to decide how to move forward, rega= rdless of the stated intentions of the current authors. However, it would = be useful for the readers during the poll for WG adoption to understand the= authors' current intentions and their thinking on this topic. Thanks, Chris From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Wednesday, January 27, 2016 7:43 PM To: Chris Bowers ; Nitish Gupta (nitisgup) ; rtgwg@ietf.org; rtg-bfd@ietf.org Cc: Jeff Haas ; colin@doch.org.uk; Aditya Dogra (addogra= ) Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Hi Chris, greatly appreciate your thorough review and the most detailed comments. As = we've contributed p2mp BFD applicability to VRRP part of the draft I'll add= ress your comments, that I've copied below, to Section 4. Please find my no= tes tagged GIM>> 4) I don't understand Section 4 which describes how to use p2mp BFD. GIM>> Hope that will be clearer once I address your questions to the Secti= on 4 below. A) The text says that "The Master router starts transmitting BFD control pa= ckets with VRID as source IP address." According to RFC5798, the VRID is a= n integer in the range from 1-255. Is the idea to encode the integer VRID = as an IP address? Or should the BFD control packets be sent with the sour= ce IP address set to an IPvX address associated with the virtual router? O= r are both used? In any case, it seems like this needs clarification. GIM>> Very good catch. Indeed, the idea is to use IPvX address associated w= ith the particular VRID. Would the following change clarify selection of so= urce IP address: The Master router starts transmitting BFD control packets with IPvX address= associated with the VRID as source IP address. Backup router demultiplexes= p2mp BFD test sessions based on IP source address associated with the virt= ual router that it been configured with. B) What is the destination IP address of the p2mp BFD control packet? Is i= t 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IPv4 and IPv6 multicast addresses= for VRRP? If so, this should be made explicit. GIM>> I think that VRRP multicast address MAY be used as destination IP add= ress for p2mp BFD which has VRRP as its client. I think that subnet broadca= st address SHOULD be used as destination IP address. I'll add the text to t= he Section 4. C) Again, a state machine description would help readers and future impleme= nters understand exactly what is intended. GIM>> p2mp BFD, as I think, does not change VRRP state machine. I'll add st= atement to that to the text for the next version. -----Original Message----- From: Chris Bowers [mailto:cbowers@juniper.net] Sent: Tuesday, January 19, 2016 11:54 AM To: Nitish Gupta (nitisgup); rtgwg@ietf.org; rtg-bfd= @ietf.org Cc: Gregory Mirsky; Jeff Haas; colin@doch.org.uk;= Aditya Dogra (addogra) Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Nitish and co-authors, I have read this draft and have several comments below. In general, I pref= er that authors address outstanding comments in a new revision before we co= nduct a poll for adoption in RTGWG. Since an adoption poll usually trigger= s quite a few people read a draft in detail, it makes better use of the wor= king groups time to have them reading the most up-to-date version. However= , an argument could also be made for filling in some of the additional deta= il that I am asking for below after WG adoption (assuming it is adopted), w= hen the WG has more direct control of the document. So I am open to eithe= r approach. So please respond to the feedback below and tell me if you would like to ad= dress some of it in a new revision before I conduct a poll for WG adoption,= or if you would prefer to do the WG adoption poll using the current revisi= on. There has also been feedback from others on this draft in response to = your email, so you should respond to that as well. In general, I think the draft would benefit from specifying the VRRP state = machine for this BFD mode of operation at the same level of detail that RFC= 5798 specifies the existing VRRP state machine. There are several places = where it is probably possible to infer the correct behavior, but making it = very explicit will make for a better document. 1) Section 3.5 of this draft defines the Critical BFD session which is the = BFD session between the VRRP Master and the next best VRRP backup. In the = existing VRRP state machine, a VRRP router in the backup state is not able = to determine if it is the next best VRRP backup. Presumably, in the VRRP s= tate machine for the BFD mode of operation, a VRRP router in the backup sta= te will look at the peer table populated by the Backup Advertisements and f= igure out which router is the next best VRRP router based on highest priori= ty value with highest IPvX address as tie breaker. However, it would be be= tter to be as explicit as RFC5798 about how this new state machine operates= . 2) Section 5 says that "To reduce the number of packets generated at a regu= lar interval, Backup Advert packets may be sent at a reduced rate as compar= ed to Advert packets sent by the VRRP Master." It seems that the state mac= hine for VRRP BFD mode will have to be enhanced in some way to support this= . One way to do this would be for each router to have a Backup_Advertisem= ent_Interval which it uses to populate the Maximum Advertisement Interval i= n the BACKUP ADVERTISEMENT, and have each receiving router maintain a Peer_= Advert_Interval(P) for each peer(P), and remove a peer entry when a BACKUP = ADVERTISEMENT is not received from P for 3* Peer_Advert_Interval(P). But t= his is just one possible approach. In any case, it would be good to choos= e a mechanism and describe the corresponding state machine. 3) The text should clarify how the VRRP state machine interacts with the BF= D state machine. One can imagine scenarios where a BFD session stays up b= ut the VRRP advertisements stop being received, or vice versa. This scenar= io is not very far-fetched because BFD may use unicast and VRRP uses multic= ast. Behavior can probably be inferred from existing text, but I think mor= e precision is better here. 4) I don't understand Section 4 which describes how to use p2mp BFD. A) The text says that "The Master router starts transmitting BFD control pa= ckets with VRID as source IP address." According to RFC5798, the VRID is a= n integer in the range from 1-255. Is the idea to encode the integer VRID = as an IP address? Or should the BFD control packets be sent with the sour= ce IP address set to an IPvX address associated with the virtual router? O= r are both used? In any case, it seems like this needs clarification. B) What is the destination IP address of the p2mp BFD control packet? Is i= t 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IPv4 and IPv6 multicast addresses= for VRRP? If so, this should be made explicit. C) Again, a state machine description would help readers and future impleme= nters understand exactly what is intended. Thanks, Chris -----Original Message----- From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Nitish Gupta (niti= sgup) Sent: Wednesday, January 13, 2016 3:31 AM To: rtgwg@ietf.org; rtg-bfd@ietf.org Cc: Gregory Mirsky >; Jeff Haas >; colin@d= och.org.uk; Aditya Dogra (addogra) > Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Hi, We had presented the Draft for VRRP BFD integration in IETF 93 and we had t= aken care of all the comments that came as part of the WG meeting. We had also merged the two drafts as per the comments in IETF 93: http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 We had presented the merged draft in IETF 94 and there were no specific com= ments on the draft. We would like to ask the RTGWG to adopt the Draft as a WG document. Thanks, Nitish On 26/10/15 11:57 am, "Nitish Gupta (nitisgup)" > wrote: >Hi, > >We have submitted a new version of the draft. As discussed in IETF 93 >at prague. > >We have merged the following drafts: >http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 > >https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 > > > >We have also taken care of all the comments that were discussed in the >RTGWG meeting. >We welcome any comments and suggestions on the draft. > >Thanks, >Nitish > >On 13/10/15 9:09 pm, "internet-drafts@ietf.org" >> >wrote: > >> >>A new version of I-D, draft-nitish-vrrp-bfd-02.txt has been >>successfully submitted by Nitish Gupta and posted to the IETF >>repository. >> >>Name: draft-nitish-vrrp-bfd >>Revision: 02 >>Title: Fast failure detection in VRRP with BFD >>Document date: 2015-10-13 >>Group: Individual Submission >>Pages: 10 >>URL: >>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt >>Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ >>Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 >>Diff: >>https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02 >> >>Abstract: >> This document describes how Bidirectional Forwarding Detection (BFD) >> can be used to support sub-second detection of a Master Router >> failure in the Virtual Router Redundancy Protocol (VRRP). >> >> >> >> >> >>Please note that it may take a couple of minutes from the time of >>submission until the htmlized version and diff are available at >>tools.ietf.org. >> >>The IETF Secretariat >> > _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg --_000_DM2PR05MB6238B357B0163E8E079558EA9DA0DM2PR05MB623namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greg,

 

Thanks.  Those cl= arifications seem reasonable. 

 

Draft authors,

 

I do have another gene= ral comment about the current text of the draft.   The current te= xt discusses two different approaches to doing fast failure detection in VR= RP with BFD, using p2p BFD or p2mp BFD.  The first uses existing BFD p2p sessions and enhances VRRP to use the p2p BFD sessio= ns.  The second requires less enhancement of VRRP, but relies on enhan= ced functionality in BFD.   If this is correct, it would be good = for the text to explicitly state that these are two distinct approaches, to help the readers during the poll for WG adopti= on.

 

If this work is adopte= d by RTGWG, one could imagine a scenario where the working group decides to= document both approaches in the final version.  However, it is usuall= y more desirable for the working group to evaluate the different approaches and choose one.  It would also be u= seful for the text to explicitly state the authors’ thoughts and inte= ntions with respect to how the document should evolve.  Should it ulti= mately document one solution, should it document multiple solutions, or should more work be done to determine if there are = compelling reasons to document multiple solutions?   If adopted, = it will ultimately be up to the WG to decide how to move forward, regardles= s of the stated intentions of the current authors.  However, it would be useful for the readers during the poll= for WG adoption to understand the authors’ current intentions and th= eir thinking on this topic.

 

Thanks,

Chris

 

 

 

From: Gregory Mirsky [mailto:gregory.mirsky@e= ricsson.com]
Sent: Wednesday, January 27, 2016 7:43 PM
To: Chris Bowers <cbowers@juniper.net>; Nitish Gupta (nitisgup= ) <nitisgup@cisco.com>; rtgwg@ietf.org; rtg-bfd@ietf.org
Cc: Jeff Haas <jhaas@juniper.net>; colin@doch.org.uk; Aditya D= ogra (addogra) <addogra@cisco.com>
Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.t= xt

 

Hi Chris,

greatly appreciate your thorough review and the m= ost detailed comments. As we've contributed p2mp BFD applicability to VRRP = part of the draft I'll address your comments, that I've copied below, to Se= ction 4. Please find my notes tagged GIM>>

 

4) I don't understand Section 4 which describes h= ow to use p2mp BFD.   

GIM>>  Hope that will be clearer once = I address your questions to the Section 4 below.

 

A) The text says that "The Master router sta= rts transmitting BFD control packets with VRID as source IP address."&= nbsp; According to RFC5798, the VRID is an integer in the range from 1-255.=   Is the idea to encode the integer VRID as an IP address?   Or should the BFD control packets be sent with the so= urce IP address set to an IPvX address associated with the virtual router?&= nbsp; Or are both used?  In any case, it seems like this needs clarifi= cation.

GIM>> Very good catch. Indeed, the idea is = to use IPvX address associated with the particular VRID. Would the followin= g change clarify selection of source IP address:

The Master router star= ts transmitting BFD control packets with IPvX address associated with the V= RID as source IP address. Backup router demultiplexes p2mp BFD test session= s based on IP source address associated with the virtual router that it been configured with.

 

B) What is the destination IP address of the p2mp= BFD control packet?  Is it 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IP= v4 and IPv6 multicast addresses for VRRP?  If so, this should be made = explicit.

GIM>> I think that VRRP multicast address M= AY be used as destination IP address for p2mp BFD which has VRRP as its cli= ent. I think that subnet broadcast address SHOULD be used as destination IP= address. I’ll add the text to the Section 4.

 

C) Again, a state machine description would help = readers and future implementers understand exactly what is intended.

GIM>> p2mp BFD, as I think, does not change= VRRP state machine. I’ll add statement to that to the text for the n= ext version.

 

-----Original Message-----
From: Chris Bowers [mailto:cbowers@j= uniper.net]
Sent: Tuesday, January 19, 2016 11:54 AM
To: Nitish Gupta (nitisgup); rtgwg@ietf.o= rg; rtg-bfd@ietf.org
Cc: Gregory Mirsky; Jeff Haas; colin@d= och.org.uk; Aditya Dogra (addogra)
Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt=

 

Nitish and co-authors,

 

I have read this draft and have several comments = below.  In general, I prefer that authors address outstanding comments= in a new revision before we conduct a poll for adoption in RTGWG.  Si= nce an adoption poll usually triggers quite a few people read a draft in detail, it makes better use of the working gr= oups time to have them reading the most up-to-date version.  However, = an argument could also be made for filling in some of the additional detail= that I am asking for below after WG adoption (assuming it is adopted), when the WG has more direct control of = the document.   So I am open to either approach.

 

So please respond to the feedback below and tell = me if you would like to address some of it in a new revision before I condu= ct a poll for WG adoption, or if you would prefer to do the WG adoption pol= l using the current revision.  There has also been feedback from others on this draft in response to your email= , so you should respond to that as well.

 

In general, I think the draft would benefit from = specifying the VRRP state machine for this BFD mode of operation at the sam= e level of detail that RFC5798 specifies the existing VRRP state machine.&n= bsp;  There are several places where it is probably possible to infer the correct behavior, but making it very exp= licit will make for a better document.

 

1) Section 3.5 of this draft defines the Critical= BFD session which is the BFD session between the VRRP Master and the next = best VRRP backup.  In the existing VRRP state machine, a VRRP router i= n the backup state is not able to determine if it is the next best VRRP backup.  Presumably, in the VRRP state ma= chine for the BFD mode of operation, a VRRP router in the backup state will= look at the peer table populated by the Backup Advertisements and figure o= ut which router is the next best VRRP router based on highest priority value with highest IPvX address as tie br= eaker.  However, it would be better to be as explicit as RFC5798 about= how this new state machine operates.

 

2) Section 5 says that "To reduce the number= of packets generated at a regular interval, Backup Advert packets may be s= ent at a reduced rate as compared to Advert packets sent by the VRRP Master= ."  It seems that the state machine for VRRP BFD mode will have to be enhanced in some way to support this.  = One  way to do this would be for each router to have a Backup_Advertis= ement_Interval which it uses to populate the Maximum Advertisement Interval= in the BACKUP ADVERTISEMENT, and have each receiving router maintain a Peer_Advert_Interval(P) for each peer(P), and = remove a peer entry when a BACKUP ADVERTISEMENT is not received from P for = 3* Peer_Advert_Interval(P).  But this is just one possible approach.&n= bsp; In any case,  it would be good to choose a mechanism and describe the corresponding state machine.

 

3) The text should clarify how the VRRP state mac= hine interacts with the BFD state machine.   One can imagine scen= arios where a BFD session stays up but the VRRP advertisements stop being r= eceived, or vice versa.  This scenario is not very far-fetched because BFD may use unicast and VRRP uses multicast. = ; Behavior can probably be inferred from existing text, but I think more pr= ecision is better here.

 

4) I don't understand Section 4 which describes h= ow to use p2mp BFD.   

 

A) The text says that "The Master router sta= rts transmitting BFD control packets with VRID as source IP address."&= nbsp; According to RFC5798, the VRID is an integer in the range from 1-255.=   Is the idea to encode the integer VRID as an IP address?   Or should the BFD control packets be sent with the so= urce IP address set to an IPvX address associated with the virtual router?&= nbsp; Or are both used?  In any case, it seems like this needs clarifi= cation.

 

B) What is the destination IP address of the p2mp= BFD control packet?  Is it 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IP= v4 and IPv6 multicast addresses for VRRP?  If so, this should be made = explicit.

 

C) Again, a state machine description would help = readers and future implementers understand exactly what is intended.

 

Thanks,

Chris

 

-----Original Message-----

From: rtgwg [mailto:rtgwg-bo= unces@ietf.org] On Behalf Of Nitish Gupta (nitisgup)<= /p>

Sent: Wednesday, January 13, 2016 3:31 AM

To: rtgwg@ietf.org; rtg-bfd@ietf.org

Cc: Gregory Mirsky <= gregory.mirsky@ericsson.com>; Jeff Haas <j= haas@juniper.net>; colin@doch.org.uk; Aditya Dogra (addogra) <addogra@cisco.com>

Subject: Re: New Version Notification for draft-n= itish-vrrp-bfd-02.txt

 

Hi,

 

We had presented the Draft for VRRP BFD integrati= on in IETF 93 and we had taken care of all the comments that came as part o= f the WG meeting.

We had also merged the two drafts as per the comm= ents in IETF 93:

http:/= /tools.ietf.org/html/draft-nitish-vrrp-bfd-01

https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00=

 

We had presented the merged draft in IETF 94 and = there were no specific comments on the draft.

We would like to ask the RTGWG to adopt the Draft= as a WG document.

 

Thanks,

Nitish

 

 

On 26/10/15 11:57 am, "Nitish Gupta (nitisgu= p)" <nitisgup@cisco.com> wrote:=

 

>Hi,

> 

>We have submitted a new version of the draft.= As discussed in IETF 93

>at prague.

> 

>We have merged the following drafts:

>ht= tp://tools.ietf.org/html/draft-nitish-vrrp-bfd-01

> 

>https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-cas= e-00

> 

> 

> 

>We have also taken care of all the comments t= hat were discussed in the

>RTGWG meeting.

>We welcome any comments and suggestions on th= e draft.

> 

>Thanks,

>Nitish

> 

>On 13/10/15 9:09 pm, "internet-drafts@ietf.org"

><internet-drafts@ie= tf.org>

>wrote:

> 

>> 

>>A new version of I-D, draft-nitish-vrrp-b= fd-02.txt has been

>>successfully submitted by Nitish Gupta an= d posted to the IETF

>>repository.

>> 

>>Name:      =             &nb= sp;          draft-nitish-vrrp= -bfd

>>Revision:     &n= bsp;  02

>>Title:      = ;           Fast failure = detection in VRRP with BFD

>>Document date:    &nb= sp;     2015-10-13

>>Group:      = ;            &n= bsp;         Individual Submission<= o:p>

>>Pages:      = ;            &n= bsp;          10

>>URL:      &= nbsp;    

>>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-= 02.txt

>>Status:     &nbs= p;   https://datatracker.i= etf.org/doc/draft-nitish-vrrp-bfd/

>>Htmlized:     &n= bsp; https://tools.ietf.or= g/html/draft-nitish-vrrp-bfd-02

>>Diff:      =     

>>https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02

>> 

>>Abstract:

>>   This document describes how = Bidirectional Forwarding Detection (BFD)

>>   can be used to support sub-s= econd detection of a Master Router

>>   failure in the Virtual Route= r Redundancy Protocol (VRRP).

>> 

>>       = ;         

>>       = ;

>> 

>> 

>>Please note that it may take a couple of = minutes from the time of

>>submission until the htmlized version and= diff are available at

>>tools.ietf.org.

>> 

>>The IETF Secretariat

>> 

> 

 

_______________________________________________

rtgwg mailing list

rtgwg@ietf.org=

https://www.ie= tf.org/mailman/listinfo/rtgwg

--_000_DM2PR05MB6238B357B0163E8E079558EA9DA0DM2PR05MB623namprd_-- From nobody Thu Jan 28 12:14:02 2016 Return-Path: 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 3810B1ACDB7; Thu, 28 Jan 2016 12:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.199 X-Spam-Level: X-Spam-Status: No, score=-104.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, USER_IN_WHITELIST=-100] 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 4rbW_lDerFVb; Thu, 28 Jan 2016 12:13:51 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C561ACDB2; Thu, 28 Jan 2016 12:13:51 -0800 (PST) X-AuditID: c618062d-f79d16d000001b1c-e9-56aa739da789 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 26.E5.06940.E937AA65; Thu, 28 Jan 2016 21:01:34 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0248.002; Thu, 28 Jan 2016 15:13:50 -0500 From: Gregory Mirsky To: Chris Bowers , "Nitish Gupta (nitisgup)" , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYpHSG9NZLZk0mhGks73w62U559pVgAgHxsaYCAChvegIAMmnaggAFDr4D///ZdUA== Date: Thu, 28 Jan 2016 20:13:48 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221996D4C@eusaamb103.ericsson.se> References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF11221996661@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221996D4Ceusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBIsWRmVeSWpSXmKPExsUyuXRPoO684lVhBodWSlqcv7+Z0eLHeleL fVNfM1psm25hceLhRSaLz3+2MVpcePOb2YHdY8rvjawer3+sZfZYsuQnk8f1pqvsASxRXDYp qTmZZalF+nYJXBm925eyFHw5zlRxccNHtgbGizOZuhg5OSQETCQ2r97BCGGLSVy4t56ti5GL Q0jgCKPEie4ZUM5yRol13T9ZQarYBIwkXmzsYQexRQSWMEocv54IYjMLVEmc/N4OViMs4CZx ++ExRogad4kpd5dD2WESN7evAathEVCVmP35CQuIzSvgKzF7WiMzxLKPTBKzek+xgSQ4BaIl 5r2cB3YqI9B530+tYYJYJi5x68l8qBcEJJbsOc8MYYtKvHz8jxXCVpTY1z+dHaI+X+Lo3Vvs EMsEJU7OfMIygVF0FpJRs5CUzUJSBhHXkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxcpQW F+TkphsZbGIExucxCTbdHYz3p3seYhTgYFTi4TVIXRUmxJpYVlyZe4hRgoNZSYQ3PAsoxJuS WFmVWpQfX1Sak1p8iFGag0VJnNeGd1GYkEB6YklqdmpqQWoRTJaJg1OqgTFKPV62XftlrbLe tkOxPbfmW8kYp+c7zJglNNmr5QVDk5TJQo8VOzMCF5qz18+T+qw216o+6I/ElXgpDS+xD5M0 XnVd+jj79JcvvPJqM/QEuj7d/bpO8dGiZbNzN4tW9l2vYzkz/5Jmxod5wUYTP/vM52a3lJt9 kc02qpQvzZn/4ul5Xj1zc5VYijMSDbWYi4oTARvNMAfLAgAA Archived-At: Cc: Jeff Haas , "colin@doch.org.uk" , "Aditya Dogra \(addogra\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 20:14:00 -0000 --_000_7347100B5761DC41A166AC17F22DF11221996D4Ceusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Chris, thank you for your review. Will include the proposed update in the next ver= sion of the draft. On two approaches being presented in the draft. We'll work on the text to m= ake the situation more clear. And I can refer to RFC 4090 where two approac= hes to RSVP FRR defined. And, as in the case with VRRP-BFD, it was result o= f merging two drafts that presented technically viable though different sol= utions. And that how I see two solutions presented in this draft - both are= technically sound, with their own pros and cons. But, of course, it would = be for the RTGWG and community of experts from other WGs, e.g. BFD, to deci= de. Regards, Greg From: Chris Bowers [mailto:cbowers@juniper.net] Sent: Thursday, January 28, 2016 7:40 AM To: Gregory Mirsky; Nitish Gupta (nitisgup); rtgwg@ietf.org; rtg-bfd@ietf.o= rg Cc: Jeff Haas; colin@doch.org.uk; Aditya Dogra (addogra) Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Greg, Thanks. Those clarifications seem reasonable. Draft authors, I do have another general comment about the current text of the draft. Th= e current text discusses two different approaches to doing fast failure det= ection in VRRP with BFD, using p2p BFD or p2mp BFD. The first uses existin= g BFD p2p sessions and enhances VRRP to use the p2p BFD sessions. The seco= nd requires less enhancement of VRRP, but relies on enhanced functionality = in BFD. If this is correct, it would be good for the text to explicitly s= tate that these are two distinct approaches, to help the readers during the= poll for WG adoption. If this work is adopted by RTGWG, one could imagine a scenario where the wo= rking group decides to document both approaches in the final version. Howe= ver, it is usually more desirable for the working group to evaluate the dif= ferent approaches and choose one. It would also be useful for the text to = explicitly state the authors' thoughts and intentions with respect to how t= he document should evolve. Should it ultimately document one solution, sho= uld it document multiple solutions, or should more work be done to determin= e if there are compelling reasons to document multiple solutions? If adop= ted, it will ultimately be up to the WG to decide how to move forward, rega= rdless of the stated intentions of the current authors. However, it would = be useful for the readers during the poll for WG adoption to understand the= authors' current intentions and their thinking on this topic. Thanks, Chris From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Wednesday, January 27, 2016 7:43 PM To: Chris Bowers >; Nitish = Gupta (nitisgup) >; rtgwg@iet= f.org; rtg-bfd@ietf.org Cc: Jeff Haas >; colin@doch.org= .uk; Aditya Dogra (addogra) > Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Hi Chris, greatly appreciate your thorough review and the most detailed comments. As = we've contributed p2mp BFD applicability to VRRP part of the draft I'll add= ress your comments, that I've copied below, to Section 4. Please find my no= tes tagged GIM>> 4) I don't understand Section 4 which describes how to use p2mp BFD. GIM>> Hope that will be clearer once I address your questions to the Secti= on 4 below. A) The text says that "The Master router starts transmitting BFD control pa= ckets with VRID as source IP address." According to RFC5798, the VRID is a= n integer in the range from 1-255. Is the idea to encode the integer VRID = as an IP address? Or should the BFD control packets be sent with the sour= ce IP address set to an IPvX address associated with the virtual router? O= r are both used? In any case, it seems like this needs clarification. GIM>> Very good catch. Indeed, the idea is to use IPvX address associated w= ith the particular VRID. Would the following change clarify selection of so= urce IP address: The Master router starts transmitting BFD control packets with IPvX address= associated with the VRID as source IP address. Backup router demultiplexes= p2mp BFD test sessions based on IP source address associated with the virt= ual router that it been configured with. B) What is the destination IP address of the p2mp BFD control packet? Is i= t 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IPv4 and IPv6 multicast addresses= for VRRP? If so, this should be made explicit. GIM>> I think that VRRP multicast address MAY be used as destination IP add= ress for p2mp BFD which has VRRP as its client. I think that subnet broadca= st address SHOULD be used as destination IP address. I'll add the text to t= he Section 4. C) Again, a state machine description would help readers and future impleme= nters understand exactly what is intended. GIM>> p2mp BFD, as I think, does not change VRRP state machine. I'll add st= atement to that to the text for the next version. -----Original Message----- From: Chris Bowers [mailto:cbowers@juniper.net] Sent: Tuesday, January 19, 2016 11:54 AM To: Nitish Gupta (nitisgup); rtgwg@ietf.org; rtg-bfd= @ietf.org Cc: Gregory Mirsky; Jeff Haas; colin@doch.org.uk;= Aditya Dogra (addogra) Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt Nitish and co-authors, I have read this draft and have several comments below. In general, I pref= er that authors address outstanding comments in a new revision before we co= nduct a poll for adoption in RTGWG. Since an adoption poll usually trigger= s quite a few people read a draft in detail, it makes better use of the wor= king groups time to have them reading the most up-to-date version. However= , an argument could also be made for filling in some of the additional deta= il that I am asking for below after WG adoption (assuming it is adopted), w= hen the WG has more direct control of the document. So I am open to eithe= r approach. So please respond to the feedback below and tell me if you would like to ad= dress some of it in a new revision before I conduct a poll for WG adoption,= or if you would prefer to do the WG adoption poll using the current revisi= on. There has also been feedback from others on this draft in response to = your email, so you should respond to that as well. In general, I think the draft would benefit from specifying the VRRP state = machine for this BFD mode of operation at the same level of detail that RFC= 5798 specifies the existing VRRP state machine. There are several places = where it is probably possible to infer the correct behavior, but making it = very explicit will make for a better document. 1) Section 3.5 of this draft defines the Critical BFD session which is the = BFD session between the VRRP Master and the next best VRRP backup. In the = existing VRRP state machine, a VRRP router in the backup state is not able = to determine if it is the next best VRRP backup. Presumably, in the VRRP s= tate machine for the BFD mode of operation, a VRRP router in the backup sta= te will look at the peer table populated by the Backup Advertisements and f= igure out which router is the next best VRRP router based on highest priori= ty value with highest IPvX address as tie breaker. However, it would be be= tter to be as explicit as RFC5798 about how this new state machine operates= . 2) Section 5 says that "To reduce the number of packets generated at a regu= lar interval, Backup Advert packets may be sent at a reduced rate as compar= ed to Advert packets sent by the VRRP Master." It seems that the state mac= hine for VRRP BFD mode will have to be enhanced in some way to support this= . One way to do this would be for each router to have a Backup_Advertisem= ent_Interval which it uses to populate the Maximum Advertisement Interval i= n the BACKUP ADVERTISEMENT, and have each receiving router maintain a Peer_= Advert_Interval(P) for each peer(P), and remove a peer entry when a BACKUP = ADVERTISEMENT is not received from P for 3* Peer_Advert_Interval(P). But t= his is just one possible approach. In any case, it would be good to choos= e a mechanism and describe the corresponding state machine. 3) The text should clarify how the VRRP state machine interacts with the BF= D state machine. One can imagine scenarios where a BFD session stays up b= ut the VRRP advertisements stop being received, or vice versa. This scenar= io is not very far-fetched because BFD may use unicast and VRRP uses multic= ast. Behavior can probably be inferred from existing text, but I think mor= e precision is better here. 4) I don't understand Section 4 which describes how to use p2mp BFD. A) The text says that "The Master router starts transmitting BFD control pa= ckets with VRID as source IP address." According to RFC5798, the VRID is a= n integer in the range from 1-255. Is the idea to encode the integer VRID = as an IP address? Or should the BFD control packets be sent with the sour= ce IP address set to an IPvX address associated with the virtual router? O= r are both used? In any case, it seems like this needs clarification. B) What is the destination IP address of the p2mp BFD control packet? Is i= t 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IPv4 and IPv6 multicast addresses= for VRRP? If so, this should be made explicit. C) Again, a state machine description would help readers and future impleme= nters understand exactly what is intended. Thanks, Chris -----Original Message----- From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Nitish Gupta (niti= sgup) Sent: Wednesday, January 13, 2016 3:31 AM To: rtgwg@ietf.org; rtg-bfd@ietf.org Cc: Gregory Mirsky >; Jeff Haas >; colin@d= och.org.uk; Aditya Dogra (addogra) > Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Hi, We had presented the Draft for VRRP BFD integration in IETF 93 and we had t= aken care of all the comments that came as part of the WG meeting. We had also merged the two drafts as per the comments in IETF 93: http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 We had presented the merged draft in IETF 94 and there were no specific com= ments on the draft. We would like to ask the RTGWG to adopt the Draft as a WG document. Thanks, Nitish On 26/10/15 11:57 am, "Nitish Gupta (nitisgup)" > wrote: >Hi, > >We have submitted a new version of the draft. As discussed in IETF 93 >at prague. > >We have merged the following drafts: >http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 > >https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 > > > >We have also taken care of all the comments that were discussed in the >RTGWG meeting. >We welcome any comments and suggestions on the draft. > >Thanks, >Nitish > >On 13/10/15 9:09 pm, "internet-drafts@ietf.org" >> >wrote: > >> >>A new version of I-D, draft-nitish-vrrp-bfd-02.txt has been >>successfully submitted by Nitish Gupta and posted to the IETF >>repository. >> >>Name: draft-nitish-vrrp-bfd >>Revision: 02 >>Title: Fast failure detection in VRRP with BFD >>Document date: 2015-10-13 >>Group: Individual Submission >>Pages: 10 >>URL: >>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt >>Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ >>Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 >>Diff: >>https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02 >> >>Abstract: >> This document describes how Bidirectional Forwarding Detection (BFD) >> can be used to support sub-second detection of a Master Router >> failure in the Virtual Router Redundancy Protocol (VRRP). >> >> >> >> >> >>Please note that it may take a couple of minutes from the time of >>submission until the htmlized version and diff are available at >>tools.ietf.org. >> >>The IETF Secretariat >> > _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg --_000_7347100B5761DC41A166AC17F22DF11221996D4Ceusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Chris,

thank you for your rev= iew. Will include the proposed update in the next version of the draft.

 

On two approaches bein= g presented in the draft. We’ll work on the text to make the situatio= n more clear. And I can refer to RFC 4090 where two approaches to RSVP FRR = defined. And, as in the case with VRRP-BFD, it was result of merging two drafts that presented technically viable thou= gh different solutions. And that how I see two solutions presented in this = draft – both are technically sound, with their own pros and cons. But= , of course, it would be for the RTGWG and community of experts from other WGs, e.g. BFD, to decide.

 

   &nbs= p;            Regard= s,

   &nbs= p;            &= nbsp;           &nbs= p;   Greg

 

From: Chris Bo= wers [mailto:cbowers@juniper.net]
Sent: Thursday, January 28, 2016 7:40 AM
To: Gregory Mirsky; Nitish Gupta (nitisgup); rtgwg@ietf.org; rtg-bfd= @ietf.org
Cc: Jeff Haas; colin@doch.org.uk; Aditya Dogra (addogra)
Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.t= xt

 

Greg,

 

Thanks.  Those cl= arifications seem reasonable. 

 

Draft authors,

 

I do have another gene= ral comment about the current text of the draft.   The current te= xt discusses two different approaches to doing fast failure detection in VR= RP with BFD, using p2p BFD or p2mp BFD.  The first uses existing BFD p2p sessions and enhances VRRP to use the p2p BFD sessio= ns.  The second requires less enhancement of VRRP, but relies on enhan= ced functionality in BFD.   If this is correct, it would be good = for the text to explicitly state that these are two distinct approaches, to help the readers during the poll for WG adopti= on.

 

If this work is adopte= d by RTGWG, one could imagine a scenario where the working group decides to= document both approaches in the final version.  However, it is usuall= y more desirable for the working group to evaluate the different approaches and choose one.  It would also be u= seful for the text to explicitly state the authors’ thoughts and inte= ntions with respect to how the document should evolve.  Should it ulti= mately document one solution, should it document multiple solutions, or should more work be done to determine if there are = compelling reasons to document multiple solutions?   If adopted, = it will ultimately be up to the WG to decide how to move forward, regardles= s of the stated intentions of the current authors.  However, it would be useful for the readers during the poll= for WG adoption to understand the authors’ current intentions and th= eir thinking on this topic.

 

Thanks,

Chris

 

 

 

From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Wednesday, January 27, 2016 7:43 PM
To: Chris Bowers <cbowers@= juniper.net>; Nitish Gupta (nitisgup) <nitisgup@cisco.com>; rtgwg@ietf.org; rtg-bfd@ietf.org
Cc: Jeff Haas <jhaas@juniper= .net>; colin@doch.org.uk; Aditya Dogra (addogra) <addogra@cisco.com>
Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.t= xt

 

Hi Chris,

greatly appreciate your thorough review and the m= ost detailed comments. As we've contributed p2mp BFD applicability to VRRP = part of the draft I'll address your comments, that I've copied below, to Se= ction 4. Please find my notes tagged GIM>>

 

4) I don't understand Section 4 which describes h= ow to use p2mp BFD.   

GIM>>  Hope that will be clearer once = I address your questions to the Section 4 below.

 

A) The text says that "The Master router sta= rts transmitting BFD control packets with VRID as source IP address."&= nbsp; According to RFC5798, the VRID is an integer in the range from 1-255.=   Is the idea to encode the integer VRID as an IP address?   Or should the BFD control packets be sent with the so= urce IP address set to an IPvX address associated with the virtual router?&= nbsp; Or are both used?  In any case, it seems like this needs clarifi= cation.

GIM>> Very good catch. Indeed, the idea is = to use IPvX address associated with the particular VRID. Would the followin= g change clarify selection of source IP address:

The Master router star= ts transmitting BFD control packets with IPvX address associated with the V= RID as source IP address. Backup router demultiplexes p2mp BFD test session= s based on IP source address associated with the virtual router that it been configured with.

 

B) What is the destination IP address of the p2mp= BFD control packet?  Is it 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IP= v4 and IPv6 multicast addresses for VRRP?  If so, this should be made = explicit.

GIM>> I think that VRRP multicast address M= AY be used as destination IP address for p2mp BFD which has VRRP as its cli= ent. I think that subnet broadcast address SHOULD be used as destination IP= address. I’ll add the text to the Section 4.

 

C) Again, a state machine description would help = readers and future implementers understand exactly what is intended.

GIM>> p2mp BFD, as I think, does not change= VRRP state machine. I’ll add statement to that to the text for the n= ext version.

 

-----Original Message-----
From: Chris Bowers [mailto:cbowers@j= uniper.net]
Sent: Tuesday, January 19, 2016 11:54 AM
To: Nitish Gupta (nitisgup); rtgwg@ietf.o= rg; rtg-bfd@ietf.org
Cc: Gregory Mirsky; Jeff Haas; colin@d= och.org.uk; Aditya Dogra (addogra)
Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt=

 

Nitish and co-authors,

 

I have read this draft and have several comments = below.  In general, I prefer that authors address outstanding comments= in a new revision before we conduct a poll for adoption in RTGWG.  Si= nce an adoption poll usually triggers quite a few people read a draft in detail, it makes better use of the working gr= oups time to have them reading the most up-to-date version.  However, = an argument could also be made for filling in some of the additional detail= that I am asking for below after WG adoption (assuming it is adopted), when the WG has more direct control of = the document.   So I am open to either approach.

 

So please respond to the feedback below and tell = me if you would like to address some of it in a new revision before I condu= ct a poll for WG adoption, or if you would prefer to do the WG adoption pol= l using the current revision.  There has also been feedback from others on this draft in response to your email= , so you should respond to that as well.

 

In general, I think the draft would benefit from = specifying the VRRP state machine for this BFD mode of operation at the sam= e level of detail that RFC5798 specifies the existing VRRP state machine.&n= bsp;  There are several places where it is probably possible to infer the correct behavior, but making it very exp= licit will make for a better document.

 

1) Section 3.5 of this draft defines the Critical= BFD session which is the BFD session between the VRRP Master and the next = best VRRP backup.  In the existing VRRP state machine, a VRRP router i= n the backup state is not able to determine if it is the next best VRRP backup.  Presumably, in the VRRP state ma= chine for the BFD mode of operation, a VRRP router in the backup state will= look at the peer table populated by the Backup Advertisements and figure o= ut which router is the next best VRRP router based on highest priority value with highest IPvX address as tie br= eaker.  However, it would be better to be as explicit as RFC5798 about= how this new state machine operates.

 

2) Section 5 says that "To reduce the number= of packets generated at a regular interval, Backup Advert packets may be s= ent at a reduced rate as compared to Advert packets sent by the VRRP Master= ."  It seems that the state machine for VRRP BFD mode will have to be enhanced in some way to support this.  = One  way to do this would be for each router to have a Backup_Advertis= ement_Interval which it uses to populate the Maximum Advertisement Interval= in the BACKUP ADVERTISEMENT, and have each receiving router maintain a Peer_Advert_Interval(P) for each peer(P), and = remove a peer entry when a BACKUP ADVERTISEMENT is not received from P for = 3* Peer_Advert_Interval(P).  But this is just one possible approach.&n= bsp; In any case,  it would be good to choose a mechanism and describe the corresponding state machine.

 

3) The text should clarify how the VRRP state mac= hine interacts with the BFD state machine.   One can imagine scen= arios where a BFD session stays up but the VRRP advertisements stop being r= eceived, or vice versa.  This scenario is not very far-fetched because BFD may use unicast and VRRP uses multicast. = ; Behavior can probably be inferred from existing text, but I think more pr= ecision is better here.

 

4) I don't understand Section 4 which describes h= ow to use p2mp BFD.   

 

A) The text says that "The Master router sta= rts transmitting BFD control packets with VRID as source IP address."&= nbsp; According to RFC5798, the VRID is an integer in the range from 1-255.=   Is the idea to encode the integer VRID as an IP address?   Or should the BFD control packets be sent with the so= urce IP address set to an IPvX address associated with the virtual router?&= nbsp; Or are both used?  In any case, it seems like this needs clarifi= cation.

 

B) What is the destination IP address of the p2mp= BFD control packet?  Is it 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IP= v4 and IPv6 multicast addresses for VRRP?  If so, this should be made = explicit.

 

C) Again, a state machine description would help = readers and future implementers understand exactly what is intended.

 

Thanks,

Chris

 

-----Original Message-----

From: rtgwg [mailto:rtgwg-bo= unces@ietf.org] On Behalf Of Nitish Gupta (nitisgup)<= /p>

Sent: Wednesday, January 13, 2016 3:31 AM

To: rtgwg@ietf.org; rtg-bfd@ietf.org

Cc: Gregory Mirsky <= gregory.mirsky@ericsson.com>; Jeff Haas <j= haas@juniper.net>; colin@doch.org.uk; Aditya Dogra (addogra) <addogra@cisco.com>

Subject: Re: New Version Notification for draft-n= itish-vrrp-bfd-02.txt

 

Hi,

 

We had presented the Draft for VRRP BFD integrati= on in IETF 93 and we had taken care of all the comments that came as part o= f the WG meeting.

We had also merged the two drafts as per the comm= ents in IETF 93:

http:/= /tools.ietf.org/html/draft-nitish-vrrp-bfd-01

https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00=

 

We had presented the merged draft in IETF 94 and = there were no specific comments on the draft.

We would like to ask the RTGWG to adopt the Draft= as a WG document.

 

Thanks,

Nitish

 

 

On 26/10/15 11:57 am, "Nitish Gupta (nitisgu= p)" <nitisgup@cisco.com> wrote:=

 

>Hi,

> 

>We have submitted a new version of the draft.= As discussed in IETF 93

>at prague.

> 

>We have merged the following drafts:

>ht= tp://tools.ietf.org/html/draft-nitish-vrrp-bfd-01

> 

>https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-cas= e-00

> 

> 

> 

>We have also taken care of all the comments t= hat were discussed in the

>RTGWG meeting.

>We welcome any comments and suggestions on th= e draft.

> 

>Thanks,

>Nitish

> 

>On 13/10/15 9:09 pm, "internet-drafts@ietf.org"

><internet-drafts@ie= tf.org>

>wrote:

> 

>> 

>>A new version of I-D, draft-nitish-vrrp-b= fd-02.txt has been

>>successfully submitted by Nitish Gupta an= d posted to the IETF

>>repository.

>> 

>>Name:      =             &nb= sp;          draft-nitish-vrrp= -bfd

>>Revision:     &n= bsp;  02

>>Title:      = ;           Fast failure = detection in VRRP with BFD

>>Document date:    &nb= sp;     2015-10-13

>>Group:      = ;            &n= bsp;         Individual Submission<= o:p>

>>Pages:      = ;            &n= bsp;          10

>>URL:      &= nbsp;    

>>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-= 02.txt

>>Status:     &nbs= p;   https://datatracker.i= etf.org/doc/draft-nitish-vrrp-bfd/

>>Htmlized:     &n= bsp; https://tools.ietf.or= g/html/draft-nitish-vrrp-bfd-02

>>Diff:      =     

>>https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02

>> 

>>Abstract:

>>   This document describes how = Bidirectional Forwarding Detection (BFD)

>>   can be used to support sub-s= econd detection of a Master Router

>>   failure in the Virtual Route= r Redundancy Protocol (VRRP).

>> 

>>       = ;         

>>       = ;

>> 

>> 

>>Please note that it may take a couple of = minutes from the time of

>>submission until the htmlized version and= diff are available at

>>tools.ietf.org.

>> 

>>The IETF Secretariat

>> 

> 

 

_______________________________________________

rtgwg mailing list

rtgwg@ietf.org=

https://www.ie= tf.org/mailman/listinfo/rtgwg

--_000_7347100B5761DC41A166AC17F22DF11221996D4Ceusaamb103erics_-- From nobody Fri Jan 29 14:58:48 2016 Return-Path: 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 A42881A90A3; Fri, 29 Jan 2016 14:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.903 X-Spam-Level: X-Spam-Status: No, score=-106.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 qWv3tz_-dkoY; Fri, 29 Jan 2016 14:58:44 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329CB1A90A1; Fri, 29 Jan 2016 14:58:44 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id AF5C218019E; Fri, 29 Jan 2016 14:57:03 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 7726 on Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs) X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160129225703.AF5C218019E@rfc-editor.org> Date: Fri, 29 Jan 2016 14:57:03 -0800 (PST) Archived-At: Cc: rtg-bfd@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 22:58:45 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7726 Title: Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs) Author: V. Govindan, K. Rajaraman, G. Mirsky, N. Akiya, S. Aldrin Status: Standards Track Stream: IETF Date: January 2016 Mailbox: venggovi@cisco.com, kalyanir@cisco.com, gregory.mirsky@ericsson.com, nobo.akiya.dev@gmail.com, aldrin.ietf@gmail.com Pages: 7 Characters: 13899 Updates: RFC 5884 I-D Tag: draft-ietf-bfd-rfc5884-clarifications-04.txt URL: https://www.rfc-editor.org/info/rfc7726 DOI: http://dx.doi.org/10.17487/RFC7726 This document clarifies the procedures for establishing, maintaining, and removing multiple, concurrent BFD (Bidirectional Forwarding Detection) sessions for a given as described in RFC 5884. This document is a product of the Bidirectional Forwarding Detection Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC