From rtg-bfd-bounces@ietf.org Mon Jul 04 08:56:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpQVJ-0008OZ-Vl; Mon, 04 Jul 2005 08:56:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpQVB-0008Lm-RF for rtg-bfd@megatron.ietf.org; Mon, 04 Jul 2005 08:56:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08823 for ; Mon, 4 Jul 2005 08:56:43 -0400 (EDT) From: richard.spencer@bt.com Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpQvj-0008Gl-QD for rtg-bfd@ietf.org; Mon, 04 Jul 2005 09:24:12 -0400 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Jul 2005 13:56:25 +0100 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Jul 2005 13:56:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Jul 2005 13:56:25 +0100 Message-ID: Thread-Topic: Re: bfd application with BGP and static routes draft submission Thread-Index: AcV8Yzh8sJ4iTTWkR9ujrlp7TGB58gADotfQ To: , X-OriginalArrivalTime: 04 Jul 2005 12:56:25.0676 (UTC) FILETIME=[C95E88C0:01C58097] X-Spam-Score: 0.3 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org Subject: RE: bfd application with BGP and static routes draft submission X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Suping, Carlos, The single-hop draft describes how BFD is used with graceful restart for = OSPF/IS-IS and also mentions that BFD may be bootstrapped using = OSPF/IS-IS hellos. Therefore if there is a requirement to use BFD with = BGP, then I think a description of how BFD works with BGP graceful = restart, and how BFD may be bootstrapped using BGP Open messages is = important in order to achieve interoperability. On the other hand, I am less convinced by the need for sections to cover = BFD for static routes or RIP. In both cases, the BFD sessions will be = established independently and therefore in my opinion the mapping of a = BFD session to a static route or RIP neighbour is an implementation = issue. What information do you believe is missing from the current = drafts that prevents the implementation of interoperable static route = and RIP BFD implementations (other than saying that BFD is optional)? Additionally, what is the reason behind the suggestion to use ICMP to = bootstrap BFD in the static route case? In the single-hop case, static = route BFD sessions should be demultiplexed based on the interface and in = the multi-hop case BFD sessions can be demultiplexed based on = source/destination address pairs. The point being that the your = discriminator fields do not need to be exchanged via another mechanism. = An ideal solution would be for a BFD system (in an active role) to begin = sending BFD control packets as soon as BFD is configured on the system = using manual/OSS provisioning (with the your discriminator field set to = zero and my discriminator set to a number automatically generated by the = BFD system or via OSS). If ICMP was used here then OSS/manual = provisioning would need to be used to configure the BFD sessions, and = then to initiate the ICMP messages. Even if ICMP messages were sent = automatically following BFD session configuration, why are they needed = and what value do they add? Please see below for some specific comments based on your discussion. > > Should this draft be extended to the use of BFD for BGP in a=20 > > multi-hop environment? It seems that the changes needed for=20 > > BGP in a multi-hop environment would be that demultiplexing=20 > > should be based either on BGP signalling or on the=20 > > source/destination address pairs and that Authentication > > SHOULD be used (as specified in the multi-hop draft). =20 > [suping] For BGP I think the usually application is one-hop,=20 > so do we nessesarily need the multi-hop BGP? =20 [RS] What about IBGP and EBGP multihop? > >Could this draft be extended to the use of BFD for RIP? This would > >complete the application of BFD to the most common routing protocols > >in use today, as OSPF and IS-IS are covered in the 1Hop draft. >=20 > [suping] I am very happy to do that. > > > >As RIPv2 is mostly a protocol frozen in time, demultiplexing methods > >would only be manual configuration and demultiplexing based on > >source/destination address pairs. > >ICMP and LSP-ping would not apply, > >as reasoned below for static routes. > >Also, because of this "frozennes", no possibility exists to negotiate > >the discriminator value inside the protocol. > >So, for this protocol, as in BGP, it should be OPTIONAL not=20 > to put the routes from RIP into the routing table until the BFD = session is > >established. In this case the behaviour could also be not to require > >any peer to behave differently from standard RIP until the first > >session is established. >=20 > [suping]I agree with you. [RS] If the BFD session cannot be established dynamically using RIP = (i.e. it is established independently and then mapped to a RIP = neighbour), then what information needs to go in the draft? > >Although I'm not sure it is a good idea to use ICMP to achieve > >demultiplexing, I think the section 3.1.1 is somewhat incomplete, as > >it should define the ICMP type and code values (as TBD, perhaps), and > >be extended to ICMPv6. I wouldn't do it, anyway. >=20 > [suping]I think ICMP is a optional ways to demultiplexing=20 > BFD session. In fact in ICMP(V4), there are message types of 15=20 > (Information Request) and 16 (Information Reply), my intent is to=20 > extend the existing message by adding BFD discrimator in it. > As for ICMPv6, I think there should be some new message=20 > type(TBD) for this purpose. [RS] In the single-hop static route case (i.e. the next hop is directly = connected) then the your discriminator field should be set to zero and = the packet demultiplexed based on the interface. In the multi-hop static = route case (i.e. the next hop is more than one hop away) then the your = discriminator field should be set to zero and the packet demultiplexed = based on the source/destination address pair. ICMP could be used to = exchange your discriminator fields, but what would the advantage of this = be over just sending a your discriminator field of zero, and = demultiplexing based on the interface or source/destination address? > >I'm also unsure what scenario could have a static route needing BFD > >and have MPLS so that it has the LSP-ping mechanism to bootstrap the > >session (3.1.2). If you have MPLS, you certainly could apply BFD for > >MPLS and then you don't need BFD for this static route. [RS] The requirement to use BFD for LSPs as well as static routes is = perfectly viable. An operator may want to use BFD to detect failures = between system A and system B where forwarding is based on static routes = (e.g. for control traffic), whilst at the same time detect failures = where forwarding is based on MPLS (e.g. customer traffic using a TE = tunnel LSP). What is not viable is the use of LSP ping for bootstrapping = the static BFD session. > [suping]Yes, I think you are right. If MPLS is supported we=20 > could use BFD for MPLS and don't need BFD for the static route. In=20 > anoter word, when static route we think that no MPLS is supported. So=20 > I will make such clarification in the draft. [RS] Forwarding of traffic between two systems based MPLS and static = routes is valid, using BFD to bootstrap the static route session is not. = If the static route belongs to a FEC for which forwarding is based on = MPLS, then BFD should be used on the LSP (i.e. static route BFD is not = needed because the packets are forwarded using MPLS not IP). If traffic = for the static route is forwarded using IP, then the FEC for the LSP = will be different and therefore LSP ping cannot be used to bootstrap the = static route session, as per the MPLS BFD draft "BFD control packets = sent by the ingress LSR are encapsulated in the MPLS label stack that = corresponds to the FEC for which fault detection is being performed." = The use of LSP ping to bootstrap any protocol other than MPLS is not = viable and therefore this option should be removed from both the static = and BGP cases in the draft. > >I'm certainly overlooking something on 2.2 and 3.2, why=20 > >would one want to put a random address from 127/8 in the=20 > >destination address instead of the IP address of the peer > >or the static route points to? In BGP, we already know the=20 > >destination address, why shouldn't it be used? > >For static routes on a LAN environment, where that address must be > >known in order to get its MAC address, the same reasoning applies. I > >see the applicability to point-to-point environments, but there > >Inverse ARP could be used to get the other side's IP address. > >But in any case, probably a rationale for the decision wouldn't harm. >=20 > [suping]Yes, I think you are right again:) We can use explicity = destination=20 > IP address in BGP and static route applications because the DIP has = been known. [RS] The text from the encapsulation section being discussed here was = obviously a 'cut & paste' from the BFD MPLS draft! There is no need for = an encapsulation section anyway as encapsulation is covered in the = single-hop draft. > >It would be a good thing if there were some mechanism so that manual > >configuration does not need to configure a specific value for the My > >discriminator... =A2=AFPerhaps restricting demultiplexing in the = presence > >of a zero value for the My discriminator to one session per > >source/destination address pair? [RS] The my discriminator field must be configured using a non-zero = value, as per the base BFD draft "If the My Discriminator field is zero, = the packet MUST be discarded." However, this doesn't mean that it needs = to be manually configured, it could be dynamically generated by the = system when the BFD session is enabled, or it could be dynamically = generated/provisioned using OSS. > [suping]So in implementation a more situation must be considered if = this is=20 > the criteria, and even more if more BFD sessions are needed, = demultiplexing also > needed not according to source/destination address pair.=A2=AF [RS] Demultiplexing issues/methods are already covered in the single-hop = and multi-hop drafts. In the single-hop case, there should only be one = BFD session per interface, per protocol. Therefore, if a system receives = a BFD packet with a your discriminator of zero, then it is mapped to the = corresponding session for that interface and protocol. In the multi-hop = case, if a system receives a BFD packet with a your discriminator of = zero, then the session can be demultiplexed based on the = source/destination address pair. Alternatively, out-of-band signalling = may be used to exchange your discriminator fields prior to BFD session = establishment, in which case packets are never received with a your = discriminator field of zero. =20 > >Perhaps using the source port address for demuliplexing? >=20 > [suping] There should be scenarios that more BFD sessions in one = source port, so I don't=20 > think this will apply. [RS] In the BGP and static route case, what possible scenarios are there = where more than one BFD session will be required between two systems? Regards, Richard From rtg-bfd-bounces@ietf.org Mon Jul 04 11:23:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpSnA-0007kS-1k; Mon, 04 Jul 2005 11:23:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpSn7-0007iA-Cs for rtg-bfd@megatron.ietf.org; Mon, 04 Jul 2005 11:23:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01093 for ; Mon, 4 Jul 2005 11:23:23 -0400 (EDT) Received: from nproxy.gmail.com ([64.233.182.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpTDi-0003cu-4G for rtg-bfd@ietf.org; Mon, 04 Jul 2005 11:50:54 -0400 Received: by nproxy.gmail.com with SMTP id a4so173006nfc for ; Mon, 04 Jul 2005 08:23:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YL1tpOFDDgcyDXdeiyyRAaMP6CswWcKJGelsw0rd2mpC8RU9uwuKsvEBuaPwSoafoo3yvbsWSFwhpvkszfY8r/hM70PYcr/r0aqTeG32yIzB4viYMZsbMW+NOtNS4ZhAqe3RzJWCGy+QDtp6ojWJsaUC55zta8wcq6cGze4DU7o= Received: by 10.48.3.14 with SMTP id 14mr118131nfc; Mon, 04 Jul 2005 08:23:12 -0700 (PDT) Received: by 10.48.247.19 with HTTP; Mon, 4 Jul 2005 08:23:12 -0700 (PDT) Message-ID: <9e31186f05070408237fa7661a@mail.gmail.com> Date: Mon, 4 Jul 2005 17:23:12 +0200 From: Carlos Garcia Braschi To: "richard.spencer@bt.com" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Content-Transfer-Encoding: base64 Cc: rtg-bfd@ietf.org Subject: Re: bfd application with BGP and static routes draft submission X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Carlos Garcia Braschi List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org SSBhZ3JlZSB3aXRoIG1vc3Qgb2Ygd2hhdCB5b3Ugc2F5LCBzZWUgc29tZSBjb21tZW50cyBiZWxv dy4KCjIwMDUvNy80LCByaWNoYXJkLnNwZW5jZXJAYnQuY29tIDxyaWNoYXJkLnNwZW5jZXJAYnQu Y29tPjoKPiBTdXBpbmcsIENhcmxvcywKPiAKPiBUaGUgc2luZ2xlLWhvcCBkcmFmdCBkZXNjcmli ZXMgaG93IEJGRCBpcyB1c2VkIHdpdGggZ3JhY2VmdWwgcmVzdGFydCBmb3IgT1NQRi9JUy1JUyBh bmQgYWxzbyBtZW50aW9ucyB0aGF0IEJGRCBtYXkgYmUgYm9vdHN0cmFwcGVkIHVzaW5nIE9TUEYv SVMtSVMgaGVsbG9zLiBUaGVyZWZvcmUgaWYgdGhlcmUgaXMgYSByZXF1aXJlbWVudCB0byB1c2Ug QkZEIHdpdGggQkdQLCB0aGVuIEkgdGhpbmsgYSBkZXNjcmlwdGlvbiBvZiBob3cgQkZEIHdvcmtz IHdpdGggQkdQIGdyYWNlZnVsIHJlc3RhcnQsIGFuZCBob3cgQkZEIG1heSBiZSBib290c3RyYXBw ZWQgdXNpbmcgQkdQIE9wZW4gbWVzc2FnZXMgaXMgaW1wb3J0YW50IGluIG9yZGVyIHRvIGFjaGll dmUgaW50ZXJvcGVyYWJpbGl0eS4KPiAKPiBPbiB0aGUgb3RoZXIgaGFuZCwgSSBhbSBsZXNzIGNv bnZpbmNlZCBieSB0aGUgbmVlZCBmb3Igc2VjdGlvbnMgdG8gY292ZXIgQkZEIGZvciBzdGF0aWMg cm91dGVzIG9yIFJJUC4gSW4gYm90aCBjYXNlcywgdGhlIEJGRCBzZXNzaW9ucyB3aWxsIGJlIGVz dGFibGlzaGVkIGluZGVwZW5kZW50bHkgYW5kIHRoZXJlZm9yZSBpbiBteSBvcGluaW9uIHRoZSBt YXBwaW5nIG9mIGEgQkZEIHNlc3Npb24gdG8gYSBzdGF0aWMgcm91dGUgb3IgUklQIG5laWdoYm91 ciBpcyBhbiBpbXBsZW1lbnRhdGlvbiBpc3N1ZS4gV2hhdCBpbmZvcm1hdGlvbiBkbyB5b3UgYmVs aWV2ZSBpcyBtaXNzaW5nIGZyb20gdGhlIGN1cnJlbnQgZHJhZnRzIHRoYXQgcHJldmVudHMgdGhl IGltcGxlbWVudGF0aW9uIG9mIGludGVyb3BlcmFibGUgc3RhdGljIHJvdXRlIGFuZCBSSVAgQkZE IGltcGxlbWVudGF0aW9ucyAob3RoZXIgdGhhbiBzYXlpbmcgdGhhdCBCRkQgaXMgb3B0aW9uYWwp Pwo+IAoKW0Nhcmxvc10gV2VsbCwgZm9yIFJJUCwgSSB3YXMgYWR2b2NhdGluZyB0aGF0IHRoZSBy ZWNlaXZlciBvZiBhIFJJUAphbm5vdW5jZW1lbnQgdGFrZSB0aGUgQWN0aXZlIHJvbGUgKGFuZCB0 aGUgc2VuZGVyIGEgUGFzc2l2ZSByb2xlLAp1bmxlc3MgaXQgcmVjZWl2ZXMgYW5vdGhlciBhbm5v dW5jZW1lbnQgYW5kIGlzIHRoZXJlZm9yZSBhIHJlY2VpdmVyKSwKYW5kIHRoYXQgZGlmZmVycyBm cm9tIHRoZSAxaG9wIGRyYWZ0IHBvaW50IDMuIEFsdGhvdWdoIGl0J3MgcHJvYmFibHkKb2J2aW91 cy4uLgoKW0Nhcmxvc10gRm9yIGJvdGggcHJvdG9jb2xzLCBJRiB3ZSBkaXNjYXJkIExTUCBwaW5n IGFuZCBJQ01QIG1ldGhvZHMKZm9yIGRlbXVsdGlwbGV4aW5nLCBhIG1lbnRpb24gY291bGQgYmUg bWFkZSB0aGF0IHRoZXJlIGlzIG5vIG5lZWQgZm9yCm90aGVyIG1ldGhvZHMgZm9yIGluaXRpYWwg c2Vzc2lvbiBkZW11bHRpcGxleGluZyBvdXRzaWRlIGZyb20gd2hhdCBpcwp3cml0dGVuIGluIHRo ZSAxaG9wIGRyYWZ0IChzbyB0aGF0IHdlIGRvIG5vdCBoYXZlIGFuIGltcGxlbWVudGF0aW9uCnRo YXQgZXhwZWN0cyBJQ01QIGFuZCB0aGUgb3RoZXIgdGhhdCBkb2VzIG5vdCkuIFByb2JhYmx5IGlz IHNvIHNpbXBsZQp0aGF0IGNvdWxkIGJlIGluY2x1ZGVkIGluIHRoZSAxLWhvcCBkcmFmdC4KCj4g QWRkaXRpb25hbGx5LCB3aGF0IGlzIHRoZSByZWFzb24gYmVoaW5kIHRoZSBzdWdnZXN0aW9uIHRv IHVzZSBJQ01QIHRvIGJvb3RzdHJhcCBCRkQgaW4gdGhlIHN0YXRpYyByb3V0ZSBjYXNlPyAKCioq KkluIHRoZSBzaW5nbGUtaG9wIGNhc2UsIHN0YXRpYyByb3V0ZSBCRkQgc2Vzc2lvbnMgc2hvdWxk IGJlCmRlbXVsdGlwbGV4ZWQgYmFzZWQgb24gdGhlIGludGVyZmFjZSBhbmQgaW4gdGhlIG11bHRp LWhvcCBjYXNlIEJGRApzZXNzaW9ucyBjYW4gYmUgZGVtdWx0aXBsZXhlZCBiYXNlZCBvbiBzb3Vy Y2UvZGVzdGluYXRpb24gYWRkcmVzcwpwYWlycy4gVGhlIHBvaW50IGJlaW5nIHRoYXQgdGhlIHlv dXIgZGlzY3JpbWluYXRvciBmaWVsZHMgZG8gbm90IG5lZWQKdG8gYmUgZXhjaGFuZ2VkIHZpYSBh bm90aGVyIG1lY2hhbmlzbS4KQW4gaWRlYWwgc29sdXRpb24gd291bGQgYmUgZm9yIGEgQkZEIHN5 c3RlbSAoaW4gYW4gYWN0aXZlIHJvbGUpIHRvCmJlZ2luIHNlbmRpbmcgQkZEIGNvbnRyb2wgcGFj a2V0cyBhcyBzb29uIGFzIEJGRCBpcyBjb25maWd1cmVkIG9uIHRoZQpzeXN0ZW0gdXNpbmcgbWFu dWFsL09TUyBwcm92aXNpb25pbmcgKHdpdGggdGhlIHlvdXIgZGlzY3JpbWluYXRvcgpmaWVsZCBz ZXQgdG8gemVybyBhbmQgbXkgZGlzY3JpbWluYXRvciBzZXQgdG8gYSBudW1iZXIgYXV0b21hdGlj YWxseQpnZW5lcmF0ZWQgYnkgdGhlIEJGRCBzeXN0ZW0gb3IgdmlhIE9TUykuICoqKgpJZiBJQ01Q IHdhcyB1c2VkIGhlcmUgdGhlbiBPU1MvbWFudWFsIHByb3Zpc2lvbmluZyB3b3VsZCBuZWVkIHRv IGJlCnVzZWQgdG8gY29uZmlndXJlIHRoZSBCRkQgc2Vzc2lvbnMsIGFuZCB0aGVuIHRvIGluaXRp YXRlIHRoZSBJQ01QCm1lc3NhZ2VzLiBFdmVuIGlmIElDTVAgbWVzc2FnZXMgd2VyZSBzZW50IGF1 dG9tYXRpY2FsbHkgZm9sbG93aW5nIEJGRApzZXNzaW9uIGNvbmZpZ3VyYXRpb24sIHdoeSBhcmUg dGhleSBuZWVkZWQgYW5kIHdoYXQgdmFsdWUgZG8gdGhleSBhZGQ/Cj4gCgpbQ2FybG9zXSBJIGFn cmVlIG9uIHRoZSBteSBkaXNjcmltaW5hdG9yIGJlaW5nIHNldCB0byBhIG51bWJlcgphdXRvbWF0 aWNhbGx5IGdlbmVyYXRlZCBvciB2aWEgT1NTIChhbHRob3VnaCBJIHByZWZlciBpbXBsZW1lbnRh dGlvbnMKd2l0aCB0aGUgZm9ybWVyKSwgYnV0IHRoYXQncyBzb21ldGhpbmcgdGhhdCBzaG91bGQg bm90IGJlIG9uIGFuIFJGQywKc2hvdWxkIGl0PwpbQ2FybG9zXSBBbHRob3VnaCB0aGUgcGFyYWdy YXBoIGJldHdlZW4gKioqIHNlZW1zIHRvIGZvbGxvdyBmcm9tIHRoZQoxaG9wIFJGQyBhbmQgbXVs dGktaG9wIFJGQyAoYWx0aG91Z2ggSSBoYXZlIGRvdWJ0cyBvbiB0aGUKYXBwbGljYWJpbGl0eSBv ZiBzdGF0aWMgYW5kIFJJUCB0byBtdWx0aS1ob3ApLCB3aGF0IEkgYW0gYWR2b2NhdGluZyBpcwp0 aGF0IGEgcGFyYWdyYXBoIGNsYXJpZnlpbmcgdGhpcyBjb3VsZCBiZSBhZGRlZCBlaXRoZXIgdG8g dGhpcyBkcmFmdApvciB0byB0aGUgb3JpZ2luYWwgMWhvcCBkcmFmdC4gUHJvYmFibHkgdGhhdCdz IGFsbCB0aGF0IGlzIG5lZWRlZCBmb3IKc3RhdGljIHJvdXRlcywgYW5kIGhhbGYgb2Ygd2hhdCBp cyBuZWVkZWQgZm9yIFJJUC4KW0Nhcmxvc10gQWJvdXQgdGhlIHZhbHVlIG9mIElDTVAgaW4gYm9v dHN0cmFwcGluZywgdGhhdCBpcyBhIGdvb2QKcXVlc3Rpb24gZm9yIFN1cGluZy4gSSBkb24ndCBz ZWUgaXQgZWl0aGVyLgoKPiBQbGVhc2Ugc2VlIGJlbG93IGZvciBzb21lIHNwZWNpZmljIGNvbW1l bnRzIGJhc2VkIG9uIHlvdXIgZGlzY3Vzc2lvbi4KPiAKPiA+ID4gU2hvdWxkIHRoaXMgZHJhZnQg YmUgZXh0ZW5kZWQgdG8gdGhlIHVzZSBvZiBCRkQgZm9yIEJHUCBpbiBhCj4gPiA+IG11bHRpLWhv cCBlbnZpcm9ubWVudD8gSXQgc2VlbXMgdGhhdCB0aGUgY2hhbmdlcyBuZWVkZWQgZm9yCj4gPiA+ IEJHUCBpbiBhIG11bHRpLWhvcCBlbnZpcm9ubWVudCB3b3VsZCBiZSB0aGF0IGRlbXVsdGlwbGV4 aW5nCj4gPiA+IHNob3VsZCBiZSBiYXNlZCBlaXRoZXIgb24gQkdQIHNpZ25hbGxpbmcgb3Igb24g dGhlCj4gPiA+IHNvdXJjZS9kZXN0aW5hdGlvbiBhZGRyZXNzIHBhaXJzIGFuZCB0aGF0IEF1dGhl bnRpY2F0aW9uCj4gPiA+IFNIT1VMRCBiZSB1c2VkICAoYXMgc3BlY2lmaWVkIGluIHRoZSBtdWx0 aS1ob3AgZHJhZnQpLgo+IAo+ID4gW3N1cGluZ10gRm9yIEJHUCBJIHRoaW5rIHRoZSB1c3VhbGx5 IGFwcGxpY2F0aW9uIGlzIG9uZS1ob3AsCj4gPiBzbyBkbyB3ZSBuZXNzZXNhcmlseSBuZWVkIHRo ZSBtdWx0aS1ob3AgQkdQPwo+IAo+IFtSU10gV2hhdCBhYm91dCBJQkdQIGFuZCBFQkdQIG11bHRp aG9wPwo+IAoKW0Nhcmxvc10gSSBhZ3JlZSwgdGhhdCdzIHRoZSBhcHBsaWNhdGlvbi4uLgoKPiA+ ID5Db3VsZCB0aGlzIGRyYWZ0IGJlIGV4dGVuZGVkIHRvIHRoZSB1c2Ugb2YgQkZEIGZvciBSSVA/ IFRoaXMgd291bGQKPiA+ID5jb21wbGV0ZSB0aGUgYXBwbGljYXRpb24gb2YgQkZEIHRvIHRoZSBt b3N0IGNvbW1vbiByb3V0aW5nIHByb3RvY29scwo+ID4gPmluIHVzZSB0b2RheSwgYXMgT1NQRiBh bmQgSVMtSVMgYXJlIGNvdmVyZWQgaW4gdGhlIDFIb3AgZHJhZnQuCj4gPgo+ID4gW3N1cGluZ10g SSBhbSB2ZXJ5IGhhcHB5IHRvIGRvIHRoYXQuCj4gPiA+Cj4gPiA+QXMgUklQdjIgaXMgbW9zdGx5 IGEgcHJvdG9jb2wgZnJvemVuIGluIHRpbWUsIGRlbXVsdGlwbGV4aW5nIG1ldGhvZHMKPiA+ID53 b3VsZCBvbmx5IGJlIG1hbnVhbCBjb25maWd1cmF0aW9uIGFuZCBkZW11bHRpcGxleGluZyBiYXNl ZCBvbgo+ID4gPnNvdXJjZS9kZXN0aW5hdGlvbiBhZGRyZXNzIHBhaXJzLgo+ID4gPklDTVAgYW5k IExTUC1waW5nIHdvdWxkIG5vdCBhcHBseSwKPiA+ID5hcyByZWFzb25lZCBiZWxvdyBmb3Igc3Rh dGljIHJvdXRlcy4KPiA+ID5BbHNvLCBiZWNhdXNlIG9mIHRoaXMgImZyb3plbm5lcyIsIG5vIHBv c3NpYmlsaXR5IGV4aXN0cyB0byBuZWdvdGlhdGUKPiA+ID50aGUgZGlzY3JpbWluYXRvciB2YWx1 ZSBpbnNpZGUgdGhlIHByb3RvY29sLgo+ID4gPlNvLCBmb3IgdGhpcyBwcm90b2NvbCwgYXMgaW4g QkdQLCBpdCBzaG91bGQgYmUgT1BUSU9OQUwgbm90Cj4gPiB0byBwdXQgdGhlIHJvdXRlcyBmcm9t IFJJUCBpbnRvIHRoZSByb3V0aW5nIHRhYmxlIHVudGlsIHRoZSBCRkQgc2Vzc2lvbiBpcwo+ID4g PmVzdGFibGlzaGVkLiBJbiB0aGlzIGNhc2UgdGhlIGJlaGF2aW91ciBjb3VsZCBhbHNvIGJlIG5v dCB0byByZXF1aXJlCj4gPiA+YW55IHBlZXIgdG8gYmVoYXZlIGRpZmZlcmVudGx5IGZyb20gc3Rh bmRhcmQgUklQIHVudGlsIHRoZSBmaXJzdAo+ID4gPnNlc3Npb24gaXMgZXN0YWJsaXNoZWQuCj4g Pgo+ID4gW3N1cGluZ11JIGFncmVlIHdpdGggeW91Lgo+IAo+IFtSU10gSWYgdGhlIEJGRCBzZXNz aW9uIGNhbm5vdCBiZSBlc3RhYmxpc2hlZCBkeW5hbWljYWxseSB1c2luZyBSSVAgKGkuZS4gaXQg aXMgZXN0YWJsaXNoZWQgaW5kZXBlbmRlbnRseSBhbmQgdGhlbiBtYXBwZWQgdG8gYSBSSVAgbmVp Z2hib3VyKSwgdGhlbiB3aGF0IGluZm9ybWF0aW9uIG5lZWRzIHRvIGdvIGluIHRoZSBkcmFmdD8K PiAKCltDYXJsb3NdIEkgdGhpbmsgdGhlcmUgc2hvdWxkIGJlIGEgd2F5IHRvIGVzdGFibGlzaCB0 aGUgQkZEIHNlc3Npb25zCmRpbmFtaWNhbGx5IGJhc2VkIG9uIHRoZSBSSVAgYW5ub3VuY2VtZW50 cy4gTWFudWFsIGNvbmZpZ3VyYXRpb24gdmlhCk9TUyBjYW4gYmUgdmVyeSBjdW1iZXJzb21lIChh bmQgdGhhdCdzIHdoeSB3ZSB1c2UgUklQIGZvciByb3V0aW5nCmFueXdheSwgc28gdGhhdCB3ZSBk b24ndCBoYXZlIHRvIG1hbnVhbGx5IGNvbmZpZ3VyZSBhbGwgdGhlIG5ldHdvcmspLgpUaGF0J3Mg d2h5IEkgcHJvcG9zZSB0aGF0IFJJUCByZWNlaXZlcnMgc3RhcnQgQkZEIHNlc3Npb25zIHdoZW4K cmVjZWl2aW5nIFJJUCBhbm5vdW5jZXMgKHdoZW4gdGhleSBkbyBub3QgaGF2ZSBhbHJlYWR5IGEg QkZEIHNlc3Npb24pLAphbmQgZ2l2ZSB1cCBhZnRlciBhIG51bWVyIG9mIHRyaWFscy4KCj4gPiA+ QWx0aG91Z2ggSSdtIG5vdCBzdXJlIGl0IGlzIGEgZ29vZCBpZGVhIHRvIHVzZSBJQ01QIHRvIGFj aGlldmUKPiA+ID5kZW11bHRpcGxleGluZywgSSB0aGluayB0aGUgc2VjdGlvbiAzLjEuMSBpcyBz b21ld2hhdCBpbmNvbXBsZXRlLCBhcwo+ID4gPml0IHNob3VsZCBkZWZpbmUgdGhlIElDTVAgdHlw ZSBhbmQgY29kZSB2YWx1ZXMgKGFzIFRCRCwgcGVyaGFwcyksIGFuZAo+ID4gPmJlIGV4dGVuZGVk IHRvIElDTVB2Ni4gSSB3b3VsZG4ndCBkbyBpdCwgYW55d2F5Lgo+ID4KPiA+IFtzdXBpbmddSSB0 aGluayBJQ01QIGlzIGEgb3B0aW9uYWwgd2F5cyB0byBkZW11bHRpcGxleGluZwo+ID4gQkZEIHNl c3Npb24uIEluIGZhY3QgaW4gSUNNUChWNCksIHRoZXJlIGFyZSBtZXNzYWdlIHR5cGVzIG9mIDE1 Cj4gPiAoSW5mb3JtYXRpb24gUmVxdWVzdCkgYW5kIDE2IChJbmZvcm1hdGlvbiBSZXBseSksIG15 IGludGVudCBpcyB0bwo+ID4gZXh0ZW5kIHRoZSBleGlzdGluZyBtZXNzYWdlIGJ5IGFkZGluZyBC RkQgZGlzY3JpbWF0b3IgaW4gaXQuCj4gPiBBcyBmb3IgSUNNUHY2LCBJIHRoaW5rIHRoZXJlIHNo b3VsZCBiZSBzb21lIG5ldyBtZXNzYWdlCj4gPiB0eXBlKFRCRCkgZm9yIHRoaXMgcHVycG9zZS4K PiAKPiBbUlNdIEluIHRoZSBzaW5nbGUtaG9wIHN0YXRpYyByb3V0ZSBjYXNlIChpLmUuIHRoZSBu ZXh0IGhvcCBpcyBkaXJlY3RseSBjb25uZWN0ZWQpIHRoZW4gdGhlIHlvdXIgZGlzY3JpbWluYXRv ciBmaWVsZCBzaG91bGQgYmUgc2V0IHRvIHplcm8gYW5kIHRoZSBwYWNrZXQgZGVtdWx0aXBsZXhl ZCBiYXNlZCBvbiB0aGUgaW50ZXJmYWNlLiBJbiB0aGUgbXVsdGktaG9wIHN0YXRpYyByb3V0ZSBj YXNlIChpLmUuIHRoZSBuZXh0IGhvcCBpcyBtb3JlIHRoYW4gb25lIGhvcCBhd2F5KSB0aGVuIHRo ZSB5b3VyIGRpc2NyaW1pbmF0b3IgZmllbGQgc2hvdWxkIGJlIHNldCB0byB6ZXJvIGFuZCB0aGUg cGFja2V0IGRlbXVsdGlwbGV4ZWQgYmFzZWQgb24gdGhlIHNvdXJjZS9kZXN0aW5hdGlvbiBhZGRy ZXNzIHBhaXIuIElDTVAgY291bGQgYmUgdXNlZCB0byBleGNoYW5nZSB5b3VyIGRpc2NyaW1pbmF0 b3IgZmllbGRzLCBidXQgd2hhdCB3b3VsZCB0aGUgYWR2YW50YWdlIG9mIHRoaXMgYmUgb3ZlciBq dXN0IHNlbmRpbmcgYSB5b3VyIGRpc2NyaW1pbmF0b3IgZmllbGQgb2YgemVybywgYW5kIGRlbXVs dGlwbGV4aW5nIGJhc2VkIG9uIHRoZSBpbnRlcmZhY2Ugb3Igc291cmNlL2Rlc3RpbmF0aW9uIGFk ZHJlc3M/Cj4gCgpbQ2FybG9zXSBJIGFncmVlIHRoZXJlIGlzIG5vIGFkdmFudGFnZS4KCj4gPiA+ SSdtIGFsc28gdW5zdXJlIHdoYXQgc2NlbmFyaW8gY291bGQgaGF2ZSBhIHN0YXRpYyByb3V0ZSBu ZWVkaW5nIEJGRAo+ID4gPmFuZCBoYXZlIE1QTFMgc28gdGhhdCBpdCBoYXMgdGhlIExTUC1waW5n IG1lY2hhbmlzbSB0byBib290c3RyYXAgdGhlCj4gPiA+c2Vzc2lvbiAoMy4xLjIpLiBJZiB5b3Ug aGF2ZSBNUExTLCB5b3UgY2VydGFpbmx5IGNvdWxkIGFwcGx5IEJGRCBmb3IKPiA+ID5NUExTIGFu ZCB0aGVuIHlvdSBkb24ndCBuZWVkIEJGRCBmb3IgdGhpcyBzdGF0aWMgcm91dGUuCj4gCj4gW1JT XSBUaGUgcmVxdWlyZW1lbnQgdG8gdXNlIEJGRCBmb3IgTFNQcyBhcyB3ZWxsIGFzIHN0YXRpYyBy b3V0ZXMgaXMgcGVyZmVjdGx5IHZpYWJsZS4gQW4gb3BlcmF0b3IgbWF5IHdhbnQgdG8gdXNlIEJG RCB0byBkZXRlY3QgZmFpbHVyZXMgYmV0d2VlbiBzeXN0ZW0gQSBhbmQgc3lzdGVtIEIgd2hlcmUg Zm9yd2FyZGluZyBpcyBiYXNlZCBvbiBzdGF0aWMgcm91dGVzIChlLmcuIGZvciBjb250cm9sIHRy YWZmaWMpLCB3aGlsc3QgYXQgdGhlIHNhbWUgdGltZSBkZXRlY3QgZmFpbHVyZXMgd2hlcmUgZm9y d2FyZGluZyBpcyBiYXNlZCBvbiBNUExTIChlLmcuIGN1c3RvbWVyIHRyYWZmaWMgdXNpbmcgYSBU RSB0dW5uZWwgTFNQKS4gV2hhdCBpcyBub3QgdmlhYmxlIGlzIHRoZSB1c2Ugb2YgTFNQIHBpbmcg Zm9yIGJvb3RzdHJhcHBpbmcgdGhlIHN0YXRpYyBCRkQgc2Vzc2lvbi4KPiAKCltDYXJsb3NdIEkg c2VlLCB0aGF0J3MgcmlnaHQuIEluIGFueSBjYXNlLCBMU1AgcGluZyBzaG91bGQgbm90IGJlIHVz ZWQKdG8gYm9vdHN0cmFwIHRoZSBzdGF0aWMgcm91dGUuCgo+ID4gW3N1cGluZ11ZZXMsIEkgdGhp bmsgeW91IGFyZSByaWdodC4gSWYgTVBMUyBpcyBzdXBwb3J0ZWQgd2UKPiA+IGNvdWxkIHVzZSBC RkQgZm9yIE1QTFMgYW5kIGRvbid0IG5lZWQgQkZEIGZvciB0aGUgc3RhdGljIHJvdXRlLiBJbgo+ ID4gYW5vdGVyIHdvcmQsIHdoZW4gc3RhdGljIHJvdXRlIHdlIHRoaW5rIHRoYXQgbm8gTVBMUyBp cyBzdXBwb3J0ZWQuIFNvCj4gPiBJIHdpbGwgbWFrZSBzdWNoIGNsYXJpZmljYXRpb24gaW4gdGhl IGRyYWZ0Lgo+IAo+IFtSU10gRm9yd2FyZGluZyBvZiB0cmFmZmljIGJldHdlZW4gdHdvIHN5c3Rl bXMgYmFzZWQgTVBMUyBhbmQgc3RhdGljIHJvdXRlcyBpcyB2YWxpZCwgdXNpbmcgQkZEIHRvIGJv b3RzdHJhcCB0aGUgc3RhdGljIHJvdXRlIHNlc3Npb24gaXMgbm90LiBJZiB0aGUgc3RhdGljIHJv dXRlIGJlbG9uZ3MgdG8gYSBGRUMgZm9yIHdoaWNoIGZvcndhcmRpbmcgaXMgYmFzZWQgb24gTVBM UywgdGhlbiBCRkQgc2hvdWxkIGJlIHVzZWQgb24gdGhlIExTUCAoaS5lLiBzdGF0aWMgcm91dGUg QkZEIGlzIG5vdCBuZWVkZWQgYmVjYXVzZSB0aGUgcGFja2V0cyBhcmUgZm9yd2FyZGVkIHVzaW5n IE1QTFMgbm90IElQKS4gSWYgdHJhZmZpYyBmb3IgdGhlIHN0YXRpYyByb3V0ZSBpcyBmb3J3YXJk ZWQgdXNpbmcgSVAsIHRoZW4gdGhlIEZFQyBmb3IgdGhlIExTUCB3aWxsIGJlIGRpZmZlcmVudCBh bmQgdGhlcmVmb3JlIExTUCBwaW5nIGNhbm5vdCBiZSB1c2VkIHRvIGJvb3RzdHJhcCB0aGUgc3Rh dGljIHJvdXRlIHNlc3Npb24sIGFzIHBlciB0aGUgTVBMUyBCRkQgZHJhZnQgIkJGRCBjb250cm9s IHBhY2tldHMgc2VudCBieSB0aGUgaW5ncmVzcyBMU1IgYXJlIGVuY2Fwc3VsYXRlZCBpbiB0aGUg TVBMUyBsYWJlbCBzdGFjayB0aGF0IGNvcnJlc3BvbmRzIHRvIHRoZSBGRUMgZm9yIHdoaWNoIGZh dWx0IGRldGVjdGlvbiBpcyBiZWluZyBwZXJmb3JtZWQuIiBUaGUgdXNlIG9mIExTUCBwaW5nIHRv IGJvb3RzdHJhcCBhbnkgcHJvdG9jb2wgb3RoZXIgdGhhbiBNUExTIGlzIG5vdCB2aWFibGUgYW5k IHRoZXJlZm9yZSB0aGlzIG9wdGlvbiBzaG91bGQgYmUgcmVtb3ZlZCBmcm9tIGJvdGggdGhlIHN0 YXRpYyBhbmQgQkdQIGNhc2VzIGluIHRoZSBkcmFmdC4KPiAKPiA+ID5JJ20gY2VydGFpbmx5IG92 ZXJsb29raW5nIHNvbWV0aGluZyBvbiAyLjIgYW5kIDMuMiwgd2h5Cj4gPiA+d291bGQgb25lIHdh bnQgdG8gcHV0IGEgcmFuZG9tIGFkZHJlc3MgZnJvbSAxMjcvOCBpbiB0aGUKPiA+ID5kZXN0aW5h dGlvbiBhZGRyZXNzIGluc3RlYWQgb2YgdGhlIElQIGFkZHJlc3Mgb2YgdGhlIHBlZXIKPiA+ID5v ciB0aGUgc3RhdGljIHJvdXRlIHBvaW50cyB0bz8gSW4gQkdQLCB3ZSBhbHJlYWR5IGtub3cgdGhl Cj4gPiA+ZGVzdGluYXRpb24gYWRkcmVzcywgd2h5IHNob3VsZG4ndCBpdCBiZSB1c2VkPwo+IAo+ ID4gPkZvciBzdGF0aWMgcm91dGVzIG9uIGEgTEFOIGVudmlyb25tZW50LCB3aGVyZSB0aGF0IGFk ZHJlc3MgbXVzdCBiZQo+ID4gPmtub3duIGluIG9yZGVyIHRvIGdldCBpdHMgTUFDIGFkZHJlc3Ms IHRoZSBzYW1lIHJlYXNvbmluZyBhcHBsaWVzLiBJCj4gPiA+c2VlIHRoZSBhcHBsaWNhYmlsaXR5 IHRvIHBvaW50LXRvLXBvaW50IGVudmlyb25tZW50cywgYnV0IHRoZXJlCj4gPiA+SW52ZXJzZSBB UlAgY291bGQgYmUgdXNlZCB0byBnZXQgdGhlIG90aGVyIHNpZGUncyBJUCBhZGRyZXNzLgo+ID4g PkJ1dCBpbiBhbnkgY2FzZSwgcHJvYmFibHkgYSByYXRpb25hbGUgZm9yIHRoZSBkZWNpc2lvbiB3 b3VsZG4ndCBoYXJtLgo+ID4KPiA+IFtzdXBpbmddWWVzLCBJIHRoaW5rIHlvdSBhcmUgcmlnaHQg YWdhaW46KSBXZSBjYW4gdXNlIGV4cGxpY2l0eSBkZXN0aW5hdGlvbgo+ID4gSVAgYWRkcmVzcyBp biBCR1AgYW5kIHN0YXRpYyByb3V0ZSBhcHBsaWNhdGlvbnMgYmVjYXVzZSB0aGUgRElQIGhhcyBi ZWVuIGtub3duLgo+IAo+IFtSU10gVGhlIHRleHQgZnJvbSB0aGUgZW5jYXBzdWxhdGlvbiBzZWN0 aW9uIGJlaW5nIGRpc2N1c3NlZCBoZXJlIHdhcyBvYnZpb3VzbHkgYSAnY3V0ICYgcGFzdGUnIGZy b20gdGhlIEJGRCBNUExTIGRyYWZ0ISBUaGVyZSBpcyBubyBuZWVkIGZvciBhbiBlbmNhcHN1bGF0 aW9uIHNlY3Rpb24gYW55d2F5IGFzIGVuY2Fwc3VsYXRpb24gaXMgY292ZXJlZCBpbiB0aGUgc2lu Z2xlLWhvcCBkcmFmdC4KPiAKPiA+ID5JdCB3b3VsZCBiZSBhIGdvb2QgdGhpbmcgaWYgdGhlcmUg d2VyZSBzb21lIG1lY2hhbmlzbSBzbyB0aGF0IG1hbnVhbAo+ID4gPmNvbmZpZ3VyYXRpb24gZG9l cyBub3QgbmVlZCB0byBjb25maWd1cmUgYSBzcGVjaWZpYyB2YWx1ZSBmb3IgdGhlIE15Cj4gPiA+ ZGlzY3JpbWluYXRvci4uLiCm3FBlcmhhcHMgcmVzdHJpY3RpbmcgZGVtdWx0aXBsZXhpbmcgaW4g dGhlIHByZXNlbmNlCj4gPiA+b2YgYSB6ZXJvIHZhbHVlIGZvciB0aGUgTXkgZGlzY3JpbWluYXRv ciB0byBvbmUgc2Vzc2lvbiBwZXIKPiA+ID5zb3VyY2UvZGVzdGluYXRpb24gYWRkcmVzcyBwYWly Pwo+IAo+IFtSU10gVGhlIG15IGRpc2NyaW1pbmF0b3IgZmllbGQgbXVzdCBiZSBjb25maWd1cmVk IHVzaW5nIGEgbm9uLXplcm8gdmFsdWUsIGFzIHBlciB0aGUgYmFzZSBCRkQgZHJhZnQgIklmIHRo ZSBNeSBEaXNjcmltaW5hdG9yIGZpZWxkIGlzIHplcm8sIHRoZSBwYWNrZXQgTVVTVCBiZSBkaXNj YXJkZWQuIiBIb3dldmVyLCB0aGlzIGRvZXNuJ3QgbWVhbiB0aGF0IGl0IG5lZWRzIHRvIGJlIG1h bnVhbGx5IGNvbmZpZ3VyZWQsIGl0IGNvdWxkIGJlIGR5bmFtaWNhbGx5IGdlbmVyYXRlZCBieSB0 aGUgc3lzdGVtIHdoZW4gdGhlIEJGRCBzZXNzaW9uIGlzIGVuYWJsZWQsIG9yIGl0IGNvdWxkIGJl IGR5bmFtaWNhbGx5IGdlbmVyYXRlZC9wcm92aXNpb25lZCB1c2luZyBPU1MuCj4gCgpbQ2FybG9z XSBZb3UncmUgcmlnaHQgYWdhaW4uCgo+ID4gW3N1cGluZ11TbyBpbiBpbXBsZW1lbnRhdGlvbiBh IG1vcmUgc2l0dWF0aW9uIG11c3QgYmUgY29uc2lkZXJlZCBpZiB0aGlzIGlzCj4gPiB0aGUgY3Jp dGVyaWEsIGFuZCBldmVuIG1vcmUgaWYgbW9yZSBCRkQgc2Vzc2lvbnMgYXJlIG5lZWRlZCwgZGVt dWx0aXBsZXhpbmcgYWxzbwo+ID4gbmVlZGVkIG5vdCBhY2NvcmRpbmcgdG8gc291cmNlL2Rlc3Rp bmF0aW9uIGFkZHJlc3MgcGFpci6m3Ao+IAo+IFtSU10gRGVtdWx0aXBsZXhpbmcgaXNzdWVzL21l dGhvZHMgYXJlIGFscmVhZHkgY292ZXJlZCBpbiB0aGUgc2luZ2xlLWhvcCBhbmQgbXVsdGktaG9w IGRyYWZ0cy4gSW4gdGhlIHNpbmdsZS1ob3AgY2FzZSwgdGhlcmUgc2hvdWxkIG9ubHkgYmUgb25l IEJGRCBzZXNzaW9uIHBlciBpbnRlcmZhY2UsIHBlciBwcm90b2NvbC4gVGhlcmVmb3JlLCBpZiBh IHN5c3RlbSByZWNlaXZlcyBhIEJGRCBwYWNrZXQgd2l0aCBhIHlvdXIgZGlzY3JpbWluYXRvciBv ZiB6ZXJvLCB0aGVuIGl0IGlzIG1hcHBlZCB0byB0aGUgY29ycmVzcG9uZGluZyBzZXNzaW9uIGZv ciB0aGF0IGludGVyZmFjZSBhbmQgcHJvdG9jb2wuIEluIHRoZSBtdWx0aS1ob3AgY2FzZSwgIGlm IGEgc3lzdGVtIHJlY2VpdmVzIGEgQkZEIHBhY2tldCB3aXRoIGEgeW91ciBkaXNjcmltaW5hdG9y IG9mIHplcm8sIHRoZW4gdGhlIHNlc3Npb24gY2FuIGJlIGRlbXVsdGlwbGV4ZWQgYmFzZWQgb24g dGhlIHNvdXJjZS9kZXN0aW5hdGlvbiBhZGRyZXNzIHBhaXIuIEFsdGVybmF0aXZlbHksIG91dC1v Zi1iYW5kIHNpZ25hbGxpbmcgbWF5IGJlIHVzZWQgdG8gZXhjaGFuZ2UgeW91ciBkaXNjcmltaW5h dG9yIGZpZWxkcyBwcmlvciB0byBCRkQgc2Vzc2lvbiBlc3RhYmxpc2htZW50LCBpbiB3aGljaCBj YXNlIHBhY2tldHMgYXJlIG5ldmVyIHJlY2VpdmVkIHdpdGggYSB5b3VyIGRpc2NyaW1pbmF0b3Ig ZmllbGQgb2YgemVyby4KPiAKPiA+ID5QZXJoYXBzIHVzaW5nIHRoZSBzb3VyY2UgcG9ydCBhZGRy ZXNzIGZvciBkZW11bGlwbGV4aW5nPwo+ID4KPiA+IFtzdXBpbmddIFRoZXJlIHNob3VsZCBiZSBz Y2VuYXJpb3MgdGhhdCBtb3JlIEJGRCBzZXNzaW9ucyBpbiBvbmUgc291cmNlIHBvcnQsIHNvIEkg ZG9uJ3QKPiA+IHRoaW5rIHRoaXMgd2lsbCBhcHBseS4KPiAKPiBbUlNdIEluIHRoZSBCR1AgYW5k IHN0YXRpYyByb3V0ZSBjYXNlLCB3aGF0IHBvc3NpYmxlIHNjZW5hcmlvcyBhcmUgdGhlcmUgd2hl cmUgbW9yZSB0aGFuIG9uZSBCRkQgc2Vzc2lvbiB3aWxsIGJlIHJlcXVpcmVkIGJldHdlZW4gdHdv IHN5c3RlbXM/Cj4gCj4gUmVnYXJkcywKPiBSaWNoYXJkCj4gCj4K From rtg-bfd-bounces@ietf.org Tue Jul 05 09:26:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpnR3-00024b-8s; Tue, 05 Jul 2005 09:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpnO7-0000HO-Mz for rtg-bfd@megatron.ietf.org; Tue, 05 Jul 2005 09:23:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16675 for ; Tue, 5 Jul 2005 09:22:54 -0400 (EDT) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpj7H-0007eY-6G for rtg-bfd@ietf.org; Tue, 05 Jul 2005 04:49:24 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJ5007H8AYM8O@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Tue, 05 Jul 2005 16:15:58 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJ5005YLAYLZS@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Tue, 05 Jul 2005 16:15:57 +0800 (CST) Received: from z11024 ([10.110.100.95]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IJ500GPTB3IU2@szxml02-in.huawei.com>; Tue, 05 Jul 2005 16:18:54 +0800 (CST) Date: Tue, 05 Jul 2005 16:13:36 +0800 From: Suping Zhai To: Carlos Garcia Braschi , "richard.spencer@bt.com" Message-id: <0IJ500GPVB3IU2@szxml02-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86 Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd@ietf.org" Subject: Re: Re: bfd application with BGP and static routes draft submission X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zhaisuping@huawei.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Carlos, Richard, At first very thank you both for your comments. See some response= below. >I agree with most of what you say, see some comments below. > >2005/7/4, richard.spencer@bt.com : >> Suping, Carlos, >> >> The single-hop draft describes how BFD is used with graceful= restart for OSPF/IS-IS and also mentions that BFD may be= bootstrapped using OSPF/IS-IS hellos. Therefore if there is a= requirement to use BFD with BGP, then I think a description of= how BFD works with BGP graceful restart, and how BFD may be= bootstrapped using BGP Open messages is important in order to= achieve interoperability. >> >> On the other hand, I am less convinced by the need for= sections to cover BFD for static routes or RIP. In both cases,= the BFD sessions will be established independently and therefore= in my opinion the mapping of a BFD session to a static route or= RIP neighbour is an implementation issue. What information do= you believe is missing from the current drafts that prevents the= implementation of interoperable static route and RIP BFD= implementations (other than saying that BFD is optional)? >> > >[Carlos] Well, for RIP, I was advocating that the receiver of a= RIP >announcement take the Active role (and the sender a Passive= role, >unless it receives another announcement and is therefore a= receiver), >and that differs from the 1hop draft point 3. Although it's= probably >obvious... > [suping] Now I think that it's more appropriate to add some texts= in 1hop draft about using BFD with RIP, make some clarification about the application of BFD= with RIP. >[Carlos] For both protocols, IF we discard LSP ping and ICMP= methods >for demultiplexing, a mention could be made that there is no= need for >other methods for initial session demultiplexing outside from= what is >written in the 1hop draft (so that we do not have an= implementation >that expects ICMP and the other that does not). Probably is so= simple >that could be included in the 1-hop draft. > [suping] I agree to remove LSP ping as a method to bootstrap the= BFD session in BGP and static route case. >> Additionally, what is the reason behind the suggestion to use= ICMP to bootstrap BFD in the static route case? > >***In the single-hop case, static route BFD sessions should be >demultiplexed based on the interface and in the multi-hop case= BFD >sessions can be demultiplexed based on source/destination= address >pairs. The point being that the your discriminator fields do not= need >to be exchanged via another mechanism. >An ideal solution would be for a BFD system (in an active role)= to >begin sending BFD control packets as soon as BFD is configured= on the >system using manual/OSS provisioning (with the your= discriminator >field set to zero and my discriminator set to a number= automatically >generated by the BFD system or via OSS). *** >If ICMP was used here then OSS/manual provisioning would need to= be >used to configure the BFD sessions, and then to initiate the= ICMP >messages. Even if ICMP messages were sent automatically= following BFD >session configuration, why are they needed and what value do= they add? >> > >[Carlos] I agree on the my discriminator being set to a number >automatically generated or via OSS (although I prefer= implementations >with the former), but that's something that should not be on an= RFC, >should it? >[Carlos] Although the paragraph between *** seems to follow from= the >1hop RFC and multi-hop RFC (although I have doubts on the >applicability of static and RIP to multi-hop), what I am= advocating is >that a paragraph clarifying this could be added either to this= draft >or to the original 1hop draft. Probably that's all that is= needed for >static routes, and half of what is needed for RIP. >[Carlos] About the value of ICMP in bootstrapping, that is a= good >question for Suping. I don't see it either. [suping] As to ICMP, my initiate purpose is to provide a= out-of-band signalling method to bootstrap BFD session in the above two= cases. And the advange is that there is no need to send BFD control packet with the Your= Discriminator is zero. So do you think that this is applicable? > >> Please see below for some specific comments based on your= discussion. >> >> > > Should this draft be extended to the use of BFD for BGP in= a >> > > multi-hop environment? It seems that the changes needed= for >> > > BGP in a multi-hop environment would be that= demultiplexing >> > > should be based either on BGP signalling or on the >> > > source/destination address pairs and that Authentication >> > > SHOULD be used (as specified in the multi-hop draft). >> >> > [suping] For BGP I think the usually application is= one-hop, >> > so do we nessesarily need the multi-hop BGP? >> >> [RS] What about IBGP and EBGP multihop? >> > >[Carlos] I agree, that's the application... [suping] Yes, Perhaps that's the application. I think that= according to the discussion we had, the demultiplexing of IBGP= and EBGP is per the single-hop(interface and protocol) and= multi-hop(source/destination pairs). And I think that the= bootstrap issue of multihop IBGP and EBGP can be the same with= the single-hop BGP(use the BGP OPEN message at least). And I= want to know your opions? > >> > >Could this draft be extended to the use of BFD for RIP?= This would >> > >complete the application of BFD to the most common routing= protocols >> > >in use today, as OSPF and IS-IS are covered in the 1Hop= draft. >> > >> > [suping] I am very happy to do that. >> > > >> > >As RIPv2 is mostly a protocol frozen in time,= demultiplexing methods >> > >would only be manual configuration and demultiplexing based= on >> > >source/destination address pairs. >> > >ICMP and LSP-ping would not apply, >> > >as reasoned below for static routes. >> > >Also, because of this "frozennes", no possibility exists to= negotiate >> > >the discriminator value inside the protocol. >> > >So, for this protocol, as in BGP, it should be OPTIONAL= not >> > to put the routes from RIP into the routing table until the= BFD session is >> > >established. In this case the behaviour could also be not= to require >> > >any peer to behave differently from standard RIP until the= first >> > >session is established. >> > >> > [suping]I agree with you. >> >> [RS] If the BFD session cannot be established dynamically= using RIP (i.e. it is established independently and then mapped= to a RIP neighbour), then what information needs to go in the= draft? >> > >[Carlos] I think there should be a way to establish the BFD= sessions >dinamically based on the RIP announcements. Manual configuration= via >OSS can be very cumbersome (and that's why we use RIP for= routing >anyway, so that we don't have to manually configure all the= network). >That's why I propose that RIP receivers start BFD sessions when >receiving RIP announces (when they do not have already a BFD= session), >and give up after a numer of trials. > >> > >Although I'm not sure it is a good idea to use ICMP to= achieve >> > >demultiplexing, I think the section 3.1.1 is somewhat= incomplete, as >> > >it should define the ICMP type and code values (as TBD,= perhaps), and >> > >be extended to ICMPv6. I wouldn't do it, anyway. >> > >> > [suping]I think ICMP is a optional ways to demultiplexing >> > BFD session. In fact in ICMP(V4), there are message types of= 15 >> > (Information Request) and 16 (Information Reply), my intent= is to >> > extend the existing message by adding BFD discrimator in= it. >> > As for ICMPv6, I think there should be some new message >> > type(TBD) for this purpose. >> >> [RS] In the single-hop static route case (i.e. the next hop is= directly connected) then the your discriminator field should be= set to zero and the packet demultiplexed based on the interface.= In the multi-hop static route case (i.e. the next hop is more= than one hop away) then the your discriminator field should be= set to zero and the packet demultiplexed based on the= source/destination address pair. ICMP could be used to exchange= your discriminator fields, but what would the advantage of this= be over just sending a your discriminator field of zero, and= demultiplexing based on the interface or source/destination= address? >> > >[Carlos] I agree there is no advantage. > >> > >I'm also unsure what scenario could have a static route= needing BFD >> > >and have MPLS so that it has the LSP-ping mechanism to= bootstrap the >> > >session (3.1.2). If you have MPLS, you certainly could= apply BFD for >> > >MPLS and then you don't need BFD for this static route. >> >> [RS] The requirement to use BFD for LSPs as well as static= routes is perfectly viable. An operator may want to use BFD to= detect failures between system A and system B where forwarding= is based on static routes (e.g. for control traffic), whilst at= the same time detect failures where forwarding is based on MPLS= (e.g. customer traffic using a TE tunnel LSP). What is not= viable is the use of LSP ping for bootstrapping the static BFD= session. >> > >[Carlos] I see, that's right. In any case, LSP ping should not= be used >to bootstrap the static route. > >> > [suping]Yes, I think you are right. If MPLS is supported we >> > could use BFD for MPLS and don't need BFD for the static= route. In >> > anoter word, when static route we think that no MPLS is= supported. So >> > I will make such clarification in the draft. >> >> [RS] Forwarding of traffic between two systems based MPLS and= static routes is valid, using BFD to bootstrap the static route= session is not. If the static route belongs to a FEC for which= forwarding is based on MPLS, then BFD should be used on the LSP= (i.e. static route BFD is not needed because the packets are= forwarded using MPLS not IP). If traffic for the static route is= forwarded using IP, then the FEC for the LSP will be different= and therefore LSP ping cannot be used to bootstrap the static= route session, as per the MPLS BFD draft "BFD control packets= sent by the ingress LSR are encapsulated in the MPLS label stack= that corresponds to the FEC for which fault detection is being= performed." The use of LSP ping to bootstrap any protocol other= than MPLS is not viable and therefore this option should be= removed from both the static and BGP cases in the draft. >> >> > >I'm certainly overlooking something on 2.2 and 3.2, why >> > >would one want to put a random address from 127/8 in the >> > >destination address instead of the IP address of the peer >> > >or the static route points to? In BGP, we already know the >> > >destination address, why shouldn't it be used? >> >> > >For static routes on a LAN environment, where that address= must be >> > >known in order to get its MAC address, the same reasoning= applies. I >> > >see the applicability to point-to-point environments, but= there >> > >Inverse ARP could be used to get the other side's IP= address. >> > >But in any case, probably a rationale for the decision= wouldn't harm. >> > >> > [suping]Yes, I think you are right again:) We can use= explicity destination >> > IP address in BGP and static route applications because the= DIP has been known. >> >> [RS] The text from the encapsulation section being discussed= here was obviously a 'cut & paste' from the BFD MPLS draft!= There is no need for an encapsulation section anyway as= encapsulation is covered in the single-hop draft. [suping] My initial purpose is to get a integral draft, So copy= some texts from BFD MPLS draft. I can remove this section if not= needed iterate it. >> >> > >It would be a good thing if there were some mechanism so= that manual >> > >configuration does not need to configure a specific value= for the My >> > >discriminator... =A6=DCPerhaps restricting demultiplexing in= the presence >> > >of a zero value for the My discriminator to one session= per >> > >source/destination address pair? >> >> [RS] The my discriminator field must be configured using a= non-zero value, as per the base BFD draft "If the My= Discriminator field is zero, the packet MUST be discarded."= However, this doesn't mean that it needs to be manually= configured, it could be dynamically generated by the system when= the BFD session is enabled, or it could be dynamically= generated/provisioned using OSS. >> > >[Carlos] You're right again. > >> > [suping]So in implementation a more situation must be= considered if this is >> > the criteria, and even more if more BFD sessions are needed,= demultiplexing also >> > needed not according to source/destination address pair.=A6=DC >> >> [RS] Demultiplexing issues/methods are already covered in the= single-hop and multi-hop drafts. In the single-hop case, there= should only be one BFD session per interface, per protocol.= Therefore, if a system receives a BFD packet with a your= discriminator of zero, then it is mapped to the corresponding= session for that interface and protocol. In the multi-hop case, = if a system receives a BFD packet with a your discriminator of= zero, then the session can be demultiplexed based on the= source/destination address pair. Alternatively, out-of-band= signalling may be used to exchange your discriminator fields= prior to BFD session establishment, in which case packets are= never received with a your discriminator field of zero. >> >> > >Perhaps using the source port address for demuliplexing? >> > >> > [suping] There should be scenarios that more BFD sessions in= one source port, so I don't >> > think this will apply. >> >> [RS] In the BGP and static route case, what possible scenarios= are there where more than one BFD session will be required= between two systems? [suping] As to the demultiplexing issues, I think we can refer to= the 1hop and multi-hop draft, so need not iterate in my draft= again. Best Regard, suping >> >> Regards, >> Richard >> >> From rtg-bfd-bounces@ietf.org Wed Jul 06 12:17:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqCaO-0003if-Tk; Wed, 06 Jul 2005 12:17:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqCaL-0003cE-8z for rtg-bfd@megatron.ietf.org; Wed, 06 Jul 2005 12:17:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16519 for ; Wed, 6 Jul 2005 12:17:12 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqCuA-0002G9-1k for rtg-bfd@ietf.org; Wed, 06 Jul 2005 12:37:47 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 06 Jul 2005 09:09:41 -0700 X-IronPort-AV: i="3.93,265,1115017200"; d="scan'208"; a="196660398:sNHT89170064" Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j66G9Zod025144; Wed, 6 Jul 2005 09:09:35 -0700 (PDT) Received: (from wardd@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id LAA26263; Wed, 6 Jul 2005 11:09:38 -0500 (CDT) Date: Wed, 6 Jul 2005 11:09:38 -0500 From: David Ward To: rtg-bfd@ietf.org, dward@cisco.com, jhaas@nexthop.com Message-ID: <20050706110938.K13750@cfcentral.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: dkatz@juniper.net Subject: WG Last call on base and single hop X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org All - As the base specifiction for BFD has stabilized as well as the single hop specification, we are going to have a 3 week WG Last Call ending July 31st. Assuming no major revisions (famous last words) will be required, we will shepherd the drafts forward at that time. If you have comments, please reply to the WG and authors with the subject line: subject: LC comments < base spec | single hop> Here are the pointers to the docs. http://www.ietf.org/internet-drafts/draft-ietf-bfd-v4v6-1hop-02.txt http://www.ietf.org/internet-drafts/draft-ietf-bfd-base-02.txt In other news, as Dave and I agreed in the last WG meeting, we will be submitting a "generic applicability" draft on how an app can boostrap BFD sessions so that we don't need individual drafts for each of our favorite protocols. Stay tuned. The new draft MIB may or may not be published in time for Paris. -DWard From rtg-bfd-bounces@ietf.org Wed Jul 06 12:50:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqD6F-0008Nr-DL; Wed, 06 Jul 2005 12:50:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqD6D-0008L4-1k for rtg-bfd@megatron.ietf.org; Wed, 06 Jul 2005 12:50:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20918 for ; Wed, 6 Jul 2005 12:50:09 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqDTQ-00047Y-KQ for rtg-bfd@ietf.org; Wed, 06 Jul 2005 13:14:13 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 06 Jul 2005 12:46:08 -0400 X-IronPort-AV: i="3.93,265,1115006400"; d="scan'208"; a="61221138:sNHT27521980" Received: from [10.83.15.52] (rtp-tnadeau-vpn3.cisco.com [10.83.15.52]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id j66Gk6be003523; Wed, 6 Jul 2005 12:46:06 -0400 (EDT) In-Reply-To: <20050706110938.K13750@cfcentral.cisco.com> References: <20050706110938.K13750@cfcentral.cisco.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <723A910E-4031-405E-AA19-0124D6488CAD@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Wed, 6 Jul 2005 12:46:01 -0400 To: David Ward X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org, Jeffrey Haas , "Zafar Ali \(\(zali\)\)" , 'Dave Katz' Subject: Re: WG Last call on base and single hop X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org On Jul 6, 2005, at 12:09 PM, David Ward wrote: > All - > As the base specifiction for BFD has stabilized as well as the > single hop specification, we are going to have a 3 week WG Last > Call ending > July 31st. Assuming no major revisions (famous last words) will be > required, > we will shepherd the drafts forward at that time. > > If you have comments, please reply to the WG and authors with the > subject line: > > subject: LC comments < base spec | single hop> > > Here are the pointers to the docs. > > http://www.ietf.org/internet-drafts/draft-ietf-bfd-v4v6-1hop-02.txt > > http://www.ietf.org/internet-drafts/draft-ietf-bfd-base-02.txt > > In other news, as Dave and I agreed in the last WG meeting, we will be > submitting a "generic applicability" draft on how an app can > boostrap BFD > sessions so that we don't need individual drafts for each of our > favorite > protocols. Stay tuned. > > The new draft MIB may or may not be published in time for Paris. Zarar and I will be pushing out the updated version today or tomorrow, and it will be ready for WG LC at that time. --Tom From rtg-bfd-bounces@ietf.org Thu Jul 07 23:22:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqjS4-0004iD-JC; Thu, 07 Jul 2005 23:22:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqjS2-0004fy-Ma for rtg-bfd@megatron.ietf.org; Thu, 07 Jul 2005 23:22:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29812 for ; Thu, 7 Jul 2005 23:22:51 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqjtK-0002ZC-JR for rtg-bfd@ietf.org; Thu, 07 Jul 2005 23:51:08 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJA00681HG2X8@szxga01-in.huawei.com> for rtg-bfd@ietf.org; Fri, 08 Jul 2005 11:24:02 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJA001PAHG18Q@szxga01-in.huawei.com> for rtg-bfd@ietf.org; Fri, 08 Jul 2005 11:24:01 +0800 (CST) Received: from z11024 ([10.110.100.95]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IJA00H5QHN52G@szxml01-in.huawei.com>; Fri, 08 Jul 2005 11:28:17 +0800 (CST) Date: Fri, 08 Jul 2005 11:19:51 +0800 From: Suping Zhai To: David Ward Message-id: <0IJA00H5RHN52G@szxml01-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7BIT Cc: "rtg-bfd@ietf.org" Subject: LC comments X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zhaisuping@huawei.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Dear David and all bfd, I don't attend the last 62th IETF meeting, and I don't know the scope of "generic applicability" draft. But as I understand, if it's a "generic applicability" draft, if the IS-IS and OSPF application with BFD in draft-ietf-bfd-v4v6-1hop-02.txt should be extracted and to fill in that "generic applicabitly" and let draft-ietf-bfd-v4v6-1hop-02.txt dedicating to just the generally single hop issues? Best Regards, suping zhai July 8, 2005 >All - > As the base specifiction for BFD has stabilized as well as the >single hop specification, we are going to have a 3 week WG Last Call ending >July 31st. Assuming no major revisions (famous last words) will be required, >we will shepherd the drafts forward at that time. > >If you have comments, please reply to the WG and authors with the subject line: > >subject: LC comments < base spec | single hop> > >Here are the pointers to the docs. > >http://www.ietf.org/internet-drafts/draft-ietf-bfd-v4v6-1hop-02.txt > >http://www.ietf.org/internet-drafts/draft-ietf-bfd-base-02.txt > >In other news, as Dave and I agreed in the last WG meeting, we will be >submitting a "generic applicability" draft on how an app can boostrap BFD >sessions so that we don't need individual drafts for each of our favorite >protocols. Stay tuned. > >The new draft MIB may or may not be published in time for Paris. > > >-DWard From rtg-bfd-bounces@ietf.org Fri Jul 08 06:05:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqpjj-0006qA-0Y; Fri, 08 Jul 2005 06:05:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqpji-0006q5-0j for rtg-bfd@megatron.ietf.org; Fri, 08 Jul 2005 06:05:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16879 for ; Fri, 8 Jul 2005 06:05:31 -0400 (EDT) Received: from nproxy.gmail.com ([64.233.182.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqqB3-0007q1-UR for rtg-bfd@ietf.org; Fri, 08 Jul 2005 06:33:51 -0400 Received: by nproxy.gmail.com with SMTP id n15so99946nfc for ; Fri, 08 Jul 2005 03:05:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=mCgN2wkeJGxVivZfFNUMpedr/nVbnScWUe2hFY/qfSBKThUWnv5XgxOBmJZ+FaVGsWZCW7AvoIgGwxr7+EeIEqybK9u9QK1k1aoETb93nzHS+kttn8ppjPiZhdGUEAuzQ+ZN8wqj3HlE4IfCBF42f0ZQkc/G2Js7lfEfUUPXMMs= Received: by 10.48.247.20 with SMTP id u20mr64120nfh; Fri, 08 Jul 2005 03:05:22 -0700 (PDT) Received: by 10.48.247.19 with HTTP; Fri, 8 Jul 2005 03:05:22 -0700 (PDT) Message-ID: <9e31186f0507080305174144e@mail.gmail.com> Date: Fri, 8 Jul 2005 12:05:22 +0200 From: Carlos Garcia Braschi To: rtg-bfd@ietf.org, dward@cisco.com, dkatz@juniper.net Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: Subject: LC comments single hop X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Carlos Garcia Braschi List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hello,=20 It may be a contrived case, but: In the context of using BFD with RIP If=20 - The RIP messages are used to detect with whom to establish BFD sessions. That is, BFD sessions are established with senders from which announcements are received. - One of the two sides is a passive RIP listener. (This may make sense where the passive listener is redistributing the received routes to another protocol). Then The non-passive side cannot take the "Active" role in the BFD session, as it does not know where to send the BFD packets (until it receives one with My Discriminator different from zero). A similar case may happen with static routes (when they are not symmetrical= ). I don't know if this contrived case warrants changing the wording on point 3 of the 1-hop draft, from: 'As such, both sides of a session MUST take the "Active" role' to 'As such, both sides of a session SHOULD take the "Active" role' Regards, Carlos. > Date: Wed, 6 Jul 2005 11:09:38 -0500 > From: David Ward > Subject: WG Last call on base and single hop > To: rtg-bfd@ietf.org, dward@cisco.com, jhaas@nexthop.com > Cc: dkatz@juniper.net > Message-ID: <20050706110938.K13750@cfcentral.cisco.com> > Content-Type: text/plain; charset=3Dus-ascii >=20 > All - > As the base specifiction for BFD has stabilized as well as the > single hop specification, we are going to have a 3 week WG Last Call endi= ng > July 31st. Assuming no major revisions (famous last words) will be requir= ed, > we will shepherd the drafts forward at that time. >=20 > If you have comments, please reply to the WG and authors with the subject= line: >=20 > subject: LC comments < base spec | single hop> >=20 > Here are the pointers to the docs. >=20 > http://www.ietf.org/internet-drafts/draft-ietf-bfd-v4v6-1hop-02.txt >=20 > http://www.ietf.org/internet-drafts/draft-ietf-bfd-base-02.txt >=20 > In other news, as Dave and I agreed in the last WG meeting, we will be > submitting a "generic applicability" draft on how an app can boostrap BFD > sessions so that we don't need individual drafts for each of our favorite > protocols. Stay tuned. >=20 > The new draft MIB may or may not be published in time for Paris. >=20 >=20 > -DWard >=20 > From rtg-bfd-bounces@ietf.org Fri Jul 08 10:50:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DquBP-0007bw-7v; Fri, 08 Jul 2005 10:50:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DquB2-0007R3-FH; Fri, 08 Jul 2005 10:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08317; Fri, 8 Jul 2005 10:50:02 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqucQ-0004Bh-MU; Fri, 08 Jul 2005 11:18:23 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DquB0-00029R-Eq; Fri, 08 Jul 2005 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 08 Jul 2005 10:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-mib-01.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Bidirectional Forwarding Detection Management Information Base Author(s) : T. Nadeau, Z. Ali Filename : draft-ietf-bfd-mib-01.txt Pages : 24 Date : 2005-7-8 This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol [BFD]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-mib-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-8102309.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-8102309.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Mon Jul 11 05:46:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drurs-0005SQ-DK; Mon, 11 Jul 2005 05:46:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drurr-0005SF-BV for rtg-bfd@megatron.ietf.org; Mon, 11 Jul 2005 05:46:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25750 for ; Mon, 11 Jul 2005 05:46:24 -0400 (EDT) Received: from nproxy.gmail.com ([64.233.182.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrvJn-0006Mr-W5 for rtg-bfd@ietf.org; Mon, 11 Jul 2005 06:15:22 -0400 Received: by nproxy.gmail.com with SMTP id o25so199933nfa for ; Mon, 11 Jul 2005 02:46:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=poDu6E4ZqfFIoV9xLDPEnoUmlizD1ZUh6tRYvNlh1GzxSqL9cpnf2g+A/pkxKzkLU2z/Eh3KdBMmu7xQ9VQaX3HzbhnmHEY5+LL/2i+i0pbAontZU1/m+lPlzU5ozmdlukRbPZ8VmboU7uHGFCUHqhi1RERlhO5PG6/qd7GrGNY= Received: by 10.48.3.19 with SMTP id 19mr135330nfc; Mon, 11 Jul 2005 02:46:12 -0700 (PDT) Received: by 10.48.247.19 with HTTP; Mon, 11 Jul 2005 02:46:12 -0700 (PDT) Message-ID: <9e31186f05071102464808a520@mail.gmail.com> Date: Mon, 11 Jul 2005 11:46:12 +0200 From: Carlos Garcia Braschi To: rtg-bfd@ietf.org In-Reply-To: <42cea4f8.3c325c90.6f04.06b9SMTPIN_ADDED@mx.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <42cea4f8.3c325c90.6f04.06b9SMTPIN_ADDED@mx.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Subject: I-D ACTION:draft-ietf-bfd-mib-01.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Carlos Garcia Braschi List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org > Date: Fri, 08 Jul 2005 10:50:02 -0400 > From: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-ietf-bfd-mib-01.txt > To: i-d-announce@ietf.org > Cc: rtg-bfd@ietf.org > Message-ID: > Content-Type: text/plain; charset=3D"us-ascii" >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Bidirectional Forwarding Detection Worki= ng Group of the IETF. >=20 > Title : Bidirectional Forwarding Detection Management I= nformation Base > Author(s) : T. Nadeau, Z. Ali > Filename : draft-ietf-bfd-mib-01.txt > Pages : 24 > Date : 2005-7-8 >=20 Hi,=20 I have two comments on this draft, probably quite trivial to correct: - The bfdSessDown notification is specified to be generated when the BFD session state changes to down or adminDown, making it a notification that the session has entered a down state. Since this does not exactly mean that there has been a disconnection detection, wouldn't it be better if it is only generated when transitioning to down or adminDown from the Up state? Transitions from init or adminDown to down or adminDown mean that the session has not been established since the last down state and transitions from down to adminDown are just an administrative change, that does not change the connectivity detection. - The draft mostly references BFD protocol version 0 and has 0 as a default version, but the syntax for the state follows version 1. Shouldn't it reference version 1 as the default BFD protocol?=20 In the same line, the drafts referenced are the previous ward-katz drafts, instead of the ietf- ones. Regards, Carlos. -- Telefonica Empresas From rtg-bfd-bounces@ietf.org Mon Jul 11 08:47:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrxhI-0000jF-CS; Mon, 11 Jul 2005 08:47:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrxhF-0000j1-3p for rtg-bfd@megatron.ietf.org; Mon, 11 Jul 2005 08:47:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06881 for ; Mon, 11 Jul 2005 08:47:39 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dry9E-0005G9-EC for rtg-bfd@ietf.org; Mon, 11 Jul 2005 09:16:37 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 11 Jul 2005 05:47:33 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,278,1115017200"; d="scan'208"; a="1257909:sNHT25049648" Received: from [10.83.15.50] (rtp-tnadeau-vpn1.cisco.com [10.83.15.50]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id j6BCjhk8005214; Mon, 11 Jul 2005 08:47:31 -0400 (EDT) In-Reply-To: <9e31186f05071102464808a520@mail.gmail.com> References: <42cea4f8.3c325c90.6f04.06b9SMTPIN_ADDED@mx.gmail.com> <9e31186f05071102464808a520@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Mon, 11 Jul 2005 08:47:30 -0400 To: Carlos Garcia Braschi X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: I-D ACTION:draft-ietf-bfd-mib-01.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org On Jul 11, 2005, at 5:46 AM, Carlos Garcia Braschi wrote: >> Date: Fri, 08 Jul 2005 10:50:02 -0400 >> From: Internet-Drafts@ietf.org >> Subject: I-D ACTION:draft-ietf-bfd-mib-01.txt >> To: i-d-announce@ietf.org >> Cc: rtg-bfd@ietf.org >> Message-ID: >> Content-Type: text/plain; charset="us-ascii" >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Bidirectional Forwarding >> Detection Working Group of the IETF. >> >> Title : Bidirectional Forwarding Detection >> Management Information Base >> Author(s) : T. Nadeau, Z. Ali >> Filename : draft-ietf-bfd-mib-01.txt >> Pages : 24 >> Date : 2005-7-8 >> >> > > Hi, > I have two comments on this draft, probably quite trivial to correct: > - The bfdSessDown notification is specified to be generated when the > BFD session state changes to down or adminDown, making it a > notification that the session has entered a down state. > > Since this does not exactly mean that there has been a disconnection > detection, wouldn't it be better if it is only generated when > transitioning to down or adminDown from the Up state? No, because we might want to notify also based on sessions going down because they are really broken. I think we want to handle BOTH cases. > Transitions from init or adminDown to down or adminDown mean that the > session has not been established since the last down state and > transitions from down to > adminDown are just an administrative change, that does not change the > connectivity detection. > > - The draft mostly references BFD protocol version 0 and has 0 as a > default version, but the syntax for the state follows version 1. > Shouldn't it reference version 1 as the default BFD protocol? > In the same line, the drafts referenced are the previous ward-katz > drafts, instead of the ietf- ones. Will fix those. --Tom > > Regards, > Carlos. > -- > Telefonica Empresas > From rtg-bfd-bounces@ietf.org Tue Jul 12 15:51:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsQnF-0008W8-4G; Tue, 12 Jul 2005 15:51:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsQli-0007rR-7D; Tue, 12 Jul 2005 15:50:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28367; Tue, 12 Jul 2005 15:50:12 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsRDr-0003x3-Hm; Tue, 12 Jul 2005 16:19:22 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DsQlX-0000XC-Sa; Tue, 12 Jul 2005 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 12 Jul 2005 15:50:03 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-v4v6-1hop-03.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD for IPv4 and IPv6 (Single Hop) Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-v4v6-1hop-03.txt Pages : 12 Date : 2005-7-12 This document describes the use of the Bidirectional Forwarding Detection protocol over IPv4 and IPv6 for single IP hops. It further describes the use of BFD with OSPFv2, OSPFv3, and IS-IS. Comments on this draft should be directed to rtg-bfd@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-v4v6-1hop-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-v4v6-1hop-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-v4v6-1hop-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-12152503.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-v4v6-1hop-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-v4v6-1hop-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-12152503.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Tue Jul 12 15:52:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsQnb-0000BQ-Lz; Tue, 12 Jul 2005 15:52:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsQlk-0007tK-DI; Tue, 12 Jul 2005 15:50:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28389; Tue, 12 Jul 2005 15:50:13 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsRDr-0003x5-Ij; Tue, 12 Jul 2005 16:19:22 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DsQlX-0000XM-UP; Tue, 12 Jul 2005 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 12 Jul 2005 15:50:03 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-multihop-03.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD for Multihop Paths Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-multihop-03.txt Pages : 7 Date : 2005-7-12 This document describes the use of the Bidirectional Forwarding Detection protocol (BFD) over multihop paths, including unidirectional links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-multihop-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-multihop-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-multihop-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-12152724.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-multihop-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-multihop-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-12152724.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Tue Jul 12 15:52:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsQoH-0000SK-6V; Tue, 12 Jul 2005 15:52:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsQlq-0007wU-58; Tue, 12 Jul 2005 15:50:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28469; Tue, 12 Jul 2005 15:50:20 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsRDs-0003x6-IL; Tue, 12 Jul 2005 16:19:23 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DsQlX-0000XR-VL; Tue, 12 Jul 2005 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 12 Jul 2005 15:50:03 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-base-03.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Bidirectional Forwarding Detection Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-base-03.txt Pages : 44 Date : 2005-7-12 This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. Comments on this draft should be directed to rtg-bfd@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-base-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-base-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-base-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-12152944.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-base-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-base-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-12152944.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Wed Jul 13 05:38:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsdhG-0003jY-DD; Wed, 13 Jul 2005 05:38:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsdhE-0003iD-1J; Wed, 13 Jul 2005 05:38:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21036; Wed, 13 Jul 2005 05:38:24 -0400 (EDT) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dse9W-0008Q0-A7; Wed, 13 Jul 2005 06:07:46 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJK004OB7ZK93@szxga02-in.huawei.com>; Wed, 13 Jul 2005 17:35:45 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJK00C2B7ZGAG@szxga02-in.huawei.com>; Wed, 13 Jul 2005 17:35:44 +0800 (CST) Received: from z11024 ([10.110.100.95]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IJK0035Z84HXZ@szxml01-in.huawei.com>; Wed, 13 Jul 2005 17:38:41 +0800 (CST) Date: Wed, 13 Jul 2005 17:30:07 +0800 From: Suping Zhai To: "internet-drafts@ietf.org" Message-id: <0IJK0036284HXZ@szxml01-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: multipart/mixed; boundary="Boundary_(ID_pRwYfb+vIF5/CCePZAED8Q)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Cc: "rtg-bfd@ietf.org" , "jhaas@nexthop.com" , "dward@cisco.com" , "dkatz@juniper.net" Subject: Re: bfd application with BGP and static routes draft submission X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zhaisuping@huawei.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_pRwYfb+vIF5/CCePZAED8Q) Content-type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Dear BFD'ers, According to the discussion in BFD working group, I have rewrite= draft of BFD application with BGP and static routes, and focus= on the BFD initialization with BGP and static routes. And let= the encapsulation and demultiplexing refer to the single hop or= multihop bfd draft, and also the bfd interaction with BGP= graceful restart refer to the single hop draft. Any comments are welcome. Please help to post to the IETF website this draft and thank you= for that. Best Regards, zhaisuping@huawei.com Huawei Technologies Co., Ltd. Tel: +86-10-82882867 Fax: +86-10-82882537 2005-07-13 >I am sorry that I don't attatch the file in the last mail, so I= send the mail again. Sorry for the mistake. > > >Dear all, >I have written a draft about BFD application with BGP and static= routes, the purpose is to resolve the BFD bootstrapping end= encapsulation problem when in applications. It's 6 pages long,= Comments are very welcome. > >Please help to post to the IETF website this draft and thank you= for that. > > >Thank you and Best regards.=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1 > >Best Regards, >zhaisuping@huawei.com >Huawei Technologies Co., Ltd. >Tel: +86-10-82882867 >Fax: +86-10-82882537 >2005-06-23 --Boundary_(ID_pRwYfb+vIF5/CCePZAED8Q) Content-type: application/octet-stream; name=draft-suping-bfd-bgp-static-ini-01.txt Content-disposition: attachment; filename=draft-suping-bfd-bgp-static-ini-01.txt Content-Transfer-Encoding: base64 QkZEIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFN1cGluZyBaaGFpDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgSHVh d2VpIFRlY2hvbm9sb2dpZXMgQ28uLCBMdGQuDQpFeHBpcmVzOiBEZWNlbWJlciAyMDA1ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQoNCiAgICAgICAgICAgZHJhZnQt c3VwaW5nLWJmZC1iZ3Atc3RhdGljLWluaS0wMS50eHQNCg0KICAgICAgICAgIEJGRCBpbml0aWFs aXp0aW9uIHdpdGggQkdQIGFuZCBzdGF0aWMgcm91dGVzDQoNCg0KU3RhdHVzIG9mIHRoaXMgTWVt bw0KDQogICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJl cHJlc2VudHMgdGhhdCBhbnkNCiAgIGFwcGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFp bXMgb2Ygd2hpY2ggaGUgb3Igc2hlIGlzIGF3YXJlDQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBk aXNjbG9zZWQsIGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMNCiAgIGF3YXJlIHdp bGwgYmUgZGlzY2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4N Cg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJu ZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMg d29ya2luZyBncm91cHMuICBOb3RlIHRoYXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0 cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLg0KDQogICBJ bnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9m IHNpeCBtb250aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRl ZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0 ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8g Y2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlz dCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4NCg0KICAgVGhlIGxpc3Qgb2Yg SW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAg aHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KQWJzdHJhY3QNCg0KICAgVGhpcyBk b2N1bWVudCBkZXNjcmliZXMgdGhlIHVzZSBvZiB0aGUgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5n DQogICBEZXRlY3Rpb24gcHJvdG9jb2wgd2l0aCBCR1AgYW5kIHRoZSBzdGF0aWMgcm91dGUgb3Zl ciBJUHY0IG9yIElQdjYuIA0KICAgVGhlIG1haW4gcHVycG9zZSBvZiB0aGlzIGRyYWZ0IGlzIHRv IHNvbHZlIHRoZSBCRkQgYm9vdHN0cmFwIHByb2JsZW0NCiAgIHdpdGggQkdQIGFuZCBzdGF0aWMg cm91dGVzLiBBcyB0byB0aGUgZW5jYXBzdWxhdGlvbiBhbmQgDQogICBkZW11bHRpcGxleGluZyBp c3N1ZXMgdGhlcmUgaGF2ZSBiZWVuIGRlc2NyaXB0aW9ucyBpbiBCRkQgc2luZ2xlIGhvcA0KICAg ZHJhZnQgW0JGRC0xSE9QXSBhbmQgbXVsdGktaG9wIGRyYWZ0IFtCRkQtTVVMSV0uIFdpdGggdGhl IEJGRA0KICAgaW50ZXJhY3Rpb24gd2l0aCBCR1AgZ3JhY2VmdWwgcmVzdGFydCwgdGhlIHJ1bGVz IGRlc2NyaWJlZCBpbiBCRkQNCiAgIHNpbmdsZSBob3AgW0JGRC0xSE9QXSB3aXRoIElTLUlTIGFu ZCBPU1BGIGdyYWNlZnVsIHJlc3RhcnQgYXJlIGFsc28NCiAgIGFwcGxpY2FibGUgdG8gdGhlIEJG RCB3aXRoIEJHUCBncmFjZWZ1bCByZXN0YXJ0LCBhbmQgd2lsbCBub3QgDQogICBpdGVyYXRlaW4g aW4gdGhpcyBkcmFmdC4gDQogICBDb21tZW50cyBvbiB0aGlzIGRyYWZ0IHNob3VsZCBiZSBkaXJl Y3RlZCB0byBydGctYmZkQGlldGYub3JnIG9yIA0KICAgdG8gYXV0aG9yIGRpcmVjdGx5Lg0KDQpD b252ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1lbnQNCg0KICAgVGhlIGtleSB3b3JkcyAiTVVT VCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNI T1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgICJNQVkiLCBhbmQgIk9QVElPTkFM IiBpbiB0aGlzDQogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVk IGluIFJGQy0yMTE5IFtLRVlXT1JEU10uDQoNCg0KDQpTdXBpbmcgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVy bmV0IERyYWZ0ICBkcmFmdC1zdXBpbmctYmZkLWJncC1zdGF0aWMtaW5pLTAxLnR4dCAgICAgICAg SnVuZSwgMjAwNQ0KDQoxIEludHJvZHVjdGlvbg0KDQogICBPbmUgdmVyeSBkZXNpcmFibGUgYXBw bGljYXRpb24gZm9yIEJGRCBbQkZEXSBpcyB0byB0cmFjayBJUHY0IGFuZA0KICAgSVB2NiBjb25u ZWN0aXZpdHkgYmV0d2VlbiBkaXJlY3RseS1jb25uZWN0ZWQgc3lzdGVtcy4gIFRoZXJlIGFyZQ0K ICAgdHdvIGtpbmRzIG9mIGRpcmVjdGx5LWNvbm5lY3RlZCBzeXN0ZW1zLCBpbnRlci1BUyBhbmQg aW50cmEtQVMgDQogICBzeXN0ZW1zLiBGb3IgdGhlIEJGRCBhcHBsaWNhdGlvbiBpbiB0aGUgaW50 cmEtQVMgc3lzdGVtIHRoZXJlIGhhdmUgDQogICBiZWVuIHNpbmdsZSBob3AgZHJhZnQgW0JGRC0x SE9QXSBhbmQgbXVsdGlob3AgcGF0aHMgZHJhZnQgDQogICBbQkZELU1VTFRJXS4gVGhpcyBkb2N1 bWVudCBpcyB0byByZXNvbHZlIHRoZSBCRkQgaW5pdGlhbGl6YXRpb24gaW4gdGhlIA0KICAgaW50 ZXItQVMgc3lzdGVtcywgZXNwZWNpYWxseSBCRkQgYXBwbGljYXRpb24gd2l0aCBCR1AuIFdpdGgg dGhlIEJGRCANCiAgIGluIHN0YXRpYyByb3V0ZSBvdmVyIElQdjQgb3IgSVB2NiwgdGhlcmUgbmVl ZCBtYW5hZ2VtZW50IA0KICAgY29uZmlndXJhdGlvbiB0byBib290c3RyYXAgdGhlIEJGRCBzZXNz aW9uLCB0aGlzIGRvY3VtZW50IGFsc28gbGlzdA0KICAgc29tZSBwYXJhbWV0ZXJzIHNob3VsZCBi ZSBjb25maWd1cmVkIHRvIHN0YXJ0dXAgdGhlIEJGRCBzZXNzaW9uLg0KICAgDQoyIFVzZSBCRkQg d2l0aCBCR1ANCg0KICAgVGhlIEJvcmRlciBHYXRld2F5IFByb3RvY29sIFtCR1BdIGlzIGFuIGlu dGVyLUF1dG9ub21vdXMgU3lzdGVtDQogICByb3V0aW5nIHByb3RvY29sLiBCR1AgdXNlcyBUQ1Ag W1RDUF0gYXMgaXRzIHRyYW5zcG9ydCBwcm90b2NvbC4NCiAgIFRDUCBtZWV0cyBCR1AncyB0cmFu c3BvcnQgcmVxdWlyZW1lbnRzIGFuZCBpcyBwcmVzZW50IGluIHZpcnR1YWxseSANCiAgIGFsbCBj b21tZXJjaWFsIHJvdXRlcnMgYW5kIGhvc3RzLiANCiAgIA0KICAgQkdQIEtFRVBBTElWRSBtZXNz YWdlcyBjYW4gYmUgdXNlZCB0byBkZXRlY3QgdGhlIHBhdGggYmV0d2Vlbg0KICAgdGhlIEJHUCBw ZWVycywgYnV0IHRoZSBncmFudWxhcml0eSBvZiBmYWlsdXJlIGRldGVjdGlvbiB0aW1lIGlzDQog ICBtaW5pbXVtIHR3byBzZWNvbmRzLiBGb3IgdGhlIGRhdGEgcGxhbmUgdG9kYXkgb2YgR2lnYSBi aXQgaW50ZXJmYWNlDQogICB0aGlzIGRldGVjdGlvbiB0aW1lIHdpbGwgY2F1c2UgbWFueSB0cmFm ZmljIHRvIGJlIGxvc3QuIFNvIHRoZQ0KICAgZmFzdGVyIGRldGVjdGlvbiBtZWNobmlzbSBpcyBu ZWVkZWQgaW4gdGhlIGRhdGEgcGxhbmUuIEJGRCBjYW4gDQogICBiZSB1c2VkIHRvIHZlcmlmeSB0 aGUgZm9yd2FyZGluZyBhYmlsaXR5IG9mIGFuIEJHUCByb3V0ZXIncw0KICAgYWRqYWNlbmNpZXMg Zm9yIHRoaXMgcHVycG9zZS4NCg0KICAgSXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgdGhlIHB1cnBv c2Ugb2YgdXNpbmcgQkZEIGluIHRoaXMgY29udGV4dCBpcw0KICAgbm90IHRvIHJlcGxhY2UgdGhl IGFkamFjZW5jeSB0aW1lb3V0IG1lY2hhbmlzbSwgbm9yIGlzIGl0IHRvDQogICBkZW1vbnN0cmF0 ZSB0aGF0IHRoZSBuZXR3b3JrIGlzIGZ1bGx5IGZ1bmN0aW9uYWwgZm9yIHRoZSB1c2Ugb2YgdGhl DQogICByb3V0aW5nIHByb3RvY29sLCBidXQgaXMgc2ltcGx5IHRvIGFkdmlzZSB0aGUgcm91dGlu ZyBwcm90b2NvbCB0aGF0DQogICB0aGVyZSBhcmUgcHJvYmxlbXMgZm9yd2FyZGluZyB0aGUgZGF0 YSBwcm90b2NvbCBmb3Igd2hpY2ggdGhlIEJHUA0KICAgc2Vzc2lvbiBpcyBydW5uaW5nLiAgICAg ICANCiANCjIuMSBJbml0aWFsaXphdGlvbg0KDQogICBXaGVuIHVzZSBCRkQgd2l0aCBCR1AsIHRo aXMgZG9jdW1lbnQgbGlzdHMgdHdvIGNob2ljZXMgdG8gYm9vdHN0cmFwDQogICBCRkQgc2Vzc2lv biBhcyBmb2xsb3dpbmdzLiBBbmQgd2hpY2ggbWVjaGFuaXNtIGlzIHVzZWQgaW4gDQogICBpbXBs ZW1lbnRhdGlvbiBpcyBvdXQgb2YgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuICAgDQogICAN CjIuMS4xIEJGRCBjYXBhYmlsaXRpZXMgYWR2ZXJ0aXNlbWVudCBpbiBCR1AgT1BFTiBtZXNzYWdl DQoNCiAgIEluIHRoZSBCR1AgcHJvdG9jb2wgT1BFTiBtZXNzYWdlLCB0aGVyZSBpcyBhbiBPcHRp b25hbCBQYXJhbWV0ZXJzIA0KICAgZmllbGQgY2FuIGNvbnRhaW4gYSBsaXN0IG9mIG9wdGlvbmFs IHBhcmFtZXRlcnMsIHdoZXJlIGVhY2ggcGFyYW1ldGVyDQogICBpcyBlbmRjb2RlIGFzIGEgPFBh cmFtZXRlciBUeXBlLCBQYXJhbWV0ZXIgTGVuZ3RoLCBQYXJhbWV0ZXIgVmFsdWU+IA0KICAgdHJp cGxldC4gSW4gdGhlIGRvY3VtZW50IFtCR1BdIFBhcmFtZXRlciBUeXBlIDEgaGFzIGJlZW4gZGVm aW5lZCANCiAgIGZvciBBdXRoZW50aWNhdGlvbiBJbmZvcm1hdGlvbi4gQW5kIGluIGRvY3VtZW50 IFtCR1AtQ0FQXSB0aGVyZSBpcw0KICAgYW5vdGhlciBkZWZpbml0aW9uIGFib3V0IFBhcmFtZXRl ciBUeXBlIDIgZm9yIGNhcGFiaWxpdGllcyANCiAgIGFkdmVydGlzZW1lbnQuIFRoZSBwYXJhbWV0 ZXIgY29udGFpbnMgb25lIG9yIG1vcmUgdHJpcGxlcyA8Q2FwYWJpbGl0eQ0KICAgQ29kZSwgQ2Fw YWJpbGl0eSBMZW5ndGgsIENhcGFiaWxpdHkgVmFsdWU+LCB3aGVyZSBlYWNoIHRyaXBsZSBpcyAN CiAgIGVuY29kZWQgYXMgc2hvd24gYmVsb3c6DQoNCg0KDQpTdXBpbmcgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMl0NCgwNCklu dGVybmV0IERyYWZ0ICBkcmFmdC1zdXBpbmctYmZkLWJncC1zdGF0aWMtaW5pLTAxLnR4dCAgICAg ICAgSnVuZSwgMjAwNQ0KDQogICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsN CiAgICAgICB8IENhcGFiaWxpdHkgQ29kZSAoMSBvY3RldCkgICAgfA0KICAgICAgICstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgfCBDYXBhYmlsaXR5IExlbmd0aCAoMSBv Y3RldCkgIHwNCiAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAg IHwgQ2FwYWJpbGl0eSBWYWx1ZSAodmFyaWFibGUpICB8DQogICAgICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgDQogICBIZXJlIHdlIHVzZSBhIG5ldyBDYXBhYmls aXR5IGNvZGUgdG8gaW5kaWNhdGUgdGhlIEJGRCBjYXBhYmlsaXR5LCB0aGUNCiAgIGNvZGUgdmFs dWUgaXMgVEJELiBUaGUgQ2FwYWJpbGl0eSBMZW5ndGggaXMgNCwgYW5kIENhcGFiaWxpdHkgdmFs dWUNCiAgIGlzIHRoZSBNeSBEaXNjcmltaW5hdG9yIGFzc2lnbmVkIGJ5IHRoZSBCR1Agc3BlYWtl ciBhbmQgdGhpcw0KICAgZGlzY3JpbWluYXRvciB3aWxsIHVzZWQgYXMgdGhlIGRlbXVsdGlwbGV4 aW5nIGluIHRoZSBmb2xsb3dpbmcgQkZEIA0KICAgc2Vzc2lvbi4gSWYgQkZEIGNhcGFiaWxpdHkg YWR2ZXJ0aXNlbWVudCBpcyBub3QgcHJlc2VudGVkIGluIHRoZSANCiAgIEJHUCBPUEVOIG1lc3Nh Z2UsIGl0IGlzIG5vdCBwcmVjbHVkZWQgdGhhdCBCRkQgZGlzY3JpbWluYXRvciANCiAgIGluaXRp YWxpenRpb24gaXMgc3VwcG9ydGVkIGJ5IG90aGVyIG1lYW5zIGUuZy4gdGhyb3VnaCBzdGF0aWMg DQogICBjb25maWd1cmF0aW9uIGFzIHNob3duIGluIHRoZSAyLjEuMiBzZWN0aW9uLg0KICAgDQog ICBOb3RlIHRoYXQgaXQgaXMgcG9zc2libGUgaW4gc29tZSBmYWlsdXJlIHNjZW5hcmlvcyBmb3Ig dGhlIG5ldHdvcmsgdG8NCiAgIGJlIGluIGEgc3RhdGUgc3VjaCB0aGF0IHRoZSBCR1AgY29tZXMg dXAsIGJ1dCB0aGUgQkZEIHNlc3Npb24gY2Fubm90DQogICBiZSBlc3RhYmxpc2hlZCwgYW5kLCBt b3JlIHBhcnRpY3VsYXJseSwgc29tZSBkYXRhIGNhbm5vdCBiZSANCiAgIGZvcndhcmRlZC4gRm9y IGV4YW1wbGUgaW4gc29tZSBzaXR1YXRpb24gVENQIHRyYWZmaWMgY2FuIGJlIGZvcndhcmRlZA0K ICAgYnV0IFVEUCB0cmFmZmljIGNhbid0IGZvcndhcmRlZC4gVG8gYXZvaWQgdGhpcyBzaXR1YXRp b24sIGl0IHdvdWxkIGJlIA0KICAgYmVuZWZpY2lhbCB0byBub3QgYWxsb3cgdGhlIEJHUCBzcGVh a2VyIHRvIGVzdGFibGlzaCB0aGUgc2Vzc2lvbiB3aXRoDQogICB0aGUgQkdQIHBlZXIgdW50aWwg dGhlIEJGRCBzZXNzaW9uIGlzIHVwLiAgSG93ZXZlciwgdGhpcyB3b3VsZCANCiAgIHByZWNsdWRl IHRoZSBvcGVyYXRpb24gb2YgdGhlIEJHUCBpbiBhbiBlbnZpcm9ubWVudCBpbiB3aGljaCBub3Qg YWxsIA0KICAgc3lzdGVtcyBzdXBwb3J0IEJGRC4NCg0KICAgVGhlcmVmb3JlLCBpZiBhIEJGRCBz ZXNzaW9uIGlzIG5vdCBpbiBVcCBzdGF0ZSAocG9zc2libHkgYmVjYXVzZSB0aGUNCiAgIHJlbW90 ZSBzeXN0ZW0gZG9lcyBub3Qgc3VwcG9ydCBCRkQpLCBpdCBpcyBPUFRJT05BTCB0byBwcmVjbHVk ZSB0aGUNCiAgIGVzdGFibGlzaG1lbnQgb2YgYW4gQkdQIHNlc3Npb24gd2l0aCB0aGUgQkdQIHBl ZXIuICBUaGUgY2hvaWNlDQogICBvZiB3aGV0aGVyIHRvIGRvIHNvIFNIT1VMRCBiZSBjb250cm9s bGVkIGJ5IG1lYW5zIG91dHNpZGUgdGhlIHNjb3BlDQogICBvZiB0aGlzIHNwZWNpZmljYXRpb24s IHN1Y2ggYXMgY29uZmlndXJhdGlvbiBvciBvdGhlciBtZWNoYW5pc21zLiAgICAgIA0KICAgcHJv dG9jb2wuDQogICAgICAgICANCjIuMS4yIENvbmZpZ3VyYXRpb24gbWFudWFsbHkNCg0KICAgRm9y IHRoZSBzaW1wbGljaXR5IGluIHRoZSBzbWFsbCBzY2FsZSBuZXR3b3JrLCBpdCBtYXkgYmUgY29u ZmlndXJlZA0KICAgbWFudWFsbHkgdG8gcHJvdmlkZSB0aGUgbmVjZXNzYXJ5IHBhcmFtZXRlcnMg dG8gc3RhcnQgdXAgdGhlIEJGRA0KICAgc2Vzc2lvbi4gVGhlIGZpcnN0IG15IGRpc2NyaW1pbmF0 b3IgZm9yIGRlbXVsdGlwbGV4aW5nIEJGRCBzZXNzaW9uIA0KICAgaXMgbmVlZGVkIHRvIGNvbmZp Z3VyZWQgaW4gdGhlIHNvdXJjZS9lbmQgaG9zdCBvciByb3V0ZXIgb3ZlciB3aGljaCANCiAgIHRo ZSBCRkQgc2Vzc2lvbiBpcyB0byBiZSBydW5uaW5nLiBUaGUgc2Vjb25kIGlmIHRoZSBCRkQgc2Vz c2lvbiBpcyANCiAgIGVuYWJsZWQgYWxzbyBuZWVkZWQgdG8gYmUgY29uZmlndXJlZC4gVGhlbiB0 aGUgc3lzdGVtIGNhbiBydW4gQkZEIA0KICAgaWYgbmVjZXNzYXJ5Lg0KICANCg0KMyBCRkQgaW5p dGlhbGl6YXRpb24gd2l0aCBzdGF0aWMgcm91dGUNCg0KMy4xIEluaXRpYWxpemF0aW9uIGJ5IGNv bmZpZ3VyYXRpb24gbWFudWFsbHkNCg0KICAgV2hlbiB1c2UgQkZEIGluIHRoZSBzaXR1YXRpb24g b2Ygc3RhdGljIHJvdXRlcywgdGhlcmUgaXMgbm8gZGVkaWNhdGVkDQogICByb3V0ZSBwcm90b2Nv bCBjYW4gYmUgdXNlZCB0byBib290c3RyYXAgQkZEIHNlc3Npb24uICAgDQogICBUaGUgc2ltcGxl IHdheSB0byBzdGFydCB1cCBCRkQgc2Vzc2lvbiBpcyB0aHJvdWdoIHRoZSBjb25maWd1cmF0aW9u Lg0KICAgTXkgRGlzY3JpbWluYXRvciBmb3IgZGVtdWx0aXBsZXhpbmcgQkZEIHNlc3Npb24gaXMg bmVlZGVkIHRvIA0KICAgY29uZmlndXJlZCBpbiB0aGUgc291cmNlL2VuZCBob3N0IG9yIHJvdXRl ciBvdmVyIHdoaWNoIHRoZSBCRkQNCiAgICANClN1cGluZyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQg RHJhZnQgIGRyYWZ0LXN1cGluZy1iZmQtYmdwLXN0YXRpYy1pbmktMDEudHh0ICAgICAgICBKdW5l LCAyMDA1DQoNCiAgIHNlc3Npb24gaXMgdG8gYmUgcnVubmluZy4gV2hldGhlciB0aGUgQkZEIHNl c3Npb24gZW5hYmxlZCBvbiANCiAgIHRoZSBzeXN0ZW0gaXMgYWxzbyBuZWVkZWQgdG8gYmUgY29u ZmlndXJlZC4gVGhlbiB0aGUgc3lzdGVtIGNhbg0KICAgc3RhcnQgQkZEIHNlc3Npb24gaWYgbmVj ZXNzYXJ5IGFjY29yZGluZyB0byB0aGUgY29uZmlndXJhdGlvbg0KICAgIHBhcmFtZXRlcnMuICAg IA0KICAgDQo0IEJGRCBFbmNhcHN1bGF0aW9uIGFuZCBEZW11bHRpcGxleGluZyB3aXRoIEJHUCBh bmQgc3RhdGljIHJvdXRlcw0KDQogICBBY2NvcmRpbmcgdG8gdGhlIEJGRCBzaW5nbGUgaG9wIGRy YWZ0IFtCRkQtMUhPUF0gdGhlIEJGRCBwYXlsb2FkDQogICBpcyBlbmNvZGVkIGluIHRoZSBVRFAg cGFja2V0LiBUbyBjb25zaXN0IHdpdGggdGhlIFtCRkQtMUhPUF0gYW5kDQogICB3aGVuIGluIHRo ZSBpbnRlci1BUyBlbnZpcm9ubWVudCBhbmQgc3RhdGljIHJvdXRlcywgdGhlIEJGRCBpcyANCiAg IGFsc28gZW5jb2RlZCBpbiBVRFAgcGFja2V0LiBCRkQgdXNpbmcgVURQIGNhbiBiZSBzaW1wbGUg YmVjYXVzZSANCiAgIG5vIHJlcXVpcm1lbnQgb2YgcmV0cmFuc21pc3Npb24sIGFja25vd2xlZGdl bWVudCBhbmQgc2VxdWVuY2luZy4NCiAgIA0KICAgQXMgdG8gdGhlIGRlbXVsdGlwbGV4LCB0byBh bGlnbiB3aXRoIHRoZSBzaW5nbGUtaG9wIGRyYWZ0IFtCRkQtMUhPUF0NCiAgIGFuZCB0aGUgbXVs dGktaG9wIGRyYWZ0IFtCRkQtTVVMVEldLCBCRkQgc2Vzc2lvbiB3aXRoIG9uZSBob3AgQkdQIA0K ICAgb3Igc3RhdGljIHJvdXRlcyBzaG91bGQgYmUgZGVtdWx0aXBsZXhlZCBiYXNlZCBvbiB0aGUg aW50ZXJmYWNlIA0KICAgYW5kIGluIHRoZSBtdWx0aS1ob3AgQkdQIG9yIHN0YXRpYyByb3V0ZXMg QkZEIHNlc3Npb25zIGNhbiBiZSANCiAgIGRlbXVsdGlwbGV4ZWQgYmFzZWQgb24gc291cmNlL2Rl c3RpbmF0aW9uIGFkZHJlc3MgcGFpcnMuIA0KICAgDQogICANCjUgIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zDQoNCiAgIEFzIEJGRCBhcHBsaWVkIGluIHRoZSBCR1AgcGVlciBzeXN0ZW0sIGl0IGlz IGVuY291cmFnZWQgdG8gdXNlIEJGRA0KICAgYXV0aGVudGljYXRpb24gZnVuY3Rpb25zIHRvIGF2 b2lkIEJGRCBhYnVzZS4gQ29uc2lkZXJpbmcgQkdQIGl0c2VsZiANCiAgIGhhcyB0aGUgc2VjdXJp dHkgbWVjaGFuaXNtcywgd2hlbiB1c2UgQkdQIE9QRU4gbWVzc2FnZSB0byBzdGFydCB1cA0KICAg dGhlIEJGRCwgaXQncyBub3QgbWFuZGF0b3J5IHRvIGhhdmUgYXV0aGVudGljYXRpb24gaW4gQkZE IHNlc3Npb24uDQogICANCiAgIFdoZW4gdXNlIEJGRCB3aXRoIHN0YXRpYyByb3V0ZXMsIGl0J3Mg b3B0aW9uIHRvIHVzZSBCRkQgDQogICBhdXRoZW50aWNhdGlvbiBmdW5jdGlvbnMuICAgICAgDQoN Ck5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtCRkRdIEthdHosIEQuLCBhbmQgV2FyZCwgRC4s ICJCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIiwNCiAgICAgICAgIGRyYWZ0LWll dGYtYmZkLWJhc2UtMDIudHh0LCBNYXJjaCwgMjAwNQ0KICAgW0JGRC0xSE9QXSBLYXR6LCBELiwg YW5kIFdhcmQsIEQuLCAiQkZEIGZvciBJUHY0IGFuZCBJUHY2IChTaW5nbGUNCiAgICAgICAgIEhv cCkiLCBkcmFmdC1pZXRmLWJmZC12NHY2LTFob3AtMDIudHh0LCBNYXJjaCwgMjAwNQ0KICAgW0JG RC1NVUxUSV0gRC4gS2F0eiwgYW5kIEQuIFdhcmQsICJCRkQgZm9yIE11bHRpaG9wIFBhdGhzIiwg ZHJhZnQNCiAgICAgICAgIC1pZXRmLWJmZC1tdWx0aWhvcC0wMi50eHQsIE1hcmNoLCAyMDA1DQog ICBbQkZELUxTUF0gUmFodWwgQWdnYXJ3YWwgZXQgYWwsICJCRkQgRm9yIE1QTFMgTFNQcyIsIGRy YWZ0LWlldGYNCiAgICAgICAgIC1iZmQtbXBscy0wMS50eHQsIGV4cGlyZWQgZGF0ZSBBdWd1c3Qg MjAwNSAgICAgIA0KICAgW1RDUF0gUG9zdGVsLCBKLiwgIlRyYW5zbWlzc2lvbiBDb250cm9sIFBy b3RvY29sIC0gREFSUEEgSW50ZXJuZXQNCiAgICAgICAgIFByb2dyYW0gUHJvdG9jb2wgU3BlY2lm aWNhdGlvbiIsIFNURCA3LCBSRkMgNzkzLCBEQVJQQSwgDQogICAgICAgICBTZXB0ZW1iZXIgMTk4 MSAgICAgICAgICANCiAgIFtCR1BdIFkuIFJla2h0ZXIsICJBIEJvcmRlciBHYXRld2F5IFByb3Rv Y29sIDQgKEJHUC00KSIsIFJGQzE3NzEsIA0KICAgICAgICAgTWFyY2ggMTk5NQ0KICAgW0JHUC1D QVBdIFIuIENoYW5kcmEgZXQgYWwsICJDYXBhYmlsaXRpZXMgQWR2ZXJ0aXNlbWVudCB3aXRoIEJH UC00IiwgDQogICAgICAgICBSRkMzOTkyLCBOb3ZlbWJlciAyMDAyICAgICAgICANCiAgIFtCR1At UkVTVEFSVF0gU3JpaGFyaSBSLiBTYW5nbGkgZXQgYWwsIGRyYWZ0LWlldGYtaWRyLXJlc3RhcnQt MTAudHh0LA0KICAgICAgICAgZXhwaXJlZCBkYXRlIERlY2VtYmVyIDIwMDQNCg0KDQoNCg0KDQpT dXBpbmcgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgW1BhZ2UgNF0NCgwNCkludGVybmV0IERyYWZ0ICBkcmFmdC1zdXBpbmctYmZkLWJncC1z dGF0aWMtaW5pLTAxLnR4dCAgICAgICAgSnVuZSwgMjAwNQ0KDQpBdXRob3IncyBBZGRyZXNzZXMN CiAgICAgDQogICAgIFN1cGluZyBaaGFpDQogICAgIEh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBM VEQuDQogICAgIE5vLiAzIFhpbnhpIFJvYWQsIFNoYW5nZGksIA0KICAgICBIYWlEaWFuIERpc3Ry aWN0LCANCiAgICAgQmVpS2luZyBDaXR5LCANCiAgICAgVGhlIFAuUi5DaGluYQ0KICAgICBFbWFp bDogemhhaXN1cGluZ0BodWF3ZWkuY29tIA0KICAgICANCkZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVu dA0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA1KS4gVGhpcyBk b2N1bWVudCBpcyBzdWJqZWN0DQogICB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJp Y3Rpb25zIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZA0KICAgZXhjZXB0IGFzIHNldCBmb3J0aCB0 aGVyZWluLCB0aGUgYXV0aG9ycyByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4NCg0KICAgVGhpcyBk b2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVk IG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTkla QVRJT04gSEUvU0hFIFJFUFJFU0VOVFMNCiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwg VEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVA0KICAgRU5HSU5FRVJJTkcgVEFT SyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELA0KICAg SU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9G IFRIRQ0KICAgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMg T1IgQU5ZIElNUExJRUQNCiAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5F U1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLg0KICAgDQogICANCiAgIA0KICAgDQogICANCiAg IA0KICAgDQogICANCiAgIA0KICAgDQogICANCiAgIA0KICAgDQogICANCiAgIA0KICAgDQogICAN CiAgIA0KICAgDQogICANCiAgIA0KDQoNCg0KDQoNCg0KDQoNCg0KDQpTdXBpbmcgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0N CgwNCkludGVybmV0IERyYWZ0ICBkcmFmdC1zdXBpbmctYmZkLWJncC1zdGF0aWMtaW5pLTAxLnR4 dCAgICAgICAgSnVuZSwgMjAwNQ0KICAg --Boundary_(ID_pRwYfb+vIF5/CCePZAED8Q)-- From rtg-bfd-bounces@ietf.org Thu Jul 14 11:40:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt5oo-0006xG-GM; Thu, 14 Jul 2005 11:40:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt5ol-0006wz-QK for rtg-bfd@megatron.ietf.org; Thu, 14 Jul 2005 11:40:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22992 for ; Thu, 14 Jul 2005 11:40:04 -0400 (EDT) Received: from furball.foretec.com ([132.151.15.110] helo=foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt6HO-0007Hm-I5 for rtg-bfd@ietf.org; Thu, 14 Jul 2005 12:09:42 -0400 Received: from localhost ([127.0.0.1] helo=furball.foretec.com) by foretec.com with esmtp (Exim 4.30) id 1Dt5oj-0004WD-De; Thu, 14 Jul 2005 11:40:05 -0400 Received: from 10.27.16.5 (SquirrelMail authenticated user ids) by furball.foretec.com with HTTP; Thu, 14 Jul 2005 11:40:05 -0400 (EDT) Message-ID: <2303.10.27.16.5.1121355605.squirrel@furball.foretec.com> In-Reply-To: <0IJK0036284HXZ@szxml01-in.huawei.com> References: <0IJK0036284HXZ@szxml01-in.huawei.com> Date: Thu, 14 Jul 2005 11:40:05 -0400 (EDT) From: internet-drafts@ietf.org To: zhaisuping@huawei.com User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA22992 Cc: "rtg-bfd@ietf.org" , "jhaas@nexthop.com" , "dward@cisco.com" , "dkatz@juniper.net" Subject: Re: bfd application with BGP and static routes draft submission X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org There is no such file draft-suping-bfd-bgp-static-ini in the directory. I= s it the initial submission? Please let know. Thanks. Dinara Suleymanova > Dear BFD'ers, > According to the discussion in BFD working group, I have rewrite draft = of > BFD application with BGP and static routes, and focus on the BFD > initialization with BGP and static routes. And let the encapsulation an= d > demultiplexing refer to the single hop or multihop bfd draft, and also = the > bfd interaction with BGP graceful restart refer to the single hop draft. > Any comments are welcome. > Please help to post to the IETF website this draft and thank you for th= at. > > Best Regards, > zhaisuping@huawei.com > Huawei Technologies Co., Ltd. > Tel: +86-10-82882867 > Fax: +86-10-82882537 > 2005-07-13 > >>I am sorry that I don't attatch the file in the last mail, so I send th= e >> mail again. Sorry for the mistake. >> >> >>Dear all, >>I have written a draft about BFD application with BGP and static routes= , >> the purpose is to resolve the BFD bootstrapping end encapsulation prob= lem >> when in applications. It's 6 pages long, Comments are very welcome. >> >>Please help to post to the IETF website this draft and thank you for >> that. >> >> >>Thank you and Best regards.=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1 >> >>Best Regards, >>zhaisuping@huawei.com >>Huawei Technologies Co., Ltd. >>Tel: +86-10-82882867 >>Fax: +86-10-82882537 >>2005-06-23 > From rtg-bfd-bounces@ietf.org Fri Jul 15 15:51:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWDu-0006Og-4h; Fri, 15 Jul 2005 15:51:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWCM-0005u2-0v; Fri, 15 Jul 2005 15:50:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10979; Fri, 15 Jul 2005 15:50:11 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtWf4-0007ph-6k; Fri, 15 Jul 2005 16:19:58 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DtWCA-0001vE-Uf; Fri, 15 Jul 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 15 Jul 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-generic-00.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Generic Application of BFD Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-generic-00.txt Pages : 7 Date : 2005-7-15 This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol in environments not specifically documented in other specifications. Comments on this draft should be directed to rtg-bfd@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-generic-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-generic-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-generic-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-15142048.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-generic-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-generic-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-15142048.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Sat Jul 16 08:57:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtmEc-0000c9-V7; Sat, 16 Jul 2005 08:57:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtmEX-0000bw-OO for rtg-bfd@megatron.ietf.org; Sat, 16 Jul 2005 08:57:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13014 for ; Sat, 16 Jul 2005 08:57:32 -0400 (EDT) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtmhY-0005pF-Qq for rtg-bfd@ietf.org; Sat, 16 Jul 2005 09:27:33 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJQ00EUD1GPQU@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Sat, 16 Jul 2005 21:00:25 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJQ006M11GPUR@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Sat, 16 Jul 2005 21:00:25 +0800 (CST) Received: from z11024 ([10.110.100.95]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IJQ0083L1QYRQ@szxml01-in.huawei.com> for rtg-bfd@ietf.org; Sat, 16 Jul 2005 21:06:35 +0800 (CST) Date: Sat, 16 Jul 2005 20:57:56 +0800 From: Suping Zhai To: "rtg-bfd@ietf.org" Message-id: <0IJQ0083M1QZRQ@szxml01-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7BIT Subject: Re: I-D ACTION:draft-ietf-bfd-generic-00.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zhaisuping@huawei.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Dear all, Perhaps I haven't pay attention to the progress of the following draft, but I want to know if there is the corresponding individual draft for the following working group draft? Or it become working group draft from begining? Thanks for reply. Regards, suping 2005-07-15 >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. > > Title : Generic Application of BFD > Author(s) : D. Katz, D. Ward > Filename : draft-ietf-bfd-generic-00.txt > Pages : 7 > Date : 2005-7-15 > > This document describes the generic application of the Bidirectional > Forwarding Detection (BFD) protocol in environments not specifically > documented in other specifications. Comments on this draft should be > directed to rtg-bfd@ietf.org. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-bfd-generic-00.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-bfd-generic-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-bfd-generic-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > >Content-Type: text/plain >Content-ID: <2005-7-15142048.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-bfd-generic-00.txt From rtg-bfd-bounces@ietf.org Mon Jul 18 18:50:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DueRQ-0002Th-M0; Mon, 18 Jul 2005 18:50:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DueR1-0002Lm-KB; Mon, 18 Jul 2005 18:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06955; Mon, 18 Jul 2005 18:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DueuW-0000qx-Na; Mon, 18 Jul 2005 19:20:33 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DueR0-0008Bq-27; Mon, 18 Jul 2005 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 18 Jul 2005 18:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-mpls-02.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD For MPLS LSPs Author(s) : R. Aggarwal, et al. Filename : draft-ietf-bfd-mpls-02.txt Pages : 11 Date : 2005-7-18 One desirable application of Bi-directional Forwarding Detection (BFD) is to detect a MPLS LSP data plane failure. LSP-Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane. BFD can be used for the former, but not for the latter. However the control plane processing required for BFD control packets is relatively smaller than the processing required for LSP-Ping messages. A combination of LSP-Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs. This document describes the applicability of BFD in relation to LSP-Ping for this application. It also describes procedures for using BFD in this environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-mpls-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-mpls-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-mpls-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-18155634.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-mpls-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-mpls-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-18155634.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Wed Jul 20 10:46:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvFqE-0003oN-78; Wed, 20 Jul 2005 10:46:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvFqC-0003jf-Al for rtg-bfd@megatron.ietf.org; Wed, 20 Jul 2005 10:46:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22995 for ; Wed, 20 Jul 2005 10:46:30 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvGK2-0007dS-9j for rtg-bfd@ietf.org; Wed, 20 Jul 2005 11:17:23 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 20 Jul 2005 07:46:22 -0700 X-IronPort-AV: i="3.93,303,1115017200"; d="scan'208"; a="649565398:sNHT23947836" Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6KEkJIs028184; Wed, 20 Jul 2005 07:46:19 -0700 (PDT) Received: from [171.71.217.15] (cfcentral.cisco.com [64.101.210.32]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA13088; Wed, 20 Jul 2005 09:46:17 -0500 (CDT) Mime-Version: 1.0 X-Sender: wardd@127.0.0.1 Message-Id: Date: Wed, 20 Jul 2005 09:46:17 -0500 To: rtg-bfd@ietf.org From: David Ward Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: jhaas@nexthop.com, dward@cisco.com Subject: BFD Agenda requests IETF 63 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org We are officially starting to gather agenda requests for the BFD WG meeting in Paris. The agenda needs to be ready by July 25th. So, please, send your requests by the end of this week (Friday, July 22nd). You should send your agenda request to the chairs indicating: 1) the topic you want to present 2) related Internet-Drafts 3) length of the requested agenda-slot Thanks From rtg-bfd-bounces@ietf.org Wed Jul 20 12:31:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvHTg-0007wO-Gu; Wed, 20 Jul 2005 12:31:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvHTf-0007vB-IV for rtg-bfd@megatron.ietf.org; Wed, 20 Jul 2005 12:31:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07078 for ; Wed, 20 Jul 2005 12:31:20 -0400 (EDT) Received: from nproxy.gmail.com ([64.233.182.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvHxW-00080P-DR for rtg-bfd@ietf.org; Wed, 20 Jul 2005 13:02:15 -0400 Received: by nproxy.gmail.com with SMTP id a4so404641nfc for ; Wed, 20 Jul 2005 09:31:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Uhnz6+d3NjqbbCoFVPuuhybQJdHpvlU5jFbKAycN9OaiO+C0wC6uGtsd0vcMskWn4hFn3ztoPUNvYGm2aSK/sU8vjPAjB0fhyxaullxTp8dRE86ekNaiLOxiXvYSmTx5GBinbEWzh2Dhq/VcaDlot6AhuIgbos2tFfm5qqN+epg= Received: by 10.48.237.12 with SMTP id k12mr25756nfh; Wed, 20 Jul 2005 09:31:10 -0700 (PDT) Received: by 10.48.247.19 with HTTP; Wed, 20 Jul 2005 09:31:10 -0700 (PDT) Message-ID: <9e31186f05072009313233c5c6@mail.gmail.com> Date: Wed, 20 Jul 2005 18:31:10 +0200 From: Carlos Garcia Braschi To: rtg-bfd@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Subject: I-D ACTION:draft-ietf-bfd-generic-00.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Carlos Garcia Braschi List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi, Reading the generic document, I now have a doubt: shouldn't mentions to OSPF and IS-IS in the 1-hop draft go in a separate "IGP application document" or "OSPF / ISIS application document"? Most of the content is not related to the 1hop functionality but rather with BFD-protocol interactions, including Graceful restart. Or perhaps, as another example in the generic draft? For example, the Graceful restart mentioned in the 1hop draft, is probably applicable to all protocols that have Graceful restart (as BGP), not only to IGPs. I know it is a non negligible amount of editorial work, but will probably lay out a clear structure for the BFD standards... that, with the count already up to more than four drafts for BFD, may be a good thing. (or not, it probably depends). Regards, Carlos. 2005/7/16, rtg-bfd-request@ietf.org : > Date: Fri, 15 Jul 2005 15:50:02 -0400 > From: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-ietf-bfd-generic-00.txt > To: i-d-announce@ietf.org > Cc: rtg-bfd@ietf.org > Message-ID: > Content-Type: text/plain; charset=3D"us-ascii" >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Bidirectional Forwarding Detection Worki= ng Group of the IETF. >=20 > Title : Generic Application of BFD > Author(s) : D. Katz, D. Ward > Filename : draft-ietf-bfd-generic-00.txt > Pages : 7 > Date : 2005-7-15 >=20 > This document describes the generic application of the Bidirectional > Forwarding Detection (BFD) protocol in environments not specifically > documented in other specifications. Comments on this draft should be > directed to rtg-bfd@ietf.org. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-bfd-generic-00.txt >=20 > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of th= e message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login with the usern= ame > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-bfd-generic-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From rtg-bfd-bounces@ietf.org Wed Jul 20 22:43:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvR2O-0003BV-Mr; Wed, 20 Jul 2005 22:43:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvR2M-0003Ah-37 for rtg-bfd@megatron.ietf.org; Wed, 20 Jul 2005 22:43:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01032 for ; Wed, 20 Jul 2005 22:43:47 -0400 (EDT) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvRWH-0001RE-Hn for rtg-bfd@ietf.org; Wed, 20 Jul 2005 23:14:47 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJY0034AI6WR6@szxga02-in.huawei.com> for rtg-bfd@ietf.org; Thu, 21 Jul 2005 10:42:33 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJY0096HI6W0M@szxga02-in.huawei.com> for rtg-bfd@ietf.org; Thu, 21 Jul 2005 10:42:32 +0800 (CST) Received: from z11024 ([10.110.100.95]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IJY00KCQIBYTN@szxml01-in.huawei.com>; Thu, 21 Jul 2005 10:45:34 +0800 (CST) Date: Thu, 21 Jul 2005 10:36:48 +0800 From: Suping Zhai To: Carlos Garcia Braschi , bfd Message-id: <0IJY00KCRIBYTN@szxml01-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7BIT Cc: Subject: Re: I-D ACTION:draft-ietf-bfd-generic-00.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zhaisuping@huawei.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Carlos, I am sympathy with you regarding this generic draft. And more I think that it's better if all the BFD related applications including IGP, BGP, MPLS and static routes can go together into one draft. And another note, in this draft section 2, it reads as followings, The service interface with BFD is straightforward. The application supplies session parameters (neighbor address, time parameters, protocol options), and BFD provides the session state, of which the most interesting transitions are to and from the Up state. The application is expected to bootstrap the BFD session, as BFD has no discovery mechanism. Perhaps, the session paramters of time parameters is the responsiblity of BFD session its self, not supplied by application. I dont' what's opinions? Regards, suping >Hi, > >Reading the generic document, I now have a doubt: shouldn't mentions >to OSPF and IS-IS in the 1-hop draft go in a separate "IGP application >document" or "OSPF / ISIS application document"? Most of the content >is not related to the 1hop functionality but rather with BFD-protocol >interactions, including Graceful restart. > >Or perhaps, as another example in the generic draft? > >For example, the Graceful restart mentioned in the 1hop draft, is >probably applicable to all protocols that have Graceful restart (as >BGP), not only to IGPs. > >I know it is a non negligible amount of editorial work, but will >probably lay out a clear structure for the BFD standards... that, with >the count already up to more than four drafts for BFD, may be a good >thing. (or not, it probably depends). > >Regards, >Carlos. > >2005/7/16, rtg-bfd-request@ietf.org : >> Date: Fri, 15 Jul 2005 15:50:02 -0400 >> From: Internet-Drafts@ietf.org >> Subject: I-D ACTION:draft-ietf-bfd-generic-00.txt >> To: i-d-announce@ietf.org >> Cc: rtg-bfd@ietf.org >> Message-ID: >> Content-Type: text/plain; charset="us-ascii" >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. >> >> Title : Generic Application of BFD >> Author(s) : D. Katz, D. Ward >> Filename : draft-ietf-bfd-generic-00.txt >> Pages : 7 >> Date : 2005-7-15 >> >> This document describes the generic application of the Bidirectional >> Forwarding Detection (BFD) protocol in environments not specifically >> documented in other specifications. Comments on this draft should be >> directed to rtg-bfd@ietf.org. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-bfd-generic-00.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> >> Internet-Drafts are also available by anonymous FTP. Login with the username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-ietf-bfd-generic-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> From rtg-bfd-bounces@ietf.org Fri Jul 22 16:27:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw47S-0007s9-OE; Fri, 22 Jul 2005 16:27:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw47S-0007s4-1p for rtg-bfd@megatron.ietf.org; Fri, 22 Jul 2005 16:27:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24092 for ; Fri, 22 Jul 2005 16:27:39 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw4bk-00072k-RY for rtg-bfd@ietf.org; Fri, 22 Jul 2005 16:59:01 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 22 Jul 2005 13:27:26 -0700 X-IronPort-AV: i="3.95,135,1120460400"; d="scan'208"; a="200065429:sNHT35368074" Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6MKRGul025665; Fri, 22 Jul 2005 13:27:16 -0700 (PDT) Received: (from wardd@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id PAA13327; Fri, 22 Jul 2005 15:27:17 -0500 (CDT) Date: Fri, 22 Jul 2005 15:27:17 -0500 From: David Ward To: Suping Zhai Message-ID: <20050722152717.N9707@cfcentral.cisco.com> References: <0IJY00KCRIBYTN@szxml01-in.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0IJY00KCRIBYTN@szxml01-in.huawei.com>; from zhaisuping@huawei.com on Thu, Jul 21, 2005 at 10:36:48AM +0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: bfd , Carlos Garcia Braschi Subject: Re: I-D ACTION:draft-ietf-bfd-generic-00.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org All - We have left the 1-hop (w/ IGP examples) and generic draft as agreed at the last two WG meetings. There is no real benefit (as discussed) to mentioning each and every app that could bootstrap a BFD session, we would never standardize the doc as new ones are creeping up every day. Since the base spec and 1-hop are in LC (again as agreed by the WG), I recommend we don't reopen this can of worms. more down below. On Thu, Jul 21, 2005 at 10:36:48AM +0800, Suping Zhai wrote: > Hi Carlos, > I am sympathy with you regarding this generic draft. > And more I think that it's better if all the BFD related applications including IGP, BGP, MPLS and static routes can go together into one draft. > > And another note, in this draft section 2, it reads as followings, > The service interface with BFD is straightforward. The application > supplies session parameters (neighbor address, time parameters, > protocol options), and BFD provides the session state, of which the > most interesting transitions are to and from the Up state. The > application is expected to bootstrap the BFD session, as BFD has no > discovery mechanism. > > > Perhaps, the session paramters of time parameters is the responsiblity of BFD session its self, not supplied by application. I don't see how this is possible. BFD checks the forwarding plane created by other applications. Those applications are requesting from BFD the fast notification of a failure. Since BFD doesn't setup the forwarding plane, it should bootstrap itself. -DWard > > I dont' what's opinions? > > Regards, > suping > >Hi, > > > >Reading the generic document, I now have a doubt: shouldn't mentions > >to OSPF and IS-IS in the 1-hop draft go in a separate "IGP application > >document" or "OSPF / ISIS application document"? Most of the content > >is not related to the 1hop functionality but rather with BFD-protocol > >interactions, including Graceful restart. > > > >Or perhaps, as another example in the generic draft? > > > >For example, the Graceful restart mentioned in the 1hop draft, is > >probably applicable to all protocols that have Graceful restart (as > >BGP), not only to IGPs. > > > >I know it is a non negligible amount of editorial work, but will > >probably lay out a clear structure for the BFD standards... that, with > >the count already up to more than four drafts for BFD, may be a good > >thing. (or not, it probably depends). > > > >Regards, > >Carlos. > > > >2005/7/16, rtg-bfd-request@ietf.org : > >> Date: Fri, 15 Jul 2005 15:50:02 -0400 > >> From: Internet-Drafts@ietf.org > >> Subject: I-D ACTION:draft-ietf-bfd-generic-00.txt > >> To: i-d-announce@ietf.org > >> Cc: rtg-bfd@ietf.org > >> Message-ID: > >> Content-Type: text/plain; charset="us-ascii" > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. > >> This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. > >> > >> Title : Generic Application of BFD > >> Author(s) : D. Katz, D. Ward > >> Filename : draft-ietf-bfd-generic-00.txt > >> Pages : 7 > >> Date : 2005-7-15 > >> > >> This document describes the generic application of the Bidirectional > >> Forwarding Detection (BFD) protocol in environments not specifically > >> documented in other specifications. Comments on this draft should be > >> directed to rtg-bfd@ietf.org. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-ietf-bfd-generic-00.txt > >> > >> To remove yourself from the I-D Announcement list, send a message to > >> i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > >> to change your subscription settings. > >> > >> > >> Internet-Drafts are also available by anonymous FTP. Login with the username > >> "anonymous" and a password of your e-mail address. After logging in, > >> type "cd internet-drafts" and then > >> "get draft-ietf-bfd-generic-00.txt". > >> > >> A list of Internet-Drafts directories can be found in > >> http://www.ietf.org/shadow.html > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> From rtg-bfd-bounces@ietf.org Fri Jul 22 23:01:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwAGo-0004qf-Ri; Fri, 22 Jul 2005 23:01:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwAGo-0004qa-1g for rtg-bfd@megatron.ietf.org; Fri, 22 Jul 2005 23:01:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02409 for ; Fri, 22 Jul 2005 23:01:43 -0400 (EDT) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwAl9-0003og-Oa for rtg-bfd@ietf.org; Fri, 22 Jul 2005 23:33:08 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IK200BPA8JQUC@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Sat, 23 Jul 2005 11:04:38 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IK200BY58JQRF@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Sat, 23 Jul 2005 11:04:38 +0800 (CST) Received: from z11024 ([10.110.100.95]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IK200GTT8U6H9@szxml01-in.huawei.com>; Sat, 23 Jul 2005 11:10:54 +0800 (CST) Date: Sat, 23 Jul 2005 11:02:06 +0800 From: Suping Zhai To: David Ward , bfd Message-id: <0IK200GTU8U6H9@szxml01-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7BIT Cc: Subject: Re: Re: I-D ACTION:draft-ietf-bfd-generic-00.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zhaisuping@huawei.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Dear David, Some clarification inline, please see below. >All - > >We have left the 1-hop (w/ IGP examples) and generic draft as agreed at >the last two WG meetings. There is no real benefit (as discussed) to mentioning >each and every app that could bootstrap a BFD session, we would never >standardize the doc as new ones are creeping up every day. Since the >base spec and 1-hop are in LC (again as agreed by the WG), I recommend >we don't reopen this can of worms. Geting together all the applications together is just a idea, perhaps it is difficult to realize:) No problem. > >more down below. > >On Thu, Jul 21, 2005 at 10:36:48AM +0800, Suping Zhai wrote: >> Hi Carlos, >> I am sympathy with you regarding this generic draft. >> And more I think that it's better if all the BFD related applications including IGP, BGP, MPLS and static routes can go together into one draft. >> >> And another note, in this draft section 2, it reads as followings, >> The service interface with BFD is straightforward. The application >> supplies session parameters (neighbor address, time parameters, >> protocol options), and BFD provides the session state, of which the >> most interesting transitions are to and from the Up state. The >> application is expected to bootstrap the BFD session, as BFD has no >> discovery mechanism. >> >> >> Perhaps, the session paramters of time parameters is the responsiblity of BFD session its self, not supplied by application. > > >I don't see how this is possible. BFD checks the forwarding plane created >by other applications. Those applications are requesting from BFD the >fast notification of a failure. Since BFD doesn't setup the forwarding plane, >it should bootstrap itself. First, I mean that the time parameters is negotiated by the BFD session, not supplied by the applicatons. Second, what does it mean by the last line above---"since BFD doesn't setup the forwarding plane, it should bootstrap ***itself***"??? Suping > >-DWard > >> >> I dont' what's opinions? >> >> Regards, >> suping >> >Hi, >> > >> >Reading the generic document, I now have a doubt: shouldn't mentions >> >to OSPF and IS-IS in the 1-hop draft go in a separate "IGP application >> >document" or "OSPF / ISIS application document"? Most of the content >> >is not related to the 1hop functionality but rather with BFD-protocol >> >interactions, including Graceful restart. >> > >> >Or perhaps, as another example in the generic draft? >> > >> >For example, the Graceful restart mentioned in the 1hop draft, is >> >probably applicable to all protocols that have Graceful restart (as >> >BGP), not only to IGPs. >> > >> >I know it is a non negligible amount of editorial work, but will >> >probably lay out a clear structure for the BFD standards... that, with >> >the count already up to more than four drafts for BFD, may be a good >> >thing. (or not, it probably depends). >> > >> >Regards, >> >Carlos. >> > >> >2005/7/16, rtg-bfd-request@ietf.org : >> >> Date: Fri, 15 Jul 2005 15:50:02 -0400 >> >> From: Internet-Drafts@ietf.org >> >> Subject: I-D ACTION:draft-ietf-bfd-generic-00.txt >> >> To: i-d-announce@ietf.org >> >> Cc: rtg-bfd@ietf.org >> >> Message-ID: >> >> Content-Type: text/plain; charset="us-ascii" >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. >> >> >> >> Title : Generic Application of BFD >> >> Author(s) : D. Katz, D. Ward >> >> Filename : draft-ietf-bfd-generic-00.txt >> >> Pages : 7 >> >> Date : 2005-7-15 >> >> >> >> This document describes the generic application of the Bidirectional >> >> Forwarding Detection (BFD) protocol in environments not specifically >> >> documented in other specifications. Comments on this draft should be >> >> directed to rtg-bfd@ietf.org. >> >> >> >> A URL for this Internet-Draft is: >> >> http://www.ietf.org/internet-drafts/draft-ietf-bfd-generic-00.txt >> >> >> >> To remove yourself from the I-D Announcement list, send a message to >> >> i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >> >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >> >> to change your subscription settings. >> >> >> >> >> >> Internet-Drafts are also available by anonymous FTP. Login with the username >> >> "anonymous" and a password of your e-mail address. After logging in, >> >> type "cd internet-drafts" and then >> >> "get draft-ietf-bfd-generic-00.txt". >> >> >> >> A list of Internet-Drafts directories can be found in >> >> http://www.ietf.org/shadow.html >> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> From rtg-bfd-bounces@ietf.org Sun Jul 24 18:17:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwomx-0003yb-0Y; Sun, 24 Jul 2005 18:17:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwomv-0003yT-7L for rtg-bfd@megatron.ietf.org; Sun, 24 Jul 2005 18:17:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29948 for ; Sun, 24 Jul 2005 18:17:34 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwpHd-00082U-Kz for rtg-bfd@ietf.org; Sun, 24 Jul 2005 18:49:22 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 24 Jul 2005 15:17:27 -0700 X-IronPort-AV: i="3.95,138,1120460400"; d="scan'208"; a="200269697:sNHT30339322" Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j6OMHO6p028120; Sun, 24 Jul 2005 15:17:24 -0700 (PDT) Received: (from wardd@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA18713; Sun, 24 Jul 2005 17:17:22 -0500 (CDT) Date: Sun, 24 Jul 2005 17:17:22 -0500 From: David Ward To: Suping Zhai Message-ID: <20050724171722.G17755@cfcentral.cisco.com> References: <0IK200GTU8U6H9@szxml01-in.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0IK200GTU8U6H9@szxml01-in.huawei.com>; from zhaisuping@huawei.com on Sat, Jul 23, 2005 at 11:02:06AM +0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: bfd , David Ward Subject: Re: Re: I-D ACTION:draft-ietf-bfd-generic-00.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Suping - On Sat, Jul 23, 2005 at 11:02:06AM +0800, Suping Zhai wrote: ...snip.. > > > > > >I don't see how this is possible. BFD checks the forwarding plane created > >by other applications. Those applications are requesting from BFD the > >fast notification of a failure. Since BFD doesn't setup the forwarding plane, > >it should bootstrap itself. > > > First, I mean that the time parameters is negotiated by the BFD session, not supplied by the applicatons. The time parameters should be defined by config. Either via template, by the bootstrapping app, etc. I don't think I see an issue but, I might be still missing your point. > Second, what does it mean by the last line above---"since BFD doesn't setup the forwarding plane, it should bootstrap ***itself***"??? It should be negative ... "should NOT bootstrap itself." Sorry for the confusion. -DWard From rtg-bfd-bounces@ietf.org Mon Jul 25 00:13:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwuIt-0005Tj-4v; Mon, 25 Jul 2005 00:10:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwuIs-0005TZ-8W for rtg-bfd@megatron.ietf.org; Mon, 25 Jul 2005 00:10:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20654 for ; Mon, 25 Jul 2005 00:10:54 -0400 (EDT) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwune-0000j1-1a for rtg-bfd@ietf.org; Mon, 25 Jul 2005 00:42:46 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IK6003M517XO2@szxga02-in.huawei.com> for rtg-bfd@ietf.org; Mon, 25 Jul 2005 12:16:46 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IK60007A17XDH@szxga02-in.huawei.com> for rtg-bfd@ietf.org; Mon, 25 Jul 2005 12:16:45 +0800 (CST) Received: from z11024 ([10.110.100.95]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IK600CRL17R34@szxml02-in.huawei.com>; Mon, 25 Jul 2005 12:16:40 +0800 (CST) Date: Mon, 25 Jul 2005 12:10:56 +0800 From: Suping Zhai To: David Ward , bfd Message-id: <0IK600CRM17S34@szxml02-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7BIT Cc: Subject: Re: Re: Re: I-D ACTION:draft-ietf-bfd-generic-00.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zhaisuping@huawei.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org David, Please see the inline below. >Suping - > >On Sat, Jul 23, 2005 at 11:02:06AM +0800, Suping Zhai wrote: >....snip.. > >> > >> > >> >I don't see how this is possible. BFD checks the forwarding plane created >> >by other applications. Those applications are requesting from BFD the >> >fast notification of a failure. Since BFD doesn't setup the forwarding plane, >> >it should bootstrap itself. >> >> >> First, I mean that the time parameters is negotiated by the BFD session, not supplied by the applicatons. > > >The time parameters should be defined by config. Either via template, by the >bootstrapping app, etc. I don't think I see an issue but, I might be still > missing your point. Yes, the time paramters are defined by config. But in the BFD session, time parameters could be changed during the negotiation. Perhaps it's more clear to add some description like "....and BFD provides the **parameters negotiation** and the session state, of which the most interesting transitions are to and from the Up state." --That's my point. Suping > > >> Second, what does it mean by the last line above---"since BFD doesn't setup the forwarding plane, it should bootstrap ***itself***"??? > > >It should be negative ... "should NOT bootstrap itself." Sorry for the >confusion. > >-DWard