From nobody Tue Sep 1 13:32:36 2015 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 335C51B4319 for ; Tue, 1 Sep 2015 13:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 EhQTPr-oSS63 for ; Tue, 1 Sep 2015 13:32:34 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 51D421B33F8 for ; Tue, 1 Sep 2015 13:32:34 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id DF8551E48F; Tue, 1 Sep 2015 16:35:37 -0400 (EDT) Date: Tue, 1 Sep 2015 16:35:37 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Fwd: Publication has been requested for draft-ietf-bfd-rfc5884-clarifications-02 Message-ID: <20150901203537.GI5027@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) 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: Tue, 01 Sep 2015 20:32:35 -0000 The shepherd writeup for the RFC 5884 clarifications document has been done and the document has been submitted to the IESG for publication. Thanks to all of the authors for their work. -- Jeff and Nobo ----- Forwarded message from Jeffrey Haas ----- Date: Tue, 01 Sep 2015 13:30:32 -0700 From: Jeffrey Haas To: aretana@cisco.com Cc: bfd-chairs@ietf.org, iesg-secretary@ietf.org, Jeffrey Haas Subject: Publication has been requested for draft-ietf-bfd-rfc5884-clarifications-02 Jeffrey Haas has requested publication of draft-ietf-bfd-rfc5884-clarifications-02 as Proposed Standard on behalf of the BFD working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-bfd-rfc5884-clarifications/ ----- End forwarded message ----- From nobody Sun Sep 6 19:39:42 2015 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 24BB91B4130; Sun, 6 Sep 2015 19:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.511 X-Spam-Level: X-Spam-Status: No, score=-12.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, 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 ieWW0ooIJRrQ; Sun, 6 Sep 2015 19:39:38 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE801B4126; Sun, 6 Sep 2015 19:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6597; q=dns/txt; s=iport; t=1441593578; x=1442803178; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Vm+c4A6Qoqa+Dc+qGy9d30jdfaa34KPlxfownCFAJSE=; b=iMgjVdkKsEqKjYx+ZzXx9Ieq9JkBxSoCxcWHz0a2774qtnLc90xnXjll cEZYPRRJHEI7cPiuAKeV9Qsxl2jyt2bMlLNcY0nitt91rcntYVNCJtsjH eGR+JohzE9wNhvzPfHCU4frkuwqCJk46GSpO4q7RykwVIZ1BNbYAujtYg M=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BNAwC++OxV/5ldJa1egyNUaQaDHro5CoFtCoUvSgKBJTgUAQEBAQEBAYEKhCMBAQEDAQEBARoGBEcEBwULAgEGAg4KJwMCAiEGCxQRAgQOBQkFiAsDCggNlxadHY5lDYUIAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4Zzgg+CbII9EoFrAQFQAgWCaS+BFAWMd4U7gyMBgkKBXYZtgW2BTIQzjTyHPCaCEByBVHEBhwk6gQUBAQE X-IronPort-AV: E=Sophos;i="5.17,482,1437436800"; d="asc'?scan'208";a="185540531" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP; 07 Sep 2015 02:39:28 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t872dRei005305 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Sep 2015 02:39:27 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 6 Sep 2015 21:39:26 -0500 Received: from xhc-rcd-x13.cisco.com (173.37.183.87) by xch-rcd-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Sun, 6 Sep 2015 21:39:26 -0500 Received: from xmb-aln-x02.cisco.com ([169.254.5.3]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0248.002; Sun, 6 Sep 2015 21:39:26 -0500 From: "Carlos Pignataro (cpignata)" To: Qin Wu Subject: Re: [Lime] Call for Adoption: draft-tissa-lime-yang-oam-model-06 Thread-Topic: [Lime] Call for Adoption: draft-tissa-lime-yang-oam-model-06 Thread-Index: AQHQ0hZtC6ZsLJ+XW0SWohJDIWwzGp4XDbMAgAUolwCAABcDAIAAB+8AgALhywCAAE/BgIARVLwA Date: Mon, 7 Sep 2015 02:39:25 +0000 Message-ID: <88821501-1AC7-476D-9B96-ACD245C29113@cisco.com> References: <8E812CBB-1058-40C0-815F-CF8C008F0582@cisco.com> <7347100B5761DC41A166AC17F22DF112218ABD6B@eusaamb103.ericsson.se> <6D32668528F93D449A073F45707153D8BEB9DDB9@US70UWXCHMBA03.zam.alcatel-lucent.com> <15590A0D-BAF7-4E42-826F-6C5C13258595@gmail.com> <55DBC076.9010701@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [173.37.102.24] Content-Type: multipart/signed; boundary="Apple-Mail=_A8C78844-C94E-48E9-A69A-20469F86319C"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" , "lime@ietf.org" , Ladislav Lhotka , Tom Taylor 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, 07 Sep 2015 02:39:40 -0000 --Apple-Mail=_A8C78844-C94E-48E9-A69A-20469F86319C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Mahesh, Please find one comment inline. > On Aug 26, 2015, at 9:56 PM, Qin Wu wrote: >=20 > Hi, Mahesh: > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Lime [mailto:lime-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Mahesh Jethanandani > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B48=E6=9C=8827=E6=97=A5= 5:11 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Tom Taylor > =E6=8A=84=E9=80=81: rtg-bfd@ietf.org; lime@ietf.org > =E4=B8=BB=E9=A2=98: Re: [Lime] Call for Adoption: = draft-tissa-lime-yang-oam-model-06 >=20 > [Adding BFD mailing list back because this decision affects them] >=20 > Tom, >=20 > I was hoping for a rational that went beyond =E2=80=9Cand you shall = =E2=80=A6=E2=80=9D In addition to what Qin said below, the main rational is to provide = higher-level abstractions, beyond the specifics of configuring = individual protocols. Thanks, =E2=80=94 Carlos, as individual. >=20 > Something along the lines of why /lime/bfd is better than /lime -> = /bfd. Or why almost all configuration models for BFD that currently work = just fine, now have to start supporting CFM like semantics in = Maintenance Domain (MD), Maintenance Association (MA) or Maintenance = Endpoint (MEP) configuration to realize a BFD session. >=20 > You might find a similar discussion around the devices YANG model = germane to this thought process. In particular, the thread titled "issue = Y34 - root node" on the netmod mailing list. >=20 > [Qin]: See > http://www.ietf.org/mail-archive/web/netmod/current/msg12986.html > http://www.ietf.org/mail-archive/web/netmod/current/msg13113.html >=20 > What device YANG model is applied to this WG is about the following = substructure: > +--rw device > +--rw logical-network-elements > +--rw networking-instances > +--rw networking-instance* = [networking-instance-name] > +--rw oam-protocols > | +--rw bfd > | +--rw cfm > | +--rw twamp > Rather than the example quoted in Y-34 = (http://www.ietf.org/mail-archive/web/netmod/current/msg12986.html) > +--rw device > +--rw info > | +--rw device-type? enumeration > +--rw hardware > +--rw interfaces > | +--rw interface* [name] > | ... > +--rw qos >=20 > So In my understanding, device model is more focusing on discussing = organizing different type of models in a > comprehensive structure. For the same type of models(e.g., OAM type), = we can find common structure to make different technology specific OAM = models with same type (i.e.,OAM type)work together. The relationship = between these models are described as several models are extension to = one base model. >=20 > The debate on Y-34 is about whether we should add new top level node = (device) on top of another existing top level node(e.g., interface). = Device and interface are of two different types, >=20 > One interesting proposal raised by Lada in = http://www.ietf.org/mail-archive/web/netmod/current/msg12986.html is: > "Extend YANG so that a *specific* schema tree can be grafted at a = given data node." > One example given by Lada in the discussion is: > " > I believe there are other use cases in the existing modules. For > example, the ietf-routing module could simply define the data model = for > a single routing instance (i.e. without "routing-instance" list at the > top), and it can be then used without changes on simple devices, and > more complex router implementations can graft it as a subtree under > "routing-instance", "networking-instance" or whatever. >=20 > " > I think this is something more relevant to what we are doing. I think = we should consider to take this approach. >=20 > Cheers. >=20 >> On Aug 24, 2015, at 6:10 PM, Tom Taylor = wrote: >>=20 >> It comes from making the making the draft Standards Track. If you = claim to implement the ultimate RFC, this is a logical consequence, just = as for any other Standards Track RFC. >>=20 >> Tom Taylor >>=20 >> On 24/08/2015 8:41 PM, Mahesh Jethanandani wrote: >>> Agree with Greg. >>>=20 >>> I have particular concern about this statement in the draft: >>>=20 >>> All implementations that follow the YANG framework presented in this >>> document MUST implement the generic YANG model presented here. >>>=20 >>>=20 >>> This seems to stipulate a requirement that neither YANG as a = language >>> nor any existing technology requires, except maybe CFM itself. Where >>> is this stipulation coming from and why is it a MUST? >>>=20 >>=20 >> _______________________________________________ >> Lime mailing list >> Lime@ietf.org >> https://www.ietf.org/mailman/listinfo/lime >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 > _______________________________________________ > Lime mailing list > Lime@ietf.org > https://www.ietf.org/mailman/listinfo/lime > _______________________________________________ > Lime mailing list > Lime@ietf.org > https://www.ietf.org/mailman/listinfo/lime --Apple-Mail=_A8C78844-C94E-48E9-A69A-20469F86319C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV7JQCAAoJEIXgpQGOZny9U6YP/0FMfCYcqWSddiybJP9NQDnC NzOxYxpb3djNR8ETyeb4J2R3MajekOAA8IZxaozvpmSkcXssdOi48Hvg/tN6o9Yi QT2ynmsNepI2dhNJZJzTNrEbtAooe8YnGoAlKdeb4rqk+fy3/YVc8P1Ax9ZX/D6O edMEqgaEQrU/+KRFUBHg2LAjJRtRDa0mEr0kjCSZw8bhaI57RYm1tw82xqui+kaf kxsbkqg3w/DLqW0DSrqEsyYM8AxizIxZEtmHcBhkgMmd+6rDE8a8NKuRKxklB/IX iZYMLY2MjckAKqlwtsrHPQ6ERJ701tLq7ks3RoVqe6wz20MK+hlMu7KQyhBNlvne HqE71rb0fk+HiP3tofDVu8/DjEDsKgxnHRigG6hHeSmMnadKvbolquadwaWulUpQ GB1E0dkU0XH1M1PG3xpD43Nst70GaAVdAwI+k+1nk7Sy4Okbq7pow5y62MyBq55e 0LDJAj1W3gQGAuGWkfmsQqwqAyiOJVsBojfad51a7XabeC5mo/6T5N1Fl05Ac7SP CvcysBvZ4VterLjp+6JPqmw8zOLkJr/cQiqTN97ZNzZhNfznTImjhSP/2+zWQFyW V1e8GEnapbz5V+0SrQH8moTht7JCBy/Xwea8emAf1Atk4fJqRsK19tLXLBIdPpCO ncUzwOCn7BudSsHHGBOY =sUTi -----END PGP SIGNATURE----- --Apple-Mail=_A8C78844-C94E-48E9-A69A-20469F86319C-- From nobody Tue Sep 8 07:52:29 2015 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 C4B011B5786; Mon, 7 Sep 2015 17:42:02 -0700 (PDT) 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 vecSxqTYOKfe; Mon, 7 Sep 2015 17:41:59 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::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 2388A1B3CCE; Mon, 7 Sep 2015 17:41:59 -0700 (PDT) Received: by padhk3 with SMTP id hk3so22838938pad.3; Mon, 07 Sep 2015 17:41:58 -0700 (PDT) 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=BxE70PKNMDBu9rtYTse/imj6LSA4SQS0J1MHtMHZSgo=; b=fTY2N5hCSdrDP4tnHloUO0tYG7xJFdMXFpfZb1YOsHDB2tSrd7U6L9bKgQviRrBBPr piF1Jv2AxQVs3pL4Jh1w/VT8q57KXuv636Wwa3hWHwKS2Yl9reGzkddOjLaOnYj40hJ5 nhrOivIb5QzNvo8jAT761fOtWI1pt6OG9PP8eQxDcThMWFjExJeWvk0tDLCJ9LPddbyd Oo5prNnZchZIo4dJOEuSHvb+l60qXTgEt9/QYoXB1rjBanKzaHSo9b5kRyatY+eldZ7z 8dYa+SiyyuyNbBpIGqe+0goQjsmtw3R3tugOojO51aewOdZ0pdnoD6sJE0cji3T/PQmO 3QcQ== X-Received: by 10.68.99.197 with SMTP id es5mr51882301pbb.112.1441672918723; Mon, 07 Sep 2015 17:41:58 -0700 (PDT) Received: from mahesh-m-62at.attlocal.net ([2602:306:cf77:df90:30d8:762b:3389:e41c]) by smtp.gmail.com with ESMTPSA id q5sm1086077pdc.65.2015.09.07.17.41.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Sep 2015 17:41:57 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3FFEC4A0-1527-4173-B852-D479A2AD68F4" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: Relationship between BFD model and LIME base model From: Mahesh Jethanandani In-Reply-To: Date: Mon, 7 Sep 2015 17:41:56 -0700 Message-Id: <78EA03A6-0D1F-4661-85A6-ACB217AB10C8@gmail.com> References: To: Qin Wu X-Mailer: Apple Mail (2.2098) Archived-At: X-Mailman-Approved-At: Tue, 08 Sep 2015 07:52:27 -0700 Cc: "Carlos Pignataro \(cpignata\)" , "Deepak Kumar \(dekumar\)" , "Ronald P. Bonica" , yang-coord@ietf.org, Alia Atlas , Joel jaeggli , Benoit Claise , rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 00:42:03 -0000 --Apple-Mail=_3FFEC4A0-1527-4173-B852-D479A2AD68F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Qin for the summary. I would add that the last option (support = for /bfd and /lime/bfd) should be considered the fourth option. The = advantage of this approach is that LIME can still collate all OAM = technologies and provide a hierarchy, and it does not require the = technologies themselves to have to change their current configuration = model. We can still investigate reuse of groupings and data types from = option 2. For a reference, please refer to the discussion on the netmod mailing = list on root nodes - = http://www.ietf.org/mail-archive/web/netmod/current/msg13243.html = If I was to extrapolate from that example, the lime model could contain = something like this: container technologies { list technology { key name; // information about MD, MA =E2=80=A6 would go here. container data { // all oam-technologies supported by lime are mounted here } } } The choice of where to build this hierarchy is now up to the = implementor.=20 You could do this on the device if the interest is to do fault isolation = on a device in which case your path would look like /lime/technologies/technology[name=3D=E2=80=98bfd-foo=E2=80=99]/data/bfd/.= .. or on the controller if you want to collate faults across a domain, in = which case it would look like: = /domains/domain[name=3D=E2=80=98bar=E2=80=99]/lime/technologies/technology= [name=3D=E2=80=98bfd-foo=E2=80=99]/data/bfd/... I would argue that most operators would be interested in the latter and = not just faults on the device. We can discuss all the options in a call. I am at IEEE meeting this = week, but we can meet next week if need be. > On Sep 7, 2015, at 12:08 AM, Qin Wu wrote: >=20 > Carlos: > I have just come back from 3-days vacations. Sorry about the delay. > Deepak has already had two discussions with Mahesh about path forward, = the goal is to try to find all the possible solutions to resolve the = relation between BFD and LIME: > I think if BFD model likes to follow LIME model structure, there are = three options we can exercise: > (1) BFD model can follow common structure proposed in LIME and = augment LIME model with technology specifics. We have already provide an = example to show how LIME model can be extended to support BFD.(See = attached), e.g., single hop, multiple hop can be distinct using = sub-technology defined in the BFD model. > (2) BFD model just try to reuse several groupings defined in the = LIME base model and reference existing grouping in LIME by using =E2=80=9C= uses prefix name: grouping name=E2=80=9D > (3) BFD model just try to reuse several leafref type defined in = the LIME base model and reference existing data nodes in LIME by using = leafref(See attached) > The options (2) and (3) use its own model structure and doesn=E2=80=99t = follow LIME model structure completely, also In option (3), it is = challenge or not easy to represent some data nodes in BFD model using = leafref type defined in LIME. Therefore Option(1) is perfect if BFD = follows LIME model > =20 > If BFD mode doesn=E2=80=99t want to follow the whole LIME model = structure or only follow subset of LIME model structure with session = level and per interface level, I think BFD model should be developed as = standalone technology independent model or generic model and decouple = from routing-cfg model, we should agree it is possible to have two = generic models. when we want to translate generic BFD model into generic = LIME model, it seems mount point proposal can be used to move BFD data = nodes to LIME model structure(i.e., moving session-cfg from bfd model to = session-cfg in LIME model, moving interface-cfg from bfd model to = interface-cfg in the LIME model. > =20 > I am expecting to talk with Mahesh about these options. Hopefully we = can converge discussion soon. > =20 > -Qin > =E5=8F=91=E4=BB=B6=E4=BA=BA: Carlos Pignataro (cpignata) = [mailto:cpignata@cisco.com ]=20 > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B49=E6=9C=887=E6=97=A5 = 10:40 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu > =E6=8A=84=E9=80=81: Mahesh Jethanandani; Deepak Kumar (dekumar); = wangzitao; Ronald P. Bonica > =E4=B8=BB=E9=A2=98: Fwd: Relationship between BFD model and LIME base = model > =20 > Qin, > =20 > This is a great message, and I appreciate the discussion and seeking = path forward with the BFD model. > =20 > I have not seen a response to this message, however. > =20 > Maybe you could have this discussion with a broader audience, = including the LIME list. > =20 > Thanks, > =20 > =E2=80=94 Carlos. >=20 >=20 > Begin forwarded message: > =20 > From: Qin Wu > > Subject: Relationship between BFD model and LIME base model > Date: August 29, 2015 at 5:13:59 AM EDT > To: Mahesh Jethanandani > > Cc: "Deepak Kumar (dekumar)" >, wangzitao > > =20 > Hi, Mahesh: > LIME model have five level parameters: > 1. MD level parameters > 2. MA level parameters > 3. MEP level parameters > 4. Session level parameters > 5. Interface level parameters > MD level parameters, MA level parameters can be directly inherited in = the LIME base model extension and set as default value, > e.g, domain name in the MA level can be set to AS Number, Area ID, > LIME base model can provide flexible structure for BFD and other OAM = technology. > =20 > Here we give an example how LIME base model can be extended to support = BFD (See attached), > We model the same parameter proposed in draft-zheng-bfd-yang-04 using = multiple level structure defined by LIME base model, > bfd-session-cfg defined in draft-zheng-bfd-yang-04 can be well grafted = into session level structure defined in LIME base model > bfd-interface-cfg defined in draft-zheng-bfd-yang-04 can be well = grafted into interface level structure define in LIME base model. > =20 > For notification, LIME base model only provide defect notification = definition, doesn=E2=80=99t provide state-change notification, so new = state-change notification can > Be defined in the BFD model, > For operation state, LIME base model doesn=E2=80=99t provide separate = state data structure for operation state, so maybe BFD model can extend = state data structure defined in > The base model for routing defined in = draft-ietf-netmod-routing-cfg-19. > =20 > I am happy to discuss if you have any questions. I hope we can come to = agreement soon. > =20 > I heard about your discussion with Deepak about harmonization of BFD = with LIME, One proposal is to have BFD generic model and LIME generic = model separately, > Support both > /bfd > And > /lime/bfd > if there is such consensus, I am happy to accept this. I also think if = we go with /lime/bfd, I think we can provide better OAM management = automation, or consistent reporting, configuration, representation, MD = level parameters and MA level parameters are just management = information, they should not be the burden for BFD, these management = information doesn=E2=80=99t bother how BFD work(BFD fuction doesn=E2=80=99= t need to know about it), just help establish the testpoints = relationship or global view of OAM topo by associating test point(MEP) = with MD, MA and other context information. > =20 > Regards! > -Qin > = Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_3FFEC4A0-1527-4173-B852-D479A2AD68F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Qin for the summary. I would add that the last option = (support for /bfd and /lime/bfd) should be considered the fourth option. = The advantage of this approach is that LIME can still collate all OAM = technologies and provide a hierarchy, and it does not require the = technologies themselves to have to change their current configuration = model. We can still investigate reuse of groupings and data types from = option 2.

For a = reference, please refer to the discussion on the netmod mailing list on = root nodes - http://www.ietf.org/mail-archive/web/netmod/current/msg13243.ht= ml

If I = was to extrapolate from that example, the lime model could contain = something like this:

container technologies {
    list technology {
  =       key name;
      =   // information about MD, MA =E2=80=A6 would go here.
        container data {
            // all = oam-technologies supported by lime are mounted here
        }
  =   }
}

The choice of where to = build this hierarchy is now up to the implementor. 

You could do this on the = device if the interest is to do fault isolation on a device in which = case your path would look like

/lime/technologies/technology[name=3D=E2=80=98bfd-foo=E2=80=99]= /data/bfd/...

or= on the controller if you want to collate faults across a domain, in = which case it would look like:

/domains/domain[name=3D=E2=80=98bar=E2=80=99]/lime/technologies= /technology[name=3D=E2=80=98bfd-foo=E2=80=99]/data/bfd/...

I would argue that most = operators would be interested in the latter and not just faults on the = device.

We= can discuss all the options in a call. I am at IEEE meeting this week, = but we can meet next week if need be.

On Sep 7, 2015, at 12:08 AM, Qin Wu <bill.wu@huawei.com> = wrote:

Carlos:
I have just come back = from 3-days vacations. Sorry about the delay.
Deepak has already had = two discussions with Mahesh about path forward, the goal is to try to = find all the possible solutions to resolve the relation between BFD and = LIME:
I think if BFD = model likes to follow LIME model structure, there are three options we = can exercise:
(1)     BFD model can follow = common structure proposed in LIME and augment LIME model with technology = specifics. We have already provide an example to show how LIME model can = be extended to support BFD.(See attached), e.g., single hop, multiple = hop can be distinct using sub-technology defined in the BFD model.
(2)     BFD model just try to = reuse several groupings defined in the LIME base model and reference = existing grouping in LIME by using =E2=80=9Cuses prefix name: grouping = name=E2=80=9D
(3)     BFD model just try to = reuse several leafref type defined in the LIME base model and reference = existing data nodes in  LIME by using leafref(See attached)
The options (2) and (3) = use its own model structure and doesn=E2=80=99t follow LIME model = structure completely, also In option (3), it is challenge or not easy to = represent some data nodes in BFD model using leafref type defined in = LIME. Therefore Option(1) is perfect if BFD follows LIME model
 
If BFD mode doesn=E2=80=99t want to follow the whole LIME = model structure or only follow subset of LIME model structure with = session level and per interface level, I think BFD model should be = developed as standalone technology independent model or generic model = and decouple from routing-cfg model, we should agree it is possible to = have two generic models. when we want to translate generic BFD model = into generic LIME model, it seems mount point proposal can be used to = move BFD data nodes to LIME model structure(i.e., moving session-cfg = from bfd model to session-cfg in LIME model, moving interface-cfg from = bfd model to interface-cfg in the LIME model.
 
I am expecting to talk with Mahesh about these options. = Hopefully we can converge discussion soon.
 
-Qin
=E5=8F=91=E4=BB=B6=E4=BA=BA: Carlos Pignataro (cpignata) = [mailto:cpignata@cisco.com] 
=E5=8F=91=E9=80=81=E6= =97=B6=E9=97=B4: 2015=E5=B9=B49=E6=9C=887=E6=97=A5 10:40
=E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu
=E6=8A=84=E9=80=81: Mahesh Jethanandani; Deepak = Kumar (dekumar); wangzitao; Ronald P. Bonica
=E4=B8=BB=E9=A2=98: Fwd: Relationship between = BFD model and LIME base model
 
Qin,
 
This is a great message, and I appreciate the discussion and = seeking path forward with the BFD model.
 
I have not seen a response to this message, however.
 
Maybe you could have this discussion with a broader audience, = including the LIME list.
 
Thanks,
 
=E2=80=94 Carlos.


Begin forwarded message:
 
From: Qin Wu <bill.wu@huawei.com>
Subject: = Relationship between BFD model and LIME base model
Date: August 29, 2015 at 5:13:59 AM EDT
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: "Deepak Kumar (dekumar)" <dekumar@cisco.com>, = wangzitao <wangzitao@huawei.com>
 
Hi, Mahesh:
LIME model have five level parameters:
1.       MD level parameters
2.       MA level parameters
3.       MEP level parameters
4.       Session level parameters
5.       Interface level parameters
MD level parameters, MA = level parameters can be directly inherited in the LIME base model = extension and set as default value,
e.g, domain name in the MA level can be set to AS Number, = Area ID,
LIME base model can = provide flexible structure for BFD and other OAM = technology.
<= div>
 
Here we give an = example how LIME base model can be extended to support BFD (See = attached),
We model the same = parameter proposed in draft-zheng-bfd-yang-04 using multiple level = structure defined by LIME base model,
bfd-session-cfg defined in = draft-zheng-bfd-yang-04 can be well grafted into session level structure = defined in LIME base model
bfd-interface-cfg defined in draft-zheng-bfd-yang-04 can be = well grafted into interface level structure define in LIME base = model.
 
For notification, LIME base model only = provide defect notification definition, doesn=E2=80=99t provide = state-change notification, so new state-change notification can
Be defined in the BFD model,
For operation state, LIME base model = doesn=E2=80=99t provide separate state data structure for operation = state, so maybe BFD model can extend state data structure defined in
The base model for routing defined in = draft-ietf-netmod-routing-cfg-19.
 
I am happy to = discuss if you have any questions. I hope we can come to agreement = soon.
 
I heard about your discussion with = Deepak about harmonization of BFD with LIME, One proposal is to have BFD = generic model and LIME generic model separately,
Support both
/bfd
And
/lime/bfd
if there is such consensus, I am happy = to accept this. I also think if we go with /lime/bfd, I think we can = provide better OAM management automation, or consistent reporting, = configuration, representation, MD level parameters and MA level = parameters are just management information, they should not be the = burden for BFD, these management information doesn=E2=80=99t bother how = BFD work(BFD fuction doesn=E2=80=99t need to know about it), just help = establish the testpoints relationship or global view of OAM topo by = associating test point(MEP) with MD, MA and other context = information.
 
Regards!
-Qin
<bfd-leafr= ef-lime.txt><bfd-leafr= ef-lime.yang><draft-wan= g-yang-bfd-oam-04.txt>

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_3FFEC4A0-1527-4173-B852-D479A2AD68F4-- From nobody Tue Sep 8 07:52:31 2015 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 5B7151B3E57; Mon, 7 Sep 2015 19:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 suIBPlaA_wPo; Mon, 7 Sep 2015 19:08:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1965C1B3E4D; Mon, 7 Sep 2015 19:08:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXG66908; Tue, 08 Sep 2015 02:08:39 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 8 Sep 2015 03:08:37 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.99]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0235.001; Tue, 8 Sep 2015 10:08:28 +0800 From: Qin Wu To: Mahesh Jethanandani Subject: RE: Relationship between BFD model and LIME base model Thread-Topic: Relationship between BFD model and LIME base model Thread-Index: AdDiOwn8N0ELnVdPQ3G8McDl19ZlpgG+/TnwABVHKAAAEQlhkA== Date: Tue, 8 Sep 2015 02:08:27 +0000 Message-ID: References: <78EA03A6-0D1F-4661-85A6-ACB217AB10C8@gmail.com> In-Reply-To: <78EA03A6-0D1F-4661-85A6-ACB217AB10C8@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA848175ACnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Tue, 08 Sep 2015 07:52:27 -0700 Cc: "Carlos Pignataro \(cpignata\)" , "Deepak Kumar \(dekumar\)" , "Ronald P. Bonica" , "yang-coord@ietf.org" , Alia Atlas , Joel jaeggli , Benoit Claise , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 02:08:49 -0000 --_000_B8F9A780D330094D99AF023C5877DABA848175ACnkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIE1haGVzaDoNCuWPkeS7tuS6ujogTWFoZXNoIEpldGhhbmFuZGFuaSBbbWFpbHRvOm1qZXRo YW5hbmRhbmlAZ21haWwuY29tXQ0K5Y+R6YCB5pe26Ze0OiAyMDE15bm0OeaciDjml6UgODo0Mg0K 5pS25Lu25Lq6OiBRaW4gV3UNCuaKhOmAgTogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpOyBE ZWVwYWsgS3VtYXIgKGRla3VtYXIpOyB3YW5neml0YW87IFJvbmFsZCBQLiBCb25pY2E7IHlhbmct Y29vcmRAaWV0Zi5vcmc7IEJlbm9pdCBDbGFpc2U7IEpvZWwgamFlZ2dsaTsgQWxpYSBBdGxhczsg cnRnLWJmZEBpZXRmLm9yZw0K5Li76aKYOiBSZTogUmVsYXRpb25zaGlwIGJldHdlZW4gQkZEIG1v ZGVsIGFuZCBMSU1FIGJhc2UgbW9kZWwNCg0KVGhhbmtzIFFpbiBmb3IgdGhlIHN1bW1hcnkuIEkg d291bGQgYWRkIHRoYXQgdGhlIGxhc3Qgb3B0aW9uIChzdXBwb3J0IGZvciAvYmZkIGFuZCAvbGlt ZS9iZmQpIHNob3VsZCBiZSBjb25zaWRlcmVkIHRoZSBmb3VydGggb3B0aW9uLg0KDQpbUWluXTog WWVzLCBJIG1pc3MgaXQsIEkgdGhpbmsgdGhpcyBvcHRpb24gd291bGQgYmUgYSBnb29kIG9wdGlv biBpZiB3ZSBjYW4gY29tZSB0byBhZ3JlZW1lbnQuDQppZiB3ZSBzdXBwb3J0DQovYmZkDQovbGlt ZS9iZmQNClRoYXQgbWVhbnMgYm90aCBMSU1FIG1vZGVsIGFuZCBCRkQgbW9kZWwgc2hvdWxkIGJl IGRldmVsb3BlZCBhcyB0ZWNobm9sb2d5IGluZGVwZW5kZW50IG1vZGVscyBvciBnZW5lcmljIFlB TkcgbW9kZWxzLCBpbiBhZGRpdGlvbiwgQkZEIGNhbiBiZSBkZXZlbG9wZWQgYXMgbW9kZWwgZXh0 ZW5zaW9uIHRvIExJTUUgYmFzZSBtb2RlbC4NCi9saW1lL2JmZCBjYW4gYWxzbyBiZSByZXByZXNl bnRlZCBhcyAvbGltZVt0ZWNobm9sb2d5PeKAmWJmZOKAmV0NCg0KVGhlIGFkdmFudGFnZSBvZiB0 aGlzIGFwcHJvYWNoIGlzIHRoYXQgTElNRSBjYW4gc3RpbGwgY29sbGF0ZSBhbGwgT0FNIHRlY2hu b2xvZ2llcyBhbmQgcHJvdmlkZSBhIGhpZXJhcmNoeSwgYW5kIGl0IGRvZXMgbm90IHJlcXVpcmUg dGhlIHRlY2hub2xvZ2llcyB0aGVtc2VsdmVzIHRvIGhhdmUgdG8gY2hhbmdlIHRoZWlyIGN1cnJl bnQgY29uZmlndXJhdGlvbiBtb2RlbC4NCg0KW1Fpbl06IHlvdXIgdW5kZXJzdGFuZGluZyBvbiB0 aGUgYWR2YW50YWdlIG9mIHRoaXMgYXBwcm9hY2ggaXMgbm90IGNvcnJlY3QsDQoNCjEuICAgICAg IExJTUUgYmFzZSBtb2RlbCBpcyBub3QgYSBzdXBlciBtb2RlbCB3aGljaCBjb21wb3NlIHZhcmlv dXMgdGVjaG5vbG9neSBzcGVjaWZpYyBPQU0gbW9kZWwgdG9nZXRoZXIsIExJTUUgbW9kZWwgaXMg bm90IGRldmljZSBtb2RlbCBwcm9wb3NlZCBieSBkcmFmdC1ydGd5YW5nZHQtcnRnd2ctZGV2aWNl LW1vZGVsLTAwLg0KDQoyLiAgICAgICBMSU1FIGJhc2UgbW9kZWwgcHJvdmlkZXMgYWJzdHJhY3Qg bW9kZWwgc3RydWN0dXJlIGZvciBlYWNoIE9BTSB0ZWNobm9sb2d5LCBFYWNoIHRlY2hub2xvZ3kg c3BlY2lmaWMgT0FNICBtb2RlbCBjYW4gZXh0ZW5kIGZyb20gTElNRSBiYXNlIG1vZGVsLCBidXQg b25lIExJTUUgYmFzZSBtb2RlbCBjYW4gbm90IGJlIGV4dGVuZGVkIHRvIHN1cHBvcnQgbXVsdGlw bGUgT0FNIHRlY2hub2xvZ2llcy4NCg0KMy4gICAgICAgTElNRSBiYXNlIG1vZGVsIHdpbGwgYmUg bWFwcGVkIGludG8gZWFjaCB0ZWNobm9sb2d5IHNwZWNpZmljIE9BTSBtb2RlbCB3aGVuIHRoZSBt YW5hZ2VtZW50IHN5c3RlbSBrbm93IHdoaWNoIE9BTSB0ZWNobm9sb2d5IGlzIHVzZWQgdG8gZG8g dGhlIHRyb3VibGVzaG9vdGluZyBvbiBzcGVjaWZpYyBuZXR3b3JrLg0KDQoNCldlIGNhbiBzdGls bCBpbnZlc3RpZ2F0ZSByZXVzZSBvZiBncm91cGluZ3MgYW5kIGRhdGEgdHlwZXMgZnJvbSBvcHRp b24gMi4NCg0KRm9yIGEgcmVmZXJlbmNlLCBwbGVhc2UgcmVmZXIgdG8gdGhlIGRpc2N1c3Npb24g b24gdGhlIG5ldG1vZCBtYWlsaW5nIGxpc3Qgb24gcm9vdCBub2RlcyAtIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRtb2QvY3VycmVudC9tc2cxMzI0My5odG1sDQoNCltR aW5dOiBJIGFtIG5vdCBzdXJlIHdlIHNob3VsZCBmb2xsb3cgdGhlIGV4YW1wbGUgcHJvcG9zZWQg aW4gdGhhdCBkaXNjdXNzaW9uLCBMYWRhIGhhcyBhbHJlYWR5IGNsYXJpZmllZCByb290IG5vZGVz IGRpc2N1c3Npb24gaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCByb3V0aW5nLWNmZyBtb2RlbCwNCkkg d291bGQgYXJndWUgYXMgd2VsbCBkYXRhIG5vZGVzIGRpc2N1c3Npb24gaXMgYWxzbyBub3QgYXBw bGljYWJsZSB0byBMSU1FIG1vZGVsIG9yIE9BTSBtb2RlbC4NCklmIHJvdXRpbmctY2ZnIG1vZGVs IGZvbGxvd3MNClJvdXRpbmcvaXNpcw0KUm91dGluZy9vc3BmDQpJIHRoaW5rIE9BTSBtb2RlbCBz aG91bGQgYWxzbyBmb2xsb3dzDQpMaW1lL2JmZA0KTGltZS90cmlsbA0KSW50ZXJmYWNlIG1vZGVs IHNob3VsZCBhbHNvIGZvbGxvd3MNCkludGVyZmFjZS9WTEFOLUludGVyZmFjZQ0KSW50ZXJmYWNl L0V0aGVybmV0LUludGVyZmFjZQ0KDQoNCklmIEkgd2FzIHRvIGV4dHJhcG9sYXRlIGZyb20gdGhh dCBleGFtcGxlLCB0aGUgbGltZSBtb2RlbCBjb3VsZCBjb250YWluIHNvbWV0aGluZyBsaWtlIHRo aXM6DQoNCmNvbnRhaW5lciB0ZWNobm9sb2dpZXMgew0KICAgIGxpc3QgdGVjaG5vbG9neSB7DQog ICAgICAgIGtleSBuYW1lOw0KICAgICAgICAvLyBpbmZvcm1hdGlvbiBhYm91dCBNRCwgTUEg4oCm IHdvdWxkIGdvIGhlcmUuDQogICAgICAgIGNvbnRhaW5lciBkYXRhIHsNCiAgICAgICAgICAgIC8v IGFsbCBvYW0tdGVjaG5vbG9naWVzIHN1cHBvcnRlZCBieSBsaW1lIGFyZSBtb3VudGVkIGhlcmUN CiAgICAgICAgfQ0KICAgIH0NCn0NCg0KW1Fpbl06IEkgYXNzdW1lIHlvdSBoYXZlbuKAmXQgaGFk IGluLWRlcHRoIHJldmlldyBvZiBkcmFmdC10aXNzYS1saW1lLXlhbmctb2FtLW1vZGVsLTA2LCBM SU1FIGJhc2UgbW9kZWwgaGFzIHRlY2hub2xvZ3kgdHlwZSB0byBkaXN0aW5jdCBvbmUgT0FNIHRl Y2hub2xvZ3kgZnJvbSBhbm90aGVyLg0KU2luY2UgeW91IGFncmVlIHdlIGdvIHdpdGggL2xpbWUv YmZkLA0KWW91IHNob3VsZCBhbHNvIGFncmVlIHdlIGdvIHdpdGggL2xpbWUvdHJpbGwNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL2xpbWUvbnZvMw0K SG93ICBpcyBpdCBwb3NzaWJsZSB0byBzdXBwb3J0DQovbGltZS9bYmZkLHRyaWxsLE5WTzNdDQpJ dCBjb250cmFkaWN0cyB3aXRoIHRoZSBhc3N1bXB0aW9uIHlvdSBtYWRlLg0KDQpUaGUgY2hvaWNl IG9mIHdoZXJlIHRvIGJ1aWxkIHRoaXMgaGllcmFyY2h5IGlzIG5vdyB1cCB0byB0aGUgaW1wbGVt ZW50b3IuDQoNCllvdSBjb3VsZCBkbyB0aGlzIG9uIHRoZSBkZXZpY2UgaWYgdGhlIGludGVyZXN0 IGlzIHRvIGRvIGZhdWx0IGlzb2xhdGlvbiBvbiBhIGRldmljZSBpbiB3aGljaCBjYXNlIHlvdXIg cGF0aCB3b3VsZCBsb29rIGxpa2UNCg0KL2xpbWUvdGVjaG5vbG9naWVzL3RlY2hub2xvZ3lbbmFt ZT3igJhiZmQtZm9v4oCZXS9kYXRhL2JmZC8uLi4NCg0KW1Fpbl06IElmIHdlIGdvIHdpdGggL2xp bWUvYmZkLywgTElNRSBpbiB0aGlzIHBhdGggaW5mbyBzdGFuZCBmb3IgYmFzZSBtb2RlbCwgYmZk IGluIHRoaXMgcGF0aCBpbmZvIHN0YW5kIGZvciBtb2RlbCBleHRlbnNpb24gdG8gQkZELg0KYmZk IGhhcyBhbHJlYWR5IGluZGljYXRlZCB0aGUgT0FNIHRlY2hub2xvZ3kgd2UgYXJlIHVzaW5nLg0K DQpvciBvbiB0aGUgY29udHJvbGxlciBpZiB5b3Ugd2FudCB0byBjb2xsYXRlIGZhdWx0cyBhY3Jv c3MgYSBkb21haW4sIGluIHdoaWNoIGNhc2UgaXQgd291bGQgbG9vayBsaWtlOg0KDQovZG9tYWlu cy9kb21haW5bbmFtZT3igJhiYXLigJldL2xpbWUvdGVjaG5vbG9naWVzL3RlY2hub2xvZ3lbbmFt ZT3igJhiZmQtZm9v4oCZXS9kYXRhL2JmZC8uLi4NCg0KSSB3b3VsZCBhcmd1ZSB0aGF0IG1vc3Qg b3BlcmF0b3JzIHdvdWxkIGJlIGludGVyZXN0ZWQgaW4gdGhlIGxhdHRlciBhbmQgbm90IGp1c3Qg ZmF1bHRzIG9uIHRoZSBkZXZpY2UuDQoNCltRaW5dOiBpZiB3ZSBnbyB3aXRoIC9saW1lL2JmZA0K TElNRSBtb2RlbCBoYXMgYWxyZWFkeSBwcm92aWRlIGhpZXJhcmNoeSBmb3IgQkZEIHN1cHBvcnQg YXMgZm9sbG93czoNCi9kb21haW5zL2RvbWFpbltuYW1lPeKAmWJhcuKAmV1bdGVjaG5vbG9neT3i gJliZmTigJldL01Bcy9NRVBbbmFtZT3igJlMU1Ix4oCZXS8NCkxJTUUgbW9kZWwgaGFzIGFscmVh ZHkgY29ycmVsYXRlIGRvbWFpbiBpbmZvcm1hdGlvbiB3aXRoIGZhdWx0cy4NCg0KV2UgY2FuIGRp c2N1c3MgYWxsIHRoZSBvcHRpb25zIGluIGEgY2FsbC4gSSBhbSBhdCBJRUVFIG1lZXRpbmcgdGhp cyB3ZWVrLCBidXQgd2UgY2FuIG1lZXQgbmV4dCB3ZWVrIGlmIG5lZWQgYmUuDQoNCk9uIFNlcCA3 LCAyMDE1LCBhdCAxMjowOCBBTSwgUWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb208bWFpbHRvOmJp bGwud3VAaHVhd2VpLmNvbT4+IHdyb3RlOg0KDQpDYXJsb3M6DQpJIGhhdmUganVzdCBjb21lIGJh Y2sgZnJvbSAzLWRheXMgdmFjYXRpb25zLiBTb3JyeSBhYm91dCB0aGUgZGVsYXkuDQpEZWVwYWsg aGFzIGFscmVhZHkgaGFkIHR3byBkaXNjdXNzaW9ucyB3aXRoIE1haGVzaCBhYm91dCBwYXRoIGZv cndhcmQsIHRoZSBnb2FsIGlzIHRvIHRyeSB0byBmaW5kIGFsbCB0aGUgcG9zc2libGUgc29sdXRp b25zIHRvIHJlc29sdmUgdGhlIHJlbGF0aW9uIGJldHdlZW4gQkZEIGFuZCBMSU1FOg0KSSB0aGlu ayBpZiBCRkQgbW9kZWwgbGlrZXMgdG8gZm9sbG93IExJTUUgbW9kZWwgc3RydWN0dXJlLCB0aGVy ZSBhcmUgdGhyZWUgb3B0aW9ucyB3ZSBjYW4gZXhlcmNpc2U6DQooMSkgICAgIEJGRCBtb2RlbCBj YW4gZm9sbG93IGNvbW1vbiBzdHJ1Y3R1cmUgcHJvcG9zZWQgaW4gTElNRSBhbmQgYXVnbWVudCBM SU1FIG1vZGVsIHdpdGggdGVjaG5vbG9neSBzcGVjaWZpY3MuIFdlIGhhdmUgYWxyZWFkeSBwcm92 aWRlIGFuIGV4YW1wbGUgdG8gc2hvdyBob3cgTElNRSBtb2RlbCBjYW4gYmUgZXh0ZW5kZWQgdG8g c3VwcG9ydCBCRkQuKFNlZSBhdHRhY2hlZCksIGUuZy4sIHNpbmdsZSBob3AsIG11bHRpcGxlIGhv cCBjYW4gYmUgZGlzdGluY3QgdXNpbmcgc3ViLXRlY2hub2xvZ3kgZGVmaW5lZCBpbiB0aGUgQkZE IG1vZGVsLg0KKDIpICAgICBCRkQgbW9kZWwganVzdCB0cnkgdG8gcmV1c2Ugc2V2ZXJhbCBncm91 cGluZ3MgZGVmaW5lZCBpbiB0aGUgTElNRSBiYXNlIG1vZGVsIGFuZCByZWZlcmVuY2UgZXhpc3Rp bmcgZ3JvdXBpbmcgaW4gTElNRSBieSB1c2luZyDigJx1c2VzIHByZWZpeCBuYW1lOiBncm91cGlu ZyBuYW1l4oCdDQooMykgICAgIEJGRCBtb2RlbCBqdXN0IHRyeSB0byByZXVzZSBzZXZlcmFsIGxl YWZyZWYgdHlwZSBkZWZpbmVkIGluIHRoZSBMSU1FIGJhc2UgbW9kZWwgYW5kIHJlZmVyZW5jZSBl eGlzdGluZyBkYXRhIG5vZGVzIGluICBMSU1FIGJ5IHVzaW5nIGxlYWZyZWYoU2VlIGF0dGFjaGVk KQ0KVGhlIG9wdGlvbnMgKDIpIGFuZCAoMykgdXNlIGl0cyBvd24gbW9kZWwgc3RydWN0dXJlIGFu ZCBkb2VzbuKAmXQgZm9sbG93IExJTUUgbW9kZWwgc3RydWN0dXJlIGNvbXBsZXRlbHksIGFsc28g SW4gb3B0aW9uICgzKSwgaXQgaXMgY2hhbGxlbmdlIG9yIG5vdCBlYXN5IHRvIHJlcHJlc2VudCBz b21lIGRhdGEgbm9kZXMgaW4gQkZEIG1vZGVsIHVzaW5nIGxlYWZyZWYgdHlwZSBkZWZpbmVkIGlu IExJTUUuIFRoZXJlZm9yZSBPcHRpb24oMSkgaXMgcGVyZmVjdCBpZiBCRkQgZm9sbG93cyBMSU1F IG1vZGVsDQoNCklmIEJGRCBtb2RlIGRvZXNu4oCZdCB3YW50IHRvIGZvbGxvdyB0aGUgd2hvbGUg TElNRSBtb2RlbCBzdHJ1Y3R1cmUgb3Igb25seSBmb2xsb3cgc3Vic2V0IG9mIExJTUUgbW9kZWwg c3RydWN0dXJlIHdpdGggc2Vzc2lvbiBsZXZlbCBhbmQgcGVyIGludGVyZmFjZSBsZXZlbCwgSSB0 aGluayBCRkQgbW9kZWwgc2hvdWxkIGJlIGRldmVsb3BlZCBhcyBzdGFuZGFsb25lIHRlY2hub2xv Z3kgaW5kZXBlbmRlbnQgbW9kZWwgb3IgZ2VuZXJpYyBtb2RlbCBhbmQgZGVjb3VwbGUgZnJvbSBy b3V0aW5nLWNmZyBtb2RlbCwgd2Ugc2hvdWxkIGFncmVlIGl0IGlzIHBvc3NpYmxlIHRvIGhhdmUg dHdvIGdlbmVyaWMgbW9kZWxzLiB3aGVuIHdlIHdhbnQgdG8gdHJhbnNsYXRlIGdlbmVyaWMgQkZE IG1vZGVsIGludG8gZ2VuZXJpYyBMSU1FIG1vZGVsLCBpdCBzZWVtcyBtb3VudCBwb2ludCBwcm9w b3NhbCBjYW4gYmUgdXNlZCB0byBtb3ZlIEJGRCBkYXRhIG5vZGVzIHRvIExJTUUgbW9kZWwgc3Ry dWN0dXJlKGkuZS4sIG1vdmluZyBzZXNzaW9uLWNmZyBmcm9tIGJmZCBtb2RlbCB0byBzZXNzaW9u LWNmZyBpbiBMSU1FIG1vZGVsLCBtb3ZpbmcgaW50ZXJmYWNlLWNmZyBmcm9tIGJmZCBtb2RlbCB0 byBpbnRlcmZhY2UtY2ZnIGluIHRoZSBMSU1FIG1vZGVsLg0KDQpJIGFtIGV4cGVjdGluZyB0byB0 YWxrIHdpdGggTWFoZXNoIGFib3V0IHRoZXNlIG9wdGlvbnMuIEhvcGVmdWxseSB3ZSBjYW4gY29u dmVyZ2UgZGlzY3Vzc2lvbiBzb29uLg0KDQotUWluDQrlj5Hku7bkuro6IENhcmxvcyBQaWduYXRh cm8gKGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0NCuWPkemAgeaXtumXtDog MjAxNeW5tDnmnIg35pelIDEwOjQwDQrmlLbku7bkuro6IFFpbiBXdQ0K5oqE6YCBOiBNYWhlc2gg SmV0aGFuYW5kYW5pOyBEZWVwYWsgS3VtYXIgKGRla3VtYXIpOyB3YW5neml0YW87IFJvbmFsZCBQ LiBCb25pY2ENCuS4u+mimDogRndkOiBSZWxhdGlvbnNoaXAgYmV0d2VlbiBCRkQgbW9kZWwgYW5k IExJTUUgYmFzZSBtb2RlbA0KDQpRaW4sDQoNClRoaXMgaXMgYSBncmVhdCBtZXNzYWdlLCBhbmQg SSBhcHByZWNpYXRlIHRoZSBkaXNjdXNzaW9uIGFuZCBzZWVraW5nIHBhdGggZm9yd2FyZCB3aXRo IHRoZSBCRkQgbW9kZWwuDQoNCkkgaGF2ZSBub3Qgc2VlbiBhIHJlc3BvbnNlIHRvIHRoaXMgbWVz c2FnZSwgaG93ZXZlci4NCg0KTWF5YmUgeW91IGNvdWxkIGhhdmUgdGhpcyBkaXNjdXNzaW9uIHdp dGggYSBicm9hZGVyIGF1ZGllbmNlLCBpbmNsdWRpbmcgdGhlIExJTUUgbGlzdC4NCg0KVGhhbmtz LA0KDQrigJQgQ2FybG9zLg0KDQoNCg0KQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQoNCkZyb206 IFFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29tPG1haWx0bzpiaWxsLnd1QGh1YXdlaS5jb20+Pg0K U3ViamVjdDogUmVsYXRpb25zaGlwIGJldHdlZW4gQkZEIG1vZGVsIGFuZCBMSU1FIGJhc2UgbW9k ZWwNCkRhdGU6IEF1Z3VzdCAyOSwgMjAxNSBhdCA1OjEzOjU5IEFNIEVEVA0KVG86IE1haGVzaCBK ZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5p QGdtYWlsLmNvbT4+DQpDYzogIkRlZXBhayBLdW1hciAoZGVrdW1hcikiIDxkZWt1bWFyQGNpc2Nv LmNvbTxtYWlsdG86ZGVrdW1hckBjaXNjby5jb20+Piwgd2FuZ3ppdGFvIDx3YW5neml0YW9AaHVh d2VpLmNvbTxtYWlsdG86d2FuZ3ppdGFvQGh1YXdlaS5jb20+Pg0KDQpIaSwgTWFoZXNoOg0KTElN RSBtb2RlbCBoYXZlIGZpdmUgbGV2ZWwgcGFyYW1ldGVyczoNCjEuICAgICAgIE1EIGxldmVsIHBh cmFtZXRlcnMNCjIuICAgICAgIE1BIGxldmVsIHBhcmFtZXRlcnMNCjMuICAgICAgIE1FUCBsZXZl bCBwYXJhbWV0ZXJzDQo0LiAgICAgICBTZXNzaW9uIGxldmVsIHBhcmFtZXRlcnMNCjUuICAgICAg IEludGVyZmFjZSBsZXZlbCBwYXJhbWV0ZXJzDQpNRCBsZXZlbCBwYXJhbWV0ZXJzLCBNQSBsZXZl bCBwYXJhbWV0ZXJzIGNhbiBiZSBkaXJlY3RseSBpbmhlcml0ZWQgaW4gdGhlIExJTUUgYmFzZSBt b2RlbCBleHRlbnNpb24gYW5kIHNldCBhcyBkZWZhdWx0IHZhbHVlLA0KZS5nLCBkb21haW4gbmFt ZSBpbiB0aGUgTUEgbGV2ZWwgY2FuIGJlIHNldCB0byBBUyBOdW1iZXIsIEFyZWEgSUQsDQpMSU1F IGJhc2UgbW9kZWwgY2FuIHByb3ZpZGUgZmxleGlibGUgc3RydWN0dXJlIGZvciBCRkQgYW5kIG90 aGVyIE9BTSB0ZWNobm9sb2d5Lg0KDQpIZXJlIHdlIGdpdmUgYW4gZXhhbXBsZSBob3cgTElNRSBi YXNlIG1vZGVsIGNhbiBiZSBleHRlbmRlZCB0byBzdXBwb3J0IEJGRCAoU2VlIGF0dGFjaGVkKSwN CldlIG1vZGVsIHRoZSBzYW1lIHBhcmFtZXRlciBwcm9wb3NlZCBpbiBkcmFmdC16aGVuZy1iZmQt eWFuZy0wNCB1c2luZyBtdWx0aXBsZSBsZXZlbCBzdHJ1Y3R1cmUgZGVmaW5lZCBieSBMSU1FIGJh c2UgbW9kZWwsDQpiZmQtc2Vzc2lvbi1jZmcgZGVmaW5lZCBpbiBkcmFmdC16aGVuZy1iZmQteWFu Zy0wNCBjYW4gYmUgd2VsbCBncmFmdGVkIGludG8gc2Vzc2lvbiBsZXZlbCBzdHJ1Y3R1cmUgZGVm aW5lZCBpbiBMSU1FIGJhc2UgbW9kZWwNCmJmZC1pbnRlcmZhY2UtY2ZnIGRlZmluZWQgaW4gZHJh ZnQtemhlbmctYmZkLXlhbmctMDQgY2FuIGJlIHdlbGwgZ3JhZnRlZCBpbnRvIGludGVyZmFjZSBs ZXZlbCBzdHJ1Y3R1cmUgZGVmaW5lIGluIExJTUUgYmFzZSBtb2RlbC4NCg0KRm9yIG5vdGlmaWNh dGlvbiwgTElNRSBiYXNlIG1vZGVsIG9ubHkgcHJvdmlkZSBkZWZlY3Qgbm90aWZpY2F0aW9uIGRl ZmluaXRpb24sIGRvZXNu4oCZdCBwcm92aWRlIHN0YXRlLWNoYW5nZSBub3RpZmljYXRpb24sIHNv IG5ldyBzdGF0ZS1jaGFuZ2Ugbm90aWZpY2F0aW9uIGNhbg0KQmUgZGVmaW5lZCBpbiB0aGUgQkZE IG1vZGVsLA0KRm9yIG9wZXJhdGlvbiBzdGF0ZSwgTElNRSBiYXNlIG1vZGVsIGRvZXNu4oCZdCBw cm92aWRlIHNlcGFyYXRlIHN0YXRlIGRhdGEgc3RydWN0dXJlIGZvciBvcGVyYXRpb24gc3RhdGUs IHNvIG1heWJlIEJGRCBtb2RlbCBjYW4gZXh0ZW5kIHN0YXRlIGRhdGEgc3RydWN0dXJlIGRlZmlu ZWQgaW4NClRoZSBiYXNlIG1vZGVsIGZvciByb3V0aW5nIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1u ZXRtb2Qtcm91dGluZy1jZmctMTkuDQoNCkkgYW0gaGFwcHkgdG8gZGlzY3VzcyBpZiB5b3UgaGF2 ZSBhbnkgcXVlc3Rpb25zLiBJIGhvcGUgd2UgY2FuIGNvbWUgdG8gYWdyZWVtZW50IHNvb24uDQoN CkkgaGVhcmQgYWJvdXQgeW91ciBkaXNjdXNzaW9uIHdpdGggRGVlcGFrIGFib3V0IGhhcm1vbml6 YXRpb24gb2YgQkZEIHdpdGggTElNRSwgT25lIHByb3Bvc2FsIGlzIHRvIGhhdmUgQkZEIGdlbmVy aWMgbW9kZWwgYW5kIExJTUUgZ2VuZXJpYyBtb2RlbCBzZXBhcmF0ZWx5LA0KU3VwcG9ydCBib3Ro DQovYmZkDQpBbmQNCi9saW1lL2JmZA0KaWYgdGhlcmUgaXMgc3VjaCBjb25zZW5zdXMsIEkgYW0g aGFwcHkgdG8gYWNjZXB0IHRoaXMuIEkgYWxzbyB0aGluayBpZiB3ZSBnbyB3aXRoIC9saW1lL2Jm ZCwgSSB0aGluayB3ZSBjYW4gcHJvdmlkZSBiZXR0ZXIgT0FNIG1hbmFnZW1lbnQgYXV0b21hdGlv biwgb3IgY29uc2lzdGVudCByZXBvcnRpbmcsIGNvbmZpZ3VyYXRpb24sIHJlcHJlc2VudGF0aW9u LCBNRCBsZXZlbCBwYXJhbWV0ZXJzIGFuZCBNQSBsZXZlbCBwYXJhbWV0ZXJzIGFyZSBqdXN0IG1h bmFnZW1lbnQgaW5mb3JtYXRpb24sIHRoZXkgc2hvdWxkIG5vdCBiZSB0aGUgYnVyZGVuIGZvciBC RkQsIHRoZXNlIG1hbmFnZW1lbnQgaW5mb3JtYXRpb24gZG9lc27igJl0IGJvdGhlciBob3cgQkZE IHdvcmsoQkZEIGZ1Y3Rpb24gZG9lc27igJl0IG5lZWQgdG8ga25vdyBhYm91dCBpdCksIGp1c3Qg aGVscCBlc3RhYmxpc2ggdGhlIHRlc3Rwb2ludHMgcmVsYXRpb25zaGlwIG9yIGdsb2JhbCB2aWV3 IG9mIE9BTSB0b3BvIGJ5IGFzc29jaWF0aW5nIHRlc3QgcG9pbnQoTUVQKSB3aXRoIE1ELCBNQSBh bmQgb3RoZXIgY29udGV4dCBpbmZvcm1hdGlvbi4NCg0KUmVnYXJkcyENCi1RaW4NCjxiZmQtbGVh ZnJlZi1saW1lLnR4dD48YmZkLWxlYWZyZWYtbGltZS55YW5nPjxkcmFmdC13YW5nLXlhbmctYmZk LW9hbS0wNC50eHQ+DQoNCk1haGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlAZ21haWwu Y29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KDQoNCg0K --_000_B8F9A780D330094D99AF023C5877DABA848175ACnkgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpwLk1zb0FjZXRh dGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWls eTrlrovkvZM7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYu TXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1pbmRlbnQ6MjEuMHB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNw YWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkNoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms65om55rOo5qGG5paH5pysOw0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8g Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmi hOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0 IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNzgyODcz Mzk5Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTE0 MTMzNTI0MiAtNDIzMDk4NDUyIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3 Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJbWFyZ2luLWxlZnQ6MTguMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksIE1haGVzaDo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuWPkeS7tuS6 ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gTWFoZXNoIEpldGhhbmFuZGFuaSBbbWFpbHRvOm1q ZXRoYW5hbmRhbmlAZ21haWwuY29tXQ0KPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+IDIwMTU8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuW5tDxzcGFuIGxhbmc9IkVOLVVT Ij45PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj44PC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVO LVVTIj4gODo0Mjxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBRaW4gV3U8YnI+DQo8L3NwYW4+PGI+5oqE6YCB PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gQ2FybG9z IFBpZ25hdGFybyAoY3BpZ25hdGEpOyBEZWVwYWsgS3VtYXIgKGRla3VtYXIpOyB3YW5neml0YW87 IFJvbmFsZCBQLiBCb25pY2E7IHlhbmctY29vcmRAaWV0Zi5vcmc7IEJlbm9pdCBDbGFpc2U7IEpv ZWwgamFlZ2dsaTsgQWxpYSBBdGxhczsgcnRnLWJmZEBpZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj7k uLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBS ZTogUmVsYXRpb25zaGlwIGJldHdlZW4gQkZEIG1vZGVsIGFuZCBMSU1FIGJhc2UgbW9kZWw8bzpw PjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzIFFpbiBmb3IgdGhl IHN1bW1hcnkuIEkgd291bGQgYWRkIHRoYXQgdGhlIGxhc3Qgb3B0aW9uIChzdXBwb3J0IGZvciAv YmZkIGFuZCAvbGltZS9iZmQpIHNob3VsZCBiZSBjb25zaWRlcmVkIHRoZSBmb3VydGggb3B0aW9u LjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPltRaW5dOiBZZXMsIEkgbWlzcyBpdCwgSSB0aGluayB0aGlzIG9wdGlv biB3b3VsZCBiZSBhIGdvb2Qgb3B0aW9uIGlmIHdlIGNhbiBjb21lIHRvIGFncmVlbWVudC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmlmIHdlIHN1cHBvcnQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi9iZmQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi9saW1lL2JmZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhdCBtZWFucyBib3RoIExJTUUgbW9kZWwgYW5k IEJGRCBtb2RlbCBzaG91bGQgYmUgZGV2ZWxvcGVkIGFzIHRlY2hub2xvZ3kgaW5kZXBlbmRlbnQg bW9kZWxzIG9yIGdlbmVyaWMgWUFORyBtb2RlbHMsIGluIGFkZGl0aW9uLCBCRkQgY2FuIGJlIGRl dmVsb3BlZA0KIGFzIG1vZGVsIGV4dGVuc2lvbiB0byBMSU1FIGJhc2UgbW9kZWwuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4vbGltZS9iZmQgY2FuIGFsc28gYmUg cmVwcmVzZW50ZWQgYXMgL2xpbWVbdGVjaG5vbG9neT3igJliZmTigJldPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGFkdmFudGFnZSBv ZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgTElNRSBjYW4gc3RpbGwgY29sbGF0ZSBhbGwgT0FNIHRl Y2hub2xvZ2llcyBhbmQgcHJvdmlkZSBhIGhpZXJhcmNoeSwgYW5kIGl0IGRvZXMgbm90IHJlcXVp cmUgdGhlIHRlY2hub2xvZ2llcyB0aGVtc2VsdmVzIHRvIGhhdmUgdG8gY2hhbmdlIHRoZWlyIGN1 cnJlbnQgY29uZmlndXJhdGlvbiBtb2RlbC4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltRaW5dOiB5b3VyIHVu ZGVyc3RhbmRpbmcgb24gdGhlIGFkdmFudGFnZSBvZiB0aGlzIGFwcHJvYWNoIGlzIG5vdCBjb3Jy ZWN0LA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkxJTUUgYmFzZSBtb2RlbCBpcyBub3QgYSBzdXBlciBtb2RlbCB3 aGljaCBjb21wb3NlIHZhcmlvdXMgdGVjaG5vbG9neSBzcGVjaWZpYyBPQU0gbW9kZWwgdG9nZXRo ZXIsIExJTUUgbW9kZWwgaXMgbm90IGRldmljZSBtb2RlbCBwcm9wb3NlZA0KIGJ5IGRyYWZ0LXJ0 Z3lhbmdkdC1ydGd3Zy1kZXZpY2UtbW9kZWwtMDAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1p bmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxJTUUgYmFzZSBtb2Rl bCBwcm92aWRlcyBhYnN0cmFjdCBtb2RlbCBzdHJ1Y3R1cmUgZm9yIGVhY2ggT0FNIHRlY2hub2xv Z3ksIEVhY2ggdGVjaG5vbG9neSBzcGVjaWZpYyBPQU0gJm5ic3A7bW9kZWwgY2FuIGV4dGVuZCBm cm9tIExJTUUgYmFzZQ0KIG1vZGVsLCBidXQgb25lIExJTUUgYmFzZSBtb2RlbCBjYW4gbm90IGJl IGV4dGVuZGVkIHRvIHN1cHBvcnQgbXVsdGlwbGUgT0FNIHRlY2hub2xvZ2llcy4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4zLjxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5MSU1FIGJhc2UgbW9kZWwgd2lsbCBiZSBtYXBwZWQgaW50byBlYWNoIHRlY2hub2xvZ3kg c3BlY2lmaWMgT0FNIG1vZGVsIHdoZW4gdGhlIG1hbmFnZW1lbnQgc3lzdGVtIGtub3cgd2hpY2gg T0FNIHRlY2hub2xvZ3kgaXMgdXNlZCB0bw0KIGRvIHRoZSB0cm91Ymxlc2hvb3Rpbmcgb24gc3Bl Y2lmaWMgbmV0d29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPldlIGNhbiBzdGlsbCBpbnZlc3RpZ2F0ZSByZXVzZSBvZiBncm91cGluZ3MgYW5kIGRh dGEgdHlwZXMgZnJvbSBvcHRpb24gMi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5Gb3IgYSByZWZlcmVuY2UsIHBsZWFzZSByZWZlciB0byB0aGUgZGlzY3Vzc2lvbiBv biB0aGUgbmV0bW9kIG1haWxpbmcgbGlzdCBvbiByb290IG5vZGVzIC0mbmJzcDs8YSBocmVmPSJo dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNnMTMy NDMuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldG1vZC9jdXJy ZW50L21zZzEzMjQzLmh0bWw8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PltRaW5dOiBJIGFtIG5vdCBzdXJlIHdlIHNob3VsZCBmb2xsb3cgdGhlIGV4YW1wbGUgcHJvcG9z ZWQgaW4gdGhhdCBkaXNjdXNzaW9uLCBMYWRhIGhhcyBhbHJlYWR5IGNsYXJpZmllZCByb290IG5v ZGVzIGRpc2N1c3Npb24gaGFzIG5vdGhpbmcgdG8NCiBkbyB3aXRoIHJvdXRpbmctY2ZnIG1vZGVs LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB3b3VsZCBhcmd1 ZSBhcyB3ZWxsIGRhdGEgbm9kZXMgZGlzY3Vzc2lvbiBpcyBhbHNvIG5vdCBhcHBsaWNhYmxlIHRv IExJTUUgbW9kZWwgb3IgT0FNIG1vZGVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SWYgcm91dGluZy1jZmcgbW9kZWwgZm9sbG93czxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Um91dGluZy9pc2lzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Sb3V0aW5nL29zcGY8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgT0FNIG1vZGVsIHNob3VsZCBhbHNvIGZv bGxvd3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxpbWUvYmZk PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MaW1lL3RyaWxsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbnRlcmZhY2UgbW9kZWwg c2hvdWxkIGFsc28gZm9sbG93czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SW50ZXJmYWNlL1ZMQU4tSW50ZXJmYWNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5JbnRlcmZhY2UvRXRoZXJuZXQtSW50ZXJmYWNlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiBJIHdhcyB0byBleHRyYXBv bGF0ZSBmcm9tIHRoYXQgZXhhbXBsZSwgdGhlIGxpbWUgbW9kZWwgY291bGQgY29udGFpbiBzb21l dGhpbmcgbGlrZSB0aGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPmNvbnRhaW5lciB0ZWNobm9sb2dpZXMgezxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDsgJm5ic3A7IGxpc3QgdGVjaG5vbG9neSB7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBrZXkgbmFtZTs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC8vIGluZm9ybWF0aW9uIGFib3V0IE1ELCBN QSDigKYgd291bGQgZ28gaGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IGNvbnRhaW5lciBkYXRhIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLy8gYWxsIG9hbS10ZWNobm9sb2dp ZXMgc3VwcG9ydGVkIGJ5IGxpbWUgYXJlIG1vdW50ZWQgaGVyZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsgJm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+fTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5bUWluXTogSSBhc3N1bWUgeW91IGhhdmVu4oCZdCBoYWQgaW4tZGVwdGgg cmV2aWV3IG9mIGRyYWZ0LXRpc3NhLWxpbWUteWFuZy1vYW0tbW9kZWwtMDYsIExJTUUgYmFzZSBt b2RlbCBoYXMgdGVjaG5vbG9neSB0eXBlIHRvIGRpc3RpbmN0IG9uZSBPQU0NCiB0ZWNobm9sb2d5 IGZyb20gYW5vdGhlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlNpbmNlIHlvdSBhZ3JlZSB3ZSBnbyB3aXRoIC9saW1lL2JmZCwNCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WW91IHNob3VsZCBhbHNvIGFncmVlIHdlIGdvIHdp dGggL2xpbWUvdHJpbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAvbGltZS9udm8zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5Ib3cgJm5ic3A7aXMgaXQgcG9zc2libGUgdG8gc3VwcG9ydDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+L2xpbWUvW2JmZCx0cmlsbCxOVk8zXTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgY29udHJhZGljdHMgd2l0 aCB0aGUgYXNzdW1wdGlvbiB5b3UgbWFkZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGNob2lj ZSBvZiB3aGVyZSB0byBidWlsZCB0aGlzIGhpZXJhcmNoeSBpcyBub3cgdXAgdG8gdGhlIGltcGxl bWVudG9yLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+WW91IGNvdWxkIGRvIHRoaXMgb24gdGhlIGRldmljZSBpZiB0aGUgaW50ZXJlc3QgaXMg dG8gZG8gZmF1bHQgaXNvbGF0aW9uIG9uIGEgZGV2aWNlIGluIHdoaWNoIGNhc2UgeW91ciBwYXRo IHdvdWxkIGxvb2sgbGlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+L2xpbWUvdGVjaG5vbG9naWVzL3RlY2hub2xvZ3lbbmFtZT3igJhiZmQtZm9v4oCZ XS9kYXRhL2JmZC8uLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1Fpbl06 IElmIHdlIGdvIHdpdGggL2xpbWUvYmZkLywgTElNRSBpbiB0aGlzIHBhdGggaW5mbyBzdGFuZCBm b3IgYmFzZSBtb2RlbCwgYmZkIGluIHRoaXMgcGF0aCBpbmZvIHN0YW5kIGZvciBtb2RlbCBleHRl bnNpb24gdG8gQkZELjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ YmZkIGhhcyBhbHJlYWR5IGluZGljYXRlZCB0aGUgT0FNIHRlY2hub2xvZ3kgd2UgYXJlIHVzaW5n LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPm9yIG9uIHRoZSBjb250cm9sbGVyIGlmIHlvdSB3YW50IHRvIGNvbGxh dGUgZmF1bHRzIGFjcm9zcyBhIGRvbWFpbiwgaW4gd2hpY2ggY2FzZSBpdCB3b3VsZCBsb29rIGxp a2U6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4vZG9t YWlucy9kb21haW5bbmFtZT3igJhiYXLigJldL2xpbWUvdGVjaG5vbG9naWVzL3RlY2hub2xvZ3lb bmFtZT3igJhiZmQtZm9v4oCZXS9kYXRhL2JmZC8uLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHdvdWxkIGFy Z3VlIHRoYXQgbW9zdCBvcGVyYXRvcnMgd291bGQgYmUgaW50ZXJlc3RlZCBpbiB0aGUgbGF0dGVy IGFuZCBub3QganVzdCBmYXVsdHMgb24gdGhlIGRldmljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bUWluXTogaWYgd2UgZ28gd2l0aCAvbGltZS9iZmQNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TElNRSBtb2RlbCBoYXMg YWxyZWFkeSBwcm92aWRlIGhpZXJhcmNoeSBmb3IgQkZEIHN1cHBvcnQgYXMgZm9sbG93czo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi9kb21haW5zL2RvbWFpbltu YW1lPeKAmWJhcuKAmV1bdGVjaG5vbG9neT3igJliZmTigJldL01Bcy9NRVBbbmFtZT3igJlMU1Ix 4oCZXS88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxJTUUgbW9k ZWwgaGFzIGFscmVhZHkgY29ycmVsYXRlIGRvbWFpbiBpbmZvcm1hdGlvbiB3aXRoIGZhdWx0cy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5XZSBjYW4gZGlzY3VzcyBhbGwgdGhlIG9wdGlvbnMgaW4gYSBjYWxsLiBJ IGFtIGF0IElFRUUgbWVldGluZyB0aGlzIHdlZWssIGJ1dCB3ZSBjYW4gbWVldCBuZXh0IHdlZWsg aWYgbmVlZCBiZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPk9uIFNlcCA3LCAyMDE1LCBhdCAxMjowOCBBTSwgUWluIFd1ICZsdDs8YSBo cmVmPSJtYWlsdG86YmlsbC53dUBodWF3ZWkuY29tIj5iaWxsLnd1QGh1YXdlaS5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2FybG9zOjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5JIGhhdmUganVzdCBjb21lIGJhY2sgZnJvbSAzLWRheXMgdmFjYXRpb25zLiBTb3Jy eSBhYm91dCB0aGUgZGVsYXkuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRlZXBhayBoYXMg YWxyZWFkeSBoYWQgdHdvIGRpc2N1c3Npb25zIHdpdGggTWFoZXNoIGFib3V0IHBhdGggZm9yd2Fy ZCwgdGhlIGdvYWwgaXMgdG8gdHJ5IHRvIGZpbmQgYWxsIHRoZSBwb3NzaWJsZSBzb2x1dGlvbnMg dG8gcmVzb2x2ZSB0aGUgcmVsYXRpb24NCiBiZXR3ZWVuIEJGRCBhbmQgTElNRTo8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayBpZiBCRkQgbW9kZWwgbGlrZXMgdG8gZm9sbG93IExJ TUUgbW9kZWwgc3RydWN0dXJlLCB0aGVyZSBhcmUgdGhyZWUgb3B0aW9ucyB3ZSBjYW4gZXhlcmNp c2U6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4oMSk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5CRkQNCiBtb2RlbCBjYW4gZm9sbG93IGNvbW1vbiBzdHJ1Y3R1cmUgcHJvcG9zZWQgaW4g TElNRSBhbmQgYXVnbWVudCBMSU1FIG1vZGVsIHdpdGggdGVjaG5vbG9neSBzcGVjaWZpY3MuIFdl IGhhdmUgYWxyZWFkeSBwcm92aWRlIGFuIGV4YW1wbGUgdG8gc2hvdyBob3cgTElNRSBtb2RlbCBj YW4gYmUgZXh0ZW5kZWQgdG8gc3VwcG9ydCBCRkQuKFNlZSBhdHRhY2hlZCksIGUuZy4sIHNpbmds ZSBob3AsIG11bHRpcGxlIGhvcCBjYW4gYmUgZGlzdGluY3QgdXNpbmcNCiBzdWItdGVjaG5vbG9n eSBkZWZpbmVkIGluIHRoZSBCRkQgbW9kZWwuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4oMik8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CRkQNCiBtb2RlbCBqdXN0IHRyeSB0byByZXVz ZSBzZXZlcmFsIGdyb3VwaW5ncyBkZWZpbmVkIGluIHRoZSBMSU1FIGJhc2UgbW9kZWwgYW5kIHJl ZmVyZW5jZSBleGlzdGluZyBncm91cGluZyBpbiBMSU1FIGJ5IHVzaW5nIOKAnHVzZXMgcHJlZml4 IG5hbWU6IGdyb3VwaW5nIG5hbWXigJ08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPigzKTwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJGRA0KIG1vZGVsIGp1c3QgdHJ5IHRvIHJldXNlIHNl dmVyYWwgbGVhZnJlZiB0eXBlIGRlZmluZWQgaW4gdGhlIExJTUUgYmFzZSBtb2RlbCBhbmQgcmVm ZXJlbmNlIGV4aXN0aW5nIGRhdGEgbm9kZXMgaW4mbmJzcDsgTElNRSBieSB1c2luZyBsZWFmcmVm KFNlZSBhdHRhY2hlZCk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIG9wdGlvbnMgKDIp IGFuZCAoMykgdXNlIGl0cyBvd24gbW9kZWwgc3RydWN0dXJlIGFuZCBkb2VzbuKAmXQgZm9sbG93 IExJTUUgbW9kZWwgc3RydWN0dXJlIGNvbXBsZXRlbHksIGFsc28gSW4gb3B0aW9uICgzKSwgaXQg aXMgY2hhbGxlbmdlIG9yDQogbm90IGVhc3kgdG8gcmVwcmVzZW50IHNvbWUgZGF0YSBub2RlcyBp biBCRkQgbW9kZWwgdXNpbmcgbGVhZnJlZiB0eXBlIGRlZmluZWQgaW4gTElNRS4gVGhlcmVmb3Jl IE9wdGlvbigxKSBpcyBwZXJmZWN0IGlmIEJGRCBmb2xsb3dzIExJTUUgbW9kZWw8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIEJG RCBtb2RlIGRvZXNu4oCZdCB3YW50IHRvIGZvbGxvdyB0aGUgd2hvbGUgTElNRSBtb2RlbCBzdHJ1 Y3R1cmUgb3Igb25seSBmb2xsb3cgc3Vic2V0IG9mIExJTUUgbW9kZWwgc3RydWN0dXJlIHdpdGgg c2Vzc2lvbiBsZXZlbCBhbmQgcGVyIGludGVyZmFjZQ0KIGxldmVsLCBJIHRoaW5rIEJGRCBtb2Rl bCBzaG91bGQgYmUgZGV2ZWxvcGVkIGFzIHN0YW5kYWxvbmUgdGVjaG5vbG9neSBpbmRlcGVuZGVu dCBtb2RlbCBvciBnZW5lcmljIG1vZGVsIGFuZCBkZWNvdXBsZSBmcm9tIHJvdXRpbmctY2ZnIG1v ZGVsLCB3ZSBzaG91bGQgYWdyZWUgaXQgaXMgcG9zc2libGUgdG8gaGF2ZSB0d28gZ2VuZXJpYyBt b2RlbHMuIHdoZW4gd2Ugd2FudCB0byB0cmFuc2xhdGUgZ2VuZXJpYyBCRkQgbW9kZWwgaW50byBn ZW5lcmljDQogTElNRSBtb2RlbCwgaXQgc2VlbXMgbW91bnQgcG9pbnQgcHJvcG9zYWwgY2FuIGJl IHVzZWQgdG8gbW92ZSBCRkQgZGF0YSBub2RlcyB0byBMSU1FIG1vZGVsIHN0cnVjdHVyZShpLmUu LCBtb3Zpbmcgc2Vzc2lvbi1jZmcgZnJvbSBiZmQgbW9kZWwgdG8gc2Vzc2lvbi1jZmcgaW4gTElN RSBtb2RlbCwgbW92aW5nIGludGVyZmFjZS1jZmcgZnJvbSBiZmQgbW9kZWwgdG8gaW50ZXJmYWNl LWNmZyBpbiB0aGUgTElNRSBtb2RlbC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYW0gZXhwZWN0aW5nIHRvIHRhbGsgd2l0aCBN YWhlc2ggYWJvdXQgdGhlc2Ugb3B0aW9ucy4gSG9wZWZ1bGx5IHdlIGNhbiBjb252ZXJnZSBkaXNj dXNzaW9uIHNvb24uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4tUWluPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Q2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQogWzxh IGhyZWY9Im1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPm1haWx0bzpjcGlnbmF0YUBjaXNjby5jb208L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwv c3Bhbj48L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjIwMTU8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj45PC9z cGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj43PC9zcGFuPuaXpTxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj4xMDo0MDxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5n PSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PlFpbiBXdTxicj4NCjwvc3Bhbj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48 L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPk1haGVzaCBKZXRoYW5hbmRh bmk7IERlZXBhayBLdW1hciAoZGVrdW1hcik7IHdhbmd6aXRhbzsgUm9uYWxkIFAuIEJvbmljYTxi cj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPkZ3ZDogUmVsYXRpb25zaGlwIGJldHdlZW4g QkZEIG1vZGVsIGFuZCBMSU1FIGJhc2UgbW9kZWw8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5RaW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBpcyBhIGdyZWF0IG1lc3NhZ2Us IGFuZCBJIGFwcHJlY2lhdGUgdGhlIGRpc2N1c3Npb24gYW5kIHNlZWtpbmcgcGF0aCBmb3J3YXJk IHdpdGggdGhlIEJGRCBtb2RlbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgaGF2ZSBub3Qgc2Vl biBhIHJlc3BvbnNlIHRvIHRoaXMgbWVzc2FnZSwgaG93ZXZlci48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPk1heWJlIHlvdSBjb3VsZCBoYXZlIHRoaXMgZGlzY3Vzc2lvbiB3aXRoIGEgYnJvYWRlciBh dWRpZW5jZSwgaW5jbHVkaW5nIHRoZSBMSU1FIGxpc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5U aGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPuKAlDxzcGFuIGxhbmc9IkVOLVVTIj4gQ2FybG9zLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5CZWdpbiBmb3J3YXJkZWQgbWVzc2FnZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5RaW4gV3UgJmx0OzxhIGhyZWY9Im1haWx0bzpiaWxsLnd1 QGh1YXdlaS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmJpbGwud3VAaHVhd2VpLmNv bTwvc3Bhbj48L2E+Jmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U3ViamVjdDogUmVsYXRpb25zaGlwIGJl dHdlZW4gQkZEIG1vZGVsIGFuZCBMSU1FIGJhc2UgbW9kZWw8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5E YXRlOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkF1Z3VzdCAyOSwgMjAxNSBhdCA1OjEz OjU5IEFNIEVEVDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VG86PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+TWFoZXNoIEpldGhhbmFuZGFuaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlA Z21haWwuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tamV0aGFuYW5kYW5pQGdtYWls LmNvbTwvc3Bhbj48L2E+Jmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q2M6PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+JnF1b3Q7RGVlcGFrIEt1bWFyIChkZWt1bWFyKSZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmRla3VtYXJAY2lzY28uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5k ZWt1bWFyQGNpc2NvLmNvbTwvc3Bhbj48L2E+Jmd0OywNCiB3YW5neml0YW8gJmx0OzxhIGhyZWY9 Im1haWx0bzp3YW5neml0YW9AaHVhd2VpLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ d2FuZ3ppdGFvQGh1YXdlaS5jb208L3NwYW4+PC9hPiZndDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFs aWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGksIE1haGVzaDo8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TElNRSBtb2RlbCBoYXZlIGZpdmUg bGV2ZWwgcGFyYW1ldGVyczo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVv Z3JhcGg7dGV4dC1pbmRlbnQ6LTE4LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4xLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TUQNCiBsZXZlbCBwYXJhbWV0ZXJzPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i dGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGg7dGV4dC1pbmRl bnQ6LTE4LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4y Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+TUENCiBsZXZlbCBwYXJhbWV0ZXJzPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1s ZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0 aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGg7dGV4dC1pbmRlbnQ6LTE4LjBwdCI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4zLjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ TUVQDQogbGV2ZWwgcGFyYW1ldGVyczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3Rp Znk6aW50ZXItaWRlb2dyYXBoO3RleHQtaW5kZW50Oi0xOC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+NC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNlc3Npb24NCiBsZXZl bCBwYXJhbWV0ZXJzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1p ZGVvZ3JhcGg7dGV4dC1pbmRlbnQ6LTE4LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij41Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SW50ZXJmYWNlDQogbGV2ZWwgcGFyYW1l dGVyczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQt anVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPk1EIGxldmVsIHBhcmFtZXRlcnMsIE1BIGxldmVsIHBhcmFtZXRlcnMgY2FuIGJl IGRpcmVjdGx5IGluaGVyaXRlZCBpbiB0aGUgTElNRSBiYXNlIG1vZGVsIGV4dGVuc2lvbiBhbmQN CiBzZXQgYXMgZGVmYXVsdCB2YWx1ZSw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1 c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZS5nLCBkb21haW4gbmFtZSBpbiB0aGUgTUEgbGV2ZWwgY2Fu IGJlIHNldCB0byBBUyBOdW1iZXIsIEFyZWEgSUQsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1h bGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkxJTUUgYmFzZSBtb2RlbCBjYW4gcHJvdmlkZSBm bGV4aWJsZSBzdHJ1Y3R1cmUgZm9yIEJGRCBhbmQgb3RoZXIgT0FNIHRlY2hub2xvZ3kuPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFs aWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4 dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhlcmUgd2UgZ2l2ZSBhbiBleGFtcGxlIGhv dyBMSU1FIGJhc2UgbW9kZWwgY2FuIGJlIGV4dGVuZGVkIHRvIHN1cHBvcnQgQkZEIChTZWUgYXR0 YWNoZWQpLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3Rp Znk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5XZSBtb2RlbCB0aGUgc2FtZSBwYXJhbWV0ZXIgcHJvcG9zZWQgaW4gZHJhZnQtemhlbmct YmZkLXlhbmctMDQgdXNpbmcgbXVsdGlwbGUgbGV2ZWwgc3RydWN0dXJlIGRlZmluZWQNCiBieSBM SU1FIGJhc2UgbW9kZWwsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3Rl eHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPmJmZC1zZXNzaW9uLWNmZyBkZWZpbmVkIGluIGRyYWZ0LXpoZW5nLWJmZC15 YW5nLTA0IGNhbiBiZSB3ZWxsIGdyYWZ0ZWQgaW50byBzZXNzaW9uIGxldmVsIHN0cnVjdHVyZSBk ZWZpbmVkDQogaW4gTElNRSBiYXNlIG1vZGVsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGln bjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmJmZC1pbnRlcmZhY2UtY2ZnIGRlZmluZWQgaW4gZHJh ZnQtemhlbmctYmZkLXlhbmctMDQgY2FuIGJlIHdlbGwgZ3JhZnRlZCBpbnRvIGludGVyZmFjZSBs ZXZlbCBzdHJ1Y3R1cmUNCiBkZWZpbmUgaW4gTElNRSBiYXNlIG1vZGVsLjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFw aCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIG5vdGlmaWNh dGlvbiwgTElNRSBiYXNlIG1vZGVsIG9ubHkgcHJvdmlkZSBkZWZlY3Qgbm90aWZpY2F0aW9uIGRl ZmluaXRpb24sIGRvZXNu4oCZdCBwcm92aWRlIHN0YXRlLWNoYW5nZQ0KIG5vdGlmaWNhdGlvbiwg c28gbmV3IHN0YXRlLWNoYW5nZSBub3RpZmljYXRpb24gY2FuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i dGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkJlIGRlZmluZWQgaW4gdGhlIEJGRCBt b2RlbCw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5 OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Rm9yIG9wZXJhdGlvbiBzdGF0ZSwgTElNRSBiYXNlIG1vZGVsIGRvZXNu4oCZdCBwcm92aWRl IHNlcGFyYXRlIHN0YXRlIGRhdGEgc3RydWN0dXJlIGZvciBvcGVyYXRpb24gc3RhdGUsDQogc28g bWF5YmUgQkZEIG1vZGVsIGNhbiBleHRlbmQgc3RhdGUgZGF0YSBzdHJ1Y3R1cmUgZGVmaW5lZCBp bjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50 ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5U aGUgYmFzZSBtb2RlbCBmb3Igcm91dGluZyBkZWZpbmVkIGluIGRyYWZ0LWlldGYtbmV0bW9kLXJv dXRpbmctY2ZnLTE5Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0 LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7 dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+SSBhbSBoYXBweSB0byBkaXNjdXNzIGlmIHlvdSBoYXZlIGFueSBxdWVz dGlvbnMuIEkgaG9wZSB3ZSBjYW4gY29tZSB0byBhZ3JlZW1lbnQgc29vbi48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3Jh cGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkgaGVhcmQgYWJv dXQgeW91ciBkaXNjdXNzaW9uIHdpdGggRGVlcGFrIGFib3V0IGhhcm1vbml6YXRpb24gb2YgQkZE IHdpdGggTElNRSwgT25lIHByb3Bvc2FsIGlzIHRvIGhhdmUNCiBCRkQgZ2VuZXJpYyBtb2RlbCBh bmQgTElNRSBnZW5lcmljIG1vZGVsIHNlcGFyYXRlbHksPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4 dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlN1cHBvcnQgYm90aDwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4vYmZkPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFuZDwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBo Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4vbGltZS9iZmQ8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlk ZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aWYgdGhl cmUgaXMgc3VjaCBjb25zZW5zdXMsIEkgYW0gaGFwcHkgdG8gYWNjZXB0IHRoaXMuIEkgYWxzbyB0 aGluayBpZiB3ZSBnbyB3aXRoIC9saW1lL2JmZCwgSSB0aGluaw0KIHdlIGNhbiBwcm92aWRlIGJl dHRlciBPQU0gbWFuYWdlbWVudCBhdXRvbWF0aW9uLCBvciBjb25zaXN0ZW50IHJlcG9ydGluZywg Y29uZmlndXJhdGlvbiwgcmVwcmVzZW50YXRpb24sIE1EIGxldmVsIHBhcmFtZXRlcnMgYW5kIE1B IGxldmVsIHBhcmFtZXRlcnMgYXJlIGp1c3QgbWFuYWdlbWVudCBpbmZvcm1hdGlvbiwgdGhleSBz aG91bGQgbm90IGJlIHRoZSBidXJkZW4gZm9yIEJGRCwgdGhlc2UgbWFuYWdlbWVudCBpbmZvcm1h dGlvbiBkb2VzbuKAmXQNCiBib3RoZXIgaG93IEJGRCB3b3JrKEJGRCBmdWN0aW9uIGRvZXNu4oCZ dCBuZWVkIHRvIGtub3cgYWJvdXQgaXQpLCBqdXN0IGhlbHAgZXN0YWJsaXNoIHRoZSB0ZXN0cG9p bnRzIHJlbGF0aW9uc2hpcCBvciBnbG9iYWwgdmlldyBvZiBPQU0gdG9wbyBieSBhc3NvY2lhdGlu ZyB0ZXN0IHBvaW50KE1FUCkgd2l0aCBNRCwgTUEgYW5kIG90aGVyIGNvbnRleHQgaW5mb3JtYXRp b24uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTpp bnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3Rp Znk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5SZWdhcmRzITwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0 LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4tUWluPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+Jmx0O2JmZC1sZWFmcmVmLWxpbWUudHh0Jmd0OyZsdDtiZmQtbGVhZnJl Zi1saW1lLnlhbmcmZ3Q7Jmx0O2RyYWZ0LXdhbmcteWFuZy1iZmQtb2FtLTA0LnR4dCZndDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5NYWhlc2ggSmV0aGFuYW5kYW5p PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRv Om1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B8F9A780D330094D99AF023C5877DABA848175ACnkgeml501mbschi_-- From nobody Fri Sep 11 11:40:53 2015 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 2441A1B49AA for ; Fri, 11 Sep 2015 11:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 WkuiGsEb1pjk for ; Fri, 11 Sep 2015 11:40:50 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 640A01B3514 for ; Fri, 11 Sep 2015 11:40:50 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 817A81E364; Fri, 11 Sep 2015 14:44:08 -0400 (EDT) Date: Fri, 11 Sep 2015 14:44:08 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: [nomcom-chair-2015@ietf.org: NomCom 2015: Second call for nominations] Message-ID: <20150911184408.GA5770@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.21 (2010-09-15) 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: Fri, 11 Sep 2015 18:40:52 -0000 ----- Forwarded message from NomCom Chair 2015 ----- Date: Fri, 11 Sep 2015 08:19:03 -0700 From: NomCom Chair 2015 To: IETF Announcement List Cc: wgchairs@ietf.org Subject: NomCom 2015: Second call for nominations This is the SECOND call for nominations for the 2015-2016 nomcom. The 2015-16 Nominating Committee (Nomcom) is seeking nominations from now until October 8, 2015. The open positions being considered by this year's Nomcom can be found at the end of this email and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2015/ Nominations may be made by selecting the Nominate link at the top of the Nomcom 2015 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2015/nominate/ {Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ } If you are unable to use the web form, nominations may instead be made by email to nomcom15@ietf.org. If using email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you are nominating someone other than yourself, please tell us if we may tell the nominee that you were the one who made the nomination. If you wish to nominate someone via email for more than one position, please use separate emails to do so. Self-nomination is welcome! NomCom 2015-16 will follow the policy for "Open Disclosure of Willing Nominees" described in BCP 10/RFC 7437. As stated in RFC 7437: "The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. Additionally, the nomination form asks if we may share your own name with the nominee. In all other ways, the confidentiality requirements of BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. The list of nominees who have accepted their nomination is visible at this link: https://datatracker.ietf.org/nomcom/2015/feedback/ There is a field on the form you can mark in order to allow the Nomcom to tell the nominee that you were the one who made the nomination. This is a new thing this year, and it defaults to “no” - we won’t tell. After the nomination cycle, we will evaluate the result of this and recommend whether the next Nomcom should do something different. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the Nomcom on or before October 8, 2015. Please submit your nominations as early as possible for the sake of your nominees. Note that nominations should not wait for management permission, as it is easier to decline the nomination than put one in late. We have set the questionnaire submission deadline for October 15, 2015. The Nomcom appoints individuals to fill the open slots on the IAOC, the IAB, and the IESG. The list of people and posts whose terms end with the March 2016 IETF meeting, and thus the positions for which this Nomcom is responsible, follows: IAB: * Mary Barnes * Joe Hildebrand * Ted Hardie * Erik Nordmark * Brian Trammell * Marc Blanchet IESG: - Alissa Cooper, ART - Barry Leiba, ART - Brian Haberman, Internet (*) - Benoit Claise, O&M - Alia Atlas, Routing - Kathleen Moriarty, Security - Martin Stiemerling, Transport (*) *- have indicated that they do not intend to accept a renomination. This information is always up to date on https://datatracker.ietf.org/nomcom/2015/ Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF, and also, please consider accepting a nomination. You'll find extensive information about specific positions, developed by the IAB, IESG, and IAOC, under individual tabs at: https://datatracker.ietf.org/nomcom/2015/requirements/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. Please send suggestions and feedback about this to nomcom15@ietf.org. Thank you for your help in identifying qualified nominees! Harald Alvestrand Nomcom Chair 2015-16 nomcom-chair-2015@ietf.org, hta+nomcom@alvestrand.no ----- End forwarded message ----- From nobody Mon Sep 14 02:36:31 2015 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 28B9F1B4217 for ; Mon, 14 Sep 2015 02:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.939 X-Spam-Level: * X-Spam-Status: No, score=1.939 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, J_BACKHAIR_25=1, J_CHICKENPOX_65=0.6, T_RP_MATCHES_RCVD=-0.01] 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 mqDaXBPdWq09 for ; Mon, 14 Sep 2015 02:36:27 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F8D1B3BFE for ; Mon, 14 Sep 2015 02:36:26 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id B53142AA0F; Mon, 14 Sep 2015 09:36:22 +0000 (GMT) Date: Mon, 14 Sep 2015 02:36:21 -0700 From: Marc Binderberger To: Vengada Prasad Govindan (venggovi) , Santosh P K Message-ID: <20150914023621783380.e60e074d@sniff.de> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D545D1911@xmb-rcd-x15.cisco.com> References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831F4941F@SJEXCHMB12.corp.ad.broadcom.com> <454798CB-8559-40C8-8714-B5B44D9A5921@gmail.com> <4A6CE49E6084B141B15C0713B8993F2831F4FEE1@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831F501BA@SJEXCHMB12.corp.ad.broadcom.com> <2279CC94-1E55-487E-9402-07D1055739F0@gmail.com> <315041E4211CB84E86EF7C25A2AB583D545D1911@xmb-rcd-x15.cisco.com> Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: base64 X-Mailer: GyazMail version 1.5.16 Archived-At: Cc: "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 09:36:30 -0000 SGVsbG8gU2FudG9zaCwgVmVuZ2FkYSBldCBhbC4sDQoNCnR1bmluZyBpbiBhIGJpdCBsYXRl IGJ1dCBuZXZlcnRoZWxlc3MgYW4gaW50ZXJlc3RpbmcgZGlzY3Vzc2lvbi4gQmVpbmcgc28g DQpsYXRlIEkgYWxtb3N0IGV4cGVjdCBhIHZlcnNpb24gLTAyIHNvb24gKD8pIDotKQ0KDQoN Ck1heSBJIGVuY291cmFnZSB0aGUgYXV0aG9ycyB0byBzdGljayB0byBCRkQncyBzaW1wbGlj aXR5LiBXaGlsZSBhbGwgdGhlIA0KY29tbWVudHMgSSd2ZSBzZWVuIGhhdmUgYSB2YWxpZCBw b2ludCBJIGRvIHRoaW5rIHRoZSBvcmlnaW5hbCBpZGVhIG9mIGEgDQpzaW1wbGUgdW5pY2Fz dCBhc3luY2hyb25vdXMgQkZEIGluc2lkZSBhIFZ4TEFOIFZOSSBpcyB2YWxpZC4NCg0KTm9i bydzIGlkZWEgb2YgQkZEIGVjaG8gb24gbGF5ZXItMiBpcyByZWFsbHkgbmljZSBhbmQgeW91 IHNob3VsZCBkZXNjcmliZSBpdCANCmluIHlvdXIgZG9jdW1lbnQgdG9vIC0gYXMgYW4gb3B0 aW9uLiBIb3cgdGhlIGxlYXJuaW5nIG1lY2hhbmlzbSByZWFjdHMgdG8gDQpzcmMtbWFjID09 IGRzdC1tYWMgYW5kIGlmIHRoZSBzaWxpY29uIGluIGEgc2VydmVyLU5JQyBzdXBwb3J0cyAN CmRlY2FwLWxvb2t1cC1lbmNhcCBzZWVtcyBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwgdG8g bWUsIHRodXMgd2h5IEkgd291bGQgZ28gDQpmb3Igb3B0aW9uYWwuDQoNCkZvciB0aGUgInNo b3J0Y29taW5ncyIgb2YgdGhlIHVuaWNhc3QgYXN5bmMgYXBwcm9hY2g6IHdlbGwsIGRpc2N1 c3MgdGhlbSBpbiANCnRoZSBkb2N1bWVudC4gSXQgbWF5IHdlbGwgYmUgdGhhdCBhbiBpbXBs ZW1lbnRhdGlvbiBjYW4gImluamVjdCIgdGhlIA0KQkZEK2V0aGVyLWZyYW1lIGludG8gdGhl IHNvdXJjZSBWVEVQIGhhcmR3YXJlL21lY2hhbmlzbSB0byBnbyB0aHJvdWdoIHRoZSANCndo b2xlIGxvb2t1cCtlbmNhcCwgaS5lLiB0aGUgQUMtPlZ4TEFOIGZvcndhcmRpbmcuIEp1c3Qg cHJvcG9zZSB0aGF0IGFuIA0KaW1wbGVtZW50YXRpb24gc2hvdWxkIGRvIHNvLiBTaW1pbGFy IG9uIHRoZSBkZWNhcHN1bGF0aW9uIHNpZGUsIGlmIHlvdXIgVlRFUCANCk1BQywgbG9jYWwg SVAgYW5kIEJGRCBleGlzdCBpbiBhIFZNIChlLmcuIE9wZW5Wc3dpdGNoKSB0aGVuIHRoZSBk ZWxpdmVyeSBtYXkgDQpiZSBubyBkaWZmZXJlbnQgZnJvbSB0aGUgZGVsaXZlcnkgb2YgYSBw YWNrZXQgdG8gdGhlIG90aGVyIChBcHBsaWNhdGlvbikgVk1zLiANCkFuZCBpZiB5b3VyIFZU RVAgaXMgYSBzd2l0Y2gvcm91dGVyIHRoZXJlIGlzIGFsd2F5cyB0aGUgb3B0aW9uIG9mIGEg bG9vcGJhY2sgDQpjYWJsZSB0byBwcm92aWRlIHRoZSB0cnVlIEFDPC0+VnhMQU4gZXhwZXJp ZW5jZSA6LSkgSnVzdCBtZW50aW9uIHRoaXMgYXMgYSANCmhpbnQgdG8gaW1wbGVtZW50b3Jz Lg0KDQpUaGUgaWRlYSB0byB1c2UgbXVsdGljYXN0IHBhY2tldHMgaXMgaW50ZXJlc3Rpbmcu IEkgd291bGQgc2VlIGl0IGFzIGFuIA0KYWRkaXRpb25hbCBjaGVjayBhcyB1bmljYXN0IGFu ZCBtdWx0aWNhc3QgbWF5IHVzZSBkaWZmZXJlbnQgcGFja2V0IHBhdGggaW4gDQpoYXJkd2Fy ZS9zb2Z0d2FyZSwgbm90IGFzIGEgcmVwbGFjZW1lbnQgZm9yIHVuaWNhc3QgVnhMQU4gQkZE IGJ1dCBJIG1heSBiZSANCndyb25nLg0KDQoNCkZvciB0aGUgZG9jdW1lbnQsIHlvdSBhcmUg YSBiaXQgc2hvcnQgb24gdGhlIG1vdGl2YXRpb24gc2lkZSwgSU1ITy4gU2F5aW5nIA0KIk1h aW4gdXNlIGNhc2Ugb2YgQkZEIGZvciBWWExBTiBpcyBmb3IgdHVubmVsIGNvbm5lY3Rpdml0 eSBjaGVjay4gVGhlcmUgYXJlIA0Kb3RoZXIgdXNlIGNhc2VzIHN1Y2ggYXMgWy4uLl0iIGFu ZCB0aGVuIHNheWluZyBtb3JlIGFib3V0IHRoZSBvdGhlciB1c2UgY2FzZXMgDQp0aGFuIHlv dXIgbWFpbiBjYXNlIGlzIGEgYml0IG9kZCA7LSkNCg0KDQpUaGFua3MgJiBSZWdhcmRzLA0K TWFyYw0KDQoNCg0KDQpPbiBTYXQsIDE4IEp1bCAyMDE1IDAxOjI5OjE0ICswMDAwLCBWZW5n YWRhIFByYXNhZCBHb3ZpbmRhbiAodmVuZ2dvdmkpIHdyb3RlOg0KPiBIZWxsbyBOb2JvLA0K PiAgIFdoaWxlIEkgZG8gYWdyZWUgdGhhdCB0aGVyZSBjb3VsZCBiZSB2YWx1ZSBpbiBnZXR0 aW5nIGEgc2VsZi1kZXN0aW5lZCANCj4gcGFja2V0IGVuY2Fwc3VsYXRlZCBpbiBWeExBTiBh cyB5b3UgZGVzY3JpYmUgYmVsb3csIHRoZSBkYXRhcGF0aCBmbG93IG9mIA0KPiBWeExBTiBk ZWNhcCBmb2xsb3dlZCBieSBhIEwyIGxvb2t1cCBhbmQgYSBWeExBTiAocmUpZW5jYXAgaXMg bm90IHN1cHBvcnRlZCANCj4gb24gbW9zdCBzaWxpY29uIChTaGFocmFtLCBwbGVhc2UgY29y cmVjdCBtZSBpZiBJIGFtIHdyb25nIGhlcmUpIGFuZCBoZW5jZSANCj4gZGlmZmljdWx0IHRv IGltcGxlbWVudC4gSW5zdGVhZCBhIFZ4TEFOIEFzeW5jIGlzIHdoYXQgaXMgcHJvcG9zZWQg aW4gdGhlIA0KPiBkcmFmdC4NCj4gVGhhbmtzDQo+IFByYXNhZA0KPiAgDQo+IEZyb206IFJ0 Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBO b2JvIEFraXlhDQo+IFNlbnQ6IEZyaWRheSwgSnVseSAxNywgMjAxNSA2OjI1IFBNDQo+IFRv OiBTYW50b3NoIFAgSw0KPiBDYzogUmVzaGFkIFJhaG1hbiAocnJhaG1hbik7IHJ0Zy1iZmRA aWV0Zi5vcmc7IFMuIERhdmFyaQ0KPiBTdWJqZWN0OiBSZTogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1zcGFsbGFnYXR0aS1iZmQtdnhsYW4tMDAudHh0DQo+ICANCj4g SGkgU2FudG9zaCwNCj4gIA0KPiBFc3NlbnRpYWxseSB0aGUgc2VuZGVyIGNhbiBwZXJpb2Rp Y2FsbHkgc2VuZCBzZWxmLWRlc3RpbmVkIHBhY2tldHMgKE1BQy1EQSANCj4gPSBzZW5kZXIg VlRFUCkgdGhhdCBnZXRzIGxvb3BlZCBiYWNrIG9uIHRoZSByZW1vdGUgVlRFUCAodGhpcyBi ZXR0ZXIgDQo+IGV4ZXJjaXNlcyB0aGUgVk5JIGZvcndhcmRpbmcgb24gdGhlIHJlbW90ZSBW VEVQKS4gU2ltaWxhciBjb25jZXB0IGFzIEJGRCANCj4gZWNoby4NCj4gIA0KPiBUaGFua3Mh DQo+ICANCj4gLU5vYm8NCj4gIA0KPiBPbiBGcmksIEp1bCAxMCwgMjAxNSBhdCAxMTowMSBQ TSwgU2FudG9zaCBQIEsgPHNhbnRvc2hwa0BqdW5pcGVyLm5ldD4gd3JvdGU6DQo+PiBOb2Jv IGFuZCBTaGFycmFtLA0KPj4gICAgICBJIGFtIGJpdCBjb25mdXNlZCBkaWQgeW91IG1lYW4g TUFDLURBIG9mIHRoZSByZWNlaXZlciBWVEVQPyBIb3cgd291bGQgDQo+PiBzZW5kZXIgVlRF UCBzb2x2ZSB0aGUgcHJvYmxlbT8gDQo+PiAgDQo+PiAgDQo+PiBUaGFua3MNCj4+IFNhbnRv c2ggUCBLIA0KPj4gIA0KPj4gRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFMuIERhdmFyaQ0KPj4gU2VudDogRnJpZGF5LCBK dWx5IDEwLCAyMDE1IDY6NTIgUE0NCj4+IFRvOiBOb2JvIEFraXlhDQo+PiBDYzogUmVzaGFk IFJhaG1hbiAocnJhaG1hbik7IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4+IA0KPj4gU3ViamVjdDog UmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+PiBkcmFmdC1zcGFsbGFnYXR0 aS1iZmQtdnhsYW4tMDAudHh0DQo+PiAgDQo+PiBZZXMgdGhhdCBpcyB0aGUgc29sdXRpb24u DQo+PiANCj4+IFJlZ2FyZHMsDQo+PiBTaGFocmFtDQo+PiAgDQo+PiANCj4+IE9uIEp1bCAx MCwgMjAxNSwgYXQgMTI6MTIgQU0sIE5vYm8gQWtpeWEgPG5vYm8uYWtpeWEuZGV2QGdtYWls LmNvbT4gd3JvdGU6DQo+Pj4gTG9uZyBhbmQgaW50ZXJlc3RpbmcgdGhyZWFkIDopDQo+Pj4g IA0KPj4+IEhvdyBhYm91dCBzZXR0aW5nIHRoZSBNQUMtREEgYXMgdGhlIE1BQyBvZiB0aGUg c2VuZGVyIFZURVA/DQo+Pj4gIA0KPj4+IFRoYW5rcyENCj4+PiAgDQo+Pj4gLU5vYm8NCj4+ PiAgDQo+Pj4gT24gRnJpLCBKdWwgMywgMjAxNSBhdCA1OjM5IEFNLCBTaGFocmFtIERhdmFy aSA8ZGF2YXJpQGJyb2FkY29tLmNvbT4gDQo+Pj4gd3JvdGU6DQo+Pj4+IFN1cmUuDQo+Pj4+ ICANCj4+Pj4gRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIFNoYWhyYW0gDQo+Pj4+IERhdmFyaQ0KPj4+PiBTZW50OiBUaHVy c2RheSwgSnVseSAwMiwgMjAxNSAxMTo1OCBBTQ0KPj4+PiBUbzogUmVzaGFkIFJhaG1hbiAo cnJhaG1hbik7IFNoYWhyYW0gRGF2YXJpDQo+Pj4+IENjOiBydGctYmZkQGlldGYub3JnDQo+ Pj4+IFN1YmplY3Q6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KPj4+PiBk cmFmdC1zcGFsbGFnYXR0aS1iZmQtdnhsYW4tMDAudHh0DQo+Pj4+ICANCj4+Pj4gQWdyZWUu IEJ1dCB3ZSBjYW4gbWF5IGJlIGNvbWUgdXAgd2l0aCBhIG1vcmUgZWZmaWNpZW50IHNvbHV0 aW9uLg0KPj4+PiAgDQo+Pj4+IFRoeA0KPj4+PiBTRA0KPj4+PiAgDQo+Pj4+IEZyb206IFJ0 Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBS ZXNoYWQgDQo+Pj4+IFJhaG1hbiAocnJhaG1hbikNCj4+Pj4gU2VudDogVGh1cnNkYXksIEp1 bHkgMDIsIDIwMTUgNTo0NiBBTQ0KPj4+PiBUbzogU2hhaHJhbSBEYXZhcmkNCj4+Pj4gQ2M6 IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4+Pj4gU3ViamVjdDogUmU6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgDQo+Pj4+IGRyYWZ0LXNwYWxsYWdhdHRpLWJmZC12eGxhbi0wMC50eHQN Cj4+Pj4gIA0KPj4+PiBIaSBTaGFocmFtLA0KPj4+PiAgDQo+Pj4+IEFncmVlZC4gTXkgcG9p bnQgaXMgdGhhdCBydW5uaW5nIEJGRCBvbiB0aGUgdHVubmVsIGlzIG5vdCBnb29kIGVub3Vn aCANCj4+Pj4gZm9yIHNvbWUgZmFpbHVyZXMuDQo+Pj4+ICANCj4+Pj4gUmVnYXJkcywNCj4+ Pj4gUmVzaGFkLiANCj4+Pj4gDQo+Pj4+ICANCj4+Pj4gIA0KPj4+PiBGcm9tOiBSdGctYmZk IDxydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBTaGFocmFtIERhdmFy aSANCj4+Pj4gPHJlYWxlc3RhdGUuZGF2YXJpQGdtYWlsLmNvbT4NCj4+Pj4gRGF0ZTogVGh1 cnNkYXksIEp1bHkgMiwgMjAxNSBhdCAxMjoyNSBBTQ0KPj4+PiBUbzogUmVzaGFkIDxycmFo bWFuQGNpc2NvLmNvbT4NCj4+Pj4gQ2M6IFNoYWhyYW0gRGF2YXJpIDxyZWFsZXN0YXRlLmRh dmFyaUBnbWFpbC5jb20+LCAicnRnLWJmZEBpZXRmLm9yZyIgDQo+Pj4+IDxydGctYmZkQGll dGYub3JnPg0KPj4+PiBTdWJqZWN0OiBSZTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciANCj4+Pj4gZHJhZnQtc3BhbGxhZ2F0dGktYmZkLXZ4bGFuLTAwLnR4dA0KPj4+PiAgDQo+ Pj4+IEhpIFJlc2hhZCwgDQo+Pj4+ICANCj4+Pj4gWW91IGRvbqJ0IG5lZWQgdG8gcnVuIGNv bnRpbnVvdXMgIEJGRCBzZXNzaW9uIHBlciBWTkkgdG8gZGV0ZWN0IFVEUCBwb3J0IA0KPj4+ PiBjb25maWd1cmF0aW9uIGlzc3VlLiBUbyBqdXN0aWZ5IHJ1bm5pbmcgQkZEIHBlciBWTkks IG9uZSBuZWVkcyB0byBzaG93IA0KPj4+PiB0aGF0IHRoZSBmb3J3YXJkaW5nIG9mIGVhY2gg b2YgdGhvc2UgQkZEIHNlc3Npb25zIGRlcGVuZHMgb24gc3BlY2lmaWMgDQo+Pj4+IFZOSSB2 YWx1ZS4gICANCj4+Pj4gIA0KPj4+PiBUaHgNCj4+Pj4gU2hhaHJhbQ0KPj4+PiAgDQo+Pj4+ PiBPbiBKdWwgMSwgMjAxNSwgYXQgNjoyMiBQTSwgUmVzaGFkIFJhaG1hbiAocnJhaG1hbikg PHJyYWhtYW5AY2lzY28uY29tPiANCj4+Pj4+IHdyb3RlOg0KPj4+Pj4gIA0KPj4+Pj4gSGkg U2hhaHJhbSwNCj4+Pj4+ICANCj4+Pj4+IEkgYWdyZWUgdGhhdCBydW5uaW5nIEJGRCBiZXR3 ZWVuIFZURVBzIHBlciBWTkkgbWlnaHQgbm90IHNjYWxlIHdlbGwuIA0KPj4+Pj4gQnV0IGJ5 IGp1c3QgcnVubmluZyBCRkQgb24gdGhlIElQIHR1bm5lbCBJTU8geW91IHdvbqJ0IGRldGVj dCBjZXJ0YWluIA0KPj4+Pj4gcHJvYmxlbXMsIG1heWJlIGh5cG90aGV0aWNhbCwgc3VjaCBh cyB0aGUgVURQIHBvcnQgYmVpbmcgYmxvY2tlZCAoZS5nLiANCj4+Pj4+IER1ZSB0byBhIG1p c2NvbmZpZ3VyZWQgQUNMKS4NCj4+Pj4+ICANCj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+PiBSZXNo YWQuDQo+Pj4+PiAgDQo+Pj4+PiBGcm9tOiBSdGctYmZkIDxydGctYmZkLWJvdW5jZXNAaWV0 Zi5vcmc+IG9uIGJlaGFsZiBvZiBTaGFocmFtIERhdmFyaSANCj4+Pj4+IDxkYXZhcmlAYnJv YWRjb20uY29tPg0KPj4+Pj4gRGF0ZTogVHVlc2RheSwgSnVuZSAzMCwgMjAxNSBhdCA5OjI0 IFBNDQo+Pj4+PiBUbzogU2FudG9zaCBQIEsgPHNhbnRvc2hwa0BqdW5pcGVyLm5ldD4sICJT LiBEYXZhcmkiIA0KPj4+Pj4gPHJlYWxlc3RhdGUuZGF2YXJpQGdtYWlsLmNvbT4sICJydGct YmZkQGlldGYub3JnIiA8cnRnLWJmZEBpZXRmLm9yZz4NCj4+Pj4+IFN1YmplY3Q6IFJFOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KPj4+Pj4gZHJhZnQtc3BhbGxhZ2F0dGkt YmZkLXZ4bGFuLTAwLnR4dA0KPj4+Pj4gIA0KPj4+Pj4gU2FudG9zaCwNCj4+Pj4+ICANCj4+ Pj4+IElzIHRoZSBCRkQgeW91ICBhcmUgZGVzY3JpYmluZyBpbiB5b3VyIGRyYWZ0IHVuaWNh c3Qgb3IgbXVsdGljYXN0PyBJZiANCj4+Pj4+IHVuaWNhc3QgdGhlbiBzZXJ2aWNlIG5vZGVz IHdvdWxkIG5vdCBhcHBseS4NCj4+Pj4+ICANCj4+Pj4+IEFsc28gaWYgdGhlcmUgaXMgYSBz ZXJ2aWNlIG5vZGUgdGhlbiBvbmUgY2FuIHJ1biBCRkQgb24gdGhlIElQIHR1bm5lbCANCj4+ Pj4+IGJldHdlZW4gc291cmNlIFZURVAgYW5kIHNlcnZpY2Ugbm9kZSBhbmQgYmV0d2VlbiBz ZXJ2aWNlIG5vZGUgYW5kIHRoZSANCj4+Pj4+IGRlc3RpbmF0aW9uIFZURVAuIFRoaXMgaXMg bXVjaCBtb3JlIHNjYWxhYmxlIHRoYW4gcnVubmluZyBlbmQtdG8tZW5kIA0KPj4+Pj4gQkZE IGJldHdlZW4gVlRFUHMgcGVyIFZOSS4gWW91IGNvdWxkIGV2ZW4gdXNlIHN1Y2ggQkZEIHRv IHN3aXRjaCB0byBhIA0KPj4+Pj4gYmFja3VwIHNlcnZpY2Ugbm9kZSBpZiB0aGVyZSBpcyBm YWlsdXJlIHRvIHRoZSBtYWluIHNlcnZpY2Ugbm9kZS4NCj4+Pj4+ICANCj4+Pj4+IFRoeA0K Pj4+Pj4gU2hhaHJhbQ0KPj4+Pj4gIA0KPj4+Pj4gRnJvbTogU2FudG9zaCBQIEsgW21haWx0 bzpzYW50b3NocGtAanVuaXBlci5uZXRdIA0KPj4+Pj4gU2VudDogVHVlc2RheSwgSnVuZSAz MCwgMjAxNSAyOjE0IEFNDQo+Pj4+PiBUbzogUy4gRGF2YXJpOyBTaGFocmFtIERhdmFyaTsg cnRnLWJmZEBpZXRmLm9yZw0KPj4+Pj4gU3ViamVjdDogUkU6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgDQo+Pj4+PiBkcmFmdC1zcGFsbGFnYXR0aS1iZmQtdnhsYW4tMDAudHh0 DQo+Pj4+PiAgDQo+Pj4+PiBUaGVyZSBjYW4gYmUgZmV3IFZURVBzIHdobyBtaWdodCBoYXZl IGNhcGFiaWxpdGllcyB0byBtdWx0aWNhc3QgdGhlIA0KPj4+Pj4gcGFja2V0LiBJbiBzdWNo IGEgc2NlbmFyaW8gVlRFUCB3aWxsIHNlbmQgdGhhdCBwYWNrZXQgdG8gc2VydmljZSBub2Rl IA0KPj4+Pj4gYW5kIHNlcnZpY2Ugbm9kZSB3aWxsIGRvIGEgbXVsdGljYXN0IG9uIGl0cyBi ZWhhbGYuIA0KPj4+Pj4gIA0KPj4+Pj4gIA0KPj4+Pj4gVGhhbmtzDQo+Pj4+PiBTYW50b3No IFAgSw0KPj4+Pj4gIA0KPj4+Pj4gRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFMuIERhdmFyaQ0KPj4+Pj4gU2VudDogTW9u ZGF5LCBKdW5lIDI5LCAyMDE1IDEwOjQ4IEFNDQo+Pj4+PiBUbzogU2hhaHJhbSBEYXZhcmk7 IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4+Pj4+IFN1YmplY3Q6IFJlOiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIA0KPj4+Pj4gZHJhZnQtc3BhbGxhZ2F0dGktYmZkLXZ4bGFuLTAwLnR4 dA0KPj4+Pj4gIA0KPj4+Pj4gSGkNCj4+Pj4+ICANCj4+Pj4+IFdoYXQgaXMgYSBzZXJ2aWNl IG5vZGU/DQo+Pj4+PiAgDQo+Pj4+PiBUaHgNCj4+Pj4+ICANCj4+Pj4+IFNkDQo+Pj4+PiAg DQo+Pj4+PiAgDQo+Pj4+Pj4gSGkgUHJhc2FkICwNCj4+Pj4+PiANCj4+Pj4+PiBJIGRvbid0 IHNlZSBob3cgeW91IGdldCBtb3JlIGNvdmVyYWdlIGhhdmluZyBhIFZYTEFOIHRhZy4gDQo+ Pj4+Pj4gDQo+Pj4+Pj4gU2luY2UgeW91IGFyZSBub3QgdGVzdGluZyB0aGUgVlhMQU4gYmFz ZWQgVkZJL1ZSRiBmb3J3YXJkaW5nLiBCeSB0aGF0IA0KPj4+Pj4+IEkgbWVhbiB5b3UgYXJl IG5vdCB0ZXN0aW5nIChEQSwgVlhMQU4gKSBvciAoRElQLCBWWExBTikgZm9yd2FyZGluZy4N Cj4+Pj4+PiBHVlAxPiBPbmUgb2YgdGhlIGFzcGVjdHMgb2YgdGhlIG5leHQgdmVyc2lvbiBv ZiB0aGUgZHJhZnQgd2lsbCBoYXZlIGEgDQo+Pj4+Pj4gdmFsaWQgaW5uZXIgRElQIGluc3Rl YWQgb2YgMTI3LzguIFRoaXMgc2hvdWxkIGhlbHAgYWRkcmVzcyB5b3VyIA0KPj4+Pj4+IGNv bmNlcm4gdG8gYW4gZXh0ZW50Lg0KPj4+Pj4+IEFsc28geW91IGFyZSBub3QgdGVzdGluZyB0 aGUgbWFwcGluZyBmcm9tIEFDIChBdHRhY2htZW50IENpcmN1aXQpIHRvIGEgDQo+Pj4+Pj4g VlhMQU4gdGFnLiANCj4+Pj4+PiBHVlAxPiBBZ3JlZWQsIHRoaXMgYXNwZWN0IGhhcyBub3Qg KHlldCkgYmVlbiBhZGRyZXNzZWQgYnkgUkZDNTg4NCBhcyANCj4+Pj4+PiB3ZWxsLCBub3Qg dXNpbmcgaXQgYXMgYW4gZXhjdXNlIGJ1dCBJIGFtIGp1c3Qgbm90aW5nIHRoZSBwcmVjZWRl bnQgDQo+Pj4+Pj4gaGVyZS4NCj4+Pj4+PiANCj4+Pj4+PiBJbiBteSBvcGluaW9uIGFsbCB5 b3UgYXJlIHRlc3RpbmcsIGlzIHRoYXQgYXQgdGhlIG90aGVyIGVuZCBvZiBhbiBJUCANCj4+ Pj4+PiBUdW5uZWwgYSBzcGVjaWZpYyBWWExBTiBleGlzdCBvciBub3QuIFdoaWNoIGRvZXMg bm90IHJlcXVpcmUgcnVubmluZyANCj4+Pj4+PiBjb250aW51b3VzIEJGRC4NCj4+Pj4+PiBH VlAxPiBUaGVyZSBhcmUgc3BlY2lmaWMgdXNlLWNhc2VzIChzZWUgbm90ZSBhYm91dCBTZXJ2 aWNlIE5vZGUgDQo+Pj4+Pj4gcmVhY2hhYmlsaXR5IGluIFNlYyAyIG9mIHRoZSBkcmFmdCkg dGhhdCByZXF1aXJlIGNvbnRpbnVvdXMgbW9uaXRvcmluZyANCj4+Pj4+PiBvZiBzb21lIHNw ZWNpYWwtcHVycG9zZSBWVEVQcy4NCj4+Pj4+PiANCj4+Pj4+PiBJbiBteSBvcGluaW9uIHRo aXMgaXMgYSB2ZXJ5IGluIGVmZmljaWVudCB3YXkgb2YgZ2V0dGluZyB0aGF0IA0KPj4+Pj4+ IGluZm9ybWF0aW9uLiBUaGUgY29udHJvbGxlciBzaG91bGQgYmUgYWJsZSB0byBnZXQgdGhp cyBpbmZvcm1hdGlvbiANCj4+Pj4+PiBtdWNoIG1vcmUgZWZmaWNpZW50bHkuIA0KPj4+Pj4+ IA0KPj4+Pj4+IEl0IHdvdWxkIGJlIGdvb2QgaWYgeW91IGNhbiBwcm92aWRlIGFuIGV4YW1w bGUgb2Ygd2hhdCB5b3UgdGhpbmsgaXMgDQo+Pj4+Pj4gbW9yZSBjb3ZlcmFnZSB0aGFuIEJG RC4gT3IgYXQgbGVhc3Qgd2hhdCBleHRyYSBjb3ZlcmFnZSBkbyB5b3UgZXhhY3RseSANCj4+ Pj4+PiBoYXZlIGluIG1pbmQsIHNpbmNlIHRoaXMgZHJhZnQgaXMgbm90IGNhcGFibGUgb2Yg bW9yZSBjb3ZlcmFnZSB0aGFuIA0KPj4+Pj4+IHN0YW5kYXJkIEJGRCBvdmVyIHRoZSBJUCB0 dW5uZWwuIA0KPj4+Pj4+IA0KPj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4gU2hhaHJhbQ0KPj4+ Pj4gUmVnYXJkcywNCj4+Pj4+IFNoYWhyYW0NCj4+Pj4+ICANCj4+Pj4+IA0KPj4+Pj4gT24g SnVuIDI3LCAyMDE1LCBhdCA3OjA2IEFNLCBTaGFocmFtIERhdmFyaSA8ZGF2YXJpQGJyb2Fk Y29tLmNvbT4gd3JvdGU6DQo+Pj4+Pj4gSGkgUHJhc2FkICwNCj4+Pj4+PiANCj4+Pj4+PiBJ IGRvbid0IHNlZSBob3cgeW91IGdldCBtb3JlIGNvdmVyYWdlIGhhdmluZyBhIFZYTEFOIHRh Zy4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gU2luY2UgeW91IGFyZSBub3QgdGVzdGluZyB0aGUgVlhM QU4gYmFzZWQgVkZJL1ZSRiBmb3J3YXJkaW5nLiBCeSB0aGF0IA0KPj4+Pj4+IEkgbWVhbiB5 b3UgYXJlIG5vdCB0ZXN0aW5nIChEQSwgVlhMQU4gKSBvciAoRElQLCBWWExBTikgZm9yd2Fy ZGluZy4NCj4+Pj4+PiBHVlAxPiBPbmUgb2YgdGhlIGFzcGVjdHMgb2YgdGhlIG5leHQgdmVy c2lvbiBvZiB0aGUgZHJhZnQgd2lsbCBoYXZlIGEgDQo+Pj4+Pj4gdmFsaWQgaW5uZXIgRElQ IGluc3RlYWQgb2YgMTI3LzguIFRoaXMgc2hvdWxkIGhlbHAgYWRkcmVzcyB5b3VyIA0KPj4+ Pj4+IGNvbmNlcm4gdG8gYW4gZXh0ZW50Lg0KPj4+Pj4+IEFsc28geW91IGFyZSBub3QgdGVz dGluZyB0aGUgbWFwcGluZyBmcm9tIEFDIChBdHRhY2htZW50IENpcmN1aXQpIHRvIGEgDQo+ Pj4+Pj4gVlhMQU4gdGFnLiANCj4+Pj4+PiBHVlAxPiBBZ3JlZWQsIHRoaXMgYXNwZWN0IGhh cyBub3QgKHlldCkgYmVlbiBhZGRyZXNzZWQgYnkgUkZDNTg4NCBhcyANCj4+Pj4+PiB3ZWxs LCBub3QgdXNpbmcgaXQgYXMgYW4gZXhjdXNlIGJ1dCBJIGFtIGp1c3Qgbm90aW5nIHRoZSBw cmVjZWRlbnQgDQo+Pj4+Pj4gaGVyZS4NCj4+Pj4+PiANCj4+Pj4+PiBJbiBteSBvcGluaW9u IGFsbCB5b3UgYXJlIHRlc3RpbmcsIGlzIHRoYXQgYXQgdGhlIG90aGVyIGVuZCBvZiBhbiBJ UCANCj4+Pj4+PiBUdW5uZWwgYSBzcGVjaWZpYyBWWExBTiBleGlzdCBvciBub3QuIFdoaWNo IGRvZXMgbm90IHJlcXVpcmUgcnVubmluZyANCj4+Pj4+PiBjb250aW51b3VzIEJGRC4NCj4+ Pj4+PiBHVlAxPiBUaGVyZSBhcmUgc3BlY2lmaWMgdXNlLWNhc2VzIChzZWUgbm90ZSBhYm91 dCBTZXJ2aWNlIE5vZGUgDQo+Pj4+Pj4gcmVhY2hhYmlsaXR5IGluIFNlYyAyIG9mIHRoZSBk cmFmdCkgdGhhdCByZXF1aXJlIGNvbnRpbnVvdXMgbW9uaXRvcmluZyANCj4+Pj4+PiBvZiBz b21lIHNwZWNpYWwtcHVycG9zZSBWVEVQcy4NCj4+Pj4+PiANCj4+Pj4+PiBJbiBteSBvcGlu aW9uIHRoaXMgaXMgYSB2ZXJ5IGluIGVmZmljaWVudCB3YXkgb2YgZ2V0dGluZyB0aGF0IA0K Pj4+Pj4+IGluZm9ybWF0aW9uLiBUaGUgY29udHJvbGxlciBzaG91bGQgYmUgYWJsZSB0byBn ZXQgdGhpcyBpbmZvcm1hdGlvbiANCj4+Pj4+PiBtdWNoIG1vcmUgZWZmaWNpZW50bHkuIA0K Pj4+Pj4+IA0KPj4+Pj4+IEl0IHdvdWxkIGJlIGdvb2QgaWYgeW91IGNhbiBwcm92aWRlIGFu IGV4YW1wbGUgb2Ygd2hhdCB5b3UgdGhpbmsgaXMgDQo+Pj4+Pj4gbW9yZSBjb3ZlcmFnZSB0 aGFuIEJGRC4gT3IgYXQgbGVhc3Qgd2hhdCBleHRyYSBjb3ZlcmFnZSBkbyB5b3UgZXhhY3Rs eSANCj4+Pj4+PiBoYXZlIGluIG1pbmQsIHNpbmNlIHRoaXMgZHJhZnQgaXMgbm90IGNhcGFi bGUgb2YgbW9yZSBjb3ZlcmFnZSB0aGFuIA0KPj4+Pj4+IHN0YW5kYXJkIEJGRCBvdmVyIHRo ZSBJUCB0dW5uZWwuIA0KPj4+Pj4+IA0KPj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4gU2hhaHJh bQ0KPj4+Pj4gDQo+Pj4+IA0KPj4+PiAgDQo+Pj4gDQo+Pj4gIA0KPj4gDQo+IA0KPiAg From nobody Fri Sep 18 10:39:54 2015 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 F310B1B2CB1 for ; Fri, 18 Sep 2015 10:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.321 X-Spam-Level: X-Spam-Status: No, score=0.321 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 o7-R0ES2xCkN for ; Fri, 18 Sep 2015 10:39:52 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 422B91B2CAD for ; Fri, 18 Sep 2015 10:39:52 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id CF4C01E367; Fri, 18 Sep 2015 13:43:20 -0400 (EDT) Date: Fri, 18 Sep 2015 13:43:20 -0400 From: Jeffrey Haas To: draft-ietf-bfd-mpls-mib@tools.ietf.org Subject: draft-ietf-bfd-mpls-mib-06 (was Re: Comments on draft-ietf-bfd-mpls-mib-05) Message-ID: <20150918174320.GA32318@pfrc.org> References: <20141230172539.GA25357@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141230172539.GA25357@pfrc> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 17:39:53 -0000 Authors of the BFD MPLS MIB, Thanks for addressing the majority of my comments during MIB review. Only a few items have remained without any response: - Splitting the TCs into IANA maintained modules. Do you intend to just wait until we have MIB doctor review and see if they require it? The other items are below and at least need reply. Beyond addressing these two items, what are the authors' beliefs about the state of the MIB? Ready for Last Call and/or MIB Doctor review? On Tue, Dec 30, 2014 at 12:25:39PM -0500, Jeffrey Haas wrote: > The bfdMplsSessPerfTable consists only of Counter32 objects. Practice > appears to use paired Counter64 "High Capacity" counters. Are these being > left out for any specific reason? > > One final comment is that no NOTIFICATIONs are defined for this MIB. While > not strictly required, an operator has no indication that a given > NOTIFICATION in the underlying RFC 7331 MIB is for sessions that may change > state for reasons having to do with underlying MPLS session association. > > One possibility that comes to mind to address this is to add a > recommendation that the bfdSessUp/bfdSessDown NOTIFICATIONS receive an > additional OBJECTS entry of bfdMplsSessMapPointer. The one obvious counter > to such a practice is this may disrupt the low/high range optimization in > the base NOTIFICATION. > > -- Jeff From nobody Fri Sep 18 11:07:33 2015 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 4F9161B2E33 for ; Fri, 18 Sep 2015 11:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.122 X-Spam-Level: * X-Spam-Status: No, score=1.122 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 N8JeH1YtBrvu for ; Fri, 18 Sep 2015 11:07:31 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BBF751B2E3F for ; Fri, 18 Sep 2015 11:07:31 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7A1EF1E382; Fri, 18 Sep 2015 14:11:00 -0400 (EDT) Date: Fri, 18 Sep 2015 14:11:00 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: BFD Multipoint documents - ready to progress? Message-ID: <20150918181100.GD32318@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) 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: Fri, 18 Sep 2015 18:07:32 -0000 The BFD multipoint documents, including the active-tail document, have been stable for a while. Are the documents ready to progress to WGLC? Any implementors of multipoint willing to say their implementations match the document? -- Jeff From nobody Fri Sep 18 13:42:07 2015 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 4B9581B3532 for ; Fri, 18 Sep 2015 13:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.321 X-Spam-Level: X-Spam-Status: No, score=0.321 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 r_LEnckZCcy9 for ; Fri, 18 Sep 2015 13:42:05 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 18F9D1B3533 for ; Fri, 18 Sep 2015 13:42:05 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id AF0701E382; Fri, 18 Sep 2015 16:45:33 -0400 (EDT) Date: Fri, 18 Sep 2015 16:45:33 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Working group status Message-ID: <20150918204533.GG32318@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) 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: Fri, 18 Sep 2015 20:42:06 -0000 The working group has been quiet. Certainly I've been a bit distracted, and Nobo even more so! I've taken this opportunity to prod a few document authors to move their work along. I've also spent some time updating the WG wiki with current perceived WG status. If you have a BFD document, please check the wiki and make sure the status seems correct. If your document is marked expired, then it means you're not pushing your proposal very hard! https://wiki.tools.ietf.org/wg/bfd/trac/wiki/WikiStart The multipoint documents, presuming the WG agrees, are likely to hit WGLC soon. Please review them and provide feedback. This is also a reminder that in terms of chartered work, the Yang module could use WG attention. The design team has done an excellent job getting us this far - help them get to the finish line. Finally, our need to do presentations at the upcoming IETF session in Yokohama will be based on *active* work with discussion on the mailing list. This means that now, in this quiet time between IETFs, is a perfect time to try to get the attention of your fellow BFD experts. -- Jeff From nobody Sat Sep 19 01:40:58 2015 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 C421B1A90CF for ; Sat, 19 Sep 2015 01:40:56 -0700 (PDT) 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 4XTOl4m7gEBF for ; Sat, 19 Sep 2015 01:40:55 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (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 9E9891A90C4 for ; Sat, 19 Sep 2015 01:40:54 -0700 (PDT) Received: by lbbvu2 with SMTP id vu2so34344034lbb.0 for ; Sat, 19 Sep 2015 01:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pl/PCr2HYizDLmnf3BQUs48jVyqIVaDpFmltfmxhA7M=; b=Iz9fEaxNBV0enqY8B01AtxCqt0EIT9xBfDEVJDWIupTD+S5hU9TeUyTZH93ZRgb9/P xTjlJzxRy28n8jUx6+SuZyTIO/gdiZfQQgxZ+F5lDXgV4zUgxqg1fvw4Kn1gd7RZjDYq rqf7HoZfGcI6b6wzxUHW2oOmKEEPsRX5cNDRaRNE6KtsHHUuFuD+Ga3KyRJjx/7HiOKB rLCyZjDuPalbxsXMQEkKYpC4JafNFEKXTurVcAFiIBcQxcSZC7j7cqCgWxgq7qK/YWx4 A+2oqQP56fn9e0aVxavk8hgdHInhlVDhBwB9RBNgX9GLhpEsgS0ZMqDJAL8ztEidv0xU fIEQ== MIME-Version: 1.0 X-Received: by 10.152.204.9 with SMTP id ku9mr4567447lac.51.1442652051866; Sat, 19 Sep 2015 01:40:51 -0700 (PDT) Received: by 10.25.22.94 with HTTP; Sat, 19 Sep 2015 01:40:51 -0700 (PDT) In-Reply-To: <20150918174320.GA32318@pfrc.org> References: <20141230172539.GA25357@pfrc> <20150918174320.GA32318@pfrc.org> Date: Sat, 19 Sep 2015 01:40:51 -0700 Message-ID: Subject: Re: draft-ietf-bfd-mpls-mib-06 (was Re: Comments on draft-ietf-bfd-mpls-mib-05) From: Venkatesan Mahalingam To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a1134386e160a2e0520159b42 Archived-At: Cc: "draft-ietf-bfd-mpls-mib@tools.ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 08:40:56 -0000 --001a1134386e160a2e0520159b42 Content-Type: text/plain; charset=UTF-8 Jeff, Thanks. Please see in-line my replies. -Venkat, On Fri, Sep 18, 2015 at 10:43 AM, Jeffrey Haas wrote: > Authors of the BFD MPLS MIB, > > Thanks for addressing the majority of my comments during MIB review. Only > a > few items have remained without any response: > > - Splitting the TCs into IANA maintained modules. Do you intend to just > wait until we have MIB doctor review and see if they require it? > Yes. > The other items are below and at least need reply. > > Beyond addressing these two items, what are the authors' beliefs about the > state of the MIB? Ready for Last Call and/or MIB Doctor review? > Yes, ready for Last Call, we'll fix the remaining comments as part of Last Call. > On Tue, Dec 30, 2014 at 12:25:39PM -0500, Jeffrey Haas wrote: > > The bfdMplsSessPerfTable consists only of Counter32 objects. Practice > > appears to use paired Counter64 "High Capacity" counters. Are these > being > > left out for any specific reason? > We dont expect a big counter value so, Counter32 is enough. > > One final comment is that no NOTIFICATIONs are defined for this MIB. > While > > not strictly required, an operator has no indication that a given > > NOTIFICATION in the underlying RFC 7331 MIB is for sessions that may > change > > state for reasons having to do with underlying MPLS session association. > As we augment the existing BFD Session MIB for MPLS, whatever notifications present in BFD session MIB will be applicable for MPLS BFD session also. > > One possibility that comes to mind to address this is to add a > > recommendation that the bfdSessUp/bfdSessDown NOTIFICATIONS receive an > > additional OBJECTS entry of bfdMplsSessMapPointer. The one obvious > counter > > to such a practice is this may disrupt the low/high range optimization in > > the base NOTIFICATION. > > > Do we really need an additional entry bfdMplsSessMapPointer in the notification? > > -- Jeff > --001a1134386e160a2e0520159b42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jeff,

Thanks.

= Please see in-line my replies.

-Venkat,

On Fri, Sep 18, 2015 at = 10:43 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
Authors of the BFD MPLS MIB,

Thanks for addressing the majority of my comments during MIB review.=C2=A0 = Only a
few items have remained without any response:

- Splitting the TCs into IANA maintained modules.=C2=A0 Do you intend to ju= st
=C2=A0 wait until we have MIB doctor review and see if they require it?
=
Yes.=C2=A0
The other items are below and at least need reply.

Beyond addressing these two items, what are the authors' beliefs about = the
state of the MIB?=C2=A0 Ready for Last Call and/or MIB Doctor review?
Yes, ready for Last Call, we'll fix the remaining comme= nts as part of Last Call.
=C2=A0
On Tue, Dec 30, 2014 at 12:25:39PM -0500, Jeffrey Haas wrote:
> The bfdMplsSessPerfTable consists only of Counter32 objects.=C2=A0 Pra= ctice
> appears to use paired Counter64 "High Capacity" counters.=C2= =A0 Are these being
> left out for any specific reason?
We dont expect = a big counter value so, Counter32 is enough.=C2=A0
> One final comment is that no NOTIFICATIONs are defined for this MIB.= =C2=A0 While
> not strictly required, an operator has no indication that a given
> NOTIFICATION in the underlying RFC 7331 MIB is for sessions that may c= hange
> state for reasons having to do with underlying MPLS session associatio= n.
As we augment the existing BFD Session MIB for MPLS= , whatever notifications present in BFD session MIB will be applicable for = MPLS BFD session also.
> One possibility that comes to mind to address this is to add a
> recommendation that the bfdSessUp/bfdSessDown NOTIFICATIONS receive an=
> additional OBJECTS entry of bfdMplsSessMapPointer.=C2=A0 The one obvio= us counter
> to such a practice is this may disrupt the low/high range optimization= in
> the base NOTIFICATION.
>
Do we really need an additional entry bfdMplsSess= MapPointer in the notification?
> -- Jeff

--001a1134386e160a2e0520159b42-- From nobody Sat Sep 19 03:28:32 2015 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 3F8F51ACDDA for ; Sat, 19 Sep 2015 03:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 DrskWlviudMp for ; Sat, 19 Sep 2015 03:28:29 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F501ACDD8 for ; Sat, 19 Sep 2015 03:28:28 -0700 (PDT) Received: from [192.168.0.102] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 77C0518014F3; Sat, 19 Sep 2015 12:28:26 +0200 (CEST) Subject: Re: Working group status To: Jeffrey Haas , rtg-bfd@ietf.org References: <20150918204533.GG32318@pfrc.org> From: Loa Andersson Message-ID: <55FD38C6.9010404@pi.nu> Date: Sat, 19 Sep 2015 12:28:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150918204533.GG32318@pfrc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Sat, 19 Sep 2015 10:28:31 -0000 Jeff, Thanks for this, I think you have one more bfd related document in the PALS wg; draft-ietf-pals-seamless-vccv-00 Seamless BFD for VCCV /Loa On 2015-09-18 22:45, Jeffrey Haas wrote: > The working group has been quiet. Certainly I've been a bit distracted, and > Nobo even more so! > > I've taken this opportunity to prod a few document authors to move their > work along. > > I've also spent some time updating the WG wiki with current perceived WG > status. If you have a BFD document, please check the wiki and make sure the > status seems correct. If your document is marked expired, then it means > you're not pushing your proposal very hard! > > https://wiki.tools.ietf.org/wg/bfd/trac/wiki/WikiStart > > The multipoint documents, presuming the WG agrees, are likely to hit WGLC > soon. Please review them and provide feedback. > > This is also a reminder that in terms of chartered work, the Yang module > could use WG attention. The design team has done an excellent job getting > us this far - help them get to the finish line. > > Finally, our need to do presentations at the upcoming IETF session in > Yokohama will be based on *active* work with discussion on the mailing list. > This means that now, in this quiet time between IETFs, is a perfect time to > try to get the attention of your fellow BFD experts. > > -- Jeff > From nobody Mon Sep 21 04:17:25 2015 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 869E01B30AC for ; Mon, 21 Sep 2015 04:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_25=1, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 PvLgsPSOsfhH for ; Mon, 21 Sep 2015 04:17:20 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0119.outbound.protection.outlook.com [207.46.100.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04A7F1B30A9 for ; Mon, 21 Sep 2015 04:17:19 -0700 (PDT) Received: from SN1PR0501MB1758.namprd05.prod.outlook.com (10.163.130.25) by SN1PR0501MB1744.namprd05.prod.outlook.com (10.163.130.23) with Microsoft SMTP Server (TLS) id 15.1.274.16; Mon, 21 Sep 2015 11:17:19 +0000 Received: from SN1PR0501MB1760.namprd05.prod.outlook.com (10.163.130.27) by SN1PR0501MB1758.namprd05.prod.outlook.com (10.163.130.25) with Microsoft SMTP Server (TLS) id 15.1.268.17; Mon, 21 Sep 2015 11:17:17 +0000 Received: from SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) by SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) with mapi id 15.01.0274.009; Mon, 21 Sep 2015 11:17:17 +0000 From: Santosh P K To: Marc Binderberger , Vengada Prasad Govindan Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt Thread-Index: AQHQsEzmEknWHHNqr0WZplypYqzrJZ3AKHaggAAt1oCAAAv0AIAAAfoAgAKROICAAdPPMIABD5SAgAGRpQCAADMkAIAAi+iAgABn/oCAABwvgIALsT0AgABnWwCAAAq68IALv5QAgAABHACAW69RgIALGx3w Date: Mon, 21 Sep 2015 11:17:17 +0000 Message-ID: References: <201A584A-C88F-4B5E-B43B-5BDF04F443B7@gmail.com> <315041E4211CB84E86EF7C25A2AB583D5457CD9E@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D5457CDFC@xmb-rcd-x15.cisco.com> <93F4D9E1-2498-4E82-8559-17BBA18BDDB5@broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831F4941F@SJEXCHMB12.corp.ad.broadcom.com> <454798CB-8559-40C8-8714-B5B44D9A5921@gmail.com> <4A6CE49E6084B141B15C0713B8993F2831F4FEE1@SJEXCHMB12.corp.ad.broadcom.com> <4A6CE49E6084B141B15C0713B8993F2831F501BA@SJEXCHMB12.corp.ad.broadcom.com> <2279CC94-1E55-487E-9402-07D1055739F0@gmail.com> <315041E4211CB84E86EF7C25A2AB583D545D1911@xmb-rcd-x15.cisco.com> <20150914023621783380.e60e074d@sniff.de> In-Reply-To: <20150914023621783380.e60e074d@sniff.de> 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=santoshpk@juniper.net; x-originating-ip: [116.197.184.14] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1758; 5:tG/TIDrYUfukGrtB+gpJm23zxcvL/CJiGms652z2BDfGRFyrbVgzl6auDlat2MKv9jE+i5OAFRFUfhvtizgq8mAw5aOq6Ulep8BkHNQDnizvYESjQkYUHg+4BnHpXVc/c59HrYyT+TqauNVsCelz1Q==; 24:KVGENaxyjcotpv2XV5JMFmzZtKePvK2Mgd+6tX5z6AWK6YN+iyQu9MovFTVPZRcUbmJ28knA9WdpWDt+Cmm5aKolu7lDkZ02GvfzEaBJkrQ=; 20:1JwTZTXYWYe7jl1CVnBL3aibwwLnHnnC+gScGPM5XWqvt5YJPANIUCCjuOvUzh9waKrhH7gRTPFgDbowzEZ98A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1758; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520078)(5005006)(8121501046)(3002001); SRVR:SN1PR0501MB1758; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1758; x-forefront-prvs: 07063A0A30 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(76104003)(189002)(24454002)(199003)(43784003)(377454003)(4001540100001)(106116001)(5001860100001)(46102003)(5003600100002)(76576001)(77156002)(74316001)(19580405001)(5007970100001)(5004730100002)(99286002)(92566002)(106356001)(122556002)(62966003)(68736005)(2950100001)(101416001)(93886004)(66066001)(77096005)(81156007)(2900100001)(87936001)(50986999)(230783001)(5890100001)(64706001)(5001960100002)(86362001)(11100500001)(189998001)(5001830100001)(102836002)(76176999)(54356999)(10400500002)(19580395003)(97736004)(33656002)(40100003)(5001770100001)(105586002)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1758; H:SN1PR0501MB1760.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) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2015 11:17:17.3786 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1758 X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB1744; 2:Fn4d+kVnEd0RXM63+BYTwWLOoap3vCA1ka0pYAb9lC6O20FWhvPNJJA8tmHTbtMqykG4p2XFDIJ66758LCNuP07nNopG/EgBB3cthXDFssCVoeF7IzP4DJBMnx1l/uzD11CiBhI8Ul8fKQdRR13Rk//wzaEmk2k5LeZPiFfRNFE=; 23:PjfR/KK+OaDptE/x/PiMObQVOb/3M34IkoH2r+vzvbKGxopeZiKiJ2ifbXSxyF2HeNyakY+zpFB2X8sNFELpkwXfE+a4WpLVyWMHJGW4C3qYQs6sdu/RkSRpgBSXstHqw3QIfU8pRDbFR3M5Bo8cILLmLBfGSSlQPfHFZkONWLYQw9z1eIPKBurlp9/HWoVR X-OriginatorOrg: juniper.net Archived-At: Cc: Reshad Rahman , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 11:17:24 -0000 Hello Marc, Sorry for delayed response. Please see my inline reply tagged [SPK]. > tuning in a bit late but nevertheless an interesting discussion. Being so= late I > almost expect a version -02 soon (?) :-) >=20 [SPK] Yes, we are working on it :). >=20 > May I encourage the authors to stick to BFD's simplicity. While all the > comments I've seen have a valid point I do think the original idea of a > simple unicast asynchronous BFD inside a VxLAN VNI is valid. [SPK] Sure we want to keep the BFD as simple as possible and not divert fro= m base RFC 5880. > > Nobo's idea of BFD echo on layer-2 is really nice and you should describe= it > in your document too - as an option. How the learning mechanism reacts to > src-mac =3D=3D dst-mac and if the silicon in a server-NIC supports > decap-lookup-encap seems an implementation detail to me, thus why I > would go > for optional. [SPK] We are discussing on this. Should we need to capture this in the same= document or a separate document is required for this? WG can take decision= based on WG inputs. >=20 > For the "shortcomings" of the unicast async approach: well, discuss them = in > the document. It may well be that an implementation can "inject" the > BFD+ether-frame into the source VTEP hardware/mechanism to go through > the > whole lookup+encap, i.e. the AC->VxLAN forwarding. Just propose that an > implementation should do so. Similar on the decapsulation side, if your V= TEP > MAC, local IP and BFD exist in a VM (e.g. OpenVswitch) then the delivery > may > be no different from the delivery of a packet to the other (Application) = VMs. > And if your VTEP is a switch/router there is always the option of a loopb= ack > cable to provide the true AC<->VxLAN experience :-) Just mention this as = a > hint to implementors. [SPK] Thanks for your suggestion. I think it really make sense to add them = in our document. We will update our document accordingly.=20 >=20 > The idea to use multicast packets is interesting. I would see it as an > additional check as unicast and multicast may use different packet path i= n > hardware/software, not as a replacement for unicast VxLAN BFD but I may > be > wrong. [SPK] I don't think we have discussed more on this. I guess it is worth dis= cussing on this and see if we reach any conclusion. >=20 >=20 > For the document, you are a bit short on the motivation side, IMHO. Sayin= g > "Main use case of BFD for VXLAN is for tunnel connectivity check. There a= re > other use cases such as [...]" and then saying more about the other use c= ases > than your main case is a bit odd ;-) [SPK] Thanks again for suggestion. We will make the required changes.=20 Thanks Santosh P K >=20 >=20 > On Sat, 18 Jul 2015 01:29:14 +0000, Vengada Prasad Govindan (venggovi) > wrote: > > Hello Nobo, > > While I do agree that there could be value in getting a self-destined > > packet encapsulated in VxLAN as you describe below, the datapath flow o= f > > VxLAN decap followed by a L2 lookup and a VxLAN (re)encap is not > supported > > on most silicon (Shahram, please correct me if I am wrong here) and hen= ce > > difficult to implement. Instead a VxLAN Async is what is proposed in th= e > > draft. > > Thanks > > Prasad > > > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya > > Sent: Friday, July 17, 2015 6:25 PM > > To: Santosh P K > > Cc: Reshad Rahman (rrahman); rtg-bfd@ietf.org; S. Davari > > Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-0= 0.txt > > > > Hi Santosh, > > > > Essentially the sender can periodically send self-destined packets (MAC= -DA > > =3D sender VTEP) that gets looped back on the remote VTEP (this better > > exercises the VNI forwarding on the remote VTEP). Similar concept as BF= D > > echo. > > > > Thanks! > > > > -Nobo > > > > On Fri, Jul 10, 2015 at 11:01 PM, Santosh P K > wrote: > >> Nobo and Sharram, > >> I am bit confused did you mean MAC-DA of the receiver VTEP? How > would > >> sender VTEP solve the problem? > >> > >> > >> Thanks > >> Santosh P K > >> > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of S. Davari > >> Sent: Friday, July 10, 2015 6:52 PM > >> To: Nobo Akiya > >> Cc: Reshad Rahman (rrahman); rtg-bfd@ietf.org > >> > >> Subject: Re: New Version Notification for > >> draft-spallagatti-bfd-vxlan-00.txt > >> > >> Yes that is the solution. > >> > >> Regards, > >> Shahram > >> > >> > >> On Jul 10, 2015, at 12:12 AM, Nobo Akiya > wrote: > >>> Long and interesting thread :) > >>> > >>> How about setting the MAC-DA as the MAC of the sender VTEP? > >>> > >>> Thanks! > >>> > >>> -Nobo > >>> > >>> On Fri, Jul 3, 2015 at 5:39 AM, Shahram Davari > >>> wrote: > >>>> Sure. > >>>> > >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > Shahram > >>>> Davari > >>>> Sent: Thursday, July 02, 2015 11:58 AM > >>>> To: Reshad Rahman (rrahman); Shahram Davari > >>>> Cc: rtg-bfd@ietf.org > >>>> Subject: RE: New Version Notification for > >>>> draft-spallagatti-bfd-vxlan-00.txt > >>>> > >>>> Agree. But we can may be come up with a more efficient solution. > >>>> > >>>> Thx > >>>> SD > >>>> > >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Reshad > >>>> Rahman (rrahman) > >>>> Sent: Thursday, July 02, 2015 5:46 AM > >>>> To: Shahram Davari > >>>> Cc: rtg-bfd@ietf.org > >>>> Subject: Re: New Version Notification for > >>>> draft-spallagatti-bfd-vxlan-00.txt > >>>> > >>>> Hi Shahram, > >>>> > >>>> Agreed. My point is that running BFD on the tunnel is not good enoug= h > >>>> for some failures. > >>>> > >>>> Regards, > >>>> Reshad. > >>>> > >>>> > >>>> > >>>> From: Rtg-bfd on behalf of Shahram > Davari > >>>> > >>>> Date: Thursday, July 2, 2015 at 12:25 AM > >>>> To: Reshad > >>>> Cc: Shahram Davari , "rtg-bfd@ietf.org" > >>>> > >>>> Subject: Re: New Version Notification for > >>>> draft-spallagatti-bfd-vxlan-00.txt > >>>> > >>>> Hi Reshad, > >>>> > >>>> You don=A2t need to run continuous BFD session per VNI to detect UD= P > port > >>>> configuration issue. To justify running BFD per VNI, one needs to sh= ow > >>>> that the forwarding of each of those BFD sessions depends on specifi= c > >>>> VNI value. > >>>> > >>>> Thx > >>>> Shahram > >>>> > >>>>> On Jul 1, 2015, at 6:22 PM, Reshad Rahman (rrahman) > > >>>>> wrote: > >>>>> > >>>>> Hi Shahram, > >>>>> > >>>>> I agree that running BFD between VTEPs per VNI might not scale well= . > >>>>> But by just running BFD on the IP tunnel IMO you won=A2t detect cer= tain > >>>>> problems, maybe hypothetical, such as the UDP port being blocked > (e.g. > >>>>> Due to a misconfigured ACL). > >>>>> > >>>>> Regards, > >>>>> Reshad. > >>>>> > >>>>> From: Rtg-bfd on behalf of Shahram > Davari > >>>>> > >>>>> Date: Tuesday, June 30, 2015 at 9:24 PM > >>>>> To: Santosh P K , "S. Davari" > >>>>> , "rtg-bfd@ietf.org" bfd@ietf.org> > >>>>> Subject: RE: New Version Notification for > >>>>> draft-spallagatti-bfd-vxlan-00.txt > >>>>> > >>>>> Santosh, > >>>>> > >>>>> Is the BFD you are describing in your draft unicast or multicast? = If > >>>>> unicast then service nodes would not apply. > >>>>> > >>>>> Also if there is a service node then one can run BFD on the IP tunn= el > >>>>> between source VTEP and service node and between service node > and the > >>>>> destination VTEP. This is much more scalable than running end-to-en= d > >>>>> BFD between VTEPs per VNI. You could even use such BFD to switch > to a > >>>>> backup service node if there is failure to the main service node. > >>>>> > >>>>> Thx > >>>>> Shahram > >>>>> > >>>>> From: Santosh P K [mailto:santoshpk@juniper.net] > >>>>> Sent: Tuesday, June 30, 2015 2:14 AM > >>>>> To: S. Davari; Shahram Davari; rtg-bfd@ietf.org > >>>>> Subject: RE: New Version Notification for > >>>>> draft-spallagatti-bfd-vxlan-00.txt > >>>>> > >>>>> There can be few VTEPs who might have capabilities to multicast the > >>>>> packet. In such a scenario VTEP will send that packet to service no= de > >>>>> and service node will do a multicast on its behalf. > >>>>> > >>>>> > >>>>> Thanks > >>>>> Santosh P K > >>>>> > >>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of S. > Davari > >>>>> Sent: Monday, June 29, 2015 10:48 AM > >>>>> To: Shahram Davari; rtg-bfd@ietf.org > >>>>> Subject: Re: New Version Notification for > >>>>> draft-spallagatti-bfd-vxlan-00.txt > >>>>> > >>>>> Hi > >>>>> > >>>>> What is a service node? > >>>>> > >>>>> Thx > >>>>> > >>>>> Sd > >>>>> > >>>>> > >>>>>> Hi Prasad , > >>>>>> > >>>>>> I don't see how you get more coverage having a VXLAN tag. > >>>>>> > >>>>>> Since you are not testing the VXLAN based VFI/VRF forwarding. By > that > >>>>>> I mean you are not testing (DA, VXLAN ) or (DIP, VXLAN) forwarding= . > >>>>>> GVP1> One of the aspects of the next version of the draft will hav= e a > >>>>>> valid inner DIP instead of 127/8. This should help address your > >>>>>> concern to an extent. > >>>>>> Also you are not testing the mapping from AC (Attachment Circuit) > to a > >>>>>> VXLAN tag. > >>>>>> GVP1> Agreed, this aspect has not (yet) been addressed by RFC5884 > as > >>>>>> well, not using it as an excuse but I am just noting the precedent > >>>>>> here. > >>>>>> > >>>>>> In my opinion all you are testing, is that at the other end of an = IP > >>>>>> Tunnel a specific VXLAN exist or not. Which does not require runni= ng > >>>>>> continuous BFD. > >>>>>> GVP1> There are specific use-cases (see note about Service Node > >>>>>> reachability in Sec 2 of the draft) that require continuous monito= ring > >>>>>> of some special-purpose VTEPs. > >>>>>> > >>>>>> In my opinion this is a very in efficient way of getting that > >>>>>> information. The controller should be able to get this information > >>>>>> much more efficiently. > >>>>>> > >>>>>> It would be good if you can provide an example of what you think i= s > >>>>>> more coverage than BFD. Or at least what extra coverage do you > exactly > >>>>>> have in mind, since this draft is not capable of more coverage tha= n > >>>>>> standard BFD over the IP tunnel. > >>>>>> > >>>>>> Regards, > >>>>>> Shahram > >>>>> Regards, > >>>>> Shahram > >>>>> > >>>>> > >>>>> On Jun 27, 2015, at 7:06 AM, Shahram Davari > wrote: > >>>>>> Hi Prasad , > >>>>>> > >>>>>> I don't see how you get more coverage having a VXLAN tag. > >>>>>> > >>>>>> Since you are not testing the VXLAN based VFI/VRF forwarding. By > that > >>>>>> I mean you are not testing (DA, VXLAN ) or (DIP, VXLAN) forwarding= . > >>>>>> GVP1> One of the aspects of the next version of the draft will hav= e a > >>>>>> valid inner DIP instead of 127/8. This should help address your > >>>>>> concern to an extent. > >>>>>> Also you are not testing the mapping from AC (Attachment Circuit) > to a > >>>>>> VXLAN tag. > >>>>>> GVP1> Agreed, this aspect has not (yet) been addressed by RFC5884 > as > >>>>>> well, not using it as an excuse but I am just noting the precedent > >>>>>> here. > >>>>>> > >>>>>> In my opinion all you are testing, is that at the other end of an = IP > >>>>>> Tunnel a specific VXLAN exist or not. Which does not require runni= ng > >>>>>> continuous BFD. > >>>>>> GVP1> There are specific use-cases (see note about Service Node > >>>>>> reachability in Sec 2 of the draft) that require continuous monito= ring > >>>>>> of some special-purpose VTEPs. > >>>>>> > >>>>>> In my opinion this is a very in efficient way of getting that > >>>>>> information. The controller should be able to get this information > >>>>>> much more efficiently. > >>>>>> > >>>>>> It would be good if you can provide an example of what you think i= s > >>>>>> more coverage than BFD. Or at least what extra coverage do you > exactly > >>>>>> have in mind, since this draft is not capable of more coverage tha= n > >>>>>> standard BFD over the IP tunnel. > >>>>>> > >>>>>> Regards, > >>>>>> Shahram > >>>>> > >>>> > >>>> > >>> > >>> > >> > > > > From nobody Mon Sep 21 04:29:36 2015 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 359E91B30C3 for ; Mon, 21 Sep 2015 04:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 av6prP7u7m4A for ; Mon, 21 Sep 2015 04:29:34 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0132.outbound.protection.outlook.com [65.55.169.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62B761B30C2 for ; Mon, 21 Sep 2015 04:29:33 -0700 (PDT) Received: from SN1PR0501MB1760.namprd05.prod.outlook.com (10.163.130.27) by SN1PR0501MB1759.namprd05.prod.outlook.com (10.163.130.26) with Microsoft SMTP Server (TLS) id 15.1.274.16; Mon, 21 Sep 2015 11:29:30 +0000 Received: from SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) by SN1PR0501MB1760.namprd05.prod.outlook.com ([10.163.130.27]) with mapi id 15.01.0274.009; Mon, 21 Sep 2015 11:29:30 +0000 From: Santosh P K To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: Working group status Thread-Topic: Working group status Thread-Index: AQHQ8lJ/1JOJ1rjX102PmYJ07Y0HTJ5G3KCw Date: Mon, 21 Sep 2015 11:29:30 +0000 Message-ID: References: <20150918204533.GG32318@pfrc.org> In-Reply-To: <20150918204533.GG32318@pfrc.org> 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=santoshpk@juniper.net; x-originating-ip: [116.197.184.14] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1759; 5:FhozaDKCQEbOq1+hEPN9rZ8E8FlJawjaK3ujksfrgr/qShD5/2E0SXFZmvYw/XSLSQtvBBO9XMvBvdwf0pPOYTD4dbdaSPRjO+L0e5Ssm7T6j1z6P+64fCPUp9jWb+1k6lQAz859ilds5YG97n8KJw==; 24:6hb/4nrC7LvD2xRkWAqhlEodrfueNDOU17Am/CTPzdrVRx+au7+zV2mQMqWmQsvzgXlTW+UjTLriXEIzsfy6U1VFqxCUJETYvF3n4x47oFg=; 20:EkLLnGDGLAFYoVVJum0hgBja/dIvd+iEvftAQudGFQNu1ON4IdVsRlID7DNwizNFZPWhy1u9KbOKbwvn0SrVrQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1759; x-exchange-antispam-report-cfa: BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1759; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1759; x-forefront-prvs: 07063A0A30 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(13464003)(199003)(377454003)(64706001)(68736005)(101416001)(102836002)(107886002)(19580405001)(19580395003)(2501003)(76576001)(189998001)(105586002)(106116001)(62966003)(15975445007)(77096005)(106356001)(66066001)(99286002)(4001540100001)(40100003)(10400500002)(81156007)(5001770100001)(97736004)(5001830100001)(5001860100001)(11100500001)(5004730100002)(5003600100002)(5002640100001)(33656002)(122556002)(2950100001)(2900100001)(46102003)(92566002)(50986999)(54356999)(76176999)(77156002)(74316001)(561944003)(86362001)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1759; H:SN1PR0501MB1760.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) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM 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: 21 Sep 2015 11:29:30.3763 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1759 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: Mon, 21 Sep 2015 11:29:35 -0000 Jeff, I think " draft-ymbk-idr-rs-bfd " already a working group document?=20 Thanks Santosh P K=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Saturday, September 19, 2015 2:16 AM > To: rtg-bfd@ietf.org > Subject: Working group status >=20 > The working group has been quiet. Certainly I've been a bit distracted, = and > Nobo even more so! >=20 > I've taken this opportunity to prod a few document authors to move their > work along. >=20 > I've also spent some time updating the WG wiki with current perceived WG > status. If you have a BFD document, please check the wiki and make sure > the status seems correct. If your document is marked expired, then it me= ans > you're not pushing your proposal very hard! >=20 > https://wiki.tools.ietf.org/wg/bfd/trac/wiki/WikiStart >=20 > The multipoint documents, presuming the WG agrees, are likely to hit WGLC > soon. Please review them and provide feedback. >=20 > This is also a reminder that in terms of chartered work, the Yang module > could use WG attention. The design team has done an excellent job gettin= g > us this far - help them get to the finish line. >=20 > Finally, our need to do presentations at the upcoming IETF session in > Yokohama will be based on *active* work with discussion on the mailing li= st. > This means that now, in this quiet time between IETFs, is a perfect time = to try > to get the attention of your fellow BFD experts. >=20 > -- Jeff From nobody Mon Sep 21 06:41:18 2015 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 7A67B1B31CB for ; Mon, 21 Sep 2015 06:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 He5SV44H-TA2 for ; Mon, 21 Sep 2015 06:41:16 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A0C0B1B31AB for ; Mon, 21 Sep 2015 06:41:16 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7D06E1E383; Mon, 21 Sep 2015 09:44:49 -0400 (EDT) Date: Mon, 21 Sep 2015 09:44:49 -0400 From: Jeffrey Haas To: Venkatesan Mahalingam Subject: Re: draft-ietf-bfd-mpls-mib-06 (was Re: Comments on draft-ietf-bfd-mpls-mib-05) Message-ID: <20150921134449.GB12070@pfrc.org> References: <20141230172539.GA25357@pfrc> <20150918174320.GA32318@pfrc.org> 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: "draft-ietf-bfd-mpls-mib@tools.ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 13:41:17 -0000 Venkat, On Sat, Sep 19, 2015 at 01:40:51AM -0700, Venkatesan Mahalingam wrote: > On Fri, Sep 18, 2015 at 10:43 AM, Jeffrey Haas wrote: > > > Authors of the BFD MPLS MIB, > > > > Thanks for addressing the majority of my comments during MIB review. Only > > a > > few items have remained without any response: > > > > - Splitting the TCs into IANA maintained modules. Do you intend to just > > wait until we have MIB doctor review and see if they require it? > > > Yes. Understood. Please note that having been through this sort of thing a few times, that is the likely recommendation. It means that we'll end up having to send the document through a second WGLC as a result. > > > One final comment is that no NOTIFICATIONs are defined for this MIB. > > While > > > not strictly required, an operator has no indication that a given > > > NOTIFICATION in the underlying RFC 7331 MIB is for sessions that may > > change > > > state for reasons having to do with underlying MPLS session association. > > > As we augment the existing BFD Session MIB for MPLS, whatever notifications > present in BFD session MIB will be applicable for MPLS BFD session also. > > > > One possibility that comes to mind to address this is to add a > > > recommendation that the bfdSessUp/bfdSessDown NOTIFICATIONS receive an > > > additional OBJECTS entry of bfdMplsSessMapPointer. The one obvious > > counter > > > to such a practice is this may disrupt the low/high range optimization in > > > the base NOTIFICATION. > > > > > > Do we really need an additional entry bfdMplsSessMapPointer in the > notification? Need, no. But consider your user-base. The lack of correlation between events in various OAM systems is probably one of the most infuriating things about the management architecture IETF has put together, especially if you're trying to operate a network. If an LSP drops and you lose 100 BFD sessions, you'll get 100 BFD Down NOTIFICATIONs and perhaps some other notification from another MIB. If BFD knows that it's going down due to an MPLS LSP event, it's preferable that it simply say so. And should my own employer decide to implement this MIB, including the additional OBJECT will certainly be my recommendation. -- Jeff From nobody Mon Sep 21 06:45:38 2015 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 73C781B31BD for ; Mon, 21 Sep 2015 06:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, 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 I2tYEj8jeql2 for ; Mon, 21 Sep 2015 06:45:34 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1C051B31AC for ; Mon, 21 Sep 2015 06:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3378; q=dns/txt; s=iport; t=1442843134; x=1444052734; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ERh6yhzyviX9mpoiW9WIGdhKoZucrk/MH0gF65yHwAI=; b=TM0RakJvPpH1c0nL9/eUh+JI5iMooIazsyfQkc5T31b9krvnuXhPM1CN j2wQG7yyaSGr93jrG8wVCJLJfQtxbsGPdbeuxpNPKG6T8J+00Mauki144 QO0PYHOG8G+dTUVebk10KOQtN8E8iasxi+O8DQr5ljrfwjvQ05EjcMqzk Y=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CqAgBkCQBW/5FdJa1dgyRUaQa9PQ6Be4V5AoE1OBQBAQEBAQEBgQqEIwEBAQMBawMLBQsCAQgYLjIlAgQOBQ6IGAgNyi0BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIZzgg+CboUNB4MYgRQFhT2Bc4Z9hA6DKQGCSYFdaoVEgjKBTYQ1hyOKCINsAR8BQ4QBcQGIZ4EFAQEB X-IronPort-AV: E=Sophos;i="5.17,567,1437436800"; d="asc'?scan'208";a="34434837" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Sep 2015 13:45:33 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t8LDjXGn003722 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Sep 2015 13:45:33 GMT Received: from xch-aln-020.cisco.com (173.36.7.30) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 21 Sep 2015 08:45:32 -0500 Received: from xch-aln-020.cisco.com ([173.36.7.30]) by XCH-ALN-020.cisco.com ([173.36.7.30]) with mapi id 15.00.1104.000; Mon, 21 Sep 2015 08:45:32 -0500 From: "Carlos Pignataro (cpignata)" To: Loa Andersson Subject: Re: Working group status Thread-Topic: Working group status Thread-Index: AQHQ8lKGg9+wdTcxuk+fCbSCE0uDRZ5D+v0AgANbwQA= Date: Mon, 21 Sep 2015 13:45:32 +0000 Message-ID: <041999F3-E43A-4805-B847-39845C3D532E@cisco.com> References: <20150918204533.GG32318@pfrc.org> <55FD38C6.9010404@pi.nu> In-Reply-To: <55FD38C6.9010404@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.228.34] Content-Type: multipart/signed; boundary="Apple-Mail=_E01B6E76-E75F-4E54-8D11-A6A3A25F51ED"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 13:45:36 -0000 --Apple-Mail=_E01B6E76-E75F-4E54-8D11-A6A3A25F51ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Jeff, In addition to this document that Loa points out, there are other = related documents in other WGs: 02 Mar 2015 draft-ietf-isis-sbfd-discriminator txt pdf = xml html 23 Jul 2015 draft-ietf-l2tpext-sbfd-discriminator txt pdf = xml html 23 Mar 2015 draft-ietf-ospf-sbfd-discriminator txt pdf 21 Aug 2014 draft-zhuang-idr-bgp-ls-sbfd-extensions txt pdf I have added these to the wiki. Thanks, =97 Carlos. > On Sep 19, 2015, at 6:28 AM, Loa Andersson wrote: >=20 > Jeff, >=20 > Thanks for this, I think you have one more bfd related document in the > PALS wg; >=20 > draft-ietf-pals-seamless-vccv-00 > Seamless BFD for VCCV >=20 > /Loa >=20 >=20 > On 2015-09-18 22:45, Jeffrey Haas wrote: >> The working group has been quiet. Certainly I've been a bit = distracted, and >> Nobo even more so! >>=20 >> I've taken this opportunity to prod a few document authors to move = their >> work along. >>=20 >> I've also spent some time updating the WG wiki with current perceived = WG >> status. If you have a BFD document, please check the wiki and make = sure the >> status seems correct. If your document is marked expired, then it = means >> you're not pushing your proposal very hard! >>=20 >> https://wiki.tools.ietf.org/wg/bfd/trac/wiki/WikiStart >>=20 >> The multipoint documents, presuming the WG agrees, are likely to hit = WGLC >> soon. Please review them and provide feedback. >>=20 >> This is also a reminder that in terms of chartered work, the Yang = module >> could use WG attention. The design team has done an excellent job = getting >> us this far - help them get to the finish line. >>=20 >> Finally, our need to do presentations at the upcoming IETF session in >> Yokohama will be based on *active* work with discussion on the = mailing list. >> This means that now, in this quiet time between IETFs, is a perfect = time to >> try to get the attention of your fellow BFD experts. >>=20 >> -- Jeff >>=20 >=20 --Apple-Mail=_E01B6E76-E75F-4E54-8D11-A6A3A25F51ED Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWAAn8AAoJEIXgpQGOZny9LdAQAI5WUix0AxdTF2uNLU1cL7/E GUznmGPkyvrQXVf1b6cWAvhDMAuKLo9klNoWTGoL8xmMilYgU/ML736XPGWsbV5J MNdGNjZzpPxCEdtKY2spQKlaMbV+22rsKtwkgNhxDIR+BpeF175uKxAL2B3cpBvk NJWER9C9/N3cn03WW0Cm4rfD33HhokbY2+SzcMW/+372rdrVvdW65BPVc4TLCB6c KY9kY8ZCXKF3Gi3TpXXNclj07sYJm4HsEaxAqPpoFvIUqc90SrEPzcUTfebc2f/y L5jIyY0AWwtsiNwVrAuAUvLqfgOa2/xwigedSsdJlTh5G6NMBgzgjAOV8HqC/HY+ eRIMs6mpfVeZzNFgbPW+hV8ldNEzn6/alrnPBv1A4WMX/BSw4lPh+FP6x/WraM0j nwE57xxIH3j6HHJPD40CMxK0O2ojVCNz9kaqoV5nqgyYDsdQPTpZwHsn8gGWzaHK Kx0z1/x+wRYGprybWSQ28dCsov5ViT2lUzEmYyqRxEwx1+cZ+dnJqxuZXiL225Zu kJKfe+wehRe6tTzxCk3DsTSbFHT5O566KXyoseMIacG5dubn/njUTFxwRFVe+6SO DTIXH8ZRjbGkq3Grt8OMSkHrglhL2Jbw6WogLy5Ml9e17oAdgiMNVY/eozmo/h0u 1Dpr/tHcIb+VBWCOTron =nrcj -----END PGP SIGNATURE----- --Apple-Mail=_E01B6E76-E75F-4E54-8D11-A6A3A25F51ED-- From nobody Mon Sep 21 06:50:56 2015 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 EAF591B31DB for ; Mon, 21 Sep 2015 06:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 g_31IdRGowvH for ; Mon, 21 Sep 2015 06:50:53 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 81E1F1B31E1 for ; Mon, 21 Sep 2015 06:50:51 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 799511E383; Mon, 21 Sep 2015 09:54:24 -0400 (EDT) Date: Mon, 21 Sep 2015 09:54:24 -0400 From: Jeffrey Haas To: Loa Andersson Subject: Re: Working group status Message-ID: <20150921135424.GA13508@pfrc.org> References: <20150918204533.GG32318@pfrc.org> <55FD38C6.9010404@pi.nu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55FD38C6.9010404@pi.nu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 13:50:54 -0000 LOa, On Sat, Sep 19, 2015 at 12:28:22PM +0200, Loa Andersson wrote: > Thanks for this, I think you have one more bfd related document in the > PALS wg; > > draft-ietf-pals-seamless-vccv-00 > Seamless BFD for VCCV Thanks. This one was under "Non-WG S-BFD Documents of Interest". -- Jeff From nobody Mon Sep 21 06:52:36 2015 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 93D821B31E4 for ; Mon, 21 Sep 2015 06:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 W00Q_W8HGGXq for ; Mon, 21 Sep 2015 06:52:35 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF6F1B31E5 for ; Mon, 21 Sep 2015 06:52:35 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id D45A91E383; Mon, 21 Sep 2015 09:56:07 -0400 (EDT) Date: Mon, 21 Sep 2015 09:56:07 -0400 From: Jeffrey Haas To: Santosh P K Subject: Re: Working group status Message-ID: <20150921135607.GB13508@pfrc.org> References: <20150918204533.GG32318@pfrc.org> 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: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 13:52:35 -0000 On Mon, Sep 21, 2015 at 11:29:30AM +0000, Santosh P K wrote: > Jeff, > I think " draft-ymbk-idr-rs-bfd " already a working group document? Thanks for catching that, Santosh. And that reminds me I own the other authors more text. :-) -- Jeff From nobody Mon Sep 21 07:01:23 2015 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 49C991B31FC for ; Mon, 21 Sep 2015 07:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 zWAgbI0CEg44 for ; Mon, 21 Sep 2015 07:01:18 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id ED3EE1B31B6 for ; Mon, 21 Sep 2015 07:01:17 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id CD7621E383; Mon, 21 Sep 2015 10:04:50 -0400 (EDT) Date: Mon, 21 Sep 2015 10:04:50 -0400 From: Jeffrey Haas To: "Carlos Pignataro (cpignata)" Subject: Re: Working group status Message-ID: <20150921140450.GC13508@pfrc.org> References: <20150918204533.GG32318@pfrc.org> <55FD38C6.9010404@pi.nu> <041999F3-E43A-4805-B847-39845C3D532E@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <041999F3-E43A-4805-B847-39845C3D532E@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 14:01:22 -0000 Carlos, On Mon, Sep 21, 2015 at 01:45:32PM +0000, Carlos Pignataro (cpignata) wrote: > In addition to this document that Loa points out, there are other related documents in other WGs: > > 02 Mar 2015 draft-ietf-isis-sbfd-discriminator txt pdf xml html > 23 Jul 2015 draft-ietf-l2tpext-sbfd-discriminator txt pdf xml html > 23 Mar 2015 draft-ietf-ospf-sbfd-discriminator txt pdf > 21 Aug 2014 draft-zhuang-idr-bgp-ls-sbfd-extensions txt pdf > > I have added these to the wiki. Thanks for the edit! -- Jeff From nobody Thu Sep 24 09:09:12 2015 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 DA1DB1A6FDF; Thu, 24 Sep 2015 09:09:10 -0700 (PDT) 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 zwkY8NlAigz9; Thu, 24 Sep 2015 09:09:09 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 306511A6F45; Thu, 24 Sep 2015 09:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5099; q=dns/txt; s=iport; t=1443110949; x=1444320549; h=from:to:cc:subject:date:message-id:mime-version; bh=c09Ey0jLDoN+b8474YaKPpd1b2rBm3jnMszBoPO8ipc=; b=bL7t/Tt4oAU3E38gYnEyI0rQ1D411B3pIuSltKtm2bGUiD1RZq/vQ9F6 K1LFLdYEjmVvUM+aSYabtHdis2G1EUyb9KBz3b+pHxG1QsC8eKjIm5l7I YE9K61ctosz/DrCKmM0BclNR9iLPoyQgQ86fYmMbseKDjH/DZ9DQQ+r/C I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D1AQDSHgRW/4kNJK1cgldNgUO9PQENh3OBSTgUAQEBAQEBAX8LhCcEeRIBgQAnBA6IM8wQAQEBAQEBBAEBAQEBAQEbhnMBigmEMwWSPoMpAY0KgU+ENoxpiDwfAQFChAGJWIEFAQEB X-IronPort-AV: E=Sophos;i="5.17,581,1437436800"; d="scan'208,217";a="190902909" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP; 24 Sep 2015 16:09:08 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t8OG98q9021664 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Sep 2015 16:09:08 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 24 Sep 2015 11:09:07 -0500 Received: from xhc-aln-x13.cisco.com (173.36.12.87) by xch-rcd-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 24 Sep 2015 11:09:07 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.98]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0248.002; Thu, 24 Sep 2015 11:09:07 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-bfd-rfc5884-clarifications@ietf.org" Subject: AD Review of draft-ietf-bfd-rfc5884-clarifications-02 Thread-Topic: AD Review of draft-ietf-bfd-rfc5884-clarifications-02 Thread-Index: AQHQ9uNWQ24/sz8CtEe6rajxOetPKg== Date: Thu, 24 Sep 2015 16:09:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.20] Content-Type: multipart/alternative; boundary="_000_D229985ED37A4aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@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: Thu, 24 Sep 2015 16:09:11 -0000 --_000_D229985ED37A4aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi! This is a nice and to-the-point document! I just have a couple of minor co= mments and nits. I=92m going ahead with the IETF Last Call and scheduling this document on t= he IESG Agenda (probably for Oct/15). Please post an update before Oct/8. Thanks! Alvaro. Minor: 1. Section 2.1. (Procedures for establishment of multiple BFD sessions) * s/Section 6 of [RFC5884]/Section 4 of [RFC5884] * "It further states that a BFD session SHOULD be established for ea= ch alternate path that is discovered.=94 To avoid confusion as to where th= at rfc2119 keyword was used, please use quotes when referring to the text i= n rfc5884. * "The remaining procedures of session establishment are as specifie= d in [RFC5884].=94 Please be specific where in the process should the spec= ification in this document should be considered. In this case I=92m assumi= ng that (if rfc5884) has been clear from the start, then this new procedure= would have been in place right after the third paragraph in Section 4.. Nits: 1. 2.1. (Procedures for establishment of multiple BFD sessions): s/discr= iminator (remote)/(remote) discriminator 2. Section 4. (Encapsulation) is superfluous. --_000_D229985ED37A4aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <985074962F4A6E4F9F896668D484DD3C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi!

This is a nice and to-the-point document!  I just have a couple of min= or comments and nits.

I=92m going ahead with the IETF Last Call and scheduling this document on t= he IESG Agenda (probably for Oct/15).  Please post an update before Oc= t/8.

Thanks!

Alvaro.


Minor:
  1. Section 2.1. (Procedures for establishment of multiple BFD sessions)
    • s/Section 6 of [RFC5884]/Section 4 of [RFC5884]
    • "It further st= ates that a BFD session SHOULD be established for each alternate path = that is discovered.=94  To avoid confusion as to where that rfc21= 19 keyword was used, please use quotes when referring to the text in rfc5884.
    • "The remai= ning procedures of session establishment are as specified in [RFC5884].=94 =  Please be specific where in the process should the specification in t= his document should be considered.  In this case I=92m assuming that (= if rfc5884) has been clear from the start, then this new procedure would have been in place right after th= e third paragraph in Section 4..
Nits:
  1. 2.1. (Procedures for establishment of= multiple BFD sessions): s/discrim= inator (remote)/(remote) discriminator
  2. Section 4. (Enca= psulation) is superfluous.


--_000_D229985ED37A4aretanaciscocom_-- From nobody Thu Sep 24 09:49:02 2015 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 142B51B2A68; Thu, 24 Sep 2015 09:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 A7OVSITLRhtL; Thu, 24 Sep 2015 09:48:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E10C91B2A62; Thu, 24 Sep 2015 09:48:57 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" Subject: Last Call: (Clarifications to RFC 5884) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150924164857.2908.4527.idtracker@ietfa.amsl.com> Date: Thu, 24 Sep 2015 09:48:57 -0700 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 16:48:59 -0000 The IESG has received a request from the Bidirectional Forwarding Detection WG (bfd) to consider the following document: - 'Clarifications to RFC 5884' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-10-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document clarifies the procedures for establishing, maintaining and removing multiple, concurrent BFD sessions for a given described in RFC5884. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bfd-rfc5884-clarifications/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bfd-rfc5884-clarifications/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Sep 25 09:49:27 2015 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 191FE1ACE0A; Fri, 25 Sep 2015 09:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.25 X-Spam-Level: X-Spam-Status: No, score=-14.25 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, HTML_OBFUSCATE_05_10=0.26, 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 W5s9hdyOhrLV; Fri, 25 Sep 2015 09:49:24 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA05C1ACDFA; Fri, 25 Sep 2015 09:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26935; q=dns/txt; s=iport; t=1443199763; x=1444409363; h=from:to:cc:subject:date:message-id:mime-version; bh=lirzktMPVhYLQduX9avYYtrRL7+a7HqGtKSkjXi4tPA=; b=SGBucWPr5BEgMHHk7ObIZ/IUnIzI9ubycbfFUGF83XtEfOJZeoIdZzBu xUAOdTw4+qG1IR+ppoI4zdubFyxDPUgUm6GAOyrC+tEYgE79wpte+WIkf cnnqPmjHjbzTLz3RLbCgPXdeg+bLdbpwUtQA2wyhXJq/esni84v+eY9e8 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AlBQATegVW/5BdJa1TCoJXTYFDvT6HdIEuORMBAQEBAQEBgQqEJwQdXBIBQEAnBAENIIgTzCcBAQEBAQEBAwEBAQEBAQEBGoZzAYksBFmEMwWSQoMqAYgBhQuBT4Q2jGyIPSMBP4QBiEoCHgccgQUBAQE X-IronPort-AV: E=Sophos;i="5.17,587,1437436800"; d="scan'208,217";a="190737096" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-2.cisco.com with ESMTP; 25 Sep 2015 16:49:22 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t8PGnKuZ000647 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 25 Sep 2015 16:49:22 GMT Received: from xch-aln-019.cisco.com (173.36.7.29) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 25 Sep 2015 11:49:19 -0500 Received: from xhc-aln-x10.cisco.com (173.36.12.84) by xch-aln-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 25 Sep 2015 11:49:19 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.98]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0248.002; Fri, 25 Sep 2015 11:49:19 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-bfd-seamless-use-case@ietf.org" , "rtg-bfd@ietf.org" Subject: AD Review of draft-ietf-bfd-seamless-use-case Thread-Topic: AD Review of draft-ietf-bfd-seamless-use-case Thread-Index: AQHQ97Ieqtfo0LmZ1kugOs1WHaftMQ== Date: Fri, 25 Sep 2015 16:49:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.20] Content-Type: multipart/alternative; boundary="_000_D1E8019CC4866aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "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: Fri, 25 Sep 2015 16:49:27 -0000 --_000_D1E8019CC4866aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi! In general I believe that use case documents have a very limited purpose an= d lifetime. While guiding the WG in the type of problems that need to be s= olved is very valuable, the usefulness mostly ends there. I would like to ask the WG to consider not publishing this document. Some = of the reasons behind me asking for this consideration are that not all the= use cases seem to add new requirements, they are just examples of differen= t instances of expressing the same need, and that there may be many more si= milar examples =97 this last point from some of the text in the Introductio= n [1]. I think that it would then be better to keep them all in a place wh= ere the WG can easily update them (without going through the publication pr= ocess), a wiki or a long-lived ID, for example. I=92m talking about requirements because even though this document says tha= t =93certain requirements could be derived to be used as reference=94, the = S-BFD base document says that it =93extends BFD to provide solutions to use= cases listed in [I-D.ietf-bfd-seamless-use-case].=94 If solutions are cre= ated then it would be nice to clearly know what the requirements are. If there is still WG consensus to publish this document, I would like to se= e the readability improved and the requirements clarified. See my detailed= comments below. I will keep the document in AD Evaluation (and not return= it to the WG) at least until a decision has been made. Thanks! Alvaro. [1] =93=85use cases could be used as reference for certain requirements, it= is outside the scope of this document to identify all of the requirements = for all possible enhancements." Major: 1. Requirements. If there are going to be requirements listed in this d= ocument, please be specific on what they are. It would be helpful for trac= king if they were also clearly identified. No need for normative language,= I=92m mostly looking for clarity and ease. Some comments: * 3.1. (Unidirectional Forwarding Path Validation) "The primary requ= irement in this use case is to enable session establishment from source net= work entity to target network entity.=94 If this is the primary requiremen= t, what are the other ones? Is the requirement itself that only the source= should have to be provisioned beforehand? * 3.2. (Validation of forwarding path prior to traffic switching) = =93It will be desirable to perform BFD validation very quickly to allow app= lications to utilize dynamically created LSPs in a timely manner.=94 Is th= at the requirement that comes out of this use case? Is it optional (=93des= irable=94)? What do =93very quickly=94 and =93in a timely manner" mean? T= his section starts with a generic description of the use case, I=92m assumi= ng the requirement is general as well and not just applicable to =93dynamic= ally created LSPs=94. * The use case in Section 3.3. (Centralized Traffic Engineering) = seems to also be calling for the ability "to instantly verify a forwarding = path=94. What does =93instantly=94 mean? Are there other requirements tha= t come from this section? * 3.4. (BFD in Centralized Segment Routing) =93In validating this us= e case, one of the requirements is to ensure the BFD packet's behavior is a= ccording to the requirement and monitoring of the segment=85=94 I-D.geib-s= pring-oam-usecase doesn=92t mention BFD =97 I know it implies it in a more = generic way. For the purposes of this document, I don=92t think it=92s eno= ugh to to just say that =93one of the requirements..is according to the req= uirements..of the segment=94 =97 in essence it seems like this document is = just pointing the reader to the other document to figure out what needs to = be done. Maybe a better reference for requirements is draft-ietf-spring-sr= -oam-requirement. It would also be nice to at least highlight the places w= here this use case introduces new requirements and why. * 3.5. (BFD Efficient Operation Under Resource Constraints) =93=85it= is desirable for BFD to=85=94 and 3.9. (MPLS BFD Session Per ECMP Path) "= it may be desirable to run in-band monitoring=85=94 Optional? * 3.6. (BFD for Anycast Address) The requirement here is ??? * 3.7. (BFD Fault Isolation) "If BFD had built-in fault isolation c= apability=85=94 and 3.8. (Multiple BFD Sessions to Same Target) "if a node= was to run multiple BFD sessions to targets=85=94 Conditional form.. Minor: 1. Some of the text needs to be cleaned up because it is repetitive. * Introduction: "Bidirectional Forwarding Detection (BFD) is a light= weight protocol=85used to detect forwarding failures. Various protocols an= d applications rely on BFD for failure detection. Even though the protocol= is simple and lightweight, there are certain use cases, where faster setti= ng up of sessions=85This document identifies use cases=85BFD was designed t= o be a lightweight "Hello" protocol to detect data plane failures=85speed a= t which these sessions could be established=85This document specifically id= entifies those cases=85=94 * Section 2. (Introduction to Seamless BFD): =93In order for BFD to = be able to initially verify that a connection is valid=85such that this inf= ormation can be used to verify that the connection is valid." 2. Solutions are outside the scope of this document. There are several = places where the text starts to describe the (potential at this point) beha= vior of S-BFD. That should be left to the solution document. Some example= s: * 2. (Introduction to Seamless BFD): "As an example of how Seamless = BFD (S-BFD) might work=85=94 * 3.1. (Unidirectional Forwarding Path Validation): "But with unidir= ectional BFD,..=94, and "This translates to=85=94 * 3.2. (Validation of forwarding path prior to traffic switching): "= This use case does not require to have sequences=85=94, and "When these seq= uences for handshake=85=94 * 3.9. (MPLS BFD Session Per ECMP Path) "One way to achieve BFD ses= sion per ECMP path of LSP is=85" * Note that if this document was maintained as a sustaining referenc= e, then it would be easier to edit and add the specifics of how the require= ments are satisfied. 3. Section 3. (Use Cases): =93This section outlines some use cases where= the existing mechanism may not be able to satisfy the requirements.=94 Ma= y not? Does that mean that for some of the use cases the existing mechanis= ms can satisfy the requirements? Which ones? Nits: 1. Missing references. * 1.1 "The reader is expected to be familiar with the BFD, IP, MPLS = and Segment Routing (SR) terminology and protocol constructs." * 3.7 "BFD multi-hop and BFD MPLS=85" 2. Section 3. (Use Cases). =93=85some of the use cases also be identify= the need for=85=94 ?? 3. Section 3.5. (BFD Efficient Operation Under Resource Constraints) =93= ?=94 4. Section 3.8. (Multiple BFD Sessions to Same Target) s/as relevant ne= twork nodes continuously transmitting BFD packets at negotiated rate/as rel= evant network nodes continuously transmit BFD packets at negotiated rates 5. Section 4. (Security Considerations) The statement made seems right,= but at least mention why. Related: are there no new security requirements= /use cases? --_000_D1E8019CC4866aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1397216E62C1BA46830BF2EAEC865B7A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi!

In general I believe that use case documents have a very limited purpose an= d lifetime.  While guiding the WG in the type of problems that need to= be solved is very valuable, the usefulness mostly ends there.

I would like to ask the WG to consider not publishing this document.  = Some of the reasons behind me asking for this consideration are that not al= l the use cases seem to add new requirements, they are just examples of dif= ferent instances of expressing the same need, and that there may be many more similar examples =97 this last point= from some of the text in the Introduction [1].  I think that it would= then be better to keep them all in a place where the WG can easily update = them (without going through the publication process), a wiki or a long-lived ID, for example.

I=92m talking about requirements bec= ause even though this document says that =93certain requirements could be derived to be used as reference=94, the S-BFD base document says that i= t =93extends BFD to provide solutions to use cases list= ed in [I-D.ietf-bfd-se= amless-use-case].=94  If solutions are created then it would be nice to clearly know what = the requirements are.

If there is still WG consensus to publish this document, I would like to se= e the readability improved and the requirements clarified.  See m= y detailed comments below.  I will keep the document in AD Evaluation = (and not return it to the WG) at least until a decision has been made.

Thanks!<= /span>

Alvaro.

[1] =93=85use cases c= ould be used as reference for certain requirements, it is outside the scope of this document to identify all of the requirements for all possible enhanc= ements."


Major:
  1. Requirements.  If there are going to be requirements listed in this do= cument, please be specific on what they are.  It would be helpful for = tracking if they were also clearly identified.  No need for normative = language, I=92m mostly looking for clarity and ease.  Some comments:
    • 3.1. (Unidirectional Forwarding Path Vali= dation) "The = primary requirement in this use case is to enable session establishment from source network entity to target network entity.=94  If this is the pr= imary requirement, what are the other ones?  Is the requirement itself= that only the source should have to be provisioned beforehand?
      • =
    • 3.2. (Validation of forwarding path prior= to traffic switching)  =93It=  will be desi= rable to perform BFD validation very quickly to allow applications to utilize dynamically created LSPs in a timely manner.=94  Is that t= he requirement that comes out of this use case?  Is it optional (=93de= sirable=94)?  What do =93very quickly=94 and =93in a timely manne= r" mean?  This section starts with a generic description of the use case, I=92m assuming the requirement is general as well and = not just applicable to =93dynamically created LSPs=94.
      • The use case in Section <= font face=3D"Calibri,sans-serif">3.3. (Centralized Traffic Engineering) see= ms to also be calling for the ability "to instantly verify a forwarding path=94.  What does =93instantly=94 mean?  Are there other requireme= nts that come from this section?
    • 3.4. (BFD in Centralized Segment Routing)=  =93In validating this use case, one of th= e requirements is to ensure the BFD packet's behavior is according to the requirement and monitoring of the segment<= font face=3D"Calibri,sans-serif">=85=94  I-D.geib-spring-oam-usecase doesn=92t mention BFD =97 I know it implies it in a more generic way.  For th= e purposes of this document, I don=92t think it=92s enough to to just = say that =93one of the requirements..is according to the requirements.= .of the segment=94 =97 in essence it seems like this document is = just pointing the reader to the other document to figure out what needs to be d= one.  Maybe a better reference for requirements is draft-ietf-spr= ing-sr-oam-requirement.  It would also be nice to at least highlight t= he places where this use case introduces new requirements and why.
    • 3.5. (BFD= Efficient Operation Under Resource Constraints) =93=85it is desirable for BFD to=85=94  = and 3.9. (MPLS BFD Session Per ECMP Path) "it may be desirable to= run in-band monitoring=85=94    Optional?
    • 3.6. (BFD for Anycast Address)  The = requirement here is ???
    • 3.= 7. (BFD Fault Isolation)  "If BFD had built-in fault isolation capability=85=94  and 3.8. (Multiple BFD Ses= sions to Same Target) "if a node w= as to run multiple BFD sessions to targets=85=94   Conditional form..

Minor:
  1. Some of the text needs to be cleaned up because it is repetitive.
    • Introduction: "Bidirectional Fo= rwarding Detection (BFD) is a lightweight protocol=85used to detect forwarding failures.  Various=  protocols and applications rely on BFD for failure detection.  Even though the protocol is simpl= e and lightweight, there are certain use cases, where faster setting up of sessions=85This document identifies use cases=85BFD was designed to be a lightweight "Hello= " protocol to detect data plane failures=85speed at which these sessions could be established=85This document s= pecifically identifies those cases= =85=94
    • Section 2. (Introduction to Seamless BFD): =93In order for BFD to be able to initially verify that a connection is valid=85such that this information can be used to verify that the connection is valid."
  3. 2. (Introduction to Seamless B= FD): "As an example of how Seamless BFD (S-BFD) might work=85=94
    • 3.1. (Unidirectional Forwarding Pa= th Validation): "But with uni= directional BFD,..=94, and "T= his translates to=85=94
      • 3.2. (Validation of forwarding p= ath prior to traffic switching): "This use case does not req= uire to have sequences=85=94, and "When these sequences for handshake=85= =94
    • 3.9. (MPLS BFD Session= Per ECMP Path)  "One way to achieve BFD session per ECMP path of LSP is=85"
      • Note that if this document was maintained as a sustaining reference, the= n it would be easier to edit and add the specifics of how the requirements are satisfied.
  4. Section 3. (Use Cases): =93This section outlines some use cases where the existing = mechanism may not be able to satisfy the requirements.=94  May not?  Does that mean t= hat for some of the use cases the existing mechanisms can satisfy the requi= rements?  Which ones?
Nits:
  1. Missing references.
    • 1.1 "The reader is expected to be familiar with the BFD, IP, MPLS and&= nbsp;Segment Routi= ng (SR) terminology and protocol constructs."
    • 3.7 "BFD mu= lti-hop and BFD MPLS=85"
  2. 3. (Use Cases). &nb= sp;=93=85some of the use cases also be ide= ntify the need for=85=94  ??
  3. Section 3.5. (BFD Efficient Operation Under Resource Constraint= s) =93?=94  
  4. Section 3.8. (Multiple BF= D Sessions to Same Target)  s/as relevant net= work nodes continuously transmitting BFD packets at negotiated rate/as relevant network nodes continuously transmit BFD packets at negotiated rates
  5. Section 4. (Security Considerations)  The stat= ement made seems right, but at least mention why.  Related: are there = no new security requirements/use cases?
--_000_D1E8019CC4866aretanaciscocom_-- From nobody Fri Sep 25 09:49:49 2015 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 3B71D1ACDFD; Fri, 25 Sep 2015 09:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 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, J_CHICKENPOX_39=0.6, 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 mG67V2esNh_t; Fri, 25 Sep 2015 09:49:42 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13DF01ACE02; Fri, 25 Sep 2015 09:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34417; q=dns/txt; s=iport; t=1443199772; x=1444409372; h=from:to:cc:subject:date:message-id:mime-version; bh=qMxYmctHxXvn7IJmykJuwD6cCq+YxHKyVls8FYjMvG0=; b=kvnSZNtwK4LvzaJtA1gFr5DXIBSSQaoIFNr0plfnr3aVYxxAmWj60++1 yc7jxfDe2z/PlESbYPDdDGR1amoeFa47GMMpnje3MHFoXkUFpWL+jChGh ciyrxH1MJnW2N+h6A15skzd9iL5Vo4zWYdCsbUIAND01zxmuiEvQPZEcp 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AlBQATegVW/5NdJa1dgldNgUPFMoEuOxEBAQEBAQEBgQqEJwQaXxIBQEAnBAENIIgTzCcBAQEBAQEBAwEBAQEBAQEBGoZzAYoJhDMFkkKDKgGNDIFPhDaDIY4bg203LIIRHIFUiQ2BBQEBAQ X-IronPort-AV: E=Sophos;i="5.17,587,1437436800"; d="scan'208,217";a="190737115" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP; 25 Sep 2015 16:49:30 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t8PGnUcd002176 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 25 Sep 2015 16:49:30 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 25 Sep 2015 11:49:29 -0500 Received: from xhc-aln-x07.cisco.com (173.36.12.81) by xch-rcd-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 25 Sep 2015 11:49:29 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.98]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0248.002; Fri, 25 Sep 2015 11:49:29 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" Subject: AD Review of draft-ietf-bfd-seamless-base Thread-Topic: AD Review of draft-ietf-bfd-seamless-base Thread-Index: AQHQ97IkT4lFfvKt5Uasfc9mskhFeQ== Date: Fri, 25 Sep 2015 16:49:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.20] Content-Type: multipart/alternative; boundary="_000_D22876B0D338Daretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 16:49:48 -0000 --_000_D22876B0D338Daretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi! In general, I think that this document could use being cleaned up and tight= ened; there are parts that could be clearer and better specified. For exam= ple, many of state variables in rfc5880 seem to apply here, but they are no= t explicitly mentioned, the document claims to solve the use cases (in I-D.= ietf-bfd-seamless-use-case), but is not explicit about how it does it, etc.= Please take a look at my Major comments below. As I mention in the review for draft-ietf-bfd-seamless-ip, please consider = merging the two documents. I will keep this document under AD Evaluation (= and not return it to the WG) unless the WG Chairs consider that it is neces= sary to WGLC the resulting document. Thanks! Alvaro. Major: 1. Section 1. (Introduction) says that "This document extends BFD to pro= vide solutions to use cases listed in [I-D.ietf-bfd-seamless-use-case].=94 = Maybe it=92s just me, but I fail to see how all the use cases are satisfie= d =97 in part because the requirements in I-D.ietf-bfd-seamless-use-case ar= e not clear (see my review for that document), and in part because this doc= ument isn=92t explicit about how the specification solves the use cases. F= or example, how does this document provide a solution for the use case in s= ection 3.6. (BFD for Anycast Address)? 2. Normative References * I-D.ietf-bfd-multipoint should clearly be Normative because of the= new bfd.SessionType state variable * I-D.ietf-bfd-generic-crypto-auth should also be Normative because = of how the Security Considerations are written: pointing to is as a =93MUST= ". Given that (as far as I can tell) there aren=92t implementations of I-D= .ietf-bfd-generic-crypto-auth, we could end up with a Normative reference t= hat blocks the publication of this document. I want to suggest that the co= mments be reworded as a suggestion or pointer to potential solutions, not a= s a mandate to use them. [Disclaimer: we will still need the SecDir to rev= iew.] 3. Related to 7.2.2 and 7.3.2 (see below for more), I=92m assuming that = all session variables are the same state variables defined in rfc5880, and = that there are no new S-BFD-specific variables. Is that correct? If so, t= hen many of my questions/comments below refer to the use of those variables= and their mention in the text. What seems to be different is not a specif= ic variable, but how it is maintained. 4. Section 7.2.2. (Transmission of S-BFD Control Packet by SBFDInitiator= ) * The header of the description uses a =93MUST=94, so the other rfc2= 119 keywords used later are redundant (as in another =93MUST=94) or in cont= radiction: what does =93MAY=94 mean in presence of a preceding =93MUST=94? * BTW, it may be easier to just point out the differences with respe= ct to Section 6.8.7. (Transmitting BFD Control Packets) in rfc5880. * "Diagnostic (Diag) MAY be set to appropriate value for communica= ting with peer=94 The obvious question is: which values? Section 7.4. (Di= agnostic Values) tries to address that, but it says that "Diagnostic value = in both directions MAY be set to a certain value=85details of such are outs= ide the scope of this specification.=94 What about bfd.LocalDiag? Are tho= se values still valid? As long as 7.4 is there, you could explain a little= bit more why this doesn=92t matter. * "State (Sta) Set to the value indicated by local state.=94 Woul= d that local state be bfd.SessionState, or is there a new state variable? * "Poll (P)=94 =85add "or 0 if not.=94 (?) * "Detect Mult MUST be set to a value describing locally used mult= iplier value.=94 Do you mean bfd.DetectMult? * "My Discriminator Set to value assigned by local node.=94 Do yo= u mean bfd.LocalDiscr? * "Your Discriminator Set to value corresponding to remote entity.= =94 Do you mean bfd.RemoteDiscr? BTW, I think you should explain how this= variable is initialized. * "Desired Min TX Interval MUST be set to a value describing local= desired minimum transmit interval.=94 Do you mean bfd.DesiredMinTxInterva= l? * You didn=92t say anything about the "Authentication Section=94. 5. Section 7.3.2. (Transmission of S-BFD Control Packet by SBFDReflector= ): note that some of the comments are different. * The header of the description uses a =93MUST=94, so the other rfc2= 119 keywords used later are redundant (as in another =93MUST=94) or in cont= radiction: what does =93MAY=94 mean in presence of a preceding =93MUST=94? * BTW, it may be easier to just point out the differences with respe= ct to Section 6.8.7. (Transmitting BFD Control Packets) in rfc5880. * "Diagnostic (Diag) MAY be set to appropriate value for communica= ting with peer=94 The obvious question is: which values? Section 7.4. (Di= agnostic Values) tries to address that, but it says that "Diagnostic value = in both directions MAY be set to a certain value=85details of such are outs= ide the scope of this specification.=94 What about bfd.LocalDiag? Are tho= se values still valid? As long as 7.4 is there, you could explain a little= bit more why this doesn=92t matter. * "State (Sta) MUST be set to UP or ADMINDOWN.=94 Even though the= states are not all of the ones in rfc5880, the state itself still refers t= o bfd.SessionState, right? It would be really nice to include a state mac= hine for the SBFDReflector (similar to the one in Section 7.2.1. (SBFDIniti= ator State Machine), where the states are clarified). BTW, the text also s= ays "Clarification of reflector BFD session state is described in Section 7= .8.=94, but that section doesn=92t really clarify anything related to the s= ession states. * Several fields are set to the value copied from the received packe= t (Detect Mult, My Discriminator, Your Discriminator and Desired Min TX Int= erval). I=92m assuming that all these values are copied into the state var= iables defined in rfc5880. What may change then is not the fact that Detec= t Mult (for example) is set to bfd.DetectMult, but how the variable is init= ialized/maintained. * "Required Min RX Interval =85how many incoming control packets t= his reflector BFD session can handle.=94 Over a period or time? If it end= up being different than bfd.RequiredMinRxInterval, then we=92ll need a new= state variable * You didn=92t say anything about the "Authentication Section=94. 6. Section 10. (S-BFD Echo Function) * =93=85it is RECOMMENDED that the "Required Min Echo RX Interval=94= field simply be set to zero in both directions.=94, but Section 7.3.2. (Tr= ansmission of S-BFD Control Packet by SBFDReflector) says about the same f= ield that "If device supports looping back S-BFD echo packets=94 then it "M= UST set non-zero value desired by local device.=94 Those two statements a= re in contradiction. * Unlike rfc5880, this document doesn=92t explicitly mention that "S= ome form of authentication SHOULD be included, since Echo packets may be sp= oofed.=94 The recommendation of sending both S-BFD control and echo packe= ts points at alleviating some of the spoofing concerns even though they are= independent packets (in other words: the Echo packet can still u-turn at a= different node). Please include a discussion of the alleviated security c= oncern in the Security Considerations (since it is different than rfc5880).= Also, it would be nice if it was mentioned explicitly whether authenticat= ion for Echo packets is needed/recommended or not. 7. Section 11. (Security Considerations) * "crypto sequence number=94 What are you referring to? I=92m gues= sing the Sequence Number field in the Authentication Section =97 is that a = good guess? Please be specific and include a reference. * The text says that the "SBFDReflector MUST compute the Authenticat= ion data=94, but that it "MUST NOT look at the crypto sequence number=94. = Is that a contradiction? As defined in rfc5880, the Authentication Data se= ems to include everything in the Authentication Section, including the sequ= ence number. * Why isn=92t the =93loop problem=94 in Appendix A mentioned? 8. Nowhere in this document (or draft-ietf-bfd-seamless-ip) is congestio= n mentioned. rfc5880 talks about some of the considerations. Are there ne= w congestion-related considerations that arise because of eliminating some = of the negotiation aspects? Thinking out loud: if a session doesn=92t have= to be established (and everyone knows a remote discriminator), then there= =92s a possibility of more nodes sending traffic to a specific reflector (j= ust as an example). Please include some text indicating any congestion iss= ues =97 or at least explaining why there aren=92t any new ones. Minor: 1. Updates to rfc5880. This document is marked as updating rfc5880. It= would be nice to have a section (or maybe just a couple of sentences) summ= arizing what the updates are. 2. The base document is not describing the operation in IP and MPLS envi= ronments, are the references to rfc5881, rfc5883, rfc5884 and rfc5885 need= ed in 7.3 and 11? And do the procedures and security considerations really= apply? 3. Section 4.1. (S-BFD Discriminator Uniqueness) I think the text in th= is section is a little confusing. The requirement (the "S-BFD discriminato= r=85MUST be unique within an administrative domain=94) is clearly stated at= the start, but then the justification of why goes into how is IP is used (= with no reference to where S-BFD for IP is specified) and concludes that (i= n that case) the "S-BFD discriminator only has to be unique within a local = node=94 =97 at first read it sounds like there is a contradiction in the te= xt. The paragraph closes with a reiteration of the uniqueness. Please cla= rify =97 maybe specifically state that the discussion (maybe in a separate = paragraph) is to justify the uniqueness.. 4. Section 6.2. (State Variable Initialization and Maintenance) "Some s= tate variables=85=94 But only one is listed. Is this the only one? Pleas= e include a reference to rfc5880 (for ease of readability). 5. Section 7.1. (Demultiplexing of S-BFD Control Packet) * What happens if the =93your discriminator=94 field doesn=92t match= an existing SBFDReflector session? I think the piece where the packet is = discarded is missing. Section 7.3.1. (Responder Demultiplexing) does say t= hat in that case the packet "MUST NOT be considered for this mechanism=94. = Does that mean that the packets are to be discarded, or something else? * Is there a reason for having 7.3.1? IOW, can anything extra there= be included in 7.1? * It may be the indenting, but it looks like the logic says: if the = packet doesn=92t correspond to an SBFDInitiator session, then discard it. * "More details on S-BFD control packet demultiplexing are described= in relevant S-BFD data plane documents.=94 Section 4. (S-BFD Control Pack= et Demultiplexing) of draft-ietf-bfd-seamless-ip actually has less details:= it doesn=92t include the step about discarding if there=92s no correspondi= ng SBFDInitiator session, nor the last ELSE. 6. Appendix A. (Loop Problem) s/reflectors MUST set the TTL/reflectors = must set the TTL This text is not the normative text, put a reference to= rfc5880 instead. Nits: 1. Missing references in Terminology: "The reader is expected to be fami= liar with the BFD, IP and MPLS terminologies and protocol constructs." 2. Section 3. (Seamless BFD Overview): "The IS-IS with..=94 The IS-IS = what? 3. Section 7.2. (Initiator Procedures) * The example and the figure seem out of place in this section as th= e responder procedures haven=92t been introduced yet. * s/ASCII art/Figure 3 4. Section 7.6. (Control Plane Independent (C)) does not seem to say any= thing different from rfc5880. Maybe we can get rid of it. 5. Maybe Section 7.7. (Additional SBFDInitiator Behaviors) should be a s= ubsection of Section 7.2. (Initiator Procedures). * The same for 7.8. (Additional SBFDReflector Behaviors) and 7.3. (R= esponder Procedures) 6. Section 8. (Scaling Aspect) The text indirectly implies that the sca= ling is better by saying that the number of sessions is less.. I understand= the point, but it just sounds like a superfluous section to me. 7. Section 9. (Co-existence with Classical BFD Sessions) is another supe= rfluous section; there=92s nothing here that you couldn=92t have said in 7.= 1. --_000_D22876B0D338Daretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0D812D2B2BD35341A6972BE98CD1908E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi!

In general, I think that this document could use being cleaned up and tight= ened; there are parts that could be clearer and better specified.  For= example, many of state variables in rfc5880 seem to apply here, but they a= re not explicitly mentioned, the document claims to solve the use cases (in I-D.ietf-bfd-seamless-use-case), but is = not explicit about how it does it, etc.  Please take a look at my Majo= r comments below.

As I mention in the review for draft-ietf-bfd-seamless-ip, please consider = merging the two documents.  I will keep this document under AD Evaluat= ion (and not return it to the WG) unless the WG Chairs consider that it is = necessary to WGLC the resulting document.

Thanks!

Alvaro.


Major:
  1. Section 1. (Introduction) says that = "This document extends BFD to provide solutions to use cas= es listed in [I-D.ietf-bfd-se= amless-use-case].=94  Maybe it=92s just me, but I fail to see how all the use cases a= re satisfied =97 in part because the requirements in I-D.ietf-bfd-seamless-use-case are not cl= ear (see my review for that document), and in part because this document isn=92t explicit about how the specification solves the use cases= .  For example, how does this document provide a solution for the use = case in section 3.6. (BFD for= Anycast Address)?
  2. Normative References
    • I-D.ietf-bfd-multipoint should clearly be= Normative because of the new bfd.SessionType state variable
      • I-D.ietf-bfd-generic-crypto-auth = should also be Normative because of how the Security Considerations are wri= tten: pointing to is as a =93MUST".  Given that (as far as I can tell) there aren=92t implementation= s of I-D.ietf-bfd-generic-cry= pto-auth, we could end up with a Normative reference that blocks the public= ation of this document.  I want to suggest that the comments be reworded as a suggestion or pointer to potential solutions, no= t as a mandate to use them.  [Disclaimer: we will still need the SecDi= r to review.]
  3. Related to 7.2.2 and 7.3.2 (see below for= more), I=92m assuming that all session variables are the same state v= ariables defined in rfc5880, and that there are no new S-BFD-specific varia= bles.  Is that correct?  If so, then many of my questions/comments below refer to the use of those variables and the= ir mention in the text.  What seems to be different is not a specific = variable, but how it is maintained.
  4. Section 7.2.2. (Transmission of S-BFD Control Packet by SBFDInitiator)=
    • The header of the description uses a&= nbsp;=93MUST=94, so the other rfc2119 keywords used later are redundant (as= in another =93MUST=94) or in contradiction:  what does =93M= AY=94 mean in presence of a preceding =93MUST=94?  
      • BTW, it may be easier to just point out= the differences with respect to Section 6.8.7. (Transmitting BFD Control Packets) in rfc5880.
    • "Diagnostic (Diag)   <= /font>MAY be set to appropriate value for= communicating with peer=94  The obvious question is: which values? &n= bsp;Section 7.4. (Diagnostic Values) tries to address that, but it says that "Diagnostic va= lue in both directions MAY be set to a certain value=85details of such are outside the scope of this specification.= =94  What about bfd.Loca= lDiag?  Are those values still valid?  As long as 7.4 is there, you cou= ld explain a little bit more why this doesn=92t matter.  
      • <= li>"State (Sta)   S= et to the value indicated by local state.=94  Would that local state b= e bfd.SessionState, or is there a new state variable?  
    • "Poll (P)=94&= nbsp;=85add "or 0 if not.=94  (?)
    • "Detec= t Mult   MUST be set to = a value describing locally used multiplier value.=94  Do you mean=  bfd.DetectMult?
      • <= li>"My Discriminator   Set to value assigned by local node.=94 &n= bsp;Do you mean bfd.LocalDiscr? 
    • "Your Discriminator=   Set to value corresponding to remote entity.=94  Do you mean&n= bsp;bfd.RemoteDiscr?  BTW, I think you should explain how this variabl= e is initialized.
    • "Desired Min TX Interval   MUST be set = to a value describing local desired minimum transmit interval.=94  Do = you mean bfd.DesiredMinTxInterval?
    • You didn=92t say anything a= bout the "Authentication Section=94.
  5. Section 7.3.2. (Transmission of S-BFD Con= trol Packet by SBFDReflector): note that some of the comments are different= .
    • The header of the description uses a =93MUST=94, so the other rfc2119 k= eywords used later are redundant (as in another =93MUST=94) or in contradic= tion:  what does =93MAY=94 mean in presence of a preceding =93MUST=94?=  
    • BTW, it may be easier to just point out the differences wit= h respect to Section 6.8.7. (Transmitting BFD Control Packets) in rfc5880.<= /li>
    • "Diagnostic (Diag)   MAY be set to appropriate value for = communicating with peer=94  The obvious question is: which values? &nb= sp;Section 7.4. (Diagnostic Values) tries to address that, but it says that= "Diagnostic value in both directions MAY be set to a certain value=85details of such are outside the scope of this specification.=94 &n= bsp;What about bfd.LocalDiag?  Are those values still valid?  As long as 7.4 is there, you could explain = a little bit more why this doesn=92t matter. 
    • "Sta= te (Sta)   MUST be set to UP or ADMINDOWN.=94  Even though the st= ates are not all of the ones in rfc5880, the state itself still refers to&n= bsp;bfd.SessionState, right?   It would be really nice to include a st= ate machine for the SBFDReflector (similar to the one in Section 7.2.1. (SBFDInitiator State Machine), where the st= ates are clarified).  BTW, the text also says "Clarification of r= eflector BFD session state is described in Section 7.8.=94, but that sectio= n doesn=92t really clarify anything related to the session states.
    • Several fields a= re set to the value copied from the received packet (Detect Mult, My Discri= minator, Your Discriminator and Desired Min TX Interval).  I=92m assum= ing that all these values are copied into the state variables defined in rfc5880.  What may change then is not the fact that <= /font>Detect Mult (for example) is set to= bfd.DetectMult, but how the variable is initialized/maintained.
    • "Required Min RX Interva= l   =85how many incoming contro= l packets this reflector BFD session can handle.=94  Over a period or = time?  If it end up being different than bfd.RequiredMinRxInterval, then we=92ll need a new state variable
    • You didn=92t say any= thing about the "Authentication Section=94.
  6. Section 10. (S-BFD Echo Funct= ion)
    • =93=85it is RECOMMENDED that the "Required Min Echo RX Interval=94=  field simply be set to = zero in both directions.=94, but Section 7.3.2. (Transmission of S-BFD Control Packet by SBFDReflector) says  about the same field = that "If device supports looping bac= k S-BFD echo packets=94 then it "MUST set non-zero value desired by lo= cal device.=94   Those two statements are in contradiction.
    • Unlike rfc5880, this document doesn= =92t explicitly mention that "Some form of authentication SHOUL= D be included, since Echo packets ma= y be spoofed.=94   The recommendation of sending both S-BFD control and echo packets points at alleviating some of the spoofing = concerns even though they are independent packets (in other words: the Echo= packet can still u-turn at a different node).  Please include a discu= ssion of the alleviated security concern in the Security Considerations (since it is different than rfc5880).  = ;Also, it would be nice if it was mentioned explicitly whether authenticati= on for Echo packets is needed/recommended or not.
  7. Section 11. (Security Considerations)
    • "crypto sequence numbe= r=94  What are you referring to?  I=92m guessing the Sequence Num= ber field in the Authentication Section =97 is that a good guess? &nbs= p;Please be specific and include a reference.
    • The text says that the "SBFDReflector MUST comp= ute the Authentication data=94, but that it "MUST NOT look at the cryp= to sequence number=94.  Is that a contradiction?  As defined in r= fc5880, the Authentication Data seems to include everything in the Authentication Section, including the sequenc= e number.
    • Why isn=92t t= he =93loop problem=94 in Appendix A mentioned?
  8. Nowhere in this document (or draft-ietf-bfd-seamless-ip) is congestion ment= ioned.  rfc5880 talks about some of the considerations.  Are ther= e new congestion-related considerations that arise because of eliminating s= ome of the negotiation aspects?  Thinking out loud: if a session doesn=92t have to be established (and everyone know= s a remote discriminator), then there=92s a possibility of more nodes sendi= ng traffic to a specific reflector (just as an example).  Please inclu= de some text indicating any congestion issues =97 or at least explaining why there aren=92t any new ones.


Minor:
  1. Updates to rfc5880.  This document is marked as updating rfc5880. &nbs= p;It would be nice to have a section (or maybe just a couple of sentences) = summarizing what the updates are.
  2. The base document is not describing the o= peration in IP and MPLS environments, are  the references to rfc5881, = rfc5883, rfc5884 and rfc5885 = needed in 7.3 and 11?  And do the procedures and security considerations really apply?
  3. Section 4.1. (S-BFD Discriminator Uniqueness)  I think the text i= n this section is a little confusing.  The requirement (the "S-BFD discriminator=85MUST be unique within a= n administrative domain=94) is clearly stated at the start, but then the justification of why goes into how is IP is used (with no ref= erence to where S-BFD for IP is specified) and concludes that (in that case= ) the "S-BFD discriminator on= ly has to be unique within a local node=94 =97 at first read it sounds like there is a contradiction in the text.  T= he paragraph closes with a reiteration of the uniqueness.  Please clar= ify =97 maybe specifically state that the discussion (maybe in a separ= ate paragraph) is to justify the uniqueness..
  4. Section 6.2. (State Variable = Initialization and Maintenance)  "Some state variables=85=94  But only one is listed.  Is this = the only one?  Please include a reference to rfc5880 (for ease of readability).
  5. Sect= ion 7.1. (Demultiplexing of S-BFD Control Packet)  
    • What happens if the =93your disc= riminator=94 field doesn=92t match an existing SBFDReflector session?  I think the piece wher= e the packet is discarded is missing.  Section 7.3.1. (Responder Demultiplexing) does say that in that case the packet &quo= t;MUST NOT be considered for this = mechanism=94.  Does that mean that the packets are to be discarded, or= something else?
    • Is there a reason for having 7.3.1?  I= OW, can anything extra there be included in 7.1?
    • It may be the indenting, but it looks like the logic says: = if the packet doesn=92t correspond to an SBFDInitiator session, then discard it.
    • "More details on S-BFD control packet= demultiplexing are described in rel= evant S-BFD data plane documents.=94  Section 4. (S-BFD Control Packet Demultiplexing) of draft-ietf-bfd-seamless-i= p actually has less details: it doesn=92t include the step about discarding= if there=92s no corresponding SBFDInitiator session, nor the last ELSE.
  6. Appendix A. (Loop Problem)  s/reflectors MUST set the TTL/ref= lectors must set the TTL    This text is not the normative text, = put a reference to rfc5880 instead.

Nits:
  1. Missing references in Terminology: "The reader is expe= cted to be familiar with the BFD, IP and MPLS terminologies and protoc= ol constructs." 
  2. Sectio= n 3. (Seamless BFD Overview): "The IS-IS with..=94   The IS-IS wh= at?
  3. Section 7.= 2. (Initiator Procedures)
    • The example and the figure seem out o= f place in this section as the responder procedures haven=92t been introduc= ed yet.
    • s/ASCII art/Figure 3
  4. Section 7.6. (Control Plane Independent (C)) does not seem = to say anything different from rfc5880.  Maybe we can get rid of it.
  5. Maybe Section <= font face=3D"Calibri,sans-serif">7.7. (Additional SBFDInitiator Behaviors) = should be a subsection of Section 7.2. (Initiator Procedures).
    • The same for 7.8. (Additional SBFDReflector Behaviors) and = 7.3. (Responder Procedures)
  6. Section 8. (Scaling Aspect)  The text indirectly impli= es that the scaling is better by saying that the number of sessions is less= .. I understand the point, but it just sounds like a superfluous section to me.
  7. Section 9.= (Co-existence with Classical BFD Sessions) is another superfluous section;= there=92s nothing here that you couldn=92t have said in 7.1.
    8. --_000_D22876B0D338Daretanaciscocom_-- From nobody Fri Sep 25 09:49:51 2015 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 EC1DC1ACE13; Fri, 25 Sep 2015 09:49:49 -0700 (PDT) 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 f2sBY6ZRXYGh; Fri, 25 Sep 2015 09:49:48 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D9911ACDFF; Fri, 25 Sep 2015 09:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11954; q=dns/txt; s=iport; t=1443199778; x=1444409378; h=from:to:cc:subject:date:message-id:mime-version; bh=AOxZirb3TRmHBAlB9A/hN3ICx8Abdo+HNe7s/ZTShpM=; b=Cqq+tzxvllopIA+zLw4247/0IBiHoRBpRAFghlWLchPK3CyDc5mGa6j9 84/5qugRKrn2ni515Pq3lkFqNv1mwIqM+NgKGrjpnRa5R2UITVEHK/tgC RkCqvxf0ixAlN2M6Ml7W6IqpewL8psb/+PpXLZTZ8V/jqJZiPZDU3jzhz E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D/AQATegVW/4gNJK1dgldNgUO9MAENh3SBLjgUAQEBAQEBAYEKhCcEeRIBgQAnBAENiDPMJwEBAQEBAQQBAQEBAQEBAQEZhnMBigmEMwWSQoMqAY0MgU+ENpUpHwEBQoQBiQ2BBQEBAQ X-IronPort-AV: E=Sophos; i="5.17,587,1437436800"; d="scan'208,217"; a="35527278" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP; 25 Sep 2015 16:49:37 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t8PGnbXi031221 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 25 Sep 2015 16:49:37 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 25 Sep 2015 11:49:36 -0500 Received: from xhc-aln-x15.cisco.com (173.36.12.89) by xch-rcd-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 25 Sep 2015 11:49:36 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.98]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0248.002; Fri, 25 Sep 2015 11:49:36 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-bfd-seamless-ip@ietf.org" , "bfd-chairs@ietf.org" Subject: AD Review of draft-ietf-bfd-seamless-ip Thread-Topic: AD Review of draft-ietf-bfd-seamless-ip Thread-Index: AQHQ97Ip8fkkgLz8RkWcTDCbHWzODQ== Date: Fri, 25 Sep 2015 16:49:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.20] Content-Type: multipart/alternative; boundary="_000_D20CE635CDAC6aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 16:49:50 -0000 --_000_D20CE635CDAC6aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi! This is a nice and short document. In fact it is so short that I wonder wh= y it isn=92t just part of draft-ietf-bfd-seamless-base. Besides indicating= specific addresses/port numbers to use, there is no significant transport-= protocol-specific contribution beyond what is already in the base document. Please consider merging this document into draft-ietf-bfd-seamless-base. I= will keep this document in AD Evaluation (and not return it to the WG) at = least until a decision has been made. Thanks! Alvaro. Major: 1. Nowhere in this document (or draft-ietf-bfd-seamless-base) is congest= ion mentioned. There is very little in rfc5881 (and nothing in rfc5884) th= at adds to what rfc5880 covers, which makes me think that a generic approac= h might be better (i.e. in draft-ietf-bfd-seamless-base). Are there new c= ongestion-related transport-protocol-specific considerations that arise whe= n using S-BFD? Please include some text indicating any congestion issues = =97 or at least explaining why there aren=92t any new ones. Minor: 1. Section 4. (S-BFD Control Packet Demultiplexing). The process descri= bed here doesn=92t match what is specified in Section 7.1. (Demultiplexing = of S-BFD Control Packet) of draft-ietf-bfd-seamless-base. 2. I think that Section 5.2. (Target vs. Remote Entity (S-BFD Discrimina= tor)) needs to be clarified. * =93=85to perform a continuity test towards a target but to a trans= it network node.=94 I think there might be a =93not=94 left out somewhere,= maybe you meant =93=85to not perform a continuity test towards a remote en= tity but to a transit network node=94. ?? * What is the "TTL expiry exception path=94? Is that an implementat= ion-specific construct? * =93=85MUST allow received S-BFD control=85=94 This is a change fr= om rfc5880, so we should mark this document as updating it. 3. Section 6.1. (Details of S-BFD Control Packet Sent by SBFDReflector) * "Source IP address=85MUST be set to a local IP address=85=94 Any = address? Why isn=92t this copied from the received packet? * "TTL field of the IP header SHOULD be set to 255.=94 From Section= 5.2 I understand why =93SHOULD=94 is used for the Initiator, but why is th= is not a =93MUST=94 for the SBFDReflector? Nits: 1. Missing references * Introduction: "The reader is expected to be familiar with the IP, = MPLS BFD and S-BFD terminologies and protocol constructs.=94 * Security Considerations: "Martian addresses" 2. Section 2. (S-BFD UDP Port) * s/can be of any/can be any * "The source port number MAY be unique among all SBFDInitiator sess= ions on the system.=94 I don=92t think we need the =93MAY=94 there. 3. Section 5.1. (Details of S-BFD Control Packet Sent by SBFDInitiator) * s/UDP source port MUST be set to a value that is not 7784/UDP sour= ce port MUST NOT be set to 7784 * "The destination IP address MUST be chosen from=85=94 Please add = a reference to where the blocks came from. 4. Section 5.2. (Target vs. Remote Entity (S-BFD Discriminator)) may be = better off as 5.1.1. --_000_D20CE635CDAC6aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <763CFBE777E1764589DD017614F76EF2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
    Hi!

    This is a nice and short document.  In fact it is so short that I wond= er why it isn=92t just part of draft-ietf-bfd-seamless-base.  Besides = indicating specific addresses/port numbers to use, there is no significant = transport-protocol-specific contribution beyond what is already in the base document.  

    Please consider merging this document into draft-ietf-bfd-seamless-base. &n= bsp;I will keep this document in AD Evaluation (and not return it to the WG= ) at least until a decision has been made.

    Thanks!

    Alvaro.

    Major:
    1. Nowhere in this document (or draf= t-ietf-bfd-seamless-base) is conge= stion mentioned.  There is very little in rfc5881 (and nothing in rfc5884) that adds to what rfc5880 covers, which make= s me think that a generic approach might be better (i.e. in  draft-ietf= -bfd-seamless-base).  Are there new congestion-related transport-protocol-specific conside= rations that arise when using S-BFD?  Please include some text indicat= ing any congestion issues =97 or at least explaining why there aren=92t any= new ones.

    Minor:
    1. Section 4. (S-BFD Control Packet Demultiplexing).  The process de= scribed here doesn=92t match what is specified in Section 7.1. (Demult= iplexing of S-BFD Control Packet) of draft-ietf-bfd-seamless-base.
    2. I think that Section 5.2. (Target vs. Remote Entity (S-BFD Discriminat= or)) needs to be clarified.
      • =93=85to perform a continuity test towards a target but to a transit n= etwork node.=94  I think there might be a =93not=94 left out some= where, maybe you meant =93=85= to not perform = a continuity test towards a remote entity but to a transit network node=94. ??
      • What is the "TTL expiry = exception path=94?  Is that an implementation-specific construct? &nbs= p;
      • =93=85MUST allow received S-BFD control=85=94  This is a change from rfc5880, so we s= hould mark this document as updating it.
    3. Section 6.1. (Details of S-BFD Control Packet Sent by SBFDR= eflector)  
      • "Source IP address=85MUST be set to a local IP address=85=94  Any address?  Why isn=92t t= his copied from the received packet?
      • "TTL field of the = IP header SHOULD be set to 255.=94  From Section 5.2 I understand= why =93SHOULD=94 is used for the Initiator, but why is this not a&nbs= p;=93MUST=94 for the SBFDRefl= ector?

    Nits:
    1. Missing references
      • Introduction: "The reader is expected to be familiar with the IP, MPLS= BFD and S-BFD terminologies and protocol constructs.=94
      • Security Considerations: "Martian addresses"
    2. Section 2. (S-BFD UDP Port)
      • s/can be of any/can be any
      • "The source port number MAY be unique among all SBFDInitia= tor sessions on the system.=94  I don=92t think we need the =93MA= Y=94 there.
    3. Section 5.1. (Details of S-BFD Control Packet Sent by = SBFDInitiator)
      • s/UDP source port MUST be set to a value that is not = 7784/UDP source port MUST NOT be set to 7784
      • "The desti= nation IP address MUST be chosen from=85=94  Please add a reference to= where the blocks came from.
    4. Section 5.2. (Target vs. Remote Entity (S-BFD Discrimi= nator)) may be better off as 5.1.1.
    --_000_D20CE635CDAC6aretanaciscocom_-- From nobody Fri Sep 25 10:03:19 2015 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 61D201A7022; Fri, 25 Sep 2015 10:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 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, HTML_OBFUSCATE_05_10=0.26, 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 I9ud9D5cpc9r; Fri, 25 Sep 2015 10:03:14 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (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 BC5D51ACE1C; Fri, 25 Sep 2015 10:02:40 -0700 (PDT) Received: by pacfv12 with SMTP id fv12so112715748pac.2; Fri, 25 Sep 2015 10:02:40 -0700 (PDT) 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=TocSU6wPPpB2WnSlB53ELFmkjXz5xC0TsVhykRqe91c=; b=dI2FIp32YK9cOeVvTGHiqOcIdrHL2FGl073g42yjZszP43MRUQEfZt1iZfzvY87hfi rxgaCdB3Ums2dJqq0wGKZo8MjXQXjRwLTXFVMMKJjtIKuuYnt+udcNG3XG6pSB2SgEDX nZIBFqxac35ybsWwJa4ThftgkZfvXxX/a9HvSYjTbYC1RnoYHW/omjLyZfZ0bnPu4PWW eRCzunzA6P0omE6lFMQRrG51+KJ6EAHPFGJ3QzbBv/mpLjdzcwlIp5XUnWRR5093b9f8 x31E1LRYUMFM77usyZ2FifWZ1g/1jTLfR8NJ+L8tE4fwkFAHPpLv+jYGSY4FTYVkeGTg Qwyg== X-Received: by 10.68.69.79 with SMTP id c15mr8587647pbu.90.1443200560153; Fri, 25 Sep 2015 10:02:40 -0700 (PDT) Received: from dhcp-172-17-94-207.mtv.corp.google.com ([172.17.94.207]) by smtp.gmail.com with ESMTPSA id hx2sm4850035pbc.67.2015.09.25.10.02.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Sep 2015 10:02:39 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9E3603E9-BA2B-40DB-93E0-AA46C27EADE3" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: AD Review of draft-ietf-bfd-seamless-use-case From: aldrin ietf In-Reply-To: Date: Fri, 25 Sep 2015 10:02:37 -0700 Message-Id: <713AD0F3-FD85-440F-A59C-40E64B10E4CA@gmail.com> References: To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@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: Fri, 25 Sep 2015 17:03:17 -0000 --Apple-Mail=_9E3603E9-BA2B-40DB-93E0-AA46C27EADE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Alvaro, Thanks for the comments. Haven=92t read the review comments, but would = like to respond to general comments. - Whether to stop Use case document to proceed further or nor, is the = comment specific to this document or general comment applicable to all = use case documents? - If use you think use case documents has limited purposes, then it = should be discouraged at the beginning and shouldn=92t even be adopted = in the first place. It is not prudent to invest time, for = individual/group, for the things which are going to be dropped. - I do not think use case has to document requirements explicitly. If it = has to, then what should requirement document contain? If the plan is to = merge both, this should be discussed across, not just BFD, to get an = agreement. I see there are lot of use case, requirement docs in various = WG=92s.=20 cheers -sam > On Sep 25, 2015, at 9:49 AM, Alvaro Retana (aretana) = wrote: >=20 > Hi! >=20 > In general I believe that use case documents have a very limited = purpose and lifetime. While guiding the WG in the type of problems that = need to be solved is very valuable, the usefulness mostly ends there. >=20 > I would like to ask the WG to consider not publishing this document. = Some of the reasons behind me asking for this consideration are that not = all the use cases seem to add new requirements, they are just examples = of different instances of expressing the same need, and that there may = be many more similar examples =97 this last point from some of the text = in the Introduction [1]. I think that it would then be better to keep = them all in a place where the WG can easily update them (without going = through the publication process), a wiki or a long-lived ID, for = example. >=20 > I=92m talking about requirements because even though this document = says that =93certain requirements could be derived to be used as = reference=94, the S-BFD base document says that it =93extends BFD to = provide solutions to use cases listed in = [I-D.ietf-bfd-seamless-use-case].=94 If solutions are created then it = would be nice to clearly know what the requirements are. >=20 > If there is still WG consensus to publish this document, I would like = to see the readability improved and the requirements clarified. See my = detailed comments below. I will keep the document in AD Evaluation (and = not return it to the WG) at least until a decision has been made. >=20 > Thanks! >=20 > Alvaro. >=20 > [1] =93=85use cases could be used as reference for certain = requirements, it is outside the scope of this document to identify all = of the requirements for all possible enhancements." >=20 >=20 > Major: > Requirements. If there are going to be requirements listed in this = document, please be specific on what they are. It would be helpful for = tracking if they were also clearly identified. No need for normative = language, I=92m mostly looking for clarity and ease. Some comments: > 3.1. (Unidirectional Forwarding Path Validation) "The primary = requirement in this use case is to enable session establishment from = source network entity to target network entity.=94 If this is the = primary requirement, what are the other ones? Is the requirement itself = that only the source should have to be provisioned beforehand? > 3.2. (Validation of forwarding path prior to traffic switching) =93It = will be desirable to perform BFD validation very quickly to allow = applications to utilize dynamically created LSPs in a timely manner.=94 = Is that the requirement that comes out of this use case? Is it optional = (=93desirable=94)? What do =93very quickly=94 and =93in a timely = manner" mean? This section starts with a generic description of the use = case, I=92m assuming the requirement is general as well and not just = applicable to =93dynamically created LSPs=94. > The use case in Section 3.3. (Centralized Traffic Engineering) seems = to also be calling for the ability "to instantly verify a forwarding = path=94. What does =93instantly=94 mean? Are there other requirements = that come from this section? > 3.4. (BFD in Centralized Segment Routing) =93In validating this use = case, one of the requirements is to ensure the BFD packet's behavior is = according to the requirement and monitoring of the segment=85=94 = I-D.geib-spring-oam-usecase doesn=92t mention BFD =97 I know it implies = it in a more generic way. For the purposes of this document, I don=92t = think it=92s enough to to just say that =93one of the requirements..is = according to the requirements..of the segment=94 =97 in essence it seems = like this document is just pointing the reader to the other document to = figure out what needs to be done. Maybe a better reference for = requirements is draft-ietf-spring-sr-oam-requirement. It would also be = nice to at least highlight the places where this use case introduces new = requirements and why. > 3.5. (BFD Efficient Operation Under Resource Constraints) =93=85it is = desirable for BFD to=85=94 and 3.9. (MPLS BFD Session Per ECMP Path) = "it may be desirable to run in-band monitoring=85=94 Optional? > 3.6. (BFD for Anycast Address) The requirement here is ??? > 3.7. (BFD Fault Isolation) "If BFD had built-in fault isolation = capability=85=94 and 3.8. (Multiple BFD Sessions to Same Target) "if a = node was to run multiple BFD sessions to targets=85=94 Conditional = form.. >=20 > Minor: > Some of the text needs to be cleaned up because it is repetitive. > Introduction: "Bidirectional Forwarding Detection (BFD) is a = lightweight protocol=85used to detect forwarding failures. Various = protocols and applications rely on BFD for failure detection. Even = though the protocol is simple and lightweight, there are certain use = cases, where faster setting up of sessions=85This document identifies = use cases=85BFD was designed to be a lightweight "Hello" protocol to = detect data plane failures=85speed at which these sessions could be = established=85This document specifically identifies those cases=85=94 > Section 2. (Introduction to Seamless BFD): =93In order for BFD to be = able to initially verify that a connection is valid=85such that this = information can be used to verify that the connection is valid." > Solutions are outside the scope of this document. There are several = places where the text starts to describe the (potential at this point) = behavior of S-BFD. That should be left to the solution document. Some = examples: > 2. (Introduction to Seamless BFD): "As an example of how Seamless BFD = (S-BFD) might work=85=94 > 3.1. (Unidirectional Forwarding Path Validation): "But with = unidirectional BFD,..=94, and "This translates to=85=94 > 3.2. (Validation of forwarding path prior to traffic switching): "This = use case does not require to have sequences=85=94, and "When these = sequences for handshake=85=94 > 3.9. (MPLS BFD Session Per ECMP Path) "One way to achieve BFD session = per ECMP path of LSP is=85" > Note that if this document was maintained as a sustaining reference, = then it would be easier to edit and add the specifics of how the = requirements are satisfied. > Section 3. (Use Cases): =93This section outlines some use cases where = the existing mechanism may not be able to satisfy the requirements.=94 = May not? Does that mean that for some of the use cases the existing = mechanisms can satisfy the requirements? Which ones? > Nits: > Missing references. > 1.1 "The reader is expected to be familiar with the BFD, IP, MPLS and = Segment Routing (SR) terminology and protocol constructs." > 3.7 "BFD multi-hop and BFD MPLS=85" > Section 3. (Use Cases). =93=85some of the use cases also be identify = the need for=85=94 ?? > Section 3.5. (BFD Efficient Operation Under Resource Constraints) =93?=94= =20 > Section 3.8. (Multiple BFD Sessions to Same Target) s/as relevant = network nodes continuously transmitting BFD packets at negotiated = rate/as relevant network nodes continuously transmit BFD packets at = negotiated rates > Section 4. (Security Considerations) The statement made seems right, = but at least mention why. Related: are there no new security = requirements/use cases? --Apple-Mail=_9E3603E9-BA2B-40DB-93E0-AA46C27EADE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Alvaro,

    Thanks for the comments. Haven=92t read the review comments, = but would like to respond to general comments.

    - Whether to stop Use case document to = proceed further or nor, is the comment specific to this document or = general comment applicable to all use case documents?
    - If use you think use case documents has limited purposes, = then it should be discouraged at the beginning and shouldn=92t even be = adopted in the first place. It is not prudent to invest time, for = individual/group, for the things which are going to be = dropped.
    - I do not think use case has to document = requirements explicitly. If it has to, then what should requirement = document contain? If the plan is to merge both, this should be discussed = across, not just BFD, to get an agreement. I see there are lot of use = case, requirement docs in various WG=92s. 

    cheers
    -sam
    On Sep 25, 2015, at 9:49 AM, Alvaro Retana = (aretana) <aretana@cisco.com> wrote:

    Hi!

    In general I believe that use case documents have a very limited purpose = and lifetime.  While guiding the WG in the type of problems that = need to be solved is very valuable, the usefulness mostly ends = there.

    I would like to ask the WG to consider not publishing this document. =  Some of the reasons behind me asking for this consideration are = that not all the use cases seem to add new requirements, they are just = examples of different instances of expressing the same need, and that there may be many more similar examples =97 this last = point from some of the text in the Introduction [1].  I think that = it would then be better to keep them all in a place where the WG can = easily update them (without going through the publication process), a wiki or a long-lived ID, for example.

    I=92m = talking about requirements because even though this document says that = =93certain requirements could be derived to be used as reference=94, the S-BFD base document says = that it =93extends BFD to provide solutions to use = cases listed in [I-D.ietf-bfd-seamless-use-case].=94  If solutions are created then it would be nice to clearly know = what the requirements are.

    If there is still WG consensus to publish this document, I would like to = see the readability improved and the requirements clarified. =  See my detailed comments below.  I will keep the document in = AD Evaluation (and not return it to the WG) at least until a decision has been made.

    Thanks!

    Alvaro.

    [1] =93=85use cases could be used as reference for certain = requirements, it is outside the scope of this document to identify all of the requirements for = all possible enhancements."


    Major:
    1. Requirements.  If there are going to be requirements listed in this = document, please be specific on what they are.  It would be helpful = for tracking if they were also clearly identified.  No need for = normative language, I=92m mostly looking for clarity and ease.  Some comments:
      • 3.1. (Unidirectional = Forwarding Path Validation) "The primary requirement in this use case is to = enable session establishment from source network entity to target network entity.=94  If this is the = primary requirement, what are the other ones?  Is the requirement = itself that only the source should have to be provisioned = beforehand?
      • 3.2. (Validation of = forwarding path prior to traffic switching)  =93It will be desirable = to perform BFD validation very quickly to allow applications to utilize dynamically created LSPs in a timely manner.=94  Is = that the requirement that comes out of this use case?  Is it = optional (=93desirable=94)?  What do =93very quickly=94 = and =93in a timely manner" mean?  This section starts with a = generic description of the use case, I=92m assuming the requirement is general as = well and not just applicable to =93dynamically created = LSPs=94.
        • The use case = in Section 3.3. = (Centralized Traffic Engineering) seems to also be calling for the = ability "to = instantly verify a forwarding path=94.  What does =93instantly=94 mean?  Are there other = requirements that come from this section?
      • 3.4. (BFD in Centralized = Segment Routing) =93In validating this use case, one of the = requirements is to ensure the BFD packet's behavior is according to the requirement and = monitoring of the segment=85=94  I-D.geib-spring-oam-usecase doesn=92t mention BFD =97 I know it implies it in a more generic way.  For = the purposes of this document, I don=92t think it=92s enough to to = just say that =93one of the requirements..is according to the = requirements..of the segment=94 =97 in essence it seems like = this document is just pointing the reader to the other document to figure out what needs to = be done.  Maybe a better reference for requirements = is draft-ietf-spring-sr-oam-requirement.  It would also be = nice to at least highlight the places where this use case introduces new = requirements and why.
      • 3.5. (BFD Efficient Operation Under Resource = Constraints) =93=85it is desirable for BFD to=85=94  and 3.9. (MPLS BFD Session Per ECMP Path) = "it may be desirable to run in-band monitoring=85=94   =  Optional?
      • 3.6. (BFD for Anycast = Address)  The requirement here is ???
      • 3.7. (BFD Fault Isolation) =  "If BFD had = built-in fault isolation capability=85=94  and 3.8. (Multiple = BFD Sessions to Same Target) "if = a node was to run multiple BFD sessions to targets=85=94   Conditional = form..

    Minor:
    1. Some of the text needs to be cleaned up because it is repetitive.
      • Introduction: "Bidirectional Forwarding Detection (BFD) is a lightweight = protocol=85used to = detect forwarding failures.  Various protocols and applications rely on BFD for failure detection.  Even though the protocol is = simple and lightweight, there are certain use cases, where faster setting up of = sessions=85This = document identifies use cases=85BFD= was designed to be a lightweight "Hello" protocol to detect = data plane = failures=85speed at which these sessions could be established=85This document specifically = identifies those cases=85=94
      • Section 2. (Introduction to Seamless BFD): =93In order for BFD to be able to initially verify that a connection = is valid=85such that this information can be used to verify that the connection is valid."
    2. Solutions are outside the scope of this document.  There = are several places where the text starts to describe the (potential at this point) behavior of S-BFD.  That should be = left to the solution document.  Some examples:
      • 2. (Introduction to = Seamless BFD): "As= an example of how Seamless BFD (S-BFD) might work=85=94
      • 3.1. (Unidirectional Forwarding = Path Validation): "But= with unidirectional BFD,..=94, and "This translates to=85=94
      • 3.2. (Validation of forwarding path prior to traffic = switching): "This use case does not require to have sequences=85=94, and "When these sequences for handshake=85=94
      • 3.9. (MPLS BFD Session Per ECMP Path)  "One way to = achieve BFD session per ECMP path of LSP is=85"
      • Note that if this document was maintained as a sustaining = reference, then it would be easier to edit and add the specifics of how the requirements are = satisfied.
    3. Section 3. (Use = Cases): =93This section outlines some use cases where the = existing mechanism may not be able to satisfy the requirements.=94  May not?  Does that = mean that for some of the use cases the existing mechanisms can satisfy = the requirements?  Which ones?
    Nits:
    1. Missing references.
      • 1.1 "The reader is expected to be = familiar with the BFD, IP, MPLS and Segment Routing = (SR) terminology and protocol constructs."
      • 3.7 "BFD multi-hop and BFD = MPLS=85"
    2. Section 3. (Use Cases).  =93=85some of the use cases= also be identify the need for=85=94  ??
    3. Section 3.5. (BFD Efficient Operation = Under Resource Constraints) =93?=94  
    4. Section 3.8. (Multiple BFD Sessions to Same Target) =  s/as relevant network nodes continuously transmitting BFD packets at = negotiated rate/as relevant network nodes continuously transmit BFD packets at negotiated rates
    5. Section 4. (Security = Considerations)  The statement made seems right, but at least = mention why.  Related: are there no new security requirements/use = cases?

    = --Apple-Mail=_9E3603E9-BA2B-40DB-93E0-AA46C27EADE3-- From nobody Fri Sep 25 10:53:49 2015 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 92CDB1A0162; Fri, 25 Sep 2015 10:53:47 -0700 (PDT) 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 ZO7Tll0hfdro; Fri, 25 Sep 2015 10:53:45 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FB8E1A0121; Fri, 25 Sep 2015 10:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8509; q=dns/txt; s=iport; t=1443203625; x=1444413225; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jc984qN8zWRW6QcViR2SMfl5fIj1jIlzpWS9X8tDMrU=; b=W23mknVZsxLwy/VaAigVCrVuCDPU9XyGObT/ygqaie/oFQuelvXNVN2U 6PYJ0mUNVT9th1MiU8789is1CV5pRhudeL9fWts2O4jRYtKxAyNvGOui5 3tRA7wCSQkshM+2ue/F5h9YoVvrGGZVZRUaydmBlpkak3WH4qt4o4gdyh 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D8AQAliQVW/40NJK1dgldNVGkGvTABDYF7hXkCgSw4FAEBAQEBAQGBCoQlAQEEeRACAQg/ByERFBECBA4FG4d+AxINxyINhQABAQEBAQEBAQEBAQEBAQEBAQEBAQETBIZzAYR8glCBZFUEB4QsBZJCgyoBhROGCoFvgU+HV4pFh0MfAQFChAFxh1lDgQUBAQE X-IronPort-AV: E=Sophos;i="5.17,587,1437436800"; d="scan'208,217";a="191810738" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Sep 2015 17:53:43 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t8PHrhY4028578 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 25 Sep 2015 17:53:43 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 25 Sep 2015 12:53:42 -0500 Received: from xhc-rcd-x06.cisco.com (173.37.183.80) by xch-aln-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 25 Sep 2015 12:53:42 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.98]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0248.002; Fri, 25 Sep 2015 12:53:42 -0500 From: "Alvaro Retana (aretana)" To: aldrin ietf Subject: Re: AD Review of draft-ietf-bfd-seamless-use-case Thread-Topic: AD Review of draft-ietf-bfd-seamless-use-case Thread-Index: AQHQ97Ieqtfo0LmZ1kugOs1WHaftMZ5NzGKA///LMwA= Date: Fri, 25 Sep 2015 17:53:42 +0000 Message-ID: References: <713AD0F3-FD85-440F-A59C-40E64B10E4CA@gmail.com> In-Reply-To: <713AD0F3-FD85-440F-A59C-40E64B10E4CA@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.20] Content-Type: multipart/alternative; boundary="_000_D22AFA54D3AEAaretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@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: Fri, 25 Sep 2015 17:53:47 -0000 --_000_D22AFA54D3AEAaretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 9/25/15, 1:02 PM, "aldrin ietf" > wrote: Sam: Hi! How are you? Haven=92t read the review comments, but would like to respond to general co= mments. - Whether to stop Use case document to proceed further or nor, is the comme= nt specific to this document or general comment applicable to all use case = documents? My opinion is general, but there are also specific reasons applicable to th= is document. - If use you think use case documents has limited purposes, then it should = be discouraged at the beginning and shouldn=92t even be adopted in the firs= t place. It is not prudent to invest time, for individual/group, for the th= ings which are going to be dropped. The work shouldn=92t be discouraged! Use cases clearly serve as motivation= for problems to be solved, which is important to frame and scope the work = to be done in any WG. However, I think that the usefulness in many cases s= tops there: once the solution has been developed. There are specific actions being taken, but as you can imagine one size doe= sn=92t fit all. As an example, take a look at the charter for detnet [1] (= still not approved). In there it is clear that the work on use cases (for = example) is important to guide the WG and help newcomers, but that it may n= ot be published. Note that the work is not changing, the expectations for = publication are =97 those are two very different things. [1] https://datatracker.ietf.org/doc/charter-ietf-detnet/ Coming back to this specific document.. I=92m asking the WG to consider no= t publishing, not telling it what to do. In fact, if you look at the WG ch= arter, even though there is a specific Milestone, the WG is chartered to = =93define a mechanism..=94 (not to produce use cases). Nonetheless, becaus= e the work has already been done, the WG can make the decision whether it s= till wants to publish or not. - I do not think use case has to document requirements explicitly. If it ha= s to, then what should requirement document contain? If the plan is to merg= e both, this should be discussed across, not just BFD, to get an agreement.= I see there are lot of use case, requirement docs in various WG=92s. It=92s interesting that you mention a requirements document because there i= sn=92t one. That is exactly one of the points I=92m trying to make: the s= olution that addresses the use cases is S-BFD (as documented in draft-ietf-= bfd-seamless-base [2]), but how do we know the solution in fact solves the = use cases without clear requirements? To me, the bottom line is this: if we=92re going to publish this document, = let=92s make it valuable by clearly stating what is needed in each use case= that BFD can=92t do. [2] That draft in fact says so in the Introduction: "This document extends = BFD to provide solutions to use cases listed in [I-D.ietf-bfd-seamless-use-= case].=94 Thanks! Alvaro. --_000_D22AFA54D3AEAaretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
    On 9/25/15, 1:02 PM, "aldrin ietf" <aldrin.ietf@gmail.com> wrote:

    Sam:

    Hi!  How are you?

    Haven=92t read the review comments, but would like to respo= nd to general comments.

    - Whether to stop Use case document to proceed further or n= or, is the comment specific to this document or general comment applicable = to all use case documents?

    My opinion is general, but there are also specific reasons applicable = to this document.


    - If use you think use case documents has limited purposes,= then it should be discouraged at the beginning and shouldn=92t even be ado= pted in the first place. It is not prudent to invest time, for individual/g= roup, for the things which are going to be dropped.

    The work shouldn=92t be discouraged!  Use cases clearly serve as = motivation for problems to be solved, which is important to frame and scope= the work to be done in any WG.  However, I think that the usefulness = in many cases stops there: once the solution has been developed.

    There are specific actions being taken, but as you can imagine one siz= e doesn=92t fit all.  As an example, take a look at the charter for de= tnet [1] (still not approved).  In there it is clear that the work on = use cases (for example) is important to guide the WG and help newcomers, but that it may not be published.  Note th= at the work is not changing, the expectations for publication are =97 those= are two very different things.



    Coming back to this specific document..  I=92m asking the WG to c= onsider not publishing, not telling it what to do.  In fact, if you lo= ok at the WG charter, even though there is a specific Milestone, the WG is = chartered to =93define a mechanism..=94 (not to produce use cases).  Nonetheless, because the work has already been d= one, the WG can make the decision whether it still wants to publish or not.=


    - I do not think use case has to document requirements expl= icitly. If it has to, then what should requirement document contain? If the= plan is to merge both, this should be discussed across, not just BFD, to g= et an agreement. I see there are lot of use case, requirement docs in various WG=92s. 

    It=92s interesting that you mention a requirements document because th= ere isn=92t one.  That is exactly one of the points I=92m trying to ma= ke:  the solution that addresses the use cases is S-BFD (as documented= in draft-ietf-bfd-seamless-base [2]), but how do we know the solution in fact solves the use cases without clear requiremen= ts?

    To me, the bottom line is this: if we=92re going to publish this docum= ent, let=92s make it valuable by clearly stating what is needed in each use= case that BFD can=92t do.  

    [2] That draft in fact says so in the Introduction: "This documen= t extends BFD to provide solutions to use cases listed in [I-D.ietf-bfd-sea= mless-use-case].=94


    Thanks!

    Alvaro.
    --_000_D22AFA54D3AEAaretanaciscocom_-- From nobody Fri Sep 25 11:48:29 2015 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 641A51A8749; Fri, 25 Sep 2015 11:48:27 -0700 (PDT) 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 9gNqYOwRyZvD; Fri, 25 Sep 2015 11:48:24 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (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 A0D171A8740; Fri, 25 Sep 2015 11:48:24 -0700 (PDT) Received: by pacfv12 with SMTP id fv12so115033320pac.2; Fri, 25 Sep 2015 11:48:24 -0700 (PDT) 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=Zy6YaRAVmhsxj8/amnIBDRI6MNIWyg0B2E8iJGAuL5I=; b=NI2Q6t7AUKdfJBOoZP2TOiYZbaQ6SQOwmFHKmHOdZVGk9O3ja1mMBQl8piqYSvqnLp cyQyHf35j69+r373L+fkPcbKN8DuajqXF+FVEGlu68qFZntSIgSDe95zGBSgoGX1z8w5 U8w9Wrye91R1p15MtFQFuOj3xifaREbzWwsTZ+gRMREQ6qDS0yAsKLe0MtvVULJ2S4/4 /MY87ucs3NR7tK2ZgttL0uVdd9fVztz2uLHJAccG4e1qTnGHUnRw2Smfv1B6pu2JvP8I BM6rUUW3yq2FWJsahGTBRqIjwfIv6Tw0SBKt8Y53vGPanQUepSE6Vi3gwrvBFWyZlgNc ERNA== X-Received: by 10.66.165.106 with SMTP id yx10mr9301993pab.102.1443206904156; Fri, 25 Sep 2015 11:48:24 -0700 (PDT) Received: from ?IPv6:2620::1000:3202:2568:e311:a4b9:bbda? ([2620:0:1000:3202:2568:e311:a4b9:bbda]) by smtp.gmail.com with ESMTPSA id by1sm5221559pab.6.2015.09.25.11.48.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Sep 2015 11:48:23 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8BC98BD7-6CFB-4CCC-9595-9C75D0B756A6" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: AD Review of draft-ietf-bfd-seamless-use-case From: aldrin ietf In-Reply-To: Date: Fri, 25 Sep 2015 11:48:19 -0700 Message-Id: References: <713AD0F3-FD85-440F-A59C-40E64B10E4CA@gmail.com> To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@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: Fri, 25 Sep 2015 18:48:27 -0000 --Apple-Mail=_8BC98BD7-6CFB-4CCC-9595-9C75D0B756A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Alvaro, Comments inline with %sam. > On Sep 25, 2015, at 10:53 AM, Alvaro Retana (aretana) = wrote: >=20 > On 9/25/15, 1:02 PM, "aldrin ietf" > wrote: >=20 > Sam: >=20 > Hi! How are you? I am fine thank you. Hope the same with you. Thanks again for your = reply. >=20 > Haven=92t read the review comments, but would like to respond to = general comments. >=20 > - Whether to stop Use case document to proceed further or nor, is the = comment specific to this document or general comment applicable to all = use case documents? >=20 > My opinion is general, but there are also specific reasons applicable = to this document. >=20 >=20 > - If use you think use case documents has limited purposes, then it = should be discouraged at the beginning and shouldn=92t even be adopted = in the first place. It is not prudent to invest time, for = individual/group, for the things which are going to be dropped. >=20 > The work shouldn=92t be discouraged! Use cases clearly serve as = motivation for problems to be solved, which is important to frame and = scope the work to be done in any WG. However, I think that the = usefulness in many cases stops there: once the solution has been = developed. %sam - The same could be argued against, problem statement, framework, = requirement, etc. Once solution is done, they serve no practical = purpose. Any enhancement work, will only cite the shortcomings of = solution document and not requirement or problem statement. >=20 > There are specific actions being taken, but as you can imagine one = size doesn=92t fit all. As an example, take a look at the charter for = detnet [1] (still not approved). In there it is clear that the work on = use cases (for example) is important to guide the WG and help newcomers, = but that it may not be published. Note that the work is not changing, = the expectations for publication are =97 those are two very different = things. >=20 > [1] https://datatracker.ietf.org/doc/charter-ietf-detnet/ = I don=92t have a problem, if the ask of not proceed was made much = earlier in the process and not late in the game. For SFD work, there is no requirement document and usecase document = provides the need to enhance BFD protocol to be extended. >=20 >=20 > Coming back to this specific document.. I=92m asking the WG to = consider not publishing, not telling it what to do. In fact, if you = look at the WG charter, even though there is a specific Milestone, the = WG is chartered to =93define a mechanism..=94 (not to produce use = cases). Nonetheless, because the work has already been done, the WG can = make the decision whether it still wants to publish or not. If that is the case, it shouldn=92t even be a WG document right? Also, the deliverable was tracked as part of milestone isn=92t it? Does that mean, milestones truly doesn=92t reflect the deliverable but = only Charter does? Do not know all the semantics of the IETF WG processes. Clarification = helps. >=20 >=20 > - I do not think use case has to document requirements explicitly. If = it has to, then what should requirement document contain? If the plan is = to merge both, this should be discussed across, not just BFD, to get an = agreement. I see there are lot of use case, requirement docs in various = WG=92s.=20 >=20 > It=92s interesting that you mention a requirements document because = there isn=92t one. That is exactly one of the points I=92m trying to = make: the solution that addresses the use cases is S-BFD (as documented = in draft-ietf-bfd-seamless-base [2]), but how do we know the solution in = fact solves the use cases without clear requirements? You may not agree to what I think, but let me put that out anyway. BFD protocol itself is much smaller and the usecases are very narrow in = scope that, they by themselves are better than some of them the = requirements we=92ve seen in actual requirement documents. What I = expected to see was for solutions to reference usecases in their = respective documents and why it is being enhanced. >=20 > To me, the bottom line is this: if we=92re going to publish this = document, let=92s make it valuable by clearly stating what is needed in = each use case that BFD can=92t do. =20 >=20 > [2] That draft in fact says so in the Introduction: "This document = extends BFD to provide solutions to use cases listed in = [I-D.ietf-bfd-seamless-use-case].=94 I am ok to enhance the text to clear any ambiguity of what is needed for = BFD to enhance.=20 But the grey area in that case will be, how not to propose implicit = solution. cheers -sam >=20 >=20 > Thanks! >=20 > Alvaro. --Apple-Mail=_8BC98BD7-6CFB-4CCC-9595-9C75D0B756A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Alvaro,

    Comments inline with %sam.
    On Sep 25, 2015, at 10:53 AM, = Alvaro Retana (aretana) <aretana@cisco.com> wrote:

    On 9/25/15, 1:02 PM, "aldrin ietf" <aldrin.ietf@gmail.com> wrote:

    Sam:

    Hi!  How are you?
    I = am fine thank you. Hope the same with you. Thanks again for your = reply.

    Haven=92t read the review comments, but would like to = respond to general comments.

    - Whether to stop Use case document to proceed further = or nor, is the comment specific to this document or general comment = applicable to all use case documents?

    My opinion is general, but there are also specific = reasons applicable to this document.


    - If use you think use case documents has limited = purposes, then it should be discouraged at the beginning and shouldn=92t = even be adopted in the first place. It is not prudent to invest time, = for individual/group, for the things which are going to be dropped.

    The work shouldn=92t be discouraged!  Use cases = clearly serve as motivation for problems to be solved, which is = important to frame and scope the work to be done in any WG. =  However, I think that the usefulness in many cases stops there: = once the solution has been developed.
    %sam - The same could = be argued against, problem statement, framework, requirement, etc. Once = solution is done, they serve no practical purpose. Any enhancement work, = will only cite the shortcomings of solution document and not requirement = or problem statement.

    There are specific actions being taken, but as you can = imagine one size doesn=92t fit all.  As an example, take a look at = the charter for detnet [1] (still not approved).  In there it is = clear that the work on use cases (for example) is important to guide the WG and help newcomers, but that it may not be published.  Note = that the work is not changing, the expectations for publication are =97 = those are two very different things.

    [1] https://datatracker.ietf.org/doc/charter-ietf-detnet/
    =

    I don=92t have a = problem, if the ask of not proceed was made much earlier in the process = and not late in the game.
    For SFD work, there is no = requirement document and usecase document provides the need to enhance = BFD protocol to be extended.



    Coming back to this specific document..  I=92m = asking the WG to consider not publishing, not telling it what to do. =  In fact, if you look at the WG charter, even though there is a = specific Milestone, the WG is chartered to =93define a mechanism..=94 = (not to produce use cases).  Nonetheless, because the work has already = been done, the WG can make the decision whether it still wants to = publish or not.

    If= that is the case, it shouldn=92t even be a WG document = right?
    Also, the deliverable was tracked as part of milestone = isn=92t it?
    Does that mean, milestones truly doesn=92t reflect = the deliverable but only Charter does?

    Do not know all the semantics of the IETF WG = processes. Clarification helps.



    - I do not think use case has to document requirements = explicitly. If it has to, then what should requirement document contain? = If the plan is to merge both, this should be discussed across, not just = BFD, to get an agreement. I see there are lot of use case, requirement docs in various WG=92s. 

    It=92s interesting that you mention a requirements = document because there isn=92t one.  That is exactly one of the = points I=92m trying to make:  the solution that addresses the use = cases is S-BFD (as documented in draft-ietf-bfd-seamless-base [2]), = but how do we know the solution in fact solves the use cases without clear = requirements?
    You may not agree to what I = think, but let me put that out anyway.
    BFD protocol itself is = much smaller and the usecases are very narrow in scope that, they by = themselves are better than some of them the requirements we=92ve seen in = actual requirement documents. What I expected to see was for solutions = to reference usecases in their respective documents and why it is being = enhanced.

    To me, the bottom line is this: if we=92re going to = publish this document, let=92s make it valuable by clearly stating what = is needed in each use case that BFD can=92t do.  

    [2] That draft in fact says so in the Introduction: = "This document extends BFD to provide solutions to use cases listed in = [I-D.ietf-bfd-seamless-use-case].=94
    I am = ok to enhance the text to clear any ambiguity of what is needed for BFD = to enhance. 
    But the grey area in that case will be, how = not to propose implicit solution.

    cheers
    -sam


    Thanks!

    Alvaro.

    = --Apple-Mail=_8BC98BD7-6CFB-4CCC-9595-9C75D0B756A6-- From nobody Fri Sep 25 13:31:38 2015 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 6CAD91A1B64; Fri, 25 Sep 2015 13:31:37 -0700 (PDT) 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 OkVbuugsZVMx; Fri, 25 Sep 2015 13:31:34 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFD051A1B20; Fri, 25 Sep 2015 13:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11349; q=dns/txt; s=iport; t=1443213093; x=1444422693; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=01r3TiwTrMAFARfg4N7k9fevowSKs+qig7Ob6NNypGU=; b=PX7EvfFLCJgUIh5EYnaszRiuiocPOlA1cQHEg22jpPlqf9K9iK80Tiit jYbCmNmG5rwGczSTZ8WZK3U0OzNNDcSteQURn/4yqCcOx4X81S3CrBIeC 0f064uTZoSPkLWLCWqlLOsZUdqhwhiTdLdh0V7Tl9/V6qFcEVGElrRiaJ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D7AQDZrgVW/5BdJa1TCoJXTYE9Br0yAQ2HdAKBLDgUAQEBAQEBAYEKhCUBAQR5EAIBCD8HIREUEQIEDgUbh34DEscdDYUAAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4ZzAYR8glCBYF0HhCwFkkKDKgGLHYFvk2uHQx8BAUKCERyBVHGIHIEFAQEB X-IronPort-AV: E=Sophos;i="5.17,588,1437436800"; d="scan'208,217";a="191650660" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP; 25 Sep 2015 20:31:32 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t8PKVWCo030028 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 25 Sep 2015 20:31:32 GMT Received: from xch-aln-019.cisco.com (173.36.7.29) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 25 Sep 2015 15:31:32 -0500 Received: from xhc-aln-x15.cisco.com (173.36.12.89) by xch-aln-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 25 Sep 2015 15:31:32 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.98]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0248.002; Fri, 25 Sep 2015 15:31:31 -0500 From: "Alvaro Retana (aretana)" To: aldrin ietf Subject: Re: AD Review of draft-ietf-bfd-seamless-use-case Thread-Topic: AD Review of draft-ietf-bfd-seamless-use-case Thread-Index: AQHQ97Ieqtfo0LmZ1kugOs1WHaftMZ5NzGKA///LMwCAAFJVgP//2cOA Date: Fri, 25 Sep 2015 20:31:31 +0000 Message-ID: References: <713AD0F3-FD85-440F-A59C-40E64B10E4CA@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.20] Content-Type: multipart/alternative; boundary="_000_D22B1130D3B9Daretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@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: Fri, 25 Sep 2015 20:31:37 -0000 --_000_D22B1130D3B9Daretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 9/25/15, 2:48 PM, "aldrin ietf" > wrote: Sam: Let=92s talk about this draft. . . . - I do not think use case has to document requirements explicitly. If it ha= s to, then what should requirement document contain? If the plan is to merg= e both, this should be discussed across, not just BFD, to get an agreement.= I see there are lot of use case, requirement docs in various WG=92s. It=92s interesting that you mention a requirements document because there i= sn=92t one. That is exactly one of the points I=92m trying to make: the s= olution that addresses the use cases is S-BFD (as documented in draft-ietf-= bfd-seamless-base [2]), but how do we know the solution in fact solves the = use cases without clear requirements? You may not agree to what I think, but let me put that out anyway. BFD protocol itself is much smaller and the usecases are very narrow in sco= pe that, they by themselves are better than some of them the requirements w= e=92ve seen in actual requirement documents. What I expected to see was for= solutions to reference usecases in their respective documents and why it i= s being enhanced. I don=92t necessarily disagree with that, but let=92s talk specifics: 3.6. BFD for Anycast Address BFD protocol requires two endpoints to host BFD sessions, both sending packets to each other. This BFD model does not fit well with anycast address monitoring, as BFD packets transmitted from a network node to an anycast address will reach only one of potentially many network nodes hosting the anycast address. That=92s the whole description of that use case..as you said: small and nar= row in scope. However (as I said in my comments), what does that mean? H= ow do you want the system to behave? What is the requirement? I=92m not a= sking about the solution, but about the expected behavior. For example, is= the requirement here that a BFD packet reach all the potential anycast nod= es in the network? Would you want that to be a point-to-multipoint type be= havior or is several point-to-point packets ok? >From what you said above, if someone wants to reference this use case to ju= stify an enhancement they should be able to easily identify what the expect= ed behavior or requirement is. If the use case is not clear, then how can = a solution/enhancement be justified? In the end that I=92m asking for: clarity. To me, the bottom line is this: if we=92re going to publish this document, = let=92s make it valuable by clearly stating what is needed in each use case= that BFD can=92t do. [2] That draft in fact says so in the Introduction: "This document extends = BFD to provide solutions to use cases listed in [I-D.ietf-bfd-seamless-use-= case].=94 I am ok to enhance the text to clear any ambiguity of what is needed for BF= D to enhance. But the grey area in that case will be, how not to propose implicit solutio= n. As with the example above, generically say what you want to do: =93reach al= l the anycast nodes with one BFD packet=94, for example. You don=92t have = to go into details of how the anycast nods are identified, what are the dis= criminators used, what IP addresses are used, packet replication, etc. All= that is part of the solution. Thanks! Alvaro. --_000_D22B1130D3B9Daretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9F28B60B396A8545B7F77DA3891C0788@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
    On 9/25/15, 2:48 PM, "aldrin ietf" <aldrin.ietf@gmail.com> wrote:

    Sam:

    Let=92s talk about this draft.
    . . .
    - I do not think use case has to document requirements expl= icitly. If it has to, then what should requirement document contain? If the= plan is to merge both, this should be discussed across, not just BFD, to g= et an agreement. I see there are lot of use case, requirement docs in various WG=92s. 

    It=92s interesting that you mention a requirements document= because there isn=92t one.  That is exactly one of the points I=92m t= rying to make:  the solution that addresses the use cases is S-BFD (as= documented in draft-ietf-bfd-seamless-base [2]), but how do we know the solution in fact solves the use cases without clear= requirements?
    You may not agree to what I think, but let me put that out anyway.
    BFD protocol itself is much smaller and the usecases are very narrow i= n scope that, they by themselves are better than some of them the requireme= nts we=92ve seen in actual requirement documents. What I expected to see wa= s for solutions to reference usecases in their respective documents and why it is being enhanced.

    I don=92t necessarily disagree with that, but let=92s talk specifics:

    3.6.  BFD for Anycast Address

       BFD protocol requires t= wo endpoints to host BFD sessions, both
       sending packets to each= other.  This BFD model does not fit well with
       anycast address monitor= ing, as BFD packets transmitted from a network
       node to an anycast addr= ess will reach only one of potentially many
       network nodes hosting t= he anycast address.

    That=92s the whole description of that use case..as you said: small and nar= row in scope.  However (as I said in my comments), what does that mean= ?   How do you want the system to behave?  What is the requiremen= t?  I=92m not asking about the solution, but about the expected behavior.  For example, is the requirement here that a B= FD packet reach all the potential anycast nodes in the network?  Would= you want that to be a point-to-multipoint type behavior or is several poin= t-to-point packets ok?

    >From what you said above, if someone wants to reference this use case to ju= stify an enhancement they should be able to easily identify what the expect= ed behavior or requirement is.  If the use case is not clear, then how= can a solution/enhancement be justified?

    In the end that I=92m asking for: clarity.



    To me, the bottom line is this: if we=92re going to publish= this document, let=92s make it valuable by clearly stating what is needed = in each use case that BFD can=92t do.  

    [2] That draft in fact says so in the Introduction: "T= his document extends BFD to provide solutions to use cases listed in [I-D.i= etf-bfd-seamless-use-case].=94
    I am ok to enhance the text to clear any ambiguity of what is needed for BF= D to enhance. 
    But the grey area in that case will be, how not to propose implicit so= lution.

    As with the example above, generically say what you want to do: =93rea= ch all the anycast nodes with one BFD packet=94, for example.  You don= =92t have to go into details of how the anycast nods are identified, what a= re the discriminators used, what IP addresses are used, packet replication, etc.  All that is part of the solution.=

    Thanks!

    Alvaro.
    --_000_D22B1130D3B9Daretanaciscocom_-- From nobody Fri Sep 25 13:44:53 2015 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 7EBA51A6F51; Fri, 25 Sep 2015 13:44:51 -0700 (PDT) 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, MIME_QP_LONG_LINE=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 rGd9V9AwObRW; Fri, 25 Sep 2015 13:44:49 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (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 50D841A6F40; Fri, 25 Sep 2015 13:44:49 -0700 (PDT) Received: by pacfv12 with SMTP id fv12so117383633pac.2; Fri, 25 Sep 2015 13:44:49 -0700 (PDT) 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 :content-transfer-encoding:message-id:references:to; bh=T9EArYkiKq7D2FR393LLy/3XtKXvicNPAYALFrJp954=; b=UM7weeyl/E0mlVoZrmrI+1zMjziU8h5bj45WtjGsTw02W3iE1KDdGYBYLKs2Ij1baf eCdrpryYstN/MnkrULo365x7tHJEcWqIPX0w5tV8NHuAll2faC4ksj2PJf5ZsjavqLq1 R5DxWsIHHJduGqVgPwbjmypx92OwOGziVZWGXKfXkO/9LCqJreC4Mcjr6Q0NIlABVoY1 eSnrvxaaBrwk/aiMjR7eduKki0ryvu8vSaXUjqDj1uLxlEfTOuKnkq5dnnq+JzzWV6O/ PImlcqDMyhLiu2yupMOSsRAgEWJkPFbQUB9HmLFR15gIprGXZzkvNTjCxZiVMJOjVvqo 0fDw== X-Received: by 10.68.65.104 with SMTP id w8mr9897690pbs.48.1443213888946; Fri, 25 Sep 2015 13:44:48 -0700 (PDT) Received: from ?IPv6:2620::1000:fd86:ac14:b726:5b1b:c31c? ([2620:0:1000:fd86:ac14:b726:5b1b:c31c]) by smtp.gmail.com with ESMTPSA id rs8sm5488785pbb.14.2015.09.25.13.44.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Sep 2015 13:44:48 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-D1EFB984-49D0-4CAC-BAC8-A093DA8A8C23 Mime-Version: 1.0 (1.0) Subject: Re: AD Review of draft-ietf-bfd-seamless-use-case From: Sam Aldrin X-Mailer: iPhone Mail (13A404) In-Reply-To: Date: Fri, 25 Sep 2015 13:45:14 -0700 Content-Transfer-Encoding: 7bit Message-Id: <2691B53A-FD6A-45D7-AF29-795C1DF743D9@gmail.com> References: <713AD0F3-FD85-440F-A59C-40E64B10E4CA@gmail.com> To: "Alvaro Retana (aretana)" Archived-At: Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@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: Fri, 25 Sep 2015 20:44:51 -0000 --Apple-Mail-D1EFB984-49D0-4CAC-BAC8-A093DA8A8C23 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Alvaro, Sorry for the top post. I am fine with enhancing the text and will definitely review your comments a= s well. But the question is, will this still be dropped? :D :D Sam Sent from my iPhone > On Sep 25, 2015, at 1:31 PM, Alvaro Retana (aretana) w= rote: >=20 > On 9/25/15, 2:48 PM, "aldrin ietf" wrote: >=20 > Sam: >=20 > Let=E2=80=99s talk about this draft. > . . . >> - I do not think use case has to document requirements explicitly. If it h= as to, then what should requirement document contain? If the plan is to merg= e both, this should be discussed across, not just BFD, to get an agreement. I= see there are lot of use case, requirement docs in various WG=E2=80=99s.=20= >>=20 >> It=E2=80=99s interesting that you mention a requirements document because= there isn=E2=80=99t one. That is exactly one of the points I=E2=80=99m try= ing to make: the solution that addresses the use cases is S-BFD (as documen= ted in draft-ietf-bfd-seamless-base [2]), but how do we know the solution in= fact solves the use cases without clear requirements? > You may not agree to what I think, but let me put that out anyway. > BFD protocol itself is much smaller and the usecases are very narrow in sc= ope that, they by themselves are better than some of them the requirements w= e=E2=80=99ve seen in actual requirement documents. What I expected to see wa= s for solutions to reference usecases in their respective documents and why i= t is being enhanced. >=20 > I don=E2=80=99t necessarily disagree with that, but let=E2=80=99s talk spe= cifics: >=20 > 3.6. BFD for Anycast Address >=20 > BFD protocol requires two endpoints to host BFD sessions, both > sending packets to each other. This BFD model does not fit well with > anycast address monitoring, as BFD packets transmitted from a network > node to an anycast address will reach only one of potentially many > network nodes hosting the anycast address. >=20 > That=E2=80=99s the whole description of that use case..as you said: small a= nd narrow in scope. However (as I said in my comments), what does that mean= ? How do you want the system to behave? What is the requirement? I=E2=80= =99m not asking about the solution, but about the expected behavior. For ex= ample, is the requirement here that a BFD packet reach all the potential any= cast nodes in the network? Would you want that to be a point-to-multipoint t= ype behavior or is several point-to-point packets ok? >=20 > =46rom what you said above, if someone wants to reference this use case to= justify an enhancement they should be able to easily identify what the expe= cted behavior or requirement is. If the use case is not clear, then how can= a solution/enhancement be justified? >=20 > In the end that I=E2=80=99m asking for: clarity. >=20 >=20 >>=20 >> To me, the bottom line is this: if we=E2=80=99re going to publish this do= cument, let=E2=80=99s make it valuable by clearly stating what is needed in e= ach use case that BFD can=E2=80=99t do. =20 >>=20 >> [2] That draft in fact says so in the Introduction: "This document extend= s BFD to provide solutions to use cases listed in [I-D.ietf-bfd-seamless-use= -case].=E2=80=9D > I am ok to enhance the text to clear any ambiguity of what is needed for B= FD to enhance.=20 > But the grey area in that case will be, how not to propose implicit soluti= on. >=20 > As with the example above, generically say what you want to do: =E2=80=9Cr= each all the anycast nodes with one BFD packet=E2=80=9D, for example. You d= on=E2=80=99t have to go into details of how the anycast nods are identified,= what are the discriminators used, what IP addresses are used, packet replic= ation, etc. All that is part of the solution. >=20 > Thanks! >=20 > Alvaro. --Apple-Mail-D1EFB984-49D0-4CAC-BAC8-A093DA8A8C23 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    Hi Alvaro,

    Sorry for the top post.

    I= am fine with enhancing the text and will definitely review your comments as= well.

    But the question is, will this still be dropped? :D :D

    Sam


    Sent from my iPhone

    On Sep 25= , 2015, at 1:31 PM, Alvaro Retana (aretana) <aretana@cisco.com> wrote:

    On 9/25/15, 2:48 PM, "aldrin ietf" <aldrin.ietf@gmail.com> wrote:

    Sam:

    Let=E2=80=99s talk about this draft.
    . . .
    - I do not think use case has to document requirements expli= citly. If it has to, then what should requirement document contain? If the p= lan is to merge both, this should be discussed across, not just BFD, to get a= n agreement. I see there are lot of use case, requirement docs in various WG=E2=80=99s. 

    It=E2=80=99s interesting that you mention a requirements doc= ument because there isn=E2=80=99t one.  That is exactly one of the poin= ts I=E2=80=99m trying to make:  the solution that addresses the use cas= es is S-BFD (as documented in draft-ietf-bfd-seamless-base [2]), but how do we know the solution in fact solves the use cases without clear r= equirements?
    You may not agree to what I think, but let me put that out anyway.
    BFD protocol itself is much smaller and the usecases are very narrow in= scope that, they by themselves are better than some of them the requirement= s we=E2=80=99ve seen in actual requirement documents. What I expected to see= was for solutions to reference usecases in their respective documents and why it is being enhanced.

    I don=E2=80=99t necessarily disagree with that, but let=E2=80=99s talk speci= fics:

    3.6.  BFD for Anycast Address

       BFD protocol requires tw= o endpoints to host BFD sessions, both
       sending packets to each o= ther.  This BFD model does not fit well with
       anycast address monitori= ng, as BFD packets transmitted from a network
       node to an anycast addre= ss will reach only one of potentially many
       network nodes hosting th= e anycast address.

    That=E2=80=99s the whole description of that use case..as you said: small an= d narrow in scope.  However (as I said in my comments), what does that m= ean?   How do you want the system to behave?  What is the requirem= ent?  I=E2=80=99m not asking about the solution, but about the expected behavior.  For example, is the requirement here that a BFD= packet reach all the potential anycast nodes in the network?  Would yo= u want that to be a point-to-multipoint type behavior or is several point-to= -point packets ok?

    =46rom what you said above, if someone wants to reference this use case to j= ustify an enhancement they should be able to easily identify what the expect= ed behavior or requirement is.  If the use case is not clear, then how c= an a solution/enhancement be justified?

    In the end that I=E2=80=99m asking for: clarity.



    To me, the bottom line is this: if we=E2=80=99re going to pu= blish this document, let=E2=80=99s make it valuable by clearly stating what i= s needed in each use case that BFD can=E2=80=99t do.  

    [2] That draft in fact says so in the Introduction: "This do= cument extends BFD to provide solutions to use cases listed in [I-D.ietf-bfd= -seamless-use-case].=E2=80=9D
    I am ok to enhance the text to clear any ambiguity of what is needed for BFD= to enhance. 
    But the grey area in that case will be, how not to propose implicit sol= ution.

    As with the example above, generically say what you want to do: =E2=80=9C= reach all the anycast nodes with one BFD packet=E2=80=9D, for example.  = ;You don=E2=80=99t have to go into details of how the anycast nods are ident= ified, what are the discriminators used, what IP addresses are used, packet replication, etc.  All that is part of the solution.<= /div>

    Thanks!

    Alvaro.
    = --Apple-Mail-D1EFB984-49D0-4CAC-BAC8-A093DA8A8C23-- From nobody Sun Sep 27 13:50:29 2015 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 2EAF11B2E54; Sun, 27 Sep 2015 13:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.81 X-Spam-Level: X-Spam-Status: No, score=-11.81 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 6cJOnRxpZhfH; Sun, 27 Sep 2015 13:50:25 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B1EF1B2E52; Sun, 27 Sep 2015 13:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15237; q=dns/txt; s=iport; t=1443387025; x=1444596625; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cdiWPWItnLjJiQLC2ppsK74XuDNhQriKvOHsPSCDREc=; b=bYQvzrd6zqIVYfC1iz+moI/AAo+g7t4ESGETsrDbh+JKmC6ZKKWdGqe7 DhZsi0BrSUS3mMzx6JRJiXnYFizjP55R+cr1skQ5udu9kTnYKehReFv5r 3MJTHmp5G0x3JSJw3eBTivLP6qigkVbxREDiR8zJm6iDd0KF5FjIouXX/ s=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DHAgA6VghW/51dJa1dgldNgS4PBr00Dod0AoEfOBQBAQEBAQEBgQqEJAEBAQMBeQULAgEIGC4yJQIEDgUODYgLCMpzAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4Zzgg+BaIEGhCoRAVEHgxiBFAWSQoMuAYJKgWCIZIFPhDaRTYNsAR8BQ4IRHIFUcYdiOoEFAQEB X-IronPort-AV: E=Sophos;i="5.17,598,1437436800"; d="asc'?scan'208,217";a="191699472" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP; 27 Sep 2015 20:50:24 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t8RKoOkG021307 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 27 Sep 2015 20:50:24 GMT Received: from xch-aln-020.cisco.com (173.36.7.30) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 27 Sep 2015 15:50:23 -0500 Received: from xch-aln-020.cisco.com ([173.36.7.30]) by XCH-ALN-020.cisco.com ([173.36.7.30]) with mapi id 15.00.1104.000; Sun, 27 Sep 2015 15:50:23 -0500 From: "Carlos Pignataro (cpignata)" To: "Alvaro Retana (aretana)" Subject: Re: AD Review of draft-ietf-bfd-seamless-base Thread-Topic: AD Review of draft-ietf-bfd-seamless-base Thread-Index: AQHQ97IkT4lFfvKt5Uasfc9mskhFeZ5RMKqA Date: Sun, 27 Sep 2015 20:50:23 +0000 Message-ID: <79E44224-CCA0-4E31-8498-4682E4C847BE@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.54] Content-Type: multipart/signed; boundary="Apple-Mail=_0661513D-BBAC-4F5F-A812-65A78EDBDD9B"; protocol="application/pgp-signature"; micalg=pgp-sha256 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, 27 Sep 2015 20:50:28 -0000 --Apple-Mail=_0661513D-BBAC-4F5F-A812-65A78EDBDD9B Content-Type: multipart/alternative; boundary="Apple-Mail=_DD71C856-B98A-401D-8BCF-484E84A843F0" --Apple-Mail=_DD71C856-B98A-401D-8BCF-484E84A843F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Alvaro, Thanks for your thorough review! Before the point-by-point response, I wanted to provide some perspective = on a small subset of your comments: > On Sep 25, 2015, at 12:49 PM, Alvaro Retana (aretana) = wrote: >=20 > As I mention in the review for draft-ietf-bfd-seamless-ip, please = consider merging the two documents. I will keep this document under AD = Evaluation (and not return it to the WG) unless the WG Chairs consider = that it is necessary to WGLC the resulting document. >=20 >=20 This is a recurring theme, one that you mention in every email about = draft-ietf-bfd-seamless-*. It might be useful to share some additional = context and perspective. When we first started drafting ideas and early text of S-BFD, there was = a single document for base + IP. At some point, we started drafting what = S-BFD for Segment Routing would look like, and different optimizations = for different environments. At that point, we realized that it was more = sensible to have a common -base specification, followed by a number of = adjunct documents, each about a different environment/transport. Yes, draft-akiya-bfd-seamless-ip is quite basic and straightforward, = specifying ports, addresses, and small specifics in procedures. And if = there were only these two documents, it would make perfect sense (to me) = to merge them. However, there=92s more! :-) For example, = draft-akiya-bfd-seamless-sr specifies S-BFD for Segment Routing, in = which a different set of specifics are needed (given for example the = ability to control the return path). Similarly, there are other uses of = S-BFD such as S-BFD for Tunnels, S-BFD for Pseudowires = (draft-ietf-pals-seamless-vccv), etc. All of these define very narrowly = scoped specifics (IP vs. SR vs. PW) =97 however, all of those adjunct = specifics would pollute and dramatically lower the SNR if all merged to = the -base spec. Net-net, we opted for modularity in the specifications. The BFD WG chose to first progress -base and -ip, and only after those = were more mature, then advance -sr. This would not imply that the first = two documents on the sbfd set are the only ones. We did consider merging the two documents, even after we purposely split = them. If these were the only two docs in the set, I=92d support merging = them (or not having split them). But in the larger constellation of = S-BFD docs, I consider it best to advance the -base separated from all = the different specifics. > Normative References > I-D.ietf-bfd-multipoint should clearly be Normative because of the new = bfd.SessionType state variable Great catch. The new bfd.SessionType state variable is new for both documents, and = neither has a dependency on values of the variable from the other = document. Consequently, I do wonder if this document should define the = variable and bfd-multipoint refer to this =97 there is no serialization = needed other than a common variable with independent use. > I-D.ietf-bfd-generic-crypto-auth should also be Normative because of = how the Security Considerations are written: pointing to is as a =93MUST".= Given that (as far as I can tell) there aren=92t implementations of = I-D.ietf-bfd-generic-crypto-auth, we could end up with a Normative = reference that blocks the publication of this document. I want to = suggest that the comments be reworded as a suggestion or pointer to = potential solutions, not as a mandate to use them. [Disclaimer: we will = still need the SecDir to review.] Another good point =97 thanks =97 given how the text is written. I am not sure, however, the text is written in the best way. :-) > Nowhere in this document (or draft-ietf-bfd-seamless-ip) is congestion = mentioned. rfc5880 talks about some of the considerations. Are there = new congestion-related considerations that arise because of eliminating = some of the negotiation aspects? Thinking out loud: if a session = doesn=92t have to be established (and everyone knows a remote = discriminator), then there=92s a possibility of more nodes sending = traffic to a specific reflector (just as an example). Please include = some text indicating any congestion issues =97 or at least explaining = why there aren=92t any new ones. >=20 Very much agree. I believe there are subtle differences in the = congestion considerations, because if the simplified negotiation. Further, I believe those should live in the -base doc. That is missing, = and we should fill in this gap. Thanks! =97 Carlos. --Apple-Mail=_DD71C856-B98A-401D-8BCF-484E84A843F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi, Alvaro,

    Thanks for your thorough review!

    Before the point-by-point response, I = wanted to provide some perspective on a small subset of your = comments:

    On Sep 25, 2015, at 12:49 PM, = Alvaro Retana (aretana) <aretana@cisco.com> wrote:

    As I = mention in the review for draft-ietf-bfd-seamless-ip, please consider = merging the two documents.  I will keep this document under AD = Evaluation (and not return it to the WG) unless the WG Chairs consider = that it is necessary to WGLC the resulting document.



    This = is a recurring theme, one that you mention in every email = about draft-ietf-bfd-seamless-*. It might be useful to share some = additional context and perspective.

    When we first started drafting ideas and early = text of S-BFD, there was a single document for base + IP. At some point, = we started drafting what S-BFD for Segment Routing would look like, and = different optimizations for different environments. At that point, we = realized that it was more sensible to have a common -base specification, = followed by a number of adjunct documents, each about a different = environment/transport.

    Yes, draft-akiya-bfd-seamless-ip is quite = basic and straightforward, specifying ports, addresses, and small = specifics in procedures. And if there were only these two documents, it = would make perfect sense (to me) to merge them. However, there=92s more! = :-) For example, draft-akiya-bfd-seamless-sr specifies S-BFD for = Segment Routing, in which a different set of specifics are needed (given = for example the ability to control the return path). Similarly, there = are other uses of S-BFD such as S-BFD for Tunnels, S-BFD for Pseudowires = (draft-ietf-pals-seamless-vccv), etc. All of these define very narrowly = scoped specifics (IP vs. SR vs. PW) =97 however, all of those adjunct = specifics would pollute and dramatically lower the SNR if all merged to = the -base spec.

    Net-net, we opted = for modularity in the specifications.

    The BFD WG chose to first progress -base and -ip, = and only after those were more mature, then advance -sr. This would not = imply that the first two documents on the sbfd set are the only = ones.

    We did consider merging the = two documents, even after we purposely split them. If these were the = only two docs in the set, I=92d support merging them (or not having = split them). But in the larger constellation of S-BFD docs, I consider = it best to advance the -base separated from all the different = specifics.

    1. Normative = References
      • I-D.ietf-bfd-multipoint should clearly be Normative because = of the new bfd.SessionType state = variable
    Great = catch.

    The new bfd.SessionType state = variable is new for both documents, and neither has a dependency on = values of the variable from the other document. Consequently, I do = wonder if this document should define the variable and bfd-multipoint = refer to this =97 there is no serialization needed other than a common = variable with independent use.
      • I-D.ietf-bfd-generic-crypto-auth should also be Normative = because of how the Security Considerations are written: pointing to is = as a =93MUST".  Given that (as far as I can tell) there = aren=92t implementations of I-D.ietf-bfd-generic-crypto-auth, we could end up with a = Normative reference that blocks the publication of this document. =  I want to suggest that the comments be reworded as a suggestion or = pointer to potential solutions, not as a mandate to use them. =  [Disclaimer: we will still need the SecDir to = review.]
    Another good = point =97 thanks =97 given how the text is written.

    I am not sure, however, the text is written in the = best way. :-)

  8. Nowhere in this document (or draft-ietf-bfd-seamless-ip) is = congestion mentioned.  rfc5880 talks about some of the = considerations.  Are there new congestion-related considerations = that arise because of eliminating some of the negotiation aspects? =  Thinking out loud: if a session doesn=92t have to be established = (and everyone knows a remote discriminator), then there=92s a = possibility of more nodes sending traffic to a specific reflector (just = as an example).  Please include some text indicating any congestion = issues =97 or at least explaining why there aren=92t any new = ones.


Very much agree. I believe there are subtle = differences in the congestion considerations, because if the simplified = negotiation.

Further, I believe = those should live in the -base doc. That is missing, and we should fill = in this gap.

Thanks!

=97 Carlos.


= --Apple-Mail=_DD71C856-B98A-401D-8BCF-484E84A843F0-- --Apple-Mail=_0661513D-BBAC-4F5F-A812-65A78EDBDD9B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWCFWKAAoJEIXgpQGOZny9if4P/RgaTDRx+AkY4Bp4vkYwvBN+ zomQ6TtdigRZY9nI7MQIhuTl0jhJlZO6HMkLaNhdusgycHmv7PfGzRltXg+OQp44 knJk8zHPFWx+CgimqN7K/BQXSL088QV65forHV4MHy8/p3gATRd0kJxYVBnc3pql a1HXNOY+Y9oRdrxXjO6lBxhOJbk3SV3LxWNQ5QXvQ0rh43KpXxdLqY/0rTe+mJmu CW2UX9WcF7rBsqQ+kRmrtWY9Z85MgQ6/nXhacEozNi5deXYS+5LvBWCejPmbIiq0 +xqAZvTmRyzsbSdiHvZ3qO3pcn2rEShDIEfCece12wSqj9+cI917hXmrOQXgQajY XMWkP3M9x6W6bSpSrtyXCTtpO6Kp2midLTMeixSN1NI/vMNxt5YDgEgy71nzQp6c JX+rCBT+6GmBoaE1ghpfoMuWFw/gAABz4gI2HJIkncMNmZCpe7wLzFJS8B3+r0Nv cc5CXzvCuFmBgCarAas4pKiYXgczEtSeFAXs3GuS8KXtbfCRk8g/S86lHO7hmksE 1PVKPgORHTxvyKLeLXuwFqCHr+rQv0zyzU9GAbFVG+0X1CNyrjp9HS0uI446n34R yJ+ssjvvBZ46DTEMadWTUGZWoa6P7h5zu7CpqQANLAFRq0o3Bz8EI8PK0uPOpUU0 Y782VCVuwhu316AJchM8 =d8/f -----END PGP SIGNATURE----- --Apple-Mail=_0661513D-BBAC-4F5F-A812-65A78EDBDD9B-- From nobody Sun Sep 27 13:54:36 2015 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 3CC4E1B2E6A; Sun, 27 Sep 2015 13:54:35 -0700 (PDT) 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 azIm15Zcq2H5; Sun, 27 Sep 2015 13:54:33 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C97F1B2E57; Sun, 27 Sep 2015 13:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6028; q=dns/txt; s=iport; t=1443387273; x=1444596873; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tW40OAp7lYzYw9gtLq7pbPC0brM20A+NV+Vwk9rUqbE=; b=Hi4IyGP61HIVKOQaUbbwpv3KNlPCRfzmkS5dhhbdDPupSyFzVxQCr07P BciO3jAZZQD1nvHkvOVsVxT5stTu7j5KXpU11wCT8sbYEnRxpdxPPcciw ryjZiakGhetsj3EyVH4iV1grq5VKEVkRDWvKF7V10Ef40FN7M94A6N382 E=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DHAgA6VghW/5FdJa1dgldNgS4PBr00Dod0AoEfOBQBAQEBAQEBgQqEJAEBAQMBeQULAgEIBBQuMiUCBA4FDogYCMpzAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4Zzgg+BaIEGhQ0HgxiBFAWVcAGCSoFgiGSBT4Q2kU2DbAEfAUOEAXGIHIEFAQEB X-IronPort-AV: E=Sophos;i="5.17,598,1437436800"; d="asc'?scan'208,217";a="35911213" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP; 27 Sep 2015 20:54:32 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t8RKsWWn026290 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 27 Sep 2015 20:54:32 GMT Received: from xch-aln-020.cisco.com (173.36.7.30) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 27 Sep 2015 15:54:31 -0500 Received: from xch-aln-020.cisco.com ([173.36.7.30]) by XCH-ALN-020.cisco.com ([173.36.7.30]) with mapi id 15.00.1104.000; Sun, 27 Sep 2015 15:54:31 -0500 From: "Carlos Pignataro (cpignata)" To: "Alvaro Retana (aretana)" Subject: Re: AD Review of draft-ietf-bfd-seamless-ip Thread-Topic: AD Review of draft-ietf-bfd-seamless-ip Thread-Index: AQHQ97Ip8fkkgLz8RkWcTDCbHWzODZ5RMdUA Date: Sun, 27 Sep 2015 20:54:31 +0000 Message-ID: <1E3AA56E-F5A7-4A05-868B-B8B64157E82B@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.54] Content-Type: multipart/signed; boundary="Apple-Mail=_69D02F47-A9F6-48EC-B262-9C188F57C171"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" , "bfd-chairs@ietf.org" , "draft-ietf-bfd-seamless-ip@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, 27 Sep 2015 20:54:35 -0000 --Apple-Mail=_69D02F47-A9F6-48EC-B262-9C188F57C171 Content-Type: multipart/alternative; boundary="Apple-Mail=_623AD50A-AB3F-4DA6-949F-DB70007735A3" --Apple-Mail=_623AD50A-AB3F-4DA6-949F-DB70007735A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Alvaro, > On Sep 25, 2015, at 12:49 PM, Alvaro Retana (aretana) = wrote: >=20 > Please consider merging this document into = draft-ietf-bfd-seamless-base. Where have I heard this before? :-) In addition to my perspective on your review of the -base document, one = additional datapoint: there is useful symmetry pf S-BFD with the = existing set of BFD documents. You might have noticed how you were = referencing only RFC 5880 about -base. That is a clean demarc. draft-ietf-bfd-seamless-ip is *exactly* as long and detailed as RFC = 5881. > I will keep this document in AD Evaluation (and not return it to the = WG) at least until a decision has been made. >=20 Sounds good =97 please let us know what=92s next about this to reach = that decision. > Nowhere in this document (or draft-ietf-bfd-seamless-base) is = congestion mentioned. There is very little in rfc5881 (and nothing in = rfc5884) that adds to what rfc5880 covers, which makes me think that a = generic approach might be better (i.e. in = draft-ietf-bfd-seamless-base). I think there are and agree with you, a generic approach (-base) would = be better. Thanks, =97 Carlos. --Apple-Mail=_623AD50A-AB3F-4DA6-949F-DB70007735A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi, Alvaro,

On Sep 25, 2015, at 12:49 PM, = Alvaro Retana (aretana) <aretana@cisco.com> wrote:

Please consider merging this document into = draft-ietf-bfd-seamless-base.  

Where have I heard this before? :-)

In addition to my perspective on your review of = the -base document, one additional datapoint: there is useful symmetry = pf S-BFD with the existing set of BFD documents. You might have noticed = how you were referencing only RFC 5880 about -base. That is a clean = demarc.

draft-ietf-bfd-seamless-ip = is *exactly* as long and detailed as RFC 5881.

I = will keep this document in AD Evaluation (and not return it to the WG) = at least until a decision has been made.


Sounds good =97 please let us know = what=92s next about this to reach that decision.
  1. Nowhere in this document = (or draft-ietf-bfd-seamless-base) is congestion mentioned. =  There is very little in rfc5881 (and nothing in rfc5884) that = adds to what rfc5880 covers, which makes me think that a generic = approach might be better (i.e. in =  draft-ietf-bfd-seamless-base). =  
I think there are and agree = with you, a generic approach (-base) would be better.

Thanks,

=97 Carlos.
= --Apple-Mail=_623AD50A-AB3F-4DA6-949F-DB70007735A3-- --Apple-Mail=_69D02F47-A9F6-48EC-B262-9C188F57C171 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWCFWVAAoJEIXgpQGOZny9Jj8P/RvVFf+V9W0/BBtl2hN1Jyde vzP0+PgNFu0BjdbRQyBs7pdORuzrmxL/WpVtwX7x4VLqaY+HxrcEa1InwuTmcFS+ L4hgbXz8hFnXL2czTo4ovsx9GL2f/MDqEKyXJvUWsUmxH1DQvvbk/is6oJklvBYu /eIIQsJ2pVFXU68nz0XMysHyKkLndHFk8tM2KCHHA/zEx0fhO3EKDj9bqEKfCBux AvmnVE1jw5roHeaO+RQUrogw7RSi4+sQOalgrbhkAg4mhrFlZtx4MgAQA5L8tDMs fQkRB10Q8UeC29AC/gLzos5a03QBkWJoIDT34qmX0y3p75LBaUiN+7FuQD6IoHi6 8QmzWh7xF2ZAbXj1KperEYJvcQb/K9mTE5dopMQDiRXeo+rX/tTgBGGNNKqrMuhA p2tfpQndTD2hmGS1dNML90m2SQmq6ryoTG7zXXss5nXoJ27SmKxH5fYKLPcl3+iL IBT4anH8eIfGd+HHhU2KPVF7xpWkKvZ1bhLP2H6l/Q1JpNYYGrUTKeXLcR2c1DXI liNEtxjWsy8XNJc2bv2D87OfuUWsK8OCBWG+JPuPvW/sm7X7MgJnGdhJmW4ABhvX VOQEzZji6zkEIOE46D2clKJ19n7NMaHLqIe8IcwH0igqnFGPcoC36AjBgKgrF7H/ sUKos5h/7DOsTd45IITL =Lbku -----END PGP SIGNATURE----- --Apple-Mail=_69D02F47-A9F6-48EC-B262-9C188F57C171-- From nobody Sun Sep 27 13:54:46 2015 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 CEF2D1B2E6D; Sun, 27 Sep 2015 13:54:44 -0700 (PDT) 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 ss_2n8ieXZcd; Sun, 27 Sep 2015 13:54:39 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D8801B2E6E; Sun, 27 Sep 2015 13:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14062; q=dns/txt; s=iport; t=1443387279; x=1444596879; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+x8JmW3+5JQIMnAengSGH6ymuALKZO7RoX6yYcPPijs=; b=mTV+w3WR4QVhtz0ZJj5cdNbYrXv+KtZLNZVZnN3ZAit7tnXJkxmpAUN0 Bu8W3VILFUjwKhDs/3v20zLhinuVz9X5CbM00rT0gczC7r9o81Eb89xx5 GQEhTN1Xw7KP/2MHisXyZmw1AGTjvPRbuhzumK9cTx9uuTLD32SP5tBts I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AFAgA6VghW/4ENJK1dgldNgS4PBr00AQ2HdAKBHzgUAQEBAQEBAYEKhCUBAQR5EAIBCD8HMhQRAgQOBRuIE8pzAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4Zzgg+BaIEGhCoRAVEHgxiBFAWSQoMuAY0OgU+ENpFNg2wBHwEBQoIRHIFUcYdiOoEFAQEB X-IronPort-AV: E=Sophos; i="5.17,598,1437436800"; d="scan'208,217"; a="35556126" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-2.cisco.com with ESMTP; 27 Sep 2015 20:54:38 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t8RKscF9024643 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 27 Sep 2015 20:54:38 GMT Received: from xch-aln-020.cisco.com (173.36.7.30) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 27 Sep 2015 15:54:37 -0500 Received: from xch-aln-020.cisco.com ([173.36.7.30]) by XCH-ALN-020.cisco.com ([173.36.7.30]) with mapi id 15.00.1104.000; Sun, 27 Sep 2015 15:54:37 -0500 From: "Carlos Pignataro (cpignata)" To: "Alvaro Retana (aretana)" Subject: Re: AD Review of draft-ietf-bfd-seamless-base Thread-Topic: AD Review of draft-ietf-bfd-seamless-base Thread-Index: AQHQ97IkT4lFfvKt5Uasfc9mskhFeZ5RMd0A Date: Sun, 27 Sep 2015 20:54:37 +0000 Message-ID: <8A567A63-F79A-48EE-A999-0F5906F29ABC@cisco.com> References: 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.117.115.54] Content-Type: multipart/alternative; boundary="_000_8A567A63F79A48EEA9990F5906F29ABCciscocom_" 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, 27 Sep 2015 20:54:45 -0000 --_000_8A567A63F79A48EEA9990F5906F29ABCciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Alvaro, Thanks for your thorough review! Before the point-by-point response, I wanted to provide some perspective on= a small subset of your comments: On Sep 25, 2015, at 12:49 PM, Alvaro Retana (aretana) > wrote: As I mention in the review for draft-ietf-bfd-seamless-ip, please consider = merging the two documents. I will keep this document under AD Evaluation (= and not return it to the WG) unless the WG Chairs consider that it is neces= sary to WGLC the resulting document. This is a recurring theme, one that you mention in every email about draft-= ietf-bfd-seamless-*. It might be useful to share some additional context an= d perspective. When we first started drafting ideas and early text of S-BFD, there was a s= ingle document for base + IP. At some point, we started drafting what S-BFD= for Segment Routing would look like, and different optimizations for diffe= rent environments. At that point, we realized that it was more sensible to = have a common -base specification, followed by a number of adjunct document= s, each about a different environment/transport. Yes, draft-akiya-bfd-seamless-ip is quite basic and straightforward, specif= ying ports, addresses, and small specifics in procedures. And if there were= only these two documents, it would make perfect sense (to me) to merge the= m. However, there=92s more! :-) For example, draft-akiya-bfd-seamless-sr sp= ecifies S-BFD for Segment Routing, in which a different set of specifics ar= e needed (given for example the ability to control the return path). Simila= rly, there are other uses of S-BFD such as S-BFD for Tunnels, S-BFD for Pse= udowires (draft-ietf-pals-seamless-vccv), etc. All of these define very nar= rowly scoped specifics (IP vs. SR vs. PW) =97 however, all of those adjunct= specifics would pollute and dramatically lower the SNR if all merged to th= e -base spec. Net-net, we opted for modularity in the specifications. The BFD WG chose to first progress -base and -ip, and only after those were= more mature, then advance -sr. This would not imply that the first two doc= uments on the sbfd set are the only ones. We did consider merging the two documents, even after we purposely split th= em. If these were the only two docs in the set, I=92d support merging them = (or not having split them). But in the larger constellation of S-BFD docs, = I consider it best to advance the -base separated from all the different sp= ecifics. 1. Normative References * I-D.ietf-bfd-multipoint should clearly be Normative because of the= new bfd.SessionType state variable Great catch. The new bfd.SessionType state variable is new for both documents, and neith= er has a dependency on values of the variable from the other document. Cons= equently, I do wonder if this document should define the variable and bfd-m= ultipoint refer to this =97 there is no serialization needed other than a c= ommon variable with independent use. 1. * I-D.ietf-bfd-generic-crypto-auth should also be Normative because = of how the Security Considerations are written: pointing to is as a =93MUST= ". Given that (as far as I can tell) there aren=92t implementations of I-D= .ietf-bfd-generic-crypto-auth, we could end up with a Normative reference t= hat blocks the publication of this document. I want to suggest that the co= mments be reworded as a suggestion or pointer to potential solutions, not a= s a mandate to use them. [Disclaimer: we will still need the SecDir to rev= iew.] Another good point =97 thanks =97 given how the text is written. I am not sure, however, the text is written in the best way. :-) 1. Nowhere in this document (or draft-ietf-bfd-seamless-ip) is congestio= n mentioned. rfc5880 talks about some of the considerations. Are there ne= w congestion-related considerations that arise because of eliminating some = of the negotiation aspects? Thinking out loud: if a session doesn=92t have= to be established (and everyone knows a remote discriminator), then there= =92s a possibility of more nodes sending traffic to a specific reflector (j= ust as an example). Please include some text indicating any congestion iss= ues =97 or at least explaining why there aren=92t any new ones. Very much agree. I believe there are subtle differences in the congestion c= onsiderations, because if the simplified negotiation. Further, I believe those should live in the -base doc. That is missing, and= we should fill in this gap. Thanks! =97 Carlos. --_000_8A567A63F79A48EEA9990F5906F29ABCciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi, Alvaro,

Thanks for your thorough review!

Before the point-by-point response, I wanted to provide som= e perspective on a small subset of your comments:

On Sep 25, 2015, at 12:49 PM, Alvaro Retana (aretana) <<= a href=3D"mailto:aretana@cisco.com" class=3D"">aretana@cisco.com> wr= ote:

As I mention in the review for draft-ietf-bfd-seamless-ip, please consider = merging the two documents.  I will keep this document under AD Evaluat= ion (and not return it to the WG) unless the WG Chairs consider that it is = necessary to WGLC the resulting document.



This is a recurring theme, one that you mention in every email about&n= bsp;draft-ietf-bfd-seamless-*. It might be useful to share some additional = context and perspective.

When we first started drafting ideas and early text of S-BFD, there wa= s a single document for base + IP. At some point, we started drafting w= hat S-BFD for Segment Routing would look like, and different optimizations = for different environments. At that point, we realized that it was more sensible to have a common -base specif= ication, followed by a number of adjunct documents, each about a different = environment/transport.

Yes, draft-akiya-bfd-seamless-ip is quite basic and straightforwa= rd, specifying ports, addresses, and small specifics in procedures. And if = there were only these two documents, it would make perfect sense (to me) to= merge them. However, there=92s more! :-) For example, draft-akiya-bfd-seamless-sr specifies S-BFD for Segment = Routing, in which a different set of specifics are needed (given for exampl= e the ability to control the return path). Similarly, there are other uses = of S-BFD such as S-BFD for Tunnels, S-BFD for Pseudowires (draft-ietf-pals-seamless-vccv), etc. All of these define = very narrowly scoped specifics (IP vs. SR vs. PW) =97 however, all of those= adjunct specifics would pollute and dramatically lower the SNR if all merg= ed to the -base spec.

Net-net, we opted for modularity in the specifications.

The BFD WG chose to first progress -base and -ip, and only after those= were more mature, then advance -sr. This would not imply that the first tw= o documents on the sbfd set are the only ones.

We did consider merging the two documents, even after we purposely spl= it them. If these were the only two docs in the set, I=92d support merging = them (or not having split them). But in the larger constellation of S-BFD d= ocs, I consider it best to advance the -base separated from all the different specifics.

  1. Normative References
    • I-D.ietf-bfd-multipoint shoul= d clearly be Normative because of the new bfd.SessionType state variable
Great catch.

The new bfd.SessionType state variable is new for both documents, and = neither has a dependency on values of the variable from the other document.= Consequently, I do wonder if this document should define the variable and = bfd-multipoint refer to this =97 there is no serialization needed other than a common variable with independent u= se.
    • I-D.ietf-bfd-generic-crypto-a= uth should also be Normative because of how the Security Considerations are= written: pointing to is as a =93MUST".  Given that (as far as I can tell) there aren=92t implementations of I-D.ietf-bfd-generic-cryp= to-auth, we could end up with a Normative reference that blocks the publica= tion of this document.  I want to suggest that the comments be reworded as a suggestion or pointer to potential solutions, no= t as a mandate to use them.  [Disclaimer: we will still need the SecDi= r to review.]
Another good point =97 thanks =97 given how the text is written.

I am not sure, however, the text is written in the best way. :-)

  1. Nowhere in this document (or draft-ietf-bfd-seamless-ip) is congestion men= tioned.  rfc5880 talks about some of the considerations.  Are the= re new congestion-related considerations that arise because of eliminating some of the negotiation aspects?  Thinki= ng out loud: if a session doesn=92t have to be established (and everyone kn= ows a remote discriminator), then there=92s a possibility of more nodes sen= ding traffic to a specific reflector (just as an example).  Please include some text indicating any congestion i= ssues =97 or at least explaining why there aren=92t any new ones.


Very much agree. I believe there are subtle differences in the congest= ion considerations, because if the simplified negotiation.

Further, I believe those should live in the -base doc. That is missing= , and we should fill in this gap.

Thanks!

=97 Carlos.


--_000_8A567A63F79A48EEA9990F5906F29ABCciscocom_-- From nobody Sun Sep 27 16:16:54 2015 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 9A9431A1A86; Sun, 27 Sep 2015 16:16:53 -0700 (PDT) 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 y3pKsxrghqtT; Sun, 27 Sep 2015 16:16:52 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E36D1A1A83; Sun, 27 Sep 2015 16:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3802; q=dns/txt; s=iport; t=1443395813; x=1444605413; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zEyg/K45ujeVsK/Uqo8qBg25+SSIdGFT+lp/WYDXDN0=; b=NUlJ14Kb7C/k0XYd+m0SoWPAgXo+OeGh7vChoCglTcpFVnXgFpKIc36r 6b0KSlJZVYEeFnaZGNj0xYRfqj4VmcRje76/3E1D5+cbttHtwYVmRNoXn Xwn/rv6Lom9bkyhrb3BOypo7gL8HgJZUCw/7Z/l2GhgsFv650yivgf/GA E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DwAQB4eAhW/5tdJa1dgldNgS4PBr00AQ2HdAKBITgUAQEBAQEBAYEKhCUBAQR5EAIBCAQ7BzIUEQIEDgWILspzAQEBAQEBAQMBAQEBAQEBAQEBGIZzAYR8hQ0HhCwFkkKDLgGNDoFPhDaDI44qg20fAQFChAFxiByBBQEBAQ X-IronPort-AV: E=Sophos; i="5.17,599,1437436800"; d="scan'208,217"; a="32488459" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 27 Sep 2015 23:16:52 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t8RNGoMQ016203 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 27 Sep 2015 23:16:51 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 27 Sep 2015 18:16:50 -0500 Received: from xhc-rcd-x13.cisco.com (173.37.183.87) by xch-rcd-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Sun, 27 Sep 2015 18:16:50 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.98]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0248.002; Sun, 27 Sep 2015 18:16:50 -0500 From: "Alvaro Retana (aretana)" To: "Carlos Pignataro (cpignata)" Subject: Re: AD Review of draft-ietf-bfd-seamless-ip Thread-Topic: AD Review of draft-ietf-bfd-seamless-ip Thread-Index: AQHQ97Ip8fkkgLz8RkWcTDCbHWzODZ5RMdUA///ksYA= Date: Sun, 27 Sep 2015 23:16:49 +0000 Message-ID: References: <1E3AA56E-F5A7-4A05-868B-B8B64157E82B@cisco.com> In-Reply-To: <1E3AA56E-F5A7-4A05-868B-B8B64157E82B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.102.23] Content-Type: multipart/alternative; boundary="_000_D22DEFE4D3DE3aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" , "bfd-chairs@ietf.org" , "draft-ietf-bfd-seamless-ip@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, 27 Sep 2015 23:16:53 -0000 --_000_D22DEFE4D3DE3aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 9/27/15, 4:54 PM, "Carlos Pignataro (cpignata)" > wrote: Carlos: Hi! I will keep this document in AD Evaluation (and not return it to the WG) at= least until a decision has been made. Sounds good =97 please let us know what=92s next about this to reach that d= ecision. That is a WG decision, so I expect the Chairs to let me know when they thin= k consensus has been reached. Note that I don=92t expect a formal consensus call or a new WGLC (based on = a potential merge) =97 unless the Chairs think it is needed. Given that th= e documents already have WG consensus, I would expect my suggestion to be r= esolved quickly. BTW, I read your justification for not merging in the thread about draft-ie= tf-bfd-seamless-base. Thanks for that! Alvaro. --_000_D22DEFE4D3DE3aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2434699A1860CF41AAB00F4228B25A5E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 9/27/15, 4:54 PM, "Carlos Pignataro (cpignata)" <cpignata@cisco.com> wrote:

Carlos:

Hi!
I will keep this document in AD Evaluation (and not return it to the WG) at= least until a decision has been made.
Sounds good =97 please let us know what=92s next about this= to reach that decision.

That is a WG decision, so I expect the Chairs to let me know when they= think consensus has been reached.

Note that I don=92t expect a formal consensus call or a new WGLC (base= d on a potential merge) =97 unless the Chairs think it is needed.  Giv= en that the documents already have WG consensus, I would expect my suggesti= on to be resolved quickly.  

BTW, I read your justification for not merging in the thread about&nbs= p;draft-ietf-bfd-seamless-base.  Thanks for that!

Alvaro.
--_000_D22DEFE4D3DE3aretanaciscocom_-- From nobody Sun Sep 27 17:33:54 2015 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 7B84C1A6FA8; Sun, 27 Sep 2015 17:33:52 -0700 (PDT) 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 9b0D7KsDoA79; Sun, 27 Sep 2015 17:33:50 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696AF1A6F9C; Sun, 27 Sep 2015 17:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7509; q=dns/txt; s=iport; t=1443400431; x=1444610031; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=M3PATsQbwwvVGV9G4X6q8EzGZcgBNnVR7UsPpOnksAg=; b=PMvlUYEF7FW7WGNyxgIVWJRhopYguL61ITPRT9+W2VOSjW8ZgoufvaVW 9IMbB5RGoripkm6L0JoZglZjj3C1HbbdPjMGgbrpPKpI/aFJwb3eCIo5X 3yol4DoFNVhoEafc6LsgR0NWMbhVc+t7dZo4zmflRHPNUxJRvRGF7C8jx I=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CpAgAMighW/5RdJa1dgldNgS4PBr00Dod0AoEoOBQBAQEBAQEBgQqEJAEBAQMBeQULAgEIGCcHMhQRAgQOBQ6IGAjKZQEBAQEBAQEBAQEBAQEBAQEBAQEBAReGc4IPgm6FDQeDGIEUBZJCgy4BgkqBYIhkgU+ENoMjjiqDbAEfAUOEAXGIHIEFAQEB X-IronPort-AV: E=Sophos;i="5.17,599,1437436800"; d="asc'?scan'208,217";a="32502601" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP; 28 Sep 2015 00:33:50 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t8S0XnP1022274 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 28 Sep 2015 00:33:49 GMT Received: from xch-aln-020.cisco.com (173.36.7.30) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 27 Sep 2015 19:33:48 -0500 Received: from xch-aln-020.cisco.com ([173.36.7.30]) by XCH-ALN-020.cisco.com ([173.36.7.30]) with mapi id 15.00.1104.000; Sun, 27 Sep 2015 19:33:48 -0500 From: "Carlos Pignataro (cpignata)" To: "Alvaro Retana (aretana)" Subject: Re: AD Review of draft-ietf-bfd-seamless-ip Thread-Topic: AD Review of draft-ietf-bfd-seamless-ip Thread-Index: AQHQ97Ip8fkkgLz8RkWcTDCbHWzODZ5RMdUA///ksYCAAFiUgA== Date: Mon, 28 Sep 2015 00:33:48 +0000 Message-ID: References: <1E3AA56E-F5A7-4A05-868B-B8B64157E82B@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.54] Content-Type: multipart/signed; boundary="Apple-Mail=_22ABA2C6-40F1-4CC3-8182-B29A92B8B24A"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" , "bfd-chairs@ietf.org" , "draft-ietf-bfd-seamless-ip@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, 28 Sep 2015 00:33:52 -0000 --Apple-Mail=_22ABA2C6-40F1-4CC3-8182-B29A92B8B24A Content-Type: multipart/alternative; boundary="Apple-Mail=_4E644F6F-B8E8-42DA-AE74-222141DA2A3E" --Apple-Mail=_4E644F6F-B8E8-42DA-AE74-222141DA2A3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Alvaro, Thanks again =97 Closing the loop, please see inline. > On Sep 27, 2015, at 7:16 PM, Alvaro Retana (aretana) = wrote: >=20 > On 9/27/15, 4:54 PM, "Carlos Pignataro (cpignata)" > wrote: >=20 > Carlos: >=20 > Hi! >> I will keep this document in AD Evaluation (and not return it to the = WG) at least until a decision has been made. >=20 > Sounds good =97 please let us know what=92s next about this to reach = that decision. >=20 > That is a WG decision, so I expect the Chairs to let me know when they = think consensus has been reached. >=20 I would assume that, since both documents were adopted simultaneously, = WG consensus was that two documents (and not a merged one) is what made = sense. We can see if there is any WG indication otherwise. Jeff? > Note that I don=92t expect a formal consensus call or a new WGLC = (based on a potential merge) =97 unless the Chairs think it is needed. = Given that the documents already have WG consensus, I would expect my = suggestion to be resolved quickly. >=20 > BTW, I read your justification for not merging in the thread about = draft-ietf-bfd-seamless-base. Thanks for that! Thank you for reading it! =97 Carlos. >=20 > Alvaro. --Apple-Mail=_4E644F6F-B8E8-42DA-AE74-222141DA2A3E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Alvaro,

Thanks again =97 Closing the loop, please see = inline.

On Sep 27, 2015, at 7:16 PM, Alvaro Retana = (aretana) <aretana@cisco.com> wrote:

On 9/27/15, 4:54 PM, "Carlos Pignataro (cpignata)" = <cpignata@cisco.com> wrote:

Carlos:

Hi!
I will keep this document in AD Evaluation (and not return it to the WG) = at least until a decision has been made.
Sounds good =97 please let us know what=92s next about = this to reach that decision.

That is a WG decision, so I expect the Chairs to let me = know when they think consensus has been reached.


I would assume that, since both documents were = adopted simultaneously, WG consensus was that two documents (and not a = merged one) is what made sense. We can see if there is any WG indication = otherwise.

Jeff?

Note that I don=92t expect a formal consensus call or a = new WGLC (based on a potential merge) =97 unless the Chairs think it is = needed.  Given that the documents already have WG consensus, I = would expect my suggestion to be resolved quickly.  

BTW, I read your justification for not merging in the = thread about draft-ietf-bfd-seamless-base.  Thanks for = that!

Thank = you for reading it!

=97 = Carlos.


Alvaro.

= --Apple-Mail=_4E644F6F-B8E8-42DA-AE74-222141DA2A3E-- --Apple-Mail=_22ABA2C6-40F1-4CC3-8182-B29A92B8B24A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWCIrrAAoJEIXgpQGOZny9ZsUQAK9BD2vL2eJjcmgAb0t5UO0m sBxmAQ8ogvE+et1XoqZT1tOmAHE0mJtfv2G0VPDwJNptBei1pRbW10uMFsnWrmCt zCAzwD8HopE4y+ubtoFxuZRT8jxVVRyCFznGiBKGR2PdX+i9hT4UW0b622ZXg+9Z WwATZG6UgjB0cmWHVTjklIujbh4QdHWeS6aVxrny2nNDbaRisvy799p9rVYvaBQU sTijfRjA2x1EvWm6qG8XxBD+YLfZLNfR1mhEQjonqeE85ZZIU3JumjS8Pzvtz5yG FJTZJZj2uLyI24G3Ke+TTCLeDrjMC3BVNHRpfYZpCxba9OqijEkICvo0+0t01YtE aROHI3yLW7wh0PH6R2L79/rmLKWn3jZXEvEUB0N4HBNdDJuc8RkIMAH+Pi0YwOsY 3SIsanylt+42xcahUBA1OcmRUZzQzCyn5k9WZgl5FYvtScs68SEM4MH4eYMe4NoD 8WhhvmIgr+YNyQiN8v9ZQbWpPeaMsgoHaprUUAhRCehO6ElnURlHsbRPZeoV4H8k +5XYGNjO7tfeTZLVPZTqvXGemRg3N64DvNKHB5wr8PVsLKktxIztcqnYznuOpuLY xEVwEnzhPe7gXnHWdIhSNxyntwbsauIJH13w6u0unkEbuGt13LziR9BxggWsMh5s nMdH24mJH329CuJXmgAz =c5O3 -----END PGP SIGNATURE----- --Apple-Mail=_22ABA2C6-40F1-4CC3-8182-B29A92B8B24A-- From nobody Sun Sep 27 19:13:21 2015 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 60E991B3038; Sun, 27 Sep 2015 19:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] 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 vtVZ3eDnGRhr; Sun, 27 Sep 2015 19:13:18 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC501B3035; Sun, 27 Sep 2015 19:13:15 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 522DC2AA0F; Mon, 28 Sep 2015 02:13:11 +0000 (GMT) Date: Sun, 27 Sep 2015 19:13:11 -0700 From: Marc Binderberger To: Carlos Pignataro (cpignata) , Alvaro Retana (aretana) Message-ID: <20150927191311104137.7ee53313@sniff.de> In-Reply-To: References: <1E3AA56E-F5A7-4A05-868B-B8B64157E82B@cisco.com> Subject: Re: AD Review of draft-ietf-bfd-seamless-ip MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.16 Archived-At: Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-ip@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: Mon, 28 Sep 2015 02:13:20 -0000 Hello everyone, not a chair of the VFD WG but I remember we made the conscious decision to _split_ the fundamentals/principles ("base") from some nitty-gritty details like the transport mechanism. > I would assume that, since both documents were adopted simultaneously, WG > consensus was that two documents (and not a merged one) is what made sense. I agree on this view. Regards, Marc On Mon, 28 Sep 2015 00:33:48 +0000, Carlos Pignataro (cpignata) wrote: > Alvaro, > > Thanks again $B!=(B Closing the loop, please see inline. > >> On Sep 27, 2015, at 7:16 PM, Alvaro Retana (aretana) >> wrote: >> On 9/27/15, 4:54 PM, "Carlos Pignataro (cpignata)" >> wrote: >> >> Carlos: >> >> Hi! >>>> I will keep this document in AD Evaluation (and not return it to the WG) >>>> at least until a decision has been made. >>> >>> Sounds good $B!=(B please let us know what$B!G(Bs next about this to reach that >>> decision. >> >> That is a WG decision, so I expect the Chairs to let me know when they >> think consensus has been reached. >> > > I would assume that, since both documents were adopted simultaneously, WG > consensus was that two documents (and not a merged one) is what made sense. > We can see if there is any WG indication otherwise. > > Jeff? > >> >> Note that I don$B!G(Bt expect a formal consensus call or a new WGLC (based on >> a potential merge) $B!=(B unless the Chairs think it is needed. Given that >> the documents already have WG consensus, I would expect my suggestion to >> be resolved quickly. >> >> BTW, I read your justification for not merging in the thread about >> draft-ietf-bfd-seamless-base. Thanks for that! > > Thank you for reading it! > > $B!=(B Carlos. > >> >> Alvaro. > > From nobody Tue Sep 29 08:32:37 2015 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 588431B451C; Tue, 29 Sep 2015 08:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 LHU_LcWnYUkw; Tue, 29 Sep 2015 08:32:26 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A44891B451B; Tue, 29 Sep 2015 08:32:26 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7CA5B1E382; Tue, 29 Sep 2015 11:36:11 -0400 (EDT) Date: Tue, 29 Sep 2015 11:36:11 -0400 From: Jeffrey Haas To: Marc Binderberger Subject: Re: AD Review of draft-ietf-bfd-seamless-ip Message-ID: <20150929153611.GA2130@pfrc.org> References: <1E3AA56E-F5A7-4A05-868B-B8B64157E82B@cisco.com> <20150927191311104137.7ee53313@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150927191311104137.7ee53313@sniff.de> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Carlos Pignataro , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-ip@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: Tue, 29 Sep 2015 15:32:28 -0000 [wearing my WG chair hat] On Sun, Sep 27, 2015 at 07:13:11PM -0700, Marc Binderberger wrote: > Hello everyone, > > not a chair of the VFD WG but I remember we made the conscious decision to > _split_ the fundamentals/principles ("base") from some nitty-gritty details > like the transport mechanism. > > > I would assume that, since both documents were adopted simultaneously, WG > > consensus was that two documents (and not a merged one) is what made sense. > > I agree on this view. This was the WG consensus. This consensus covered: - A similar split of core/base functionality for BFD in RFC 5880 vs. individual transport mappings with their own quirks. - Putting the -IP case in the -base document tends to imply that you MUST implement the -ip feature if you're doing S-BFD. Sure, you might not need to, but I suspect a number of us have been at the wrong end of RFPs which ask about "compliance with RFC XXXX". We should leave this split. We're not exactly concerned with running out of RFC numbers. :-) -- Jeff From nobody Tue Sep 29 08:39:36 2015 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 3F78A1B4575; Tue, 29 Sep 2015 08:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.321 X-Spam-Level: X-Spam-Status: No, score=0.321 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 idPZdPdGVsG9; Tue, 29 Sep 2015 08:39:25 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 796661AC3F4; Tue, 29 Sep 2015 08:39:25 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6D3B51E387; Tue, 29 Sep 2015 11:43:10 -0400 (EDT) Date: Tue, 29 Sep 2015 11:43:10 -0400 From: Jeffrey Haas To: aldrin ietf Subject: Re: AD Review of draft-ietf-bfd-seamless-use-case Message-ID: <20150929154310.GC2130@pfrc.org> References: <713AD0F3-FD85-440F-A59C-40E64B10E4CA@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@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: Tue, 29 Sep 2015 15:39:26 -0000 Sam (and to a bigger extent, Alvaro), On Fri, Sep 25, 2015 at 11:48:19AM -0700, aldrin ietf wrote: > > Coming back to this specific document.. I’m asking the WG to consider not publishing, not telling it what to do. In fact, if you look at the WG charter, even though there is a specific Milestone, the WG is chartered to “define a mechanism..” (not to produce use cases). Nonetheless, because the work has already been done, the WG can make the decision whether it still wants to publish or not. > > If that is the case, it shouldn’t even be a WG document right? > Also, the deliverable was tracked as part of milestone isn’t it? > Does that mean, milestones truly doesn’t reflect the deliverable but only Charter does? > > Do not know all the semantics of the IETF WG processes. Clarification helps. Adopting the document within the WG basically means the working group "owns" the document and that we're motivated to get work on it done. This includes things like tracking it via a milestone. Not all WG documents will be published as RFCs. The bigger question to argue IETF-wide is when we have these short-lived documents, should we just start in something like a wiki especially if the information is to be maintained long-term? Possibly. But as other people have noted in different forums, the "IETF workflow" moves around the publication life-cycle of Internet-Drafts. I'm not completely sold on the maintenance of the use cases long-term in the wiki. In my opinion, the primary purpose of use case documents is to help clarify and move forward protocol work. Ideally a portion of the use cases are clear in the actual protocol documentation, just not their individual breakdowns. -- Jeff From nobody Tue Sep 29 09:01:49 2015 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 D92431B4666; Tue, 29 Sep 2015 09:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, 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 UEjQHESMJVwa; Tue, 29 Sep 2015 09:01:45 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA42F1B4667; Tue, 29 Sep 2015 09:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=249; q=dns/txt; s=iport; t=1443542504; x=1444752104; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=l+/KGYkmk0taxam4Py5xM4je4eiSoyKKPR9oa6UQOdA=; b=EBnoiDz7z/kVNGiBiilqrJHByU4I0pvQsrEooUDQoiSVjB2mMj50CGY0 8cZM/kIcUL5BHrS8skFI5nb6T18KvIAVCouIo2YUeMlAWbTEus/5S1DtG i+coeC44XrlUOF5nbX7rYgczQGxGGTX9I5CRS+uUn2EJkJ5+TY0BHuNPr 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A8BQDGtApW/5ldJa1egySBPQa9cYd0AoFQOhIBAQEBAQEBgQqEJQEBBHkQAgEIDjgyJQIEAQ0FiC7LeAEBAQEBAQEBAQEBAQEBAQEBAQEBAReGcwGEfIUNB4QsAQSNOoUKgzABjRKbRCgLMIIRHIFUcYgagQUBAQE X-IronPort-AV: E=Sophos;i="5.17,608,1437436800"; d="scan'208";a="36101023" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 29 Sep 2015 16:01:43 +0000 Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8TG1hjG013373 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 29 Sep 2015 16:01:43 GMT Received: from xch-rcd-011.cisco.com (173.37.102.21) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 29 Sep 2015 11:01:43 -0500 Received: from xhc-rcd-x02.cisco.com (173.37.183.76) by xch-rcd-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 29 Sep 2015 11:01:43 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.98]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0248.002; Tue, 29 Sep 2015 11:01:42 -0500 From: "Alvaro Retana (aretana)" To: Jeffrey Haas , Marc Binderberger Subject: Re: AD Review of draft-ietf-bfd-seamless-ip Thread-Topic: AD Review of draft-ietf-bfd-seamless-ip Thread-Index: AQHQ97Ip8fkkgLz8RkWcTDCbHWzODZ5RMdUA///ksYCAAFiUgIAAG8WAgAJysID//7NKgA== Date: Tue, 29 Sep 2015 16:01:42 +0000 Message-ID: References: <1E3AA56E-F5A7-4A05-868B-B8B64157E82B@cisco.com> <20150927191311104137.7ee53313@sniff.de> <20150929153611.GA2130@pfrc.org> In-Reply-To: <20150929153611.GA2130@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.21] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-ip@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: Tue, 29 Sep 2015 16:01:49 -0000 On 9/29/15, 10:36 AM, "Jeffrey Haas" wrote: Hi! >[wearing my WG chair hat] > >... >We should leave this split. That=B9s fine. As I said in the review, all I wanted was for the WG to consider it. Thanks! Alvaro. From nobody Tue Sep 29 10:07:33 2015 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 DF1EA1B4931; Tue, 29 Sep 2015 10:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 Xsjx1HQPdeWC; Tue, 29 Sep 2015 10:07:30 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (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 5F70A1B4930; Tue, 29 Sep 2015 10:07:30 -0700 (PDT) Received: by pacex6 with SMTP id ex6so11549589pac.0; Tue, 29 Sep 2015 10:07:30 -0700 (PDT) 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 :content-transfer-encoding:message-id:references:to; bh=A3pG7zvHerYpFLQUhHeWaKnPV15z3i/Co4TlIHWhNNU=; b=wCeLwBZM3CCgFGkT3mFfdSmzJg+tunYf1jeCZKY1PaFmV0DxCZWYBrWZ266yVAB0JI kN0dq/TFvJaXBH9FBpzsj9lHdNc4KXdoK5X5jCRKF/JChrwkMV7khoBsBpG88vqu1MW9 jWKJZnVW4yyPFrf/QSbQkAOCoUC0UmfYoBIWpR3pF2dzSpJALjo2wEagNUxBq+3xKVf/ VNS8BxCXKXXO/oEZTgtu6sRdpEgPOcxkfApaRMnj1IdPs9lQyBAp7p7b74s+VKg8wIdt GyuXNzI852N7loMeLTahlEnteLUtT4NMZwJwp5Lg0+GxM7stKqYzWisx1gw9S9U3db8k 2LQA== X-Received: by 10.66.160.194 with SMTP id xm2mr33675122pab.111.1443546450057; Tue, 29 Sep 2015 10:07:30 -0700 (PDT) Received: from dhcp-172-19-33-182.mtv.corp.google.com ([172.19.33.182]) by smtp.gmail.com with ESMTPSA id kh7sm26565493pbc.93.2015.09.29.10.07.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Sep 2015 10:07:29 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: AD Review of draft-ietf-bfd-seamless-use-case From: Sam Aldrin In-Reply-To: <20150929154310.GC2130@pfrc.org> Date: Tue, 29 Sep 2015 10:07:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <98CBEFCA-2B40-4223-BAA2-637D44B70006@gmail.com> References: <713AD0F3-FD85-440F-A59C-40E64B10E4CA@gmail.com> <20150929154310.GC2130@pfrc.org> To: Jeffrey Haas X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@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: Tue, 29 Sep 2015 17:07:32 -0000 Hi Jeff and Alvaro, Inline for my comments. > On Sep 29, 2015, at 8:43 AM, Jeffrey Haas wrote: >=20 > Sam (and to a bigger extent, Alvaro), >=20 > On Fri, Sep 25, 2015 at 11:48:19AM -0700, aldrin ietf wrote: >>> Coming back to this specific document.. I=E2=80=99m asking the WG = to consider not publishing, not telling it what to do. In fact, if you = look at the WG charter, even though there is a specific Milestone, the = WG is chartered to =E2=80=9Cdefine a mechanism..=E2=80=9D (not to = produce use cases). Nonetheless, because the work has already been = done, the WG can make the decision whether it still wants to publish or = not. >>=20 >> If that is the case, it shouldn=E2=80=99t even be a WG document = right? >> Also, the deliverable was tracked as part of milestone isn=E2=80=99t = it? >> Does that mean, milestones truly doesn=E2=80=99t reflect the = deliverable but only Charter does? >>=20 >> Do not know all the semantics of the IETF WG processes. Clarification = helps. >=20 > Adopting the document within the WG basically means the working group = "owns" > the document and that we're motivated to get work on it done. This = includes > things like tracking it via a milestone. >=20 > Not all WG documents will be published as RFCs. >=20 > The bigger question to argue IETF-wide is when we have these = short-lived > documents, should we just start in something like a wiki especially if = the > information is to be maintained long-term? Possibly. But as other = people > have noted in different forums, the "IETF workflow" moves around the > publication life-cycle of Internet-Drafts. >=20 > I'm not completely sold on the maintenance of the use cases long-term = in the > wiki. In my opinion, the primary purpose of use case documents is to = help > clarify and move forward protocol work. Ideally a portion of the use = cases > are clear in the actual protocol documentation, just not their = individual > breakdowns. I=E2=80=99d like to see that clarified across IETF, at the lease RTG = area which I am focussed on. Secondly, would like to see what the definition of short lived documents = are. Why are problem statement, requirements etc, which are short lived and = more or less like use case document as well, made as RFC=E2=80=99s? As long as there is consistency and definition, IETF as a community = shouldn=E2=80=99t have a problem. That way folks have choice on where to invest time. -sam >=20 >=20 > -- Jeff From nobody Tue Sep 29 12:46:58 2015 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 178151B4DBA; Tue, 29 Sep 2015 12:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, 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 4opwMJS1ey5b; Tue, 29 Sep 2015 12:46:55 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03B0A1B4DB1; Tue, 29 Sep 2015 12:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5114; q=dns/txt; s=iport; t=1443556015; x=1444765615; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+jCphNXbiMDAo6gkrGS4bvZTHiqAvFaktAeVCGaRE7w=; b=lFmpEt54CwYuzGDUkkiDKu4occOZfjGUAzSTOgnTL2+x2YtWDAEYv3Xg Linnhg8mJ6yG+tMr0eerLUU9QwaimhIMJBrGvkLpSelYJx0JVOo7T4Wwp lUu0OnKouhqQbW1WRS5IS1CCLMggVEnpeTq7ajrKPIXtpYYcm7az5efsl s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DvAQBe6QpW/5xdJa1egyRUaQa9YwENgX2FdwKBUjgUAQEBAQEBAYEKhCUBAQR5EAIBCBguIRElAgQBDQUUBYgAAxINxnANhQgBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIZzAYR8glCBZCYzB4QsBZJEgzABhRVohSWBcIFPki2HSB8BAUKCERyBVHGHVkOBBQEBAQ X-IronPort-AV: E=Sophos;i="5.17,609,1437436800"; d="scan'208";a="192712403" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP; 29 Sep 2015 19:46:54 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t8TJksUf001671 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 29 Sep 2015 19:46:54 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 29 Sep 2015 14:46:53 -0500 Received: from xhc-aln-x07.cisco.com (173.36.12.81) by xch-aln-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 29 Sep 2015 14:46:53 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.98]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0248.002; Tue, 29 Sep 2015 14:46:53 -0500 From: "Alvaro Retana (aretana)" To: Sam Aldrin , Jeffrey Haas Subject: Re: AD Review of draft-ietf-bfd-seamless-use-case Thread-Topic: AD Review of draft-ietf-bfd-seamless-use-case Thread-Index: AQHQ97Ieqtfo0LmZ1kugOs1WHaftMZ5NzGKA///LMwCABivJxYAALGUA Date: Tue, 29 Sep 2015 19:46:53 +0000 Message-ID: References: <713AD0F3-FD85-440F-A59C-40E64B10E4CA@gmail.com> <20150929154310.GC2130@pfrc.org> <98CBEFCA-2B40-4223-BAA2-637D44B70006@gmail.com> In-Reply-To: <98CBEFCA-2B40-4223-BAA2-637D44B70006@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.101.220.143] Content-Type: text/plain; charset="Windows-1252" Content-ID: <730EF73F5B68C442AE87796C3F65780D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@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: Tue, 29 Sep 2015 19:46:57 -0000 On 9/29/15, 12:07 PM, "Sam Aldrin" wrote: Sam: Hi! >Hi Jeff and Alvaro, > >Inline for my comments. > >> On Sep 29, 2015, at 8:43 AM, Jeffrey Haas wrote: >>=20 >> Sam (and to a bigger extent, Alvaro), >>=20 >> On Fri, Sep 25, 2015 at 11:48:19AM -0700, aldrin ietf wrote: >>>> Coming back to this specific document.. I=B9m asking the WG to >>>>consider not publishing, not telling it what to do. In fact, if you >>>>look at the WG charter, even though there is a specific Milestone, the >>>>WG is chartered to =B3define a mechanism..=B2 (not to produce use cases= ). >>>>Nonetheless, because the work has already been done, the WG can make >>>>the decision whether it still wants to publish or not. >>>=20 >>> If that is the case, it shouldn=B9t even be a WG document right? >>> Also, the deliverable was tracked as part of milestone isn=B9t it? >>> Does that mean, milestones truly doesn=B9t reflect the deliverable but >>>only Charter does? >>>=20 >>> Do not know all the semantics of the IETF WG processes. Clarification >>>helps. >>=20 >> Adopting the document within the WG basically means the working group >>"owns" >> the document and that we're motivated to get work on it done. This >>includes >> things like tracking it via a milestone. >>=20 >> Not all WG documents will be published as RFCs. >>=20 >> The bigger question to argue IETF-wide is when we have these short-lived >> documents, should we just start in something like a wiki especially if >>the >> information is to be maintained long-term? Possibly. But as other >>people >> have noted in different forums, the "IETF workflow" moves around the >> publication life-cycle of Internet-Drafts. >>=20 >> I'm not completely sold on the maintenance of the use cases long-term >>in the >> wiki. In my opinion, the primary purpose of use case documents is to >>help >> clarify and move forward protocol work. Ideally a portion of the use >>cases >> are clear in the actual protocol documentation, just not their >>individual >> breakdowns. > >I=B9d like to see that clarified across IETF, at the lease RTG area which = I >am focussed on. This =B3change=B2 has been brewing in the IESG for a while, where many ADs have been expressing their opinion about the need (or lack thereof) for publishing some short-lived documents which have already met their useful lifetime. However, there is no one-size-fits-all statement that can be made. For example, use cases may inform the community of work that should be done later or of issues to be addressed elsewhere =8B I think a good example of may be the documentation of the use cases that are seriously affected by multicast issues in wireless networks (which the IEEE may solve). Note that even though the different ADs express their opinion about the lack of need to publish documents, the ballots are always =B3No Objection= =B2 =8B this (in my case) is due to the fact that if the document got to the IESG for publication then it already has WG and IETF consensus. However, we have been making some explicit changes in some charters =8B I pointed you before to the detnet charter as an example. All this comes back to me asking the WG to *consider* not publishing (vs just deciding myself). I (personally) still think we don=B9t need to publish this document, but if the WG has a different opinion then I=B9m ok with being on the rough side of the consensus. The other reason for making the =B3change=B2 slowly and not just issuing a wide-reaching statement is that, as Jeff mentioned above, the work moves around IDs/RFCs =8B we (as a community) are not ready and/or don=B9t have t= he tools to consistently move sustaining documents somewhere else (as in a Wiki). For now, it is a case-by-case consideration. At least in my case I will continue to ask the WGs I=B9m responsible for to *consider* not publishing short-lived documents. [As I said above, I can be in the rough.] >Secondly, would like to see what the definition of short lived documents >are. >Why are problem statement, requirements etc, which are short lived and >more or less like use case document as well, made as RFC=B9s? In general, I think that those other types of documents also fit the short-lived definition. Another example of a short-lived document is an implementation report. These are used to reflect the current implementation status of an ID, and is used in many cases to prove that the required implementations do exist and how they comply with the RFC-to-be. Not only is the lifetime limited, but if an implementation comes later (or changes), then it is not documented anywhere. The idr WG is not publishing implementation reports anymore, they are being put on a wiki. The first draft to go through this is ADD_PATH [1] [2]. :-) Thanks! Alvaro. [1]=20 https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths-implementation/ [2]=20 https://tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-add-paths%20implemen tations From nobody Tue Sep 29 16:10:37 2015 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 C8AD71A0069; Tue, 29 Sep 2015 16:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 pUfskczgnDsi; Tue, 29 Sep 2015 16:10:34 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (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 8BEA61A008E; Tue, 29 Sep 2015 16:10:34 -0700 (PDT) Received: by pacfv12 with SMTP id fv12so19494551pac.2; Tue, 29 Sep 2015 16:10:34 -0700 (PDT) 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 :content-transfer-encoding:message-id:references:to; bh=2rqBFJjW3gOOg7Q1HzoyrxD4tehoZLIxEMwJPrzdZSg=; b=fj+wSZ6amZ9zA/2DxjblaB2p1KIGxIlOlasbqU3ruggooW+La2L34J5EKgc3IX2S7P gihjweubREIRPwjcPTvgjTBx9IEltqJZ9Te94Zg53vS+XkQaa1i3aLH5chdz68lFvWN4 fHeIQ6MvdAZT7shfedjeIdQtR/tdp8An98UdWE+mOKe6MWcZBN6RfVzi2Ir0caD9/E+B 9Ce+nP6n+0BSVCivlnFWOrqxjuhNbXqcEnmM6VpLQjhtsB4laAwxD7LPcewtbMb2qzdX doRWrSDEFEX2QnVAv8JLGw4XHTTEo9OLhn/muEEYHtiYZzhQzCepTTFrn3UnH+t2iy+v M2YQ== X-Received: by 10.68.95.3 with SMTP id dg3mr694030pbb.35.1443568234188; Tue, 29 Sep 2015 16:10:34 -0700 (PDT) Received: from ?IPv6:2620::1000:3202:bc88:3bd2:882e:5675? ([2620:0:1000:3202:bc88:3bd2:882e:5675]) by smtp.gmail.com with ESMTPSA id pc8sm27387256pbc.27.2015.09.29.16.10.33 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Sep 2015 16:10:33 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: AD Review of draft-ietf-bfd-seamless-use-case From: aldrin ietf In-Reply-To: Date: Tue, 29 Sep 2015 16:10:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3C87BFAC-5BC2-4B71-98F5-F369465BA2C2@gmail.com> References: <713AD0F3-FD85-440F-A59C-40E64B10E4CA@gmail.com> <20150929154310.GC2130@pfrc.org> <98CBEFCA-2B40-4223-BAA2-637D44B70006@gmail.com> To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@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: Tue, 29 Sep 2015 23:10:36 -0000 Hi Alvaro, Like I said in my earlier emails, it would be good to have proper = guidance, at the early stage of the document.=20 When the milestone was set to propose to make it standard, I believed = that is something WG was tasked to do, not drop/orphan it. [Not specific to this doc] I have a different take to the point of, short lived documents loosing = relevancy. Whenever a solution is proposed, it is always asked, why and where this = is asked and used.=20 Solutions may or may not capture entirety of problem/requirement/where = it is used, etc.. Applied against timeline, it could spread over the time and beyond = solution becoming standard. Referring to those documents and the work related to that is useful, = which I believe, =91informational=92 track is for. If the goal is not to have these numbered as RFC, rather something else, = it is good to have that discussion across IETF happen and agreed upon, = before making any choices/decisions. I haven=92t seen much on that, thus = far. Also, this should apply to all short lived documents. cheers -sam > On Sep 29, 2015, at 12:46 PM, Alvaro Retana (aretana) = wrote: >=20 > On 9/29/15, 12:07 PM, "Sam Aldrin" wrote: >=20 > Sam: >=20 > Hi! >=20 >> Hi Jeff and Alvaro, >>=20 >> Inline for my comments. >>=20 >>> On Sep 29, 2015, at 8:43 AM, Jeffrey Haas wrote: >>>=20 >>> Sam (and to a bigger extent, Alvaro), >>>=20 >>> On Fri, Sep 25, 2015 at 11:48:19AM -0700, aldrin ietf wrote: >>>>> Coming back to this specific document.. I=B9m asking the WG to >>>>> consider not publishing, not telling it what to do. In fact, if = you >>>>> look at the WG charter, even though there is a specific Milestone, = the >>>>> WG is chartered to =B3define a mechanism..=B2 (not to produce use = cases). >>>>> Nonetheless, because the work has already been done, the WG can = make >>>>> the decision whether it still wants to publish or not. >>>>=20 >>>> If that is the case, it shouldn=B9t even be a WG document right? >>>> Also, the deliverable was tracked as part of milestone isn=B9t it? >>>> Does that mean, milestones truly doesn=B9t reflect the deliverable = but >>>> only Charter does? >>>>=20 >>>> Do not know all the semantics of the IETF WG processes. = Clarification >>>> helps. >>>=20 >>> Adopting the document within the WG basically means the working = group >>> "owns" >>> the document and that we're motivated to get work on it done. This >>> includes >>> things like tracking it via a milestone. >>>=20 >>> Not all WG documents will be published as RFCs. >>>=20 >>> The bigger question to argue IETF-wide is when we have these = short-lived >>> documents, should we just start in something like a wiki especially = if >>> the >>> information is to be maintained long-term? Possibly. But as other >>> people >>> have noted in different forums, the "IETF workflow" moves around the >>> publication life-cycle of Internet-Drafts. >>>=20 >>> I'm not completely sold on the maintenance of the use cases = long-term >>> in the >>> wiki. In my opinion, the primary purpose of use case documents is = to >>> help >>> clarify and move forward protocol work. Ideally a portion of the = use >>> cases >>> are clear in the actual protocol documentation, just not their >>> individual >>> breakdowns. >>=20 >> I=B9d like to see that clarified across IETF, at the lease RTG area = which I >> am focussed on. >=20 > This =B3change=B2 has been brewing in the IESG for a while, where many = ADs > have been expressing their opinion about the need (or lack thereof) = for > publishing some short-lived documents which have already met their = useful > lifetime. >=20 > However, there is no one-size-fits-all statement that can be made. = For > example, use cases may inform the community of work that should be = done > later or of issues to be addressed elsewhere =8B I think a good = example of > may be the documentation of the use cases that are seriously affected = by > multicast issues in wireless networks (which the IEEE may solve). >=20 > Note that even though the different ADs express their opinion about = the > lack of need to publish documents, the ballots are always =B3No = Objection=B2 =8B > this (in my case) is due to the fact that if the document got to the = IESG > for publication then it already has WG and IETF consensus. However, = we > have been making some explicit changes in some charters =8B I pointed = you > before to the detnet charter as an example. >=20 > All this comes back to me asking the WG to *consider* not publishing = (vs > just deciding myself). I (personally) still think we don=B9t need to > publish this document, but if the WG has a different opinion then I=B9m = ok > with being on the rough side of the consensus. >=20 >=20 > The other reason for making the =B3change=B2 slowly and not just = issuing a > wide-reaching statement is that, as Jeff mentioned above, the work = moves > around IDs/RFCs =8B we (as a community) are not ready and/or don=B9t = have the > tools to consistently move sustaining documents somewhere else (as in = a > Wiki). >=20 > For now, it is a case-by-case consideration. At least in my case I = will > continue to ask the WGs I=B9m responsible for to *consider* not = publishing > short-lived documents. [As I said above, I can be in the rough.] >=20 >=20 >=20 >> Secondly, would like to see what the definition of short lived = documents >> are. >> Why are problem statement, requirements etc, which are short lived = and >> more or less like use case document as well, made as RFC=B9s? >=20 > In general, I think that those other types of documents also fit the > short-lived definition. >=20 > Another example of a short-lived document is an implementation report. > These are used to reflect the current implementation status of an ID, = and > is used in many cases to prove that the required implementations do = exist > and how they comply with the RFC-to-be. Not only is the lifetime = limited, > but if an implementation comes later (or changes), then it is not > documented anywhere. The idr WG is not publishing implementation = reports > anymore, they are being put on a wiki. The first draft to go through = this > is ADD_PATH [1] [2]. :-) >=20 > Thanks! >=20 > Alvaro. >=20 > [1]=20 > = https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths-implementation/ > [2]=20 > = https://tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-add-paths%20impleme= n > tations >=20 From nobody Tue Sep 29 21:47:22 2015 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 AE9831B5BD2; Tue, 29 Sep 2015 21:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 SGt20P-oqM8j; Tue, 29 Sep 2015 21:47:20 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5641B5BD0; Tue, 29 Sep 2015 21:47:20 -0700 (PDT) Received: from [192.168.1.10] (unknown [49.149.211.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 3692018013B2; Wed, 30 Sep 2015 06:47:09 +0200 (CEST) Subject: Re: AD Review of draft-ietf-bfd-seamless-use-case To: Jeffrey Haas , aldrin ietf References: <713AD0F3-FD85-440F-A59C-40E64B10E4CA@gmail.com> <20150929154310.GC2130@pfrc.org> From: Loa Andersson Message-ID: <560B6942.9050700@pi.nu> Date: Wed, 30 Sep 2015 12:46:58 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150929154310.GC2130@pfrc.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@ietf.org" , "mpls-chairs@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 04:47:21 -0000 Jeff, Sam and Alvaro, I guess that thing are different from wg to wg, given some hard core of IETF wide wg process. I believe this is a good thing, and that practice in one wg does not define IETF process. On 2015-09-29 23:43, Jeffrey Haas wrote: > Sam (and to a bigger extent, Alvaro), > > On Fri, Sep 25, 2015 at 11:48:19AM -0700, aldrin ietf wrote: >>> Coming back to this specific document.. I’m asking the WG to consider not publishing, not telling it what to do. In fact, if you look at the WG charter, even though there is a specific Milestone, the WG is chartered to “define a mechanism..” (not to produce use cases). Nonetheless, because the work has already been done, the WG can make the decision whether it still wants to publish or not. >> >> If that is the case, it shouldn’t even be a WG document right? >> Also, the deliverable was tracked as part of milestone isn’t it? >> Does that mean, milestones truly doesn’t reflect the deliverable but only Charter does? >> >> Do not know all the semantics of the IETF WG processes. Clarification helps. > > Adopting the document within the WG basically means the working group "owns" > the document and that we're motivated to get work on it done. This includes > things like tracking it via a milestone. We talk about this as taking over the revision control. The motivation point is important, when a document stops being individual and becomes a working group document, there is a real difference for the authors / editors. > > Not all WG documents will be published as RFCs. > yes but that does not necessarily stop them from being wg documents. Actually the status of wiki text is a bit ambivalent, at least if it is possible for anyone to change it (that is often what is said to be the benefit of the wiki). > The bigger question to argue IETF-wide is when we have these short-lived > documents, should we just start in something like a wiki especially if the > information is to be maintained long-term? Possibly. But as other people > have noted in different forums, the "IETF workflow" moves around the > publication life-cycle of Internet-Drafts. I know that wiki's are popular, but I from one point of view they are only one more thing to maintain. Actually between the wg doucments page, the wg milestones and wiki-based material, I frequently find that the document page need everything I need, if maintained properly. The rest is mostly redundant. Over a year and half I worked very hard to maintain milestones and found that this was extra work, the document pae, including document history give me what I need. > > I'm not completely sold on the maintenance of the use cases long-term in the > wiki. In my opinion, the primary purpose of use case documents is to help > clarify and move forward protocol work. Ideally a portion of the use cases > are clear in the actual protocol documentation, just not their individual > breakdowns. I guess that "not completely sold on" is an understatement? /Loa > > > -- Jeff > From nobody Tue Sep 29 23:09:48 2015 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 895671B5CAF for ; Tue, 29 Sep 2015 23:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 nb-8kMYY2q6G for ; Tue, 29 Sep 2015 23:09:46 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (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 DE4FD1B5CAD for ; Tue, 29 Sep 2015 23:09:45 -0700 (PDT) Received: by padhy16 with SMTP id hy16so29873614pad.1 for ; Tue, 29 Sep 2015 23:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:from:content-type:message-id:date:to :content-transfer-encoding:mime-version; bh=6LTpgzW0/MziJ2d92G8OGy2ev2J1pFp1tPjrb181sXc=; b=ICgPQGqbgZytZJvU75r+vViuDNCMj27jn/HYiGCr02VEzGTMwoZzV+i/f71wqWbtmx th0v994jUm+i1kvn6u5GC+cLzCt2hVS+ZsBUsmvLf3K2Zds1YIjHAyAo24n9qEDET5jx wL2ZhhX16xzojUyH0sRT771X1HGHc3MpTmC7lUxMgv9YrcSjL8AyYWe0MMCUZAwBTH7D oBae2WPmnc4Sg8McIG5kqhvt3Dfe0PZyKwUojZjQGNbz49nOgldy6f5z/3+RYE6CimnY 52oxlni8wRhn2vBEbzN+uFfyGZTGyXxPGsmBKOQCkKXqFT2eIUVyfvCJW+caBpgCt+n7 b0RA== X-Received: by 10.68.200.167 with SMTP id jt7mr319346pbc.83.1443593384557; Tue, 29 Sep 2015 23:09:44 -0700 (PDT) Received: from [192.168.1.150] (108-247-125-249.lightspeed.sntcca.sbcglobal.net. [108.247.125.249]) by smtp.gmail.com with ESMTPSA id f5sm29253727pas.23.2015.09.29.23.09.43 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Sep 2015 23:09:43 -0700 (PDT) Subject: Fwd: New Version Notification for draft-mahesh-bfd-authentication-01.txt References: <20150930022701.5965.79739.idtracker@ietfa.amsl.com> From: Mahesh Jethanandani Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (12B466) Message-Id: Date: Tue, 29 Sep 2015 23:09:46 -0700 To: "rtg-bfd@ietf. org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (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, 30 Sep 2015 06:09:47 -0000 This version of the draft addresses concerns that were raised in IETF 92. Th= e change is to carry a sequence number in every packet of BFD. Carrying a se= quence number for authentication reasons is not new, but with selective auth= entication it helps detect MITM attack and has the benefit of detecting lost= BFD frames. As usual, comments are welcome. Mahesh Jethanandani mjethanandani@gmail.com Begin forwarded message: >=20 > A new version of I-D, draft-mahesh-bfd-authentication-01.txt > has been successfully submitted by Mahesh Jethanandani and posted to the > IETF repository. >=20 > Name: draft-mahesh-bfd-authentication > Revision: 01 > Title: Optimizing BFD Authentication > Document date: 2015-09-28 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/internet-drafts/draft-mahesh-bfd-auth= entication-01.txt > Status: https://datatracker.ietf.org/doc/draft-mahesh-bfd-authenti= cation/ > Htmlized: https://tools.ietf.org/html/draft-mahesh-bfd-authenticatio= n-01 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mahesh-bfd-authe= ntication-01 >=20 > Abstract: > This document describes an optimization to BFD Authentication as > described in Section 6.7 of BFD [RFC5880]. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20