From nobody Tue Jul 1 00:03:57 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689D41B27D6 for ; Tue, 1 Jul 2014 00:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOLiGIyGt3aa for ; Tue, 1 Jul 2014 00:03:52 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 883C21B27CA for ; Tue, 1 Jul 2014 00:03:52 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 4E27B2AA0F; Tue, 1 Jul 2014 07:03:50 +0000 (GMT) Date: Tue, 1 Jul 2014 00:03:50 -0700 From: Marc Binderberger To: Jeffrey Haas , Ashesh Mishra Message-ID: <20140701000350717396.6223fff1@sniff.de> In-Reply-To: <20140701030851.GB23688@pfrc> References: <20140630233047.16868.79679.idtracker@ietfa.amsl.com> <20140701030851.GB23688@pfrc> Subject: Re: New Version Notification for draft-ashesh-bfd-stability-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/celum5tM4uhZZZmbB36zbr2lGUg Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 07:03:54 -0000 Hello Jeff, Ashesh et al., > - Declaring defeat and creating BFDv2. hehe ... why did this come to my mind when I was reading the draft. But then my appetite for v2 is well known ;-) It's another example that we have discussions on overload "tricks" with all it's potential problems instead of discussing if an idea is viable, if it solves a real problem etc.. Anyway, what I take from the draft is this: having a sequence number in the BFD packet is a very useful thing to detect packet loss and distinguish a transmission delay increase from a lost packet. If we ever create BFDv2 this may be something to keep in mind. For the timestamps my question would be: do we really need them in the BFD packet? Any delay or variation of delay in the transmission or receiver engine is something I would have expected to be a local statistics. Why is e.g. the transmission delay of interest for the receiver? Not saying these statistics are not relevant, they are. Locally. Thanks & Regards, Marc On Mon, 30 Jun 2014 23:08:51 -0400, Jeffrey Haas wrote: > Manav, > > On Tue, Jul 01, 2014 at 06:12:41AM +0530, Manav Bhatia wrote: >> Security Considerations says: >> >> Since this method uses an authentication TLV to achive the >> functionality, usage of this TLV will prevent the use of other >> authentication TLVs. >> >> This is not acceptable. I would not like to see any proposal that >> precludes the possibility of adding authentication later -- your >> design stands on tenuous grounds as soon as you say this. > > Exactly how well that survives the sieve of real-world deployment of > authentication is itself somewhat tenuous grounds. :-) > > But your point about making this feature work with actual authentication is > work they've identified needing help. I suspect you'll have opinions on > that. > >> BTW, i dont feel great about overloading the authentication TLV with >> information thats completely unrelated to authentication. This breaks >> all HW that looks at this TLV and sends it for some special >> processing. You now require HW to peek deeper inside the TLV to know >> if its something that this would interest it or not. > > The authors of this draft were suggested to come together to work on this > since they all had very similar ideas for the feature. The observation that > has lead to part of the current design is that the sequence number semantics > needed for the feature are largely carried already through meticulous > authentiction sequence numbering. > > At the end of the day, if we eliminated the additional fields, kept some > well known but inexpensive authentication (such as null or password) and > simply collected statistics related to expected packet presence based on > rates and jitter it woudl be possible to derive some amount of loss and > lantency statistics. > > The addition of time stamping for additional work seemed to be another > common factor in each of the suggested designs. > > Keeping with BFDv1 problematically means one of three likely designs for > such a feature: > - Overload something like authentication. > - Packing the additional data after the BFD packet. (There is room in the > spec for this, but depending on how pedantically someone implements it or > not may result in the additional data not getting through.) > - Declaring defeat and creating BFDv2. > > My push, as is well known on the list, is "can we do this without becoming > backwardly incompatible". Some day we will. Is that today? Let's find > out! > > -- Jeff > From nobody Tue Jul 1 00:17:48 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE8D1A0183 for ; Tue, 1 Jul 2014 00:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSib10DrsXAw for ; Tue, 1 Jul 2014 00:17:45 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 170681A017D for ; Tue, 1 Jul 2014 00:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12867; q=dns/txt; s=iport; t=1404199065; x=1405408665; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=kBVGjVa5Ijhv9nOWF+fxlsxf7y1/4hH/RIFAKIcMuw4=; b=UedFEP0ILJbvBwhtz4IJfer6PYB8vAUQem6qX5YLCLc1+WSXfTh+UGdp pBj/TJ202S8aosBrX3SMZDAz7sJfPwxNGUGi74mKLgJVVs1af2uHVLLNe AS62zaalfSYjvVgWv34DA0EzfTxMI1dJI2IUvfuve7LHahTsKGgjsdD3P A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskFAJRfslOtJV2Y/2dsb2JhbABagkZHgSyrJgEBAQEBAQUBbgGZSwGBCRZ1hAMBAgRnDQMCEgEIEQMBAhYDDyYTFAkIAgQBDQWILgMRwUAYhhoXhWSJEhEHCg6EKwEEkCWKPJN/g0KCMA X-IronPort-AV: E=Sophos; i="5.01,580,1400025600"; d="scan'208,217"; a="57346747" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP; 01 Jul 2014 07:17:44 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s617HiYb016641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Jul 2014 07:17:44 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.63]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 1 Jul 2014 02:17:43 -0500 From: "MALLIK MUDIGONDA (mmudigon)" To: Marc Binderberger , Jeffrey Haas , "Ashesh Mishra" Subject: Re: New Version Notification for draft-ashesh-bfd-stability-00.txt Thread-Topic: New Version Notification for draft-ashesh-bfd-stability-00.txt Thread-Index: AQHPlMGDTNnsPAVT7Eq8kxcoYOGi1ZuKtQmAgAAo1oCAAEGoAIAAYA+A Date: Tue, 1 Jul 2014 07:17:42 +0000 Message-ID: In-Reply-To: <20140701000350717396.6223fff1@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.26.92] Content-Type: multipart/alternative; boundary="_000_CFD85D12222BCmmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/JkorfqmOwmdfBrtuHAXJxf6ySe8 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 07:17:47 -0000 --_000_CFD85D12222BCmmudigonciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Marc, Replies inline Thanks Regards Mallik From: Marc Binderberger > Date: Tuesday 1 July 2014 12:33 PM To: Jeffrey Haas >, Ashesh Mishra > Cc: "rtg-bfd@ietf.org" > Subject: Re: New Version Notification for draft-ashesh-bfd-stability-00.txt Hello Jeff, Ashesh et al., - Declaring defeat and creating BFDv2. hehe ... why did this come to my mind when I was reading the draft. But the= n my appetite for v2 is well known ;-) It's another example that we have discussions on overload "tricks" with all it's potential problems instead of discussing if an idea is viable, if it solves a real problem etc.. Anyway, what I take from the draft is this: having a sequence number in the BFD packet is a very useful thing to detect packet loss and distinguish a transmission delay increase from a lost packet. If we ever create BFDv2 thi= s may be something to keep in mind. Mallik>> Sure, will do if we reach that stage. For the timestamps my question would be: do we really need them in the BFD packet? Any delay or variation of delay in the transmission or receiver engine is something I would have expected to be a local statistics. Why is e.g. the transmission delay of interest for the receiver? Mallik>> The idea behind these timers is to ensure that the BFD interval co= nfigurations on the peers take into account these delays so that BFD sessio= ns do not flap and cause network churn. I understand these delays may be tr= ansient events, but giving the operator this delay information so that he c= onfigures proper intervals at BFD level. Not saying these statistics are not relevant, they are. Locally. Mallik>> Yes the delays are local, but a Tx delay on the sender side may re= sult in the receiver not receiving the packets on time. Thanks & Regards, Marc On Mon, 30 Jun 2014 23:08:51 -0400, Jeffrey Haas wrote: Manav, On Tue, Jul 01, 2014 at 06:12:41AM +0530, Manav Bhatia wrote: Security Considerations says: Since this method uses an authentication TLV to achive the functionality, usage of this TLV will prevent the use of other authentication TLVs. This is not acceptable. I would not like to see any proposal that precludes the possibility of adding authentication later -- your design stands on tenuous grounds as soon as you say this. Exactly how well that survives the sieve of real-world deployment of authentication is itself somewhat tenuous grounds. :-) But your point about making this feature work with actual authentication is work they've identified needing help. I suspect you'll have opinions on that. BTW, i dont feel great about overloading the authentication TLV with information thats completely unrelated to authentication. This breaks all HW that looks at this TLV and sends it for some special processing. You now require HW to peek deeper inside the TLV to know if its something that this would interest it or not. The authors of this draft were suggested to come together to work on this since they all had very similar ideas for the feature. The observation tha= t has lead to part of the current design is that the sequence number semantic= s needed for the feature are largely carried already through meticulous authentiction sequence numbering. At the end of the day, if we eliminated the additional fields, kept some well known but inexpensive authentication (such as null or password) and simply collected statistics related to expected packet presence based on rates and jitter it woudl be possible to derive some amount of loss and lantency statistics. The addition of time stamping for additional work seemed to be another common factor in each of the suggested designs. Keeping with BFDv1 problematically means one of three likely designs for such a feature: - Overload something like authentication. - Packing the additional data after the BFD packet. (There is room in the spec for this, but depending on how pedantically someone implements it o= r not may result in the additional data not getting through.) - Declaring defeat and creating BFDv2. My push, as is well known on the list, is "can we do this without becoming backwardly incompatible". Some day we will. Is that today? Let's find out! -- Jeff --_000_CFD85D12222BCmmudigonciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Marc,

Replies inline

Thanks

Regards
Mallik

From: Marc Binderberger <marc@sniff.de>
Date: Tuesday 1 July 2014 12:33 PM<= br> To: Jeffrey Haas <jhaas@pfrc.org>, Ashesh Mishra <mishra.ashesh@outlook.com>
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: New Version Notificati= on for draft-ashesh-bfd-stability-00.txt

Hello Jeff, Ashesh et al.,

- Declaring defeat and creating BFDv2.

hehe ... why did this come to my mind when I was reading the draft. Bu= t then
my appetite for v2 is well known ;-)

It's another example that we have discussions on overload "tricks= " with all
it's potential problems instead of discussing if an idea is viable, if= it
solves a real problem etc..


Anyway, what I take from the draft is this: having a sequence number i= n the
BFD packet is a very useful thing to detect packet loss and distinguis= h a
transmission delay increase from a lost packet. If we ever create BFDv= 2 this
may be something to keep in mind.

Mallik>> Sure, will do if we reach that stage.

For the timestamps my question would be: do we really need them in the= BFD
packet?   Any delay or variation of delay in the transmissio= n or receiver
engine is something I would have expected to be a local statistics. Wh= y is
e.g. the transmission delay of interest for the receiver?

Mallik>> The idea behind these timers is to ensure that the BFD = interval configurations on the peers take into account these delays so that= BFD sessions do not flap and cause network churn. I understand these delay= s may be transient events, but giving the operator this delay information so that he configures proper intervals= at BFD level. 

Not saying these statistics are not relevant, they are. Locally.

Mallik>> Yes the delays are local, but a Tx delay on the sender = side may result in the receiver not receiving the packets on time. 


Thanks & Regards,
Marc



On Mon, 30 Jun 2014 23:08:51 -0400, Jeffrey Haas wrote:
Manav,
On Tue, Jul 01, 2014 at 06:12:41AM +0530, Manav Bhatia wrote:
Security Considerations says:
    Since this method uses an authentication TLV t= o achive the
    functionality, usage of this TLV will prevent = the use of other
    authentication TLVs.
This is not acceptable. I would not like to see any proposal that
precludes the possibility of adding authentication later -- your
design stands on tenuous grounds as soon as you say this.
Exactly how well that survives the sieve of real-world deployment of
authentication is itself somewhat tenuous grounds. :-)
But your point about making this feature work with actual authenticati= on is
work they've identified needing help.  I suspect you'll have= opinions on
that.
BTW, i dont feel great about overloading the authentication TLV with
information thats completely unrelated to authentication. This breaks<= /div>
all HW that looks at this TLV and sends it for some special
processing. You now require HW to peek deeper inside the TLV to know
if its something that this would interest it or not.
The authors of this draft were suggested to come together to work on t= his
since they all had very similar ideas for the feature.  The = observation that
has lead to part of the current design is that the sequence number sem= antics
needed for the feature are largely carried already through meticulous<= /div>
authentiction sequence numbering.  
At the end of the day, if we eliminated the additional fields, kept so= me
well known but inexpensive authentication (such as null or password) a= nd
simply collected statistics related to expected packet presence based = on
rates and jitter it woudl be possible to derive some amount of loss an= d
lantency statistics.  
The addition of time stamping for additional work seemed to be another=
common factor in each of the suggested designs.
Keeping with BFDv1 problematically means one of three likely designs f= or
such a feature:
- Overload something like authentication.
- Packing the additional data after the BFD packet.  (There = is room in the
   spec for this, but depending on how pedantically someone = implements it or
   not may result in the additional data not getting through= .)
- Declaring defeat and creating BFDv2.
My push, as is well known on the list, is "can we do this without= becoming
backwardly incompatible".  Some day we will.  = ;Is that today?  Let's find
out!
-- Jeff


 --_000_CFD85D12222BCmmudigonciscocom_-- From nobody Tue Jul 1 00:30:35 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AF71A0190 for ; Tue, 1 Jul 2014 00:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xu_6P9Ktzmfm for ; Tue, 1 Jul 2014 00:30:31 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CEDB1A017D for ; Tue, 1 Jul 2014 00:30:31 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-c0-53b211c3e25c Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 85.31.05330.3C112B35; Tue, 1 Jul 2014 03:41:23 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Tue, 1 Jul 2014 03:30:28 -0400 From: Gregory Mirsky To: Jeffrey Haas Subject: RE: New Version Notification for draft-ashesh-bfd-stability-00.txt Thread-Topic: New Version Notification for draft-ashesh-bfd-stability-00.txt Thread-Index: AQHPlMGByMDiCCAb4ku6kaYC2EX7mpuKZhIAgABk0QCAAAcSkA== Date: Tue, 1 Jul 2014 07:30:28 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7E4C1C@eusaamb103.ericsson.se> References: <20140630233047.16868.79679.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B7E4A81@eusaamb103.ericsson.se> <20140701030054.GA23688@pfrc> In-Reply-To: <20140701030054.GA23688@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyuXRPoO5hwU3BBk/3iFrsP/iW1WJW2xRW i89/tjE6MHssWfKTyWPz6xfMHpd7t7IGMEdx2aSk5mSWpRbp2yVwZbzc+4qxYDZPRfs6rgbG r5xdjJwcEgImEpNvzmeCsMUkLtxbz9bFyMUhJHCUUaKprZkVJCEksIxRov2VJYjNJmAk8WJj DzuILSKgKDH/fydQAwcHs0CYxJseaZCwsIC3RPvRnSwQJT4S799uYYKwnSSW3G4HG8kioCLx 6GYHG4jNK+Ar8e3dTGaIvXOYJPZOPsUCMpNTQEuiZxPYWkag276fWgM2h1lAXOLWE5ibBSSW 7DnPDGGLSrx8/I8VwlaSmPP6GjNEvY7Egt2f2CBsbYllC18zQ+wVlDg58wnLBEaxWUjGzkLS MgtJyywkLQsYWVYxcpQWp5blphsZbGIERs0xCTbdHYx7XloeYhTgYFTi4VUw3RgsxJpYVlyZ e4hRmoNFSZx3Vu28YCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MJr9WpW4LC+vher74rVOG tti2JY5Z4lkRhlmzLlXxTlaMX27oH/nH9+Y0runhEWY+cbFzXNdrNX6e/WSnsZwKo+SUDd12 qh0R7W5zfC++nnj6yvW487N5Xef4FLhd+Z0VMafB/X3CZrvluxTytl7rFHsytZfPJ7SyL8lY OK5rdczVhjuttj5KLMUZiYZazEXFiQAMxyeLewIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/etA-JlrejfkvRP9QZ-2SK4JtNmc Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 07:30:33 -0000 Hi Jeff, I'll follow your advice and will collect my patience to see development of = this proposal in the coming days. And I'd strongly encourage authors to illustrate the solution with use-case= (s) that will highlight the stated in the document problem. Regards, Greg -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org]=20 Sent: Monday, June 30, 2014 8:01 PM To: Gregory Mirsky Cc: Ashesh Mishra; rtg-bfd@ietf.org Subject: Re: New Version Notification for draft-ashesh-bfd-stability-00.txt Greg, On Tue, Jul 01, 2014 at 01:09:12AM +0000, Gregory Mirsky wrote: > Hi Ashesh, > I'm not convinced that the goal stated in the document as quantify instab= ility of the BFD control messages through measurement of inter-packet, a.k.= a. inter-frame gap is relevant to BFD. Note, that interval between BFD cont= rol messages, according to RFC 5880 is jittered, i.e. randomized, as descri= bed in Section 6.8.7 RFC 5880. >=20 > Though it may be tempting to add performance measurements on top of BFD t= here are already OWAMP/TWAMP for IP PM and MPLS Packet Loss and Packet Dela= y Measurement RFCs to use for measuring performance metrics. The guidance given to the various authors of this effort was firmly to avoi= d trying to replace existing L2 OAM technologies. I suspect that their suc= cess in doing so will show itself over the coming days. This said, the mechanism described does have enough information given the e= xpected jitter to help determine some amount of the packet timing. -- Jeff From nobody Tue Jul 1 07:32:43 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF6B1B27F7 for ; Tue, 1 Jul 2014 07:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSvNwPHrFsT8 for ; Tue, 1 Jul 2014 07:32:39 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAE091B27F6 for ; Tue, 1 Jul 2014 07:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16936; q=dns/txt; s=iport; t=1404225158; x=1405434758; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FwcVZa/A2J/y+kXHdHqj5+rsVLRJOV+nLMa7ln8mp0I=; b=lKzAyUZXTb2U+qGhkPce2ydRb5rjKp5F5z22Ohte8BVQQV8/gNUcxJmM ixd5wMySmF/hQ2x/2yMK6Ed+5HtDYBB+KCSQ0nVi0aE0vUYdeRRURFt88 6OR85uGAmqP6H7LIeW87NWS71t5QVumCL1STEGBDqFLX8rLGnqEIgWkGr k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggJAHrFslOtJA2J/2dsb2JhbABagmkkUlMHxgEBgQ0WdYQDAQEBAwE6PwwEAgEIEQQBAQEKFAkHMhQJCAIEDgUIAYgxCAEHBchCF4ljhQsxBwaDJ4EWBZwtkjuDQmyBRA X-IronPort-AV: E=Sophos;i="5.01,581,1400025600"; d="scan'208";a="57449498" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-3.cisco.com with ESMTP; 01 Jul 2014 14:32:37 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s61EWbiF032179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Jul 2014 14:32:37 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Tue, 1 Jul 2014 09:32:37 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt Thread-Topic: I-D Action: draft-ietf-bfd-seamless-base-01.txt Thread-Index: AQHPkW78JeCHvpBJ/EuFcrJj+qOrd5uEE1MA///0AsCABPuAAIABQrxwgADQbICAADHHoA== Date: Tue, 1 Jul 2014 14:32:36 +0000 Message-ID: References: <20140626182533.30391.72279.idtracker@ietfa.amsl.com> <8fe58c80d3ba4e0da4da3e82cf7677dc@BLUPR05MB755.namprd05.prod.outlook.com> <20140629152450732481.c07ee0d4@sniff.de> <20140630230555087199.19db4b6d@sniff.de> In-Reply-To: <20140630230555087199.19db4b6d@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/yIP-m_vqyMG0Twb7M_A9YexFazM Cc: "rtg-bfd@ietf.org" , "Marc Binderberger \(mbinderb\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 14:32:41 -0000 Hi Marc, > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Tuesday, July 01, 2014 2:06 AM > To: Nobo Akiya (nobo) > Cc: Santosh P K; rtg-bfd@ietf.org; Marc Binderberger (mbinderb) > Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt >=20 > Hello Nobo, >=20 > > One of the changes from draft-ietf-bfd-seamless-base-00 to > > draft-ietf-bfd-seamless-base-01 to take out all IP related procedures > > and move it over to draft-akiya-bfd-seamless-base-ip-03. Intent of the > > authors is to: >=20 > okay, so having an IP/UDP header is a fixed part of S-BFD then? It's not= as > agnostic as RFC5880 is regarding the frame around the BFD packets? >=20 > I wasn't sure about this, thus my comment. If IP/UDP is an inherent part = of S- > BFD then ... >=20 > > it would be helpful to hear "yeah above is reasonable" or "let's > > structure it this way" from you and the WG. >=20 > yeah I think it's reasonable :-) Thanks! To answer your questions above ... I believe RFC5880 focuses on the BFD header alone since ports are different= for various use of the BFD (i.e. SH, MH, MPLS). S-BFD on the other hand will have one port for all use of S-BFD, except for= IP-less case. So, except for the exception case (i.e. IP-less), current S-BFD document st= ructure is a reasonable (or not a bad) fit. Thinking more on the exception ... S-BFD-IP document has: Ed-Note: Discuss whether we want a new associated channel type for S-BFD. But perhaps we should create a separate document for IP-less. >=20 >=20 > About the state machine >=20 > > This comment looks familiar :) >=20 > I think I repeat myself ;-) but there is a reason. Nothing wrong with the= state > machine you propose but I do not see this must be part of the definition.= As > an appendix, to show S-BFD allows for other state machines than 5880, tha= t > would be educational. >=20 > As explained I prefer a more open approach, the reflector truly reflectin= g > the state as well. Your state engine is then solely driven by the initiat= or. > Just setting the state to Up on the reflector is removing this degree of > freedom, unnecessary IMHO and reducing the ability to "play" with the S- > BFD definition. >=20 > > - Move the SBFDInitiator State Machine section to appendix. >=20 > I would like that! ACK on moving the example state machine to appendix (some texts will still = be kept around in the current section). Regarding SBFDReflector reflecting the state, I do see your point. If the s= tate of received S-BFD packet is reflected by the SBFDReflector, then the S= BFDInitiator requires no FSM changes (i.e. able to re-use FSM from RFC5880)= . Although that will result in time(2 * (RTT + Tr)) for the SBFDInitiator t= o reach UP state. In reality, it actually would be time((2 * (RTT _ Tr)) + = tx_gap) where "tx_gap" is the interval between the 2 packets transmitted. I= do think one of the strength of S-BFD is the fact it only takes one packet= to complete the connectivity test. Thus I'm leaning towards standing the g= round of SBFDReflector only being able to send [UP, ADMINDOWN] states, and = not reflecting received state. >=20 > From your reply >=20 > > True, but you forgot the aspect of: > > > > BFD: > > - in case of MPLS, LSP ping bootstraps the session on egress > > - session is created > > - tx timer is started at no faster than 1 second > > > > S-BFD: > > - no LSP ping bootstrapping > > - session is created > > - packet can get tx'ed right away > > > >> From above aspect, "considerable" delay (i.e. couple of seconds) is > >> shaved off :) >=20 >=20 > What I like from your reply and what maybe should be more pointed in the > draft are exactly the aspects that make S-BFD fast. Yes, you do say it > somehow in section 3 and section 1, 2nd paragraph. Maybe a nitpick but y= ou > could talk about your design principles more explicitly. Example from > section > 3: >=20 > Required result is that applications, > on other network nodes, possess the knowledge of the mapping from > remote entities to S-BFD discriminators. >=20 > What you probably want to say is that S-BFD is requiring the distribution= of > the mapping before a session is even requested (principle: fast setup). T= hen > logically discriminators are allocated per (system, entity) and not per > session. Again, you say it somehow in the text but you actually do not > demand this principle. Make sense, let us expand a bit more on why S-BFD will result in faster set= up than BFD, in the next revision. >=20 >=20 > > Agree, this seems to be the direction we are heading, and I think it > > is reasonable. However, I (we?) do see a need for auto-foo, where foo > > may be "S-BFD discriminator allocation", "collision detection", > > "collision correction" or combination of them. >=20 > no doubt about the auto-foo but I assume this is topic for another draft?= If > so, then how can you make your S-BFD base draft working interoperable? > Thus my comment to define something very basic (manual) to have a > starting point. > Not because manual configs are so great. > (although: in these days of central controllers and software-defined > networks maybe "manual" or it's API equivalent is all that is needed :-) This is a valuable comment, and I do like your suggestion of auto-foo being= in a separate document (than base).=20 Do you think current texts in "5. S-BFD Discriminators" section is suffici= ent to imply this? Thanks! -Nobo >=20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 >=20 > On Mon, 30 Jun 2014 23:18:00 +0000, Nobo Akiya (nobo) wrote: > > Hi Marc, > > > >> -----Original Message----- > >> From: Marc Binderberger [mailto:marc@sniff.de] > >> Sent: Sunday, June 29, 2014 6:25 PM > >> To: Nobo Akiya (nobo); Santosh P K > >> Cc: rtg-bfd@ietf.org; Marc Binderberger (mbinderb) > >> Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt > >> > >> Hello Santosh and Nobo, > >> > >> good stuff. Every time I read it I find something new to learn :-) > > > > As always, thanks for comments! > > > >> > >> Re-reading the draft I had a few thoughts: > >> > >> 1) the draft is a "base" but it actually defines some details I would > >> have expected in other drafts. One example is the IP/UDP header. Yes, > >> IP is everywhere but what about applications where you don't require > >> IP ? Or the other way around: why having an extra "bfd-seamless-ip" > >> draft when IP/UDP is an essential part of the base draft? > > > > One of the changes from draft-ietf-bfd-seamless-base-00 to > > draft-ietf-bfd-seamless-base-01 to take out all IP related procedures > > and move it over to draft-akiya-bfd-seamless-base-ip-03. Intent of the > > authors is to: > > > > 1) Focus s-bfd-base on the procedures for UDP header and BFD header. > > 2) Focus s-bfd-ip on the procedures for IP header and MPLS. > > 3) Add ip-less procedures (i.e. associated channel) in either s-bfd-ip > > or create a separate draft (i.e. s-bfd-ip-less). > > 4) s-bfd-sr to be worked on at a later time. > > > > Since we are only defining one port for S-BFD, this made sense to > > those who worked on the recent changes to the S-BFD documents. > > > > Yes there are alternative ways to structure the documents. That being > > said, it would be helpful to hear "yeah above is reasonable" or "let's > > structure it this way" from you and the WG. > > > >> > >> > >> 2) similar the details of the state machine is something I think you > >> do not really need in the base draft (!). Just define the reflector > >> as truly reflecting the state from the incoming packet (plus > >> overwrite with AdminDown) and you then leave it to the initiator if > >> it uses a new state machine or the > >> 5880 Down-Init-Up sequence or something completely different. > > > > This comment looks familiar :) > > > > Texts above the state machine now says: > > > > For > > persistent SBFDInitiators, the states and the state machine describe= d > > in [RFC5880] will function but are more than necessary. The > > following diagram provides an optimized state machine for persistent > > SBFDInitiators. > > > > And after the diagram: > > > > Note that the above state machine is different from the base BFD > > specification[RFC5880]. This is because the Init state is no longer > > applicable for the SBFDInitiator. Another important difference is > > the transition of the state machine from the Down state to the Up > > state when a packet with State Up is received by the initiator. > > > > I think the texts and the described state machine is helpful for > > reader to better understand how S-BFD operates. So I prefer that this > > section remains somewhere to give better ideas to readers on how > > SBFDInitiators can be implemented. So, I think we have few options. > > > > - Texts in the s-bfd-base-01 is sufficiently reasonable. > > - Further texts should be added to make it more obvious that describe > > state machine is not mandatory. > > - Move the SBFDInitiator State Machine section to appendix. > > > > Thoughts? > > > >> > >> S-BFD is largely about the reflector, I would say. Your draft brings > >> up a good > >> point: the state machine details are not relevant for interop as long > >> as it stays within the definition of the reflector. > > > > Yes I agree. > > > >> > >> > >> 3) Actually I do not agree with statements in the draft about the > >> 5880 state machine "may not be applicable" or that your proposal is > >> better suited for the initial delay to bring BFD sessions up. Your > >> state machine requires > >> > >> RTT + Tr > >> > >> the original 5880 takes > >> > >> 2 * (RTT + Tr). > >> > >> (RTT: Round Trip Time, Tr: the processing time of the reflector) > >> > >> True, that is faster ;-) but I'm not sure you had this in mind. And > >> if > >> O(RTT+Tr) is relevant then you _do_ have a "considerable" delay too > >> and are not "seamless" anymore :-) > > > > True, but you forgot the aspect of: > > > > BFD: > > - in case of MPLS, LSP ping bootstraps the session on egress > > - session is created > > - tx timer is started at no faster than 1 second > > > > S-BFD: > > - no LSP ping bootstrapping > > - session is created > > - packet can get tx'ed right away > > > >> From above aspect, "considerable" delay (i.e. couple of seconds) is > >> shaved off :) > > > >> > >> > >> 4) The D-Flag ... forgot what I wanted to say :-) > > > > LOL, I do that often too. > > > >> 4) The D-Flag ... forgot what I wanted to say :-) > > > > LOL, I do that often too. > > > >> 4) The D-Flag ... forgot what I wanted to say :-) > > > > Wait, didn't I reply to this already? :) > > > >> Mainly, if you define the > >> behaviour you expect on the reflector then you don't need to make any > >> statements or attempts to be "5880 compliant". > > > > Agree, I don't think S-BFD is trying to be compliant with RFC5880, but > > S-BFD is trying to keep as much the same semantics possible with BFD > > so that we are not re-inventing everything. > > > >> > >> > >>> - Greatly seeking comments on how we move forward with S-BFD > >>> discriminator uniqueness requirements. > >> > >> You mean how to be unique? Or if uniqueness is necessary? > >> For the "how", I propose that a manual option to set a "unique > >> discriminator" > >> is a requirement. Does not exclude smarter, automatic methods but it > >> gets you started. > > > > Agree, this seems to be the direction we are heading, and I think it > > is reasonable. However, I (we?) do see a need for auto-foo, where foo > > may be "S-BFD discriminator allocation", "collision detection", > > "collision correction" or combination of them. > > > >> > >> Every implementation must allow to configure a unique value within > >> the least significant M bits of the discriminator. M is > >> implementation specific, recommendation is M >=3D 16. So yes, this > >> wouldn't be the router-id then but a bfd-id. Pardon, sbfd_id ;-) > > > > For connectivity (i.e. reachability) test purpose, a system will need > > one sbfd-id [or more]. For other applications of S-BFD, there may be a > > need for a system to allocate few tens of S-BFD discriminators. So, > > this really places more weight on the "uniqueness" requirement and the > > need for auto-foo. > > > > Thanks! > > > > -Nobo > > > >> > >> > >> Regards, Marc > >> > >> > >> > >> On Thu, 26 Jun 2014 23:32:03 +0000, Nobo Akiya (nobo) wrote: > >>> Hello BFDers, > >>> > >>> Yes, many thanks to those provided comments on S-BFD. > >>> > >>> Couple of additional things: > >>> > >>> draft-ietf-bfd-seamless-base-01 > >>> - Contains significant changes from the previous version. > >>> - There should not be any technical changes. > >>> - Greatly seeking comments on how we move forward with S-BFD > >>> discriminator uniqueness requirements. > >>> > >>> draft-akiya-bfd-seamless-ip-03 > >>> - Just published, links below. > >>> - Seeking comments on whether we want to define a new associat= ed > >>> channel type for S-BFD. > >>> > >>> URL: > >>> http://www.ietf.org/internet-drafts/draft-akiya-bfd-seamless-ip-03.t > >>> xt > >>> Status: > >>> https://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ > >>> Htmlized: http://tools.ietf.org/html/draft-akiya-bfd-seamless-i= p-03 > >>> Diff: > >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-akiya-bfd-seamless-ip-03 > >>> > >>> Thanks! > >>> > >>> -Nobo > >>> > >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh > >>> P K > >>> Sent: Thursday, June 26, 2014 3:03 PM > >>> To: rtg-bfd@ietf.org > >>> Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt > >>> > >>> Hello All, > >>> S-BFD version 1 is published. Thanks to all who had provided > comments. > >>> Diff between version 0 and 1 is significant but there are no > >>> technical changes. Below are the changes. > >>> > >>> 1. Taken care of all review comments. > >>> 2. "Full/partial reachability" is removed and focus is on the > >>> reachability. > >>> 3. SPRING dependency is removed. > >>> 4. IP specific details has been moved to "draft-akiya-bfd-seaml= ess- > >>> ip". > >>> 5. Consistent terminology. > >>> 6. Lots of rephrasing for better readability. > >>> > >>> Thanks > >>> Santosh P K > >>> > >>> > >>> -----Original Message----- > >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > >>> internet-drafts@ietf.org > >>> Sent: Thursday, June 26, 2014 11:56 PM > >>> To: i-d-announce@ietf.org > >>> Cc: rtg-bfd@ietf.org > >>> Subject: I-D Action: draft-ietf-bfd-seamless-base-01.txt > >>> > >>> > >>> 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 : Seamless Bidirectional Forwarding Detection > >>> (S-BFD) > >>> Authors : Nobo Akiya > >>> Carlos Pignataro > >>> Dave Ward > >>> Manav Bhatia > >>> Juniper Networks > >>> Filename : draft-ietf-bfd-seamless-base-01.txt > >>> Pages : 17 > >>> Date : 2014-06-26 > >>> > >>> Abstract: > >>> This document defines a simplified mechanism to use Bidirectional > >>> Forwarding Detection (BFD) with large portions of negotiation aspe= cts > >>> eliminated, thus providing benefits such as quick provisioning as > >>> well as improved control and flexibility to network nodes initiati= ng > >>> the path monitoring. > >>> > >>> This document updates RFC5880. > >>> > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ > >>> > >>> There's also a htmlized version available at: > >>> http://tools.ietf.org/html/draft-ietf-bfd-seamless-base-01 > >>> > >>> A diff from the previous version is available at: > >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-seamless-base-01 > >>> > >>> > >>> Please note that it may take a couple of minutes from the time of > >>> submission until the htmlized version and diff are available at > >>> tools.ietf.org. > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > > From nobody Tue Jul 1 08:11:40 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D18D1B27D5 for ; Tue, 1 Jul 2014 08:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrOHrA8Cq46y for ; Tue, 1 Jul 2014 08:11:34 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id DC3521B2812 for ; Tue, 1 Jul 2014 08:11:21 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 5591BC3A4; Tue, 1 Jul 2014 11:11:21 -0400 (EDT) Date: Tue, 1 Jul 2014 11:11:21 -0400 From: Jeffrey Haas To: Marc Binderberger Subject: Re: New Version Notification for draft-ashesh-bfd-stability-00.txt Message-ID: <20140701151121.GA16649@pfrc> References: <20140630233047.16868.79679.idtracker@ietfa.amsl.com> <20140701030851.GB23688@pfrc> <20140701000350717396.6223fff1@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140701000350717396.6223fff1@sniff.de> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/BVQYKr77H28UiBD7QZgWsQqouAY Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 15:11:39 -0000 Marc, On Tue, Jul 01, 2014 at 12:03:50AM -0700, Marc Binderberger wrote: > Anyway, what I take from the draft is this: having a sequence number in the > BFD packet is a very useful thing to detect packet loss and distinguish a > transmission delay increase from a lost packet. If we ever create BFDv2 this > may be something to keep in mind. The key observation that came out of the various proposals that lead to throwing these authors together as a semi-design group was effectively that we already had such sequencing. It's called auth. :-) Features beyond that are there for discussion. Conveniently the timing is good for some nice on-list discussion leading to our upcoming session in Toronto. -- Jeff (getting out the popcorn) From nobody Tue Jul 1 10:04:52 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175781A05C0 for ; Tue, 1 Jul 2014 09:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.152 X-Spam-Level: X-Spam-Status: No, score=-14.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_BACKHAIR_42=1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEstFGzQfck9 for ; Tue, 1 Jul 2014 09:20:02 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0A5C1B282C for ; Tue, 1 Jul 2014 09:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20237; q=dns/txt; s=iport; t=1404231601; x=1405441201; h=date:from:to:cc:message-id:in-reply-to:references: subject:mime-version:content-transfer-encoding; bh=n9502n6ET1j7P4JAfIe0xTf0b5bi9oog/c1C/0mMZ5M=; b=KAwYhMRe15jMUFTW999rxX4NGdstNY77jsmSTirP7irXlEftUWp2W03l hzk7Ck8y7HfPgo2vqqpO0iYMk+S90gM+18Z4OZSCkuNci79jO48paEjDC dyDo8doJAZjm2XwhtI0T+JGNbrD+VWZk0c7Gu6qkDtnWSjCZ1qsgcDZfx 8=; X-IronPort-AV: E=Sophos;i="5.01,582,1400025600"; d="scan'208";a="336819328" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-1.cisco.com with ESMTP; 01 Jul 2014 16:20:01 +0000 Received: from [10.21.124.207] (sjc-vpn6-1231.cisco.com [10.21.124.207]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s61GJxs9026103; Tue, 1 Jul 2014 16:20:00 GMT Date: Tue, 1 Jul 2014 09:19:59 -0700 From: Marc Binderberger To: Nobo Akiya (nobo) Message-ID: <20140701091959093415.e0c0ca19@cisco.com> In-Reply-To: References: <20140626182533.30391.72279.idtracker@ietfa.amsl.com> <8fe58c80d3ba4e0da4da3e82cf7677dc@BLUPR05MB755.namprd05.prod.outlook.com> <20140629152450732481.c07ee0d4@sniff.de> <20140630230555087199.19db4b6d@sniff.de> Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/NtpaGTYw1hl9ronJR1l1IApcRFE X-Mailman-Approved-At: Tue, 01 Jul 2014 10:04:48 -0700 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 16:20:12 -0000 Hello Nobo, > S-BFD on the other hand will have one port for all use of S-BFD, except for > IP-less case. > Ed-Note: Discuss whether we want a new associated channel type for > S-BFD. > > But perhaps we should create a separate document for IP-less. hmm, that is a bit a circle. If you have already IP-less on the todo list then why not structure the documents accordingly? If I understand right what you require from the outer frame mechanism is this: your outer frame must be able to distinguish S-BFD from other (BFD) traffic (ex: UDP port assigned for S-BFD). Then define the UDP port, the IP address copying/selection in seamless IP. I mention this as I think the structure of 5880 + 5881/5883/5884/[...] was quite useful. Anyway, "yeah I think it's reasonable" still holds. :-) > Regarding SBFDReflector reflecting the state, I do see your point. If the > state of received S-BFD packet is reflected by the SBFDReflector, then the > SBFDInitiator requires no FSM changes (i.e. able to re-use FSM from > RFC5880). Although that will result in time(2 * (RTT + Tr)) for the > SBFDInitiator to reach UP state. In reality, it actually would be time((2 * > (RTT _ Tr)) + tx_gap) where "tx_gap" is the interval between the 2 packets > transmitted. I do think one of the strength of S-BFD is the fact it only > takes one packet to complete the connectivity test. Thus I'm leaning > towards standing the ground of SBFDReflector only being able to send [UP, > ADMINDOWN] states, and not reflecting received state. No, you may not see my new point yet :-) While discussing with you I realized the Reflector should not impose any state machine model. Dumb reflection of the state provides full control to the Initiator side which can implement any state machine it likes. For your Down<->Up machine, it's possible too with the state reflection. You need one additional rule if (bfd.SessionType == SBFDInitiator): set state in outgoing BFD packet to "Up". Carrying this a step further: I do not see why vendor X could not use a different state machine than vendor Y. The interop is guaranteed by the same definition of what the reflector does. And yes, I realized your state machine does it with a single packet and I'm not arguing against this improvement. > This is a valuable comment, and I do like your suggestion of auto-foo being > in a separate document (than base). > > Do you think current texts in "5. S-BFD Discriminators" section is > sufficient to imply this? I think section 5 is fine and we can leave certain aspects between the lines. Even my "complicated" comment with "M least significant bits" for a manual configuration is nothing we should write down. I only mentioned it here to see if it stirs up something, some concern. But otherwise common sense and silent agreements will probably get us towards some basic 32-bit manual-config implementations for day-1. Well, I hope so :-) Regards, Marc On Tue, 1 Jul 2014 07:32:36 -0700, Nobo Akiya (nobo) wrote: > Hi Marc, > >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de] >> Sent: Tuesday, July 01, 2014 2:06 AM >> To: Nobo Akiya (nobo) >> Cc: Santosh P K; rtg-bfd@ietf.org; Marc Binderberger (mbinderb) >> Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt >> >> Hello Nobo, >> >>> One of the changes from draft-ietf-bfd-seamless-base-00 to >>> draft-ietf-bfd-seamless-base-01 to take out all IP related procedures >>> and move it over to draft-akiya-bfd-seamless-base-ip-03. Intent of the >>> authors is to: >> >> okay, so having an IP/UDP header is a fixed part of S-BFD then? It's not >> as >> agnostic as RFC5880 is regarding the frame around the BFD packets? >> >> I wasn't sure about this, thus my comment. If IP/UDP is an inherent part >> of S- >> BFD then ... >> >>> it would be helpful to hear "yeah above is reasonable" or "let's >>> structure it this way" from you and the WG. >> >> yeah I think it's reasonable :-) > > Thanks! To answer your questions above ... > > I believe RFC5880 focuses on the BFD header alone since ports are different > for various use of the BFD (i.e. SH, MH, MPLS). > S-BFD on the other hand will have one port for all use of S-BFD, except for > IP-less case. > So, except for the exception case (i.e. IP-less), current S-BFD document > structure is a reasonable (or not a bad) fit. > > Thinking more on the exception ... S-BFD-IP document has: > > Ed-Note: Discuss whether we want a new associated channel type for > S-BFD. > > But perhaps we should create a separate document for IP-less. > >> >> >> About the state machine >> >>> This comment looks familiar :) >> >> I think I repeat myself ;-) but there is a reason. Nothing wrong with the >> state >> machine you propose but I do not see this must be part of the definition. >> As >> an appendix, to show S-BFD allows for other state machines than 5880, that >> would be educational. >> >> As explained I prefer a more open approach, the reflector truly reflecting >> the state as well. Your state engine is then solely driven by the >> initiator. >> Just setting the state to Up on the reflector is removing this degree of >> freedom, unnecessary IMHO and reducing the ability to "play" with the S- >> BFD definition. >> >>> - Move the SBFDInitiator State Machine section to appendix. >> >> I would like that! > > ACK on moving the example state machine to appendix (some texts will still > be kept around in the current section). > > Regarding SBFDReflector reflecting the state, I do see your point. If the > state of received S-BFD packet is reflected by the SBFDReflector, then the > SBFDInitiator requires no FSM changes (i.e. able to re-use FSM from > RFC5880). Although that will result in time(2 * (RTT + Tr)) for the > SBFDInitiator to reach UP state. In reality, it actually would be time((2 * > (RTT _ Tr)) + tx_gap) where "tx_gap" is the interval between the 2 packets > transmitted. I do think one of the strength of S-BFD is the fact it only > takes one packet to complete the connectivity test. Thus I'm leaning > towards standing the ground of SBFDReflector only being able to send [UP, > ADMINDOWN] states, and not reflecting received state. > >> >> From your reply >> >>> True, but you forgot the aspect of: >>> >>> BFD: >>> - in case of MPLS, LSP ping bootstraps the session on egress >>> - session is created >>> - tx timer is started at no faster than 1 second >>> >>> S-BFD: >>> - no LSP ping bootstrapping >>> - session is created >>> - packet can get tx'ed right away >>> >>>> From above aspect, "considerable" delay (i.e. couple of seconds) is >>>> shaved off :) >> >> >> What I like from your reply and what maybe should be more pointed in the >> draft are exactly the aspects that make S-BFD fast. Yes, you do say it >> somehow in section 3 and section 1, 2nd paragraph. Maybe a nitpick but you >> could talk about your design principles more explicitly. Example from >> section >> 3: >> >> Required result is that applications, >> on other network nodes, possess the knowledge of the mapping from >> remote entities to S-BFD discriminators. >> >> What you probably want to say is that S-BFD is requiring the distribution >> of >> the mapping before a session is even requested (principle: fast setup). >> Then >> logically discriminators are allocated per (system, entity) and not per >> session. Again, you say it somehow in the text but you actually do not >> demand this principle. > > Make sense, let us expand a bit more on why S-BFD will result in faster > setup than BFD, in the next revision. > >> >> >>> Agree, this seems to be the direction we are heading, and I think it >>> is reasonable. However, I (we?) do see a need for auto-foo, where foo >>> may be "S-BFD discriminator allocation", "collision detection", >>> "collision correction" or combination of them. >> >> no doubt about the auto-foo but I assume this is topic for another draft? >> If >> so, then how can you make your S-BFD base draft working interoperable? >> Thus my comment to define something very basic (manual) to have a >> starting point. >> Not because manual configs are so great. >> (although: in these days of central controllers and software-defined >> networks maybe "manual" or it's API equivalent is all that is needed :-) > > This is a valuable comment, and I do like your suggestion of auto-foo being > in a separate document (than base). > > Do you think current texts in "5. S-BFD Discriminators" section is > sufficient to imply this? > > Thanks! > > -Nobo > >> >> >> Regards, Marc >> >> >> >> >> >> On Mon, 30 Jun 2014 23:18:00 +0000, Nobo Akiya (nobo) wrote: >>> Hi Marc, >>> >>>> -----Original Message----- >>>> From: Marc Binderberger [mailto:marc@sniff.de] >>>> Sent: Sunday, June 29, 2014 6:25 PM >>>> To: Nobo Akiya (nobo); Santosh P K >>>> Cc: rtg-bfd@ietf.org; Marc Binderberger (mbinderb) >>>> Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt >>>> >>>> Hello Santosh and Nobo, >>>> >>>> good stuff. Every time I read it I find something new to learn :-) >>> >>> As always, thanks for comments! >>> >>>> >>>> Re-reading the draft I had a few thoughts: >>>> >>>> 1) the draft is a "base" but it actually defines some details I would >>>> have expected in other drafts. One example is the IP/UDP header. Yes, >>>> IP is everywhere but what about applications where you don't require >>>> IP ? Or the other way around: why having an extra "bfd-seamless-ip" >>>> draft when IP/UDP is an essential part of the base draft? >>> >>> One of the changes from draft-ietf-bfd-seamless-base-00 to >>> draft-ietf-bfd-seamless-base-01 to take out all IP related procedures >>> and move it over to draft-akiya-bfd-seamless-base-ip-03. Intent of the >>> authors is to: >>> >>> 1) Focus s-bfd-base on the procedures for UDP header and BFD header. >>> 2) Focus s-bfd-ip on the procedures for IP header and MPLS. >>> 3) Add ip-less procedures (i.e. associated channel) in either s-bfd-ip >>> or create a separate draft (i.e. s-bfd-ip-less). >>> 4) s-bfd-sr to be worked on at a later time. >>> >>> Since we are only defining one port for S-BFD, this made sense to >>> those who worked on the recent changes to the S-BFD documents. >>> >>> Yes there are alternative ways to structure the documents. That being >>> said, it would be helpful to hear "yeah above is reasonable" or "let's >>> structure it this way" from you and the WG. >>> >>>> >>>> >>>> 2) similar the details of the state machine is something I think you >>>> do not really need in the base draft (!). Just define the reflector >>>> as truly reflecting the state from the incoming packet (plus >>>> overwrite with AdminDown) and you then leave it to the initiator if >>>> it uses a new state machine or the >>>> 5880 Down-Init-Up sequence or something completely different. >>> >>> This comment looks familiar :) >>> >>> Texts above the state machine now says: >>> >>> For >>> persistent SBFDInitiators, the states and the state machine described >>> in [RFC5880] will function but are more than necessary. The >>> following diagram provides an optimized state machine for persistent >>> SBFDInitiators. >>> >>> And after the diagram: >>> >>> Note that the above state machine is different from the base BFD >>> specification[RFC5880]. This is because the Init state is no longer >>> applicable for the SBFDInitiator. Another important difference is >>> the transition of the state machine from the Down state to the Up >>> state when a packet with State Up is received by the initiator. >>> >>> I think the texts and the described state machine is helpful for >>> reader to better understand how S-BFD operates. So I prefer that this >>> section remains somewhere to give better ideas to readers on how >>> SBFDInitiators can be implemented. So, I think we have few options. >>> >>> - Texts in the s-bfd-base-01 is sufficiently reasonable. >>> - Further texts should be added to make it more obvious that describe >>> state machine is not mandatory. >>> - Move the SBFDInitiator State Machine section to appendix. >>> >>> Thoughts? >>> >>>> >>>> S-BFD is largely about the reflector, I would say. Your draft brings >>>> up a good >>>> point: the state machine details are not relevant for interop as long >>>> as it stays within the definition of the reflector. >>> >>> Yes I agree. >>> >>>> >>>> >>>> 3) Actually I do not agree with statements in the draft about the >>>> 5880 state machine "may not be applicable" or that your proposal is >>>> better suited for the initial delay to bring BFD sessions up. Your >>>> state machine requires >>>> >>>> RTT + Tr >>>> >>>> the original 5880 takes >>>> >>>> 2 * (RTT + Tr). >>>> >>>> (RTT: Round Trip Time, Tr: the processing time of the reflector) >>>> >>>> True, that is faster ;-) but I'm not sure you had this in mind. And >>>> if >>>> O(RTT+Tr) is relevant then you _do_ have a "considerable" delay too >>>> and are not "seamless" anymore :-) >>> >>> True, but you forgot the aspect of: >>> >>> BFD: >>> - in case of MPLS, LSP ping bootstraps the session on egress >>> - session is created >>> - tx timer is started at no faster than 1 second >>> >>> S-BFD: >>> - no LSP ping bootstrapping >>> - session is created >>> - packet can get tx'ed right away >>> >>>> From above aspect, "considerable" delay (i.e. couple of seconds) is >>>> shaved off :) >>> >>>> >>>> >>>> 4) The D-Flag ... forgot what I wanted to say :-) >>> >>> LOL, I do that often too. >>> >>>> 4) The D-Flag ... forgot what I wanted to say :-) >>> >>> LOL, I do that often too. >>> >>>> 4) The D-Flag ... forgot what I wanted to say :-) >>> >>> Wait, didn't I reply to this already? :) >>> >>>> Mainly, if you define the >>>> behaviour you expect on the reflector then you don't need to make any >>>> statements or attempts to be "5880 compliant". >>> >>> Agree, I don't think S-BFD is trying to be compliant with RFC5880, but >>> S-BFD is trying to keep as much the same semantics possible with BFD >>> so that we are not re-inventing everything. >>> >>>> >>>> >>>>> - Greatly seeking comments on how we move forward with S-BFD >>>>> discriminator uniqueness requirements. >>>> >>>> You mean how to be unique? Or if uniqueness is necessary? >>>> For the "how", I propose that a manual option to set a "unique >>>> discriminator" >>>> is a requirement. Does not exclude smarter, automatic methods but it >>>> gets you started. >>> >>> Agree, this seems to be the direction we are heading, and I think it >>> is reasonable. However, I (we?) do see a need for auto-foo, where foo >>> may be "S-BFD discriminator allocation", "collision detection", >>> "collision correction" or combination of them. >>> >>>> >>>> Every implementation must allow to configure a unique value within >>>> the least significant M bits of the discriminator. M is >>>> implementation specific, recommendation is M >= 16. So yes, this >>>> wouldn't be the router-id then but a bfd-id. Pardon, sbfd_id ;-) >>> >>> For connectivity (i.e. reachability) test purpose, a system will need >>> one sbfd-id [or more]. For other applications of S-BFD, there may be a >>> need for a system to allocate few tens of S-BFD discriminators. So, >>> this really places more weight on the "uniqueness" requirement and the >>> need for auto-foo. >>> >>> Thanks! >>> >>> -Nobo >>> >>>> >>>> >>>> Regards, Marc >>>> >>>> >>>> >>>> On Thu, 26 Jun 2014 23:32:03 +0000, Nobo Akiya (nobo) wrote: >>>>> Hello BFDers, >>>>> >>>>> Yes, many thanks to those provided comments on S-BFD. >>>>> >>>>> Couple of additional things: >>>>> >>>>> draft-ietf-bfd-seamless-base-01 >>>>> - Contains significant changes from the previous version. >>>>> - There should not be any technical changes. >>>>> - Greatly seeking comments on how we move forward with S-BFD >>>>> discriminator uniqueness requirements. >>>>> >>>>> draft-akiya-bfd-seamless-ip-03 >>>>> - Just published, links below. >>>>> - Seeking comments on whether we want to define a new associated >>>>> channel type for S-BFD. >>>>> >>>>> URL: >>>>> http://www.ietf.org/internet-drafts/draft-akiya-bfd-seamless-ip-03.t >>>>> xt >>>>> Status: >>>>> https://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ >>>>> Htmlized: >>>>> http://tools.ietf.org/html/draft-akiya-bfd-seamless-ip-03 >>>>> Diff: >>>>> http://www.ietf.org/rfcdiff?url2=draft-akiya-bfd-seamless-ip-03 >>>>> >>>>> Thanks! >>>>> >>>>> -Nobo >>>>> >>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh >>>>> P K >>>>> Sent: Thursday, June 26, 2014 3:03 PM >>>>> To: rtg-bfd@ietf.org >>>>> Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt >>>>> >>>>> Hello All, >>>>> S-BFD version 1 is published. Thanks to all who had provided >> comments. >>>>> Diff between version 0 and 1 is significant but there are no >>>>> technical changes. Below are the changes. >>>>> >>>>> 1. Taken care of all review comments. >>>>> 2. "Full/partial reachability" is removed and focus is on the >>>>> reachability. >>>>> 3. SPRING dependency is removed. >>>>> 4. IP specific details has been moved to >>>>> "draft-akiya-bfd-seamless- >>>>> ip". >>>>> 5. Consistent terminology. >>>>> 6. Lots of rephrasing for better readability. >>>>> >>>>> Thanks >>>>> Santosh P K >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of >>>>> internet-drafts@ietf.org >>>>> Sent: Thursday, June 26, 2014 11:56 PM >>>>> To: i-d-announce@ietf.org >>>>> Cc: rtg-bfd@ietf.org >>>>> Subject: I-D Action: draft-ietf-bfd-seamless-base-01.txt >>>>> >>>>> >>>>> 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 : Seamless Bidirectional Forwarding Detection >>>>> (S-BFD) >>>>> Authors : Nobo Akiya >>>>> Carlos Pignataro >>>>> Dave Ward >>>>> Manav Bhatia >>>>> Juniper Networks >>>>> Filename : draft-ietf-bfd-seamless-base-01.txt >>>>> Pages : 17 >>>>> Date : 2014-06-26 >>>>> >>>>> Abstract: >>>>> This document defines a simplified mechanism to use Bidirectional >>>>> Forwarding Detection (BFD) with large portions of negotiation aspects >>>>> eliminated, thus providing benefits such as quick provisioning as >>>>> well as improved control and flexibility to network nodes initiating >>>>> the path monitoring. >>>>> >>>>> This document updates RFC5880. >>>>> >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-bfd-seamless-base-01 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-seamless-base-01 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission until the htmlized version and diff are available at >>>>> tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>> From nobody Tue Jul 1 11:19:10 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A55F1B288C; Tue, 1 Jul 2014 11:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3b52wmQPXXe; Tue, 1 Jul 2014 11:19:06 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0907E1B2891; Tue, 1 Jul 2014 11:19:04 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-9c-53b2a7513929 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id EF.8A.25146.157A2B35; Tue, 1 Jul 2014 14:19:29 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Tue, 1 Jul 2014 14:19:02 -0400 From: Gregory Mirsky To: "mpls@ietf.org" , "rtg-bfd@ietf.org" Subject: FW: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Topic: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Index: AQHPlLkmcHLo4kmCjEWzfUskF7x6bpuLglYg Date: Tue, 1 Jul 2014 18:19:01 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7E50F6@eusaamb103.ericsson.se> References: <20140630231508.5203.4775.idtracker@ietfa.amsl.com> In-Reply-To: <20140630231508.5203.4775.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyuXRPuG7g8k3BBr/WKlrcWrqS1eLzn22M DkweS5b8ZApgjOKySUnNySxLLdK3S+DK2NJ3la1gj3DF8U372RoY/wh1MXJySAiYSLRtWMEI YYtJXLi3nq2LkYtDSOAoo8SNB13sIAkhgWWMEl8O54HYbAJGEi829oDFRQS8JJrmPAVrFhYI lFi2/w8TRDxIYuHCXjYI20hiydzXLCA2i4CKxMYr11hBbF4BX4m71x+zQMy3l3g/swmsnlPA QeLkiXPMIDYj0EHfT60Bm8ksIC5x68l8JohDBSSW7DnPDGGLSrx8/I8VwlaU2Nc/Heg2DqB6 TYn1u/QhWhUlpnQ/ZIdYKyhxcuYTlgmMorOQTJ2F0DELSccsJB0LGFlWMXKUFqeW5aYbGW5i BIb/MQk2xx2MCz5ZHmIU4GBU4uFVMN0YLMSaWFZcmXuIUZqDRUmcV7N6XrCQQHpiSWp2ampB alF8UWlOavEhRiYOTqkGxtbHyr6/OG4fM/9wc1L3XQ7vW0app72DEia6lh8pZN50rciqVPak PF+B7f6vrkIzzGYw6n//bqI3L6HF8w7/2rCevs27Lc6/FJhdE2/7f2rcrc4zegnl3Q8Lo9Ml 20LWMokHTvp2t99c+YXZEYbc7mMZMQf/TGerZTnt9HWSpYfB3ud2Ze3blViKMxINtZiLihMB Ih6NuWACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/_Noa9lu5Fo-Q_zoOWJVTqML4uV8 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 18:19:08 -0000 RGVhciBBbGwsDQp3ZSd2ZSBwb3N0ZWQgYSBuZXcgZHJhZnQuIExTUCBQaW5nIGFscmVhZHkgaXMg dXNlZCB0byBib290c3RyYXAgYSBCRkQgc2Vzc2lvbiB3aXRoIEJGRCBEaXNjcmltaW5hdG9yIFRM Vi4gQSBuZXcgQkZEIFJldmVyc2UgUGF0aCBUTFYgaXMgaW50cm9kdWNlZCBpbiBvcmRlciB0byBp bnN0cnVjdCBhIGZhci1lbmQgQkZEIHBlZXIgdG8gdXNlIHBhcnRpY3VsYXIgcGF0aCBmb3IgcmV2 ZXJzZSBkaXJlY3Rpb24gb2YgdGhlIEJGRCBzZXNzaW9uLiANCg0KR3JlYXRseSBhcHByZWNpYXRl IHlvdXIgcXVlc3Rpb25zLCBjb21tZW50cy4NCg0KCVJlZ2FyZHMsDQoJCUdyZWcNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIEp1bmUgMzAsIDIw MTQgNDoxNSBQTQ0KVG86IEdyZWdvcnkgTWlyc2t5OyBJbHlhIFZhcmxhc2hraW47IEplZmYgVGFu dHN1cmE7IEdyZWdvcnkgTWlyc2t5OyBKZWZmIFRhbnRzdXJhOyBJbHlhIFZhcmxhc2hraW4NClN1 YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWlyc2t5LW1wbHMtYmZk LWRpcmVjdGVkLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1taXJza3kt bXBscy1iZmQtZGlyZWN0ZWQtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IEdyZWcgTWlyc2t5IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFt ZToJCWRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZA0KUmV2aXNpb246CTAwDQpUaXRsZToJ CUJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgRGlyZWN0ZWQgUmV0dXJu IFBhdGgNCkRvY3VtZW50IGRhdGU6CTIwMTQtMDYtMzANCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQpQYWdlczoJCTgNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQtMDAudHh0DQpTdGF0 dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWlyc2t5 LW1wbHMtYmZkLWRpcmVjdGVkLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMA0KDQoNCkFic3RyYWN0Og0K ICAgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBpcyBleHBlY3RlZCB0 byBtb25pdG9yIGJpLQ0KICAgZGlyZWN0aW9uYWwgcGF0aHMuICBXaGVuIGZvcndhcmQgZGlyZWN0 aW9uIG9mIGEgQkZEIHNlc3Npb24gaXMgdG8NCiAgIG1vbml0b3IgZXhwbGljaXRseSByb3V0ZWQg cGF0aCB0aGVyZSBpc1wgYSBuZWVkIHRvIGJlIGFibGUgdG8gZGlyZWN0DQogICBmYXItZW5kIEJG RCBwZWVyIHRvIHVzZSBzcGVjaWZpYyBwYXRoIGFzIHJldmVyc2UgZGlyZWN0aW9uIG9mIHRoZSBC RkQNCiAgIHNlc3Npb24uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Tue Jul 1 17:14:42 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581FD1AD62A for ; Tue, 1 Jul 2014 17:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1Q8IDTJpJFV for ; Tue, 1 Jul 2014 17:14:35 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FCDC1A040C for ; Tue, 1 Jul 2014 17:14:35 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-29-53b2fd0ebe03 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 9F.CB.05330.E0DF2B35; Tue, 1 Jul 2014 20:25:19 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Tue, 1 Jul 2014 20:14:34 -0400 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , "Jeff Haas (jhaas@juniper.net)" , "rtg-bfd@ietf.org" Subject: RE: [Tentative] BFD WG Agenda for IETF90 Thread-Topic: [Tentative] BFD WG Agenda for IETF90 Thread-Index: Ac+UiZAWL5Mu2kjMROSJ/nHy59ZzAwBAGTDg Date: Wed, 2 Jul 2014 00:14:32 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7E544A@eusaamb103.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B7E544Aeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyuXRPiC7/303BBscXMVtsm25hMbsj3uLz n22MDsweU35vZPVYsuQnk8f1pqvsAcxRXDYpqTmZZalF+nYJXBk7Zy1nL3jqUNHYdpaxgXGb eRcjJ4eEgInE9/7DTBC2mMSFe+vZuhi5OIQEjjJK7NvwhxkkISSwjFFi2elCEJtNwEjixcYe dpAiEYE2RokV2zrZQBLMAnoSDa8egDUICxhKXH08C8wWAWpo+fyQHcY+sfcoK4jNIqAi8enF Y7DNvAK+Ep++XmKBWOYj8XH6C7BeTqD4yp8djCA2I9B130+tYYLYJS5x68l8qKsFJJbsOc8M YYtKvHz8jxXCVpTY1z8daC8HUH2+xN4vFhCrBCVOznzCMoFRdBaSSbMQqmYhqYIo0ZFYsPsT G4StLbFs4WtmGPvMgcdMyOILGNlXMXKUFqeW5aYbGWxiBMbYMQk23R2Me15aHmIU4GBU4uF9 sG9TsBBrYllxZe4hRmkOFiVx3lm184KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MNqeOLYz 9Z1cdU1MpOBS1oJF7rysL57bCanlsmw3fPOM02TLG/8d0uezbyy5yrn+uZ+pktcaebVp35Ke ret1WK2TE/EneaLA39vlf/S+8p2Xn6Se5F1ove2G53dzrnld5f6t0tLqq3kV7LPjNFJvu/R7 MFm1C53ayffsKmthplWqn4FrnPoSJZbijERDLeai4kQAv1GnqJICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/k5JqVdvTtiRGDF4mzsSVNQd1znM X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 00:14:39 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B7E544Aeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Nobo and Jeff, hope you would accept another presentation request for the meeting in Toron= to: * Title - BFD Directed Return Path * Draft - draft-mirsky-mpls-bfd-directed-00 * Presenter - Greg Mirsky * Duration - 10 min Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (no= bo) Sent: Monday, June 30, 2014 10:44 AM To: rtg-bfd@ietf.org Cc: Jeff Haas (jhaas@juniper.net) Subject: [Tentative] BFD WG Agenda for IETF90 Hello BFDers, Tentative BFD WG Agenda for IETF90 has been posted. http://www.ietf.org/proceedings/90/agenda/agenda-90-bfd (tentative agenda also pasted below for easier reference) If: - Your presentation information is not accurate; - Your presentation information is missing; - You do not agree with the agenda or a specific presentation listed; please provide your comment via replying to this thread (with WG list inclu= ded or just the chairs). Reminder to presenters: Please email your slides to the chairs no later than 2014-07-14 (Monday). Thanks! -Nobo and Jeff IETF 90 - BFD WG Meeting Session Agenda MONDAY, July 21, 2014 1520-1650 Afternoon Session II Salon B =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D CHAIR(s): Jeffrey Haas > Nobo Akiya > - WG Statuses and Administrivia 15 minutes Presenter Co-chairs - BFD Proxy for Connections over Monitored Links 10 minutes Draft draft-snyder-bfd-proxy-connections-monitored-links-00 Presenter Brian Snyder - BFD Stability 10 minutes Draft draft-ashesh-bfd-stability-00 Presenter Ashesh Mishra - Seamless BFD Use-Case 10 minutes Draft draft-ietf-bfd-seamless-use-case-00 Presenter Sam K. Aldrin - Seamless BFD Base/IP 10 minutes Draft draft-ietf-bfd-seamless-base-01 draft-akiya-bfd-seamless-ip-03 Presenter Nobo Akiya - L2VPN EVPN BFD 10 minutes Draft draft-vgovindan-l2vpn-evpn-bfd-02 Presenter Vengada Prasad Govindan --_000_7347100B5761DC41A166AC17F22DF1121B7E544Aeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Nobo and Jeff,
hope you would accept another presentation request for the meeting in = Toronto:
  • Title - BFD Directed Return Path
  • Draft - draft-mirsky-mpls-bfd-= directed-00
  • Presenter - Greg Mirsky
  • Duration - 10 min
    • <= /ul>
     
            Regards,
               &nbs= p;    Greg
     
    -----Original Message-----
    From: Rtg-bfd [mailto:rtg-bfd-b= ounces@ietf.org] On Behalf Of Nobo Akiya (nobo)
    Sent: Monday, June 30, 2014 10:44 AM
    To: rtg-bfd@ietf.org
    Cc: Jeff Haas (jhaas@juniper.net)
    Subject: [Tentative] BFD WG Agenda for IETF90
     
    Hello BFDers,
     
    Tentative BFD WG Agenda for IETF90 has been posted.
     
    (tentative agenda also pasted below for easier reference)
     
    If:
    - Your presentation information is not accurate;
    - Your presentation information is missing;
    - You do not agree with the agenda or a specific presentation listed;<= /div>
     
    please provide your comment via replying to this thread (with WG list = included or just the chairs).
     
    Reminder to presenters:
     
    Please email your slides to the chairs no later than 2014-07-14 (Monda= y).
     
    Thanks!
     
    -Nobo and Jeff
     
     
    IETF 90 - BFD WG Meeting Session Agenda
     
    MONDAY, July 21, 2014
    1520-1650  Afternoon Session II
    Salon B
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
     
    CHAIR(s):  Jeffrey Haas <jha= as@pfrc.org>
               Nobo Akiy= a <nobo@cisco.com>
     
    - WG Statuses and Administrivia      &nb= sp;            =      15 minutes
      Presenter
        Co-chairs
     
    - BFD Proxy for Connections over Monitored Links   &nbs= p;   10 minutes
      Draft
        draft-snyder-bfd-proxy-connections-monitored-links-= 00
      Presenter
        Brian Snyder
     
    - BFD Stability         &= nbsp;           &nbs= p;            &= nbsp;     10 minutes
      Draft
        draft-ashesh-bfd-stability-00
      Presenter
        Ashesh Mishra
     
    - Seamless BFD Use-Case        = ;            &n= bsp;           10 minutes=
      Draft
        draft-ietf-bfd-seamless-use-case-00
      Presenter
        Sam K. Aldrin
     
    - Seamless BFD Base/IP        =             &nb= sp;            10 mi= nutes
      Draft
        draft-ietf-bfd-seamless-base-01
        draft-akiya-bfd-seamless-ip-03
      Presenter
        Nobo Akiya
     
    - L2VPN EVPN BFD         =             &nb= sp;            =      10 minutes
      Draft
        draft-vgovindan-l2vpn-evpn-bfd-02
      Presenter
        Vengada Prasad Govindan
     
     
     --_000_7347100B5761DC41A166AC17F22DF1121B7E544Aeusaamb103erics_-- From nobody Tue Jul 1 17:23:04 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B8E1A0ADA for ; Tue, 1 Jul 2014 17:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.151 X-Spam-Level: X-Spam-Status: No, score=-115.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wLLS8fP8LYj for ; Tue, 1 Jul 2014 17:22:57 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A3481A0640 for ; Tue, 1 Jul 2014 17:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28056; q=dns/txt; s=iport; t=1404260577; x=1405470177; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Jh1guqrGoitylXS9r4xB4Y9iar1xMB2fxA3oX1lsi1o=; b=gaha5C3UrHLGbElqBcrOUvSBwjylQMgWQOCL+aN70Nb2LtIDr1CLrWsp zT2vfBCFDYFpoDLFq+nyrF5MiEyutzqJHf0DsEmPGc/ERWkj0qQ92SS9U w6f3mGnGfx/jU5+BaiDDfiadQFXEm+359YsEqdbFpp3fQHnNjF9Ueuc+w s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAIhPs1OtJA2B/2dsb2JhbABagkYjJFJaxgcBgRAWdYQDAQEBBC1MDAQCAQgRBAEBCxYBBgcyFAkIAQEEAQ0FCAGIOQEMxQ0Xjj0RAR8PIgYBBoMngRYFrmmDQoF3OQ X-IronPort-AV: E=Sophos; i="5.01,585,1400025600"; d="scan'208,217"; a="57609951" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP; 02 Jul 2014 00:22:56 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s620MuT7029554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jul 2014 00:22:56 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 1 Jul 2014 19:22:55 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , "Jeff Haas (jhaas@juniper.net)" , "rtg-bfd@ietf.org" Subject: RE: [Tentative] BFD WG Agenda for IETF90 Thread-Topic: [Tentative] BFD WG Agenda for IETF90 Thread-Index: Ac+UiZAWL5Mu2kjMROSJ/nHy59ZzAwBAGTDgAABhwUA= Date: Wed, 2 Jul 2014 00:22:54 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7E544A@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7E544A@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.123] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941E2589D0xmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ARdakbkndPxZF8cSg-swbCfkOIY X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 00:22:59 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3941E2589D0xmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Certainly. Please send the chairs the slides by no later than 2014-07-14 (M= onday). Thanks! -Nobo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Tuesday, July 01, 2014 8:15 PM To: Nobo Akiya (nobo); Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org Cc: Jeff Tantsura Subject: RE: [Tentative] BFD WG Agenda for IETF90 Dear Nobo and Jeff, hope you would accept another presentation request for the meeting in Toron= to: * Title - BFD Directed Return Path * Draft - draft-mirsky-mpls-bfd-directed-00 * Presenter - Greg Mirsky * Duration - 10 min Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (no= bo) Sent: Monday, June 30, 2014 10:44 AM To: rtg-bfd@ietf.org Cc: Jeff Haas (jhaas@juniper.net) Subject: [Tentative] BFD WG Agenda for IETF90 Hello BFDers, Tentative BFD WG Agenda for IETF90 has been posted. http://www.ietf.org/proceedings/90/agenda/agenda-90-bfd (tentative agenda also pasted below for easier reference) If: - Your presentation information is not accurate; - Your presentation information is missing; - You do not agree with the agenda or a specific presentation listed; please provide your comment via replying to this thread (with WG list inclu= ded or just the chairs). Reminder to presenters: Please email your slides to the chairs no later than 2014-07-14 (Monday). Thanks! -Nobo and Jeff IETF 90 - BFD WG Meeting Session Agenda MONDAY, July 21, 2014 1520-1650 Afternoon Session II Salon B =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D CHAIR(s): Jeffrey Haas > Nobo Akiya > - WG Statuses and Administrivia 15 minutes Presenter Co-chairs - BFD Proxy for Connections over Monitored Links 10 minutes Draft draft-snyder-bfd-proxy-connections-monitored-links-00 Presenter Brian Snyder - BFD Stability 10 minutes Draft draft-ashesh-bfd-stability-00 Presenter Ashesh Mishra - Seamless BFD Use-Case 10 minutes Draft draft-ietf-bfd-seamless-use-case-00 Presenter Sam K. Aldrin - Seamless BFD Base/IP 10 minutes Draft draft-ietf-bfd-seamless-base-01 draft-akiya-bfd-seamless-ip-03 Presenter Nobo Akiya - L2VPN EVPN BFD 10 minutes Draft draft-vgovindan-l2vpn-evpn-bfd-02 Presenter Vengada Prasad Govindan --_000_CECE764681BE964CBE1DFF78F3CDD3941E2589D0xmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Greg,

     <= /p>

    Certainly. Please send th= e chairs the slides by no later than 2014-07-14 (Monday).=

     <= /p>

    Thanks!=

     <= /p>

    -Nobo

     <= /p>

    From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
    Sent: Tuesday, July 01, 2014 8:15 PM
    To: Nobo Akiya (nobo); Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.o= rg
    Cc: Jeff Tantsura
    Subject: RE: [Tentative] BFD WG Agenda for IETF90    <= /p>

     

    Dear Nobo and Jeff,

    hope you would accept another presentat= ion request for the meeting in Toronto:

    ·        Title - BFD Directed Return Pat= h

    ·        Draft - draft-mirsky-mpls-bfd-d= irected-00

    ·        Presenter - Greg Mirsky

    ·        Duration - 10 min

     

          &nb= sp; Regards,

          &nb= sp;         Greg<= /p>

     

    -----Original Message-----
    From: Rtg-bfd [mailto:rtg-bfd-b= ounces@ietf.org] On Behalf Of Nobo Akiya (nobo)
    Sent: Monday, June 30, 2014 10:44 AM
    To: rtg-bfd@ietf.org
    Cc: Jeff Haas (jhaas@juniper.net)<= br> Subject: [Tentative] BFD WG Agenda for IETF90

     

    Hello BFDers,

     

    Tentative BFD WG Agenda for IETF90 has = been posted.

     

    (tentative agenda also pasted below for= easier reference)

     

    If:

    - Your presentation information is not = accurate;

    - Your presentation information is miss= ing;

    - You do not agree with the agenda or a= specific presentation listed;

     

    please provide your comment via replyin= g to this thread (with WG list included or just the chairs).

     

    Reminder to presenters:

     

    Please email your slides to the chairs = no later than 2014-07-14 (Monday).

     

    Thanks!

     

    -Nobo and Jeff

     

     

    IETF 90 - BFD WG Meeting Session Agenda=

     

    MONDAY, July 21, 2014=

    1520-1650  Afternoon Session II

    Salon B

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

     

    CHAIR(s):  Jeffrey Haas <jhaas@pfrc.org>

          &nb= sp;    Nobo Akiya <nobo= @cisco.com>

     

    - WG Statuses and Administrivia &n= bsp;            = ;          15 minutes

      Presenter

        Co-chairs=

     

    - BFD Proxy for Connections over Monito= red Links       10 minutes<= /p>

      Draft

        draft-snyder-bfd-pro= xy-connections-monitored-links-00

      Presenter

        Brian Snyder

     

    - BFD Stability    =             &nb= sp;            =            10 minutes

      Draft

        draft-ashesh-bfd-sta= bility-00

      Presenter

        Ashesh Mishra

     

    - Seamless BFD Use-Case  &nbs= p;            &= nbsp;           &nbs= p;    10 minutes

      Draft

        draft-ietf-bfd-seaml= ess-use-case-00

      Presenter

        Sam K. Aldrin

     

    - Seamless BFD Base/IP   = ;            &n= bsp;            = ;     10 minutes

      Draft

        draft-ietf-bfd-seaml= ess-base-01

        draft-akiya-bfd-seam= less-ip-03

      Presenter

        Nobo Akiya

     

    - L2VPN EVPN BFD    = ;            &n= bsp;            = ;          10 minutes

      Draft

        draft-vgovindan-l2vp= n-evpn-bfd-02

      Presenter

        Vengada Prasad Govin= dan

     

     

    --_000_CECE764681BE964CBE1DFF78F3CDD3941E2589D0xmbalnx01ciscoc_-- From nobody Tue Jul 1 18:57:30 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5041B27FC for ; Tue, 1 Jul 2014 18:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1C6lC2INxG8 for ; Tue, 1 Jul 2014 18:57:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 187F21B27B3 for ; Tue, 1 Jul 2014 18:57:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJL98363; Wed, 02 Jul 2014 01:57:22 +0000 (GMT) Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 2 Jul 2014 02:57:21 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.190]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0158.001; Wed, 2 Jul 2014 09:57:18 +0800 From: Mach Chen To: Gregory Mirsky Subject: RE: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Topic: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Index: AQHPlLkmcHLo4kmCjEWzfUskF7x6bpuLglYggAB+rEA= Date: Wed, 2 Jul 2014 01:57:17 +0000 Message-ID: References: <20140630231508.5203.4775.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B7E50F6@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7E50F6@eusaamb103.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Wk8eSHUW80znwDztW9u5zP1tvvU Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 01:57:26 -0000 SGkgR3JlZywNCg0KSSBoYXZlIGEgcXVpY2sgcmV2aWV3IG9uIHRoZSBkcmFmdCwgd2VsbCB3cml0 dGVuIGFuZCB1c2VmdWwgZHJhZnQhDQoNCkNvdXBsZSB5ZWFycyBhZ28sIHdlIHN1Ym1pdHRlZCBh IGRyYWZ0IChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGVuLW1wbHMtYmZkLWVu aGFuY2VtZW50LTAxKSB0aGF0IGludGVuZCB0byBzb2x2ZSB0aGUgc2ltaWxhciBpc3N1ZSwgZ2xh ZCB3ZSBoYXZlIHRoZSBzaW1pbGFyIHRob3VnaHQ6LSkuDQoNCkl0IGFsc28gZGVmaW5lcyBleHRl bnNpb25zIHRvIExTUCBQaW5nIHRvIGRpcmVjdCB0aGUgY2hvb3NlIG9mIHRoZSByZXR1cm4gcGF0 aCBvZiBCRkQgY29udHJvbCBwYWNrZXRzLiBQbGVhc2UgdGFrZSBhIGxvb2suDQoNCkJlc3QgcmVn YXJkcywNCk1hY2gNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSdGct YmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR3JlZ29y eSBNaXJza3kNCj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDAyLCAyMDE0IDI6MTkgQU0NCj4gVG86 IG1wbHNAaWV0Zi5vcmc7IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gU3ViamVjdDogRlc6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkLTAwLnR4 dA0KPiANCj4gRGVhciBBbGwsDQo+IHdlJ3ZlIHBvc3RlZCBhIG5ldyBkcmFmdC4gTFNQIFBpbmcg YWxyZWFkeSBpcyB1c2VkIHRvIGJvb3RzdHJhcCBhIEJGRCBzZXNzaW9uDQo+IHdpdGggQkZEIERp c2NyaW1pbmF0b3IgVExWLiBBIG5ldyBCRkQgUmV2ZXJzZSBQYXRoIFRMViBpcyBpbnRyb2R1Y2Vk IGluIG9yZGVyIHRvDQo+IGluc3RydWN0IGEgZmFyLWVuZCBCRkQgcGVlciB0byB1c2UgcGFydGlj dWxhciBwYXRoIGZvciByZXZlcnNlIGRpcmVjdGlvbiBvZiB0aGUgQkZEDQo+IHNlc3Npb24uDQo+ IA0KPiBHcmVhdGx5IGFwcHJlY2lhdGUgeW91ciBxdWVzdGlvbnMsIGNvbW1lbnRzLg0KPiANCj4g CVJlZ2FyZHMsDQo+IAkJR3JlZw0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXQ0KPiBTZW50OiBNb25kYXksIEp1bmUgMzAsIDIwMTQgNDoxNSBQTQ0KPiBUbzogR3Jl Z29yeSBNaXJza3k7IElseWEgVmFybGFzaGtpbjsgSmVmZiBUYW50c3VyYTsgR3JlZ29yeSBNaXJz a3k7IEplZmYgVGFudHN1cmE7DQo+IElseWEgVmFybGFzaGtpbg0KPiBTdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMC50 eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWlyc2t5LW1wbHMtYmZk LWRpcmVjdGVkLTAwLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEdy ZWcgTWlyc2t5IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYNCj4gcmVwb3NpdG9yeS4NCj4gDQo+IE5h bWU6CQlkcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQNCj4gUmV2aXNpb246CTAwDQo+IFRp dGxlOgkJQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBEaXJlY3RlZCBS ZXR1cm4gUGF0aA0KPiBEb2N1bWVudCBkYXRlOgkyMDE0LTA2LTMwDQo+IEdyb3VwOgkJSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJOA0KPiBVUkw6DQo+IGh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMC50eHQN Cj4gU3RhdHVzOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1taXJz a3ktbXBscy1iZmQtZGlyZWN0ZWQvDQo+IEh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQtMDANCj4gDQo+IA0KPiBB YnN0cmFjdDoNCj4gICAgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBp cyBleHBlY3RlZCB0byBtb25pdG9yIGJpLQ0KPiAgICBkaXJlY3Rpb25hbCBwYXRocy4gIFdoZW4g Zm9yd2FyZCBkaXJlY3Rpb24gb2YgYSBCRkQgc2Vzc2lvbiBpcyB0bw0KPiAgICBtb25pdG9yIGV4 cGxpY2l0bHkgcm91dGVkIHBhdGggdGhlcmUgaXNcIGEgbmVlZCB0byBiZSBhYmxlIHRvIGRpcmVj dA0KPiAgICBmYXItZW5kIEJGRCBwZWVyIHRvIHVzZSBzcGVjaWZpYyBwYXRoIGFzIHJldmVyc2Ug ZGlyZWN0aW9uIG9mIHRoZSBCRkQNCj4gICAgc2Vzc2lvbi4NCj4gDQo+IA0KPiANCj4gDQo+IFBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFy aWF0DQoNCg== From nobody Tue Jul 1 22:54:39 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B01D1B28D2 for ; Tue, 1 Jul 2014 22:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8YcC6SJ_iV1 for ; Tue, 1 Jul 2014 22:54:31 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AB361B28D0 for ; Tue, 1 Jul 2014 22:54:31 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id wp18so11643899obc.14 for ; Tue, 01 Jul 2014 22:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=es2yBoi0x9W3X/tGf1ZtiCNQOpeoed294my+uQKZBX0=; b=KJ3Uku4YjFmjMWE5hE0zXhcKEpmwzV6AIJqt9CO0zGo102dOe1L6SkttaB1Xy+OgRG ljH/UqhNUtAhMpBsFUK4FFWvGnxENg3hL3KgApvtIGUymTyFHzvt3HrMnC05427hr0fp eupGlzZxTblFfLOyKZW7qbCCqLeeFOv7zam4NaqB/kCsy8+yfqkpVH4/64LnM8zh+/+c B9zsHR2Wi9OitHM6bUng2lHSLfsx1cCmR9TsZLCiNo9FLa6wQ2dCnBTiuxrDj44pID4z xCfdZD6bvRmcsQkTYcR3EhLqoqzeo7G/CdresFCznSFBKUFyagXhqakFefrfOPoGrRgJ aJoA== MIME-Version: 1.0 X-Received: by 10.182.211.99 with SMTP id nb3mr55249955obc.40.1404280471034; Tue, 01 Jul 2014 22:54:31 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Tue, 1 Jul 2014 22:54:30 -0700 (PDT) In-Reply-To: <20140701030851.GB23688@pfrc> References: <20140630233047.16868.79679.idtracker@ietfa.amsl.com> <20140701030851.GB23688@pfrc> Date: Wed, 2 Jul 2014 11:24:30 +0530 Message-ID: Subject: Re: New Version Notification for draft-ashesh-bfd-stability-00.txt From: Manav Bhatia To: Jeffrey Haas Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/68Aie1TYMihJ8sH-RqObDsBHKiM Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 05:54:33 -0000 Jeff, > On Tue, Jul 01, 2014 at 06:12:41AM +0530, Manav Bhatia wrote: >> Security Considerations says: >> >> Since this method uses an authentication TLV to achive the >> functionality, usage of this TLV will prevent the use of other >> authentication TLVs. >> >> This is not acceptable. I would not like to see any proposal that >> precludes the possibility of adding authentication later -- your >> design stands on tenuous grounds as soon as you say this. > > Exactly how well that survives the sieve of real-world deployment of > authentication is itself somewhat tenuous grounds. :-) You never know! ;-) We'll be publishing a draft on authentication which might just make using authentication for BFD very much usable. The idea will be to only carry the digest when there is a BFD state change. All other times, the BFD packet just goes without any authentication TLV. If you think about this, then this really solves all your problems! ;-) The draft is coming your way that describes this very soon. Cheers, Manav > But your point about making this feature work with actual authentication is > work they've identified needing help. I suspect you'll have opinions on > that. > >> BTW, i dont feel great about overloading the authentication TLV with >> information thats completely unrelated to authentication. This breaks >> all HW that looks at this TLV and sends it for some special >> processing. You now require HW to peek deeper inside the TLV to know >> if its something that this would interest it or not. > > The authors of this draft were suggested to come together to work on this > since they all had very similar ideas for the feature. The observation that > has lead to part of the current design is that the sequence number semantics > needed for the feature are largely carried already through meticulous > authentiction sequence numbering. > > At the end of the day, if we eliminated the additional fields, kept some > well known but inexpensive authentication (such as null or password) and > simply collected statistics related to expected packet presence based on > rates and jitter it woudl be possible to derive some amount of loss and > lantency statistics. > > The addition of time stamping for additional work seemed to be another > common factor in each of the suggested designs. > > Keeping with BFDv1 problematically means one of three likely designs for > such a feature: > - Overload something like authentication. > - Packing the additional data after the BFD packet. (There is room in the > spec for this, but depending on how pedantically someone implements it or > not may result in the additional data not getting through.) > - Declaring defeat and creating BFDv2. > > My push, as is well known on the list, is "can we do this without becoming > backwardly incompatible". Some day we will. Is that today? Let's find > out! > > -- Jeff From nobody Wed Jul 2 07:07:24 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC13F1A00E8 for ; Wed, 2 Jul 2014 07:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyQNIp0wYpOn for ; Wed, 2 Jul 2014 07:07:09 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B54CA1A0102 for ; Wed, 2 Jul 2014 07:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=853; q=dns/txt; s=iport; t=1404310030; x=1405519630; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=+wideTROdCyW7Dplq9mdLaFlC7duFeHWFxb/SWw/noo=; b=SPAkNdFWWTIJG5EeXWXUhVywFPJEEwNIrYivJiw1kz+HgE588s4liQqW HBF6blik1iiJhklfZiIRdFgek9U1w1WknqeZuwzGqsh+jMBgX2SrcJ872 ZYYbQM7gYmGHt7cYN4QRANQpGYQhQfoOxGgLaeTDu/SkZKv89/VV0KOML Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFACIRtFOtJA2G/2dsb2JhbABagmkkUlrGHQGBBxZ1hAMBAQEEHR1LBAIBCA4DBAEBCxQJBzIUCQgCBAESCIg6AQzGDxeLfYJ0OAaDJ4EWAQScNZJBg0OCMA X-IronPort-AV: E=Sophos;i="5.01,588,1400025600"; d="scan'208";a="337342148" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP; 02 Jul 2014 14:07:09 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s62E79Yo025359 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jul 2014 14:07:09 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Wed, 2 Jul 2014 09:07:08 -0500 From: "Nobo Akiya (nobo)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15) Thread-Topic: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15) Thread-Index: AQHPlIHIBsIOBJkus0+CAihl2Ab3jJuM1HOQ Date: Wed, 2 Jul 2014 14:07:08 +0000 Message-ID: References: <20140630163846.GA11842@pfrc> In-Reply-To: <20140630163846.GA11842@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/DKCxQ9aE9Hw0L-vNvZnBcYn57U8 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 14:07:12 -0000 Hi Jeff, As a co-author of this document, I believe the document provides helpful in= formation and is ready for publication. Thanks! -Nobo > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Monday, June 30, 2014 12:39 PM > To: rtg-bfd@ietf.org > Subject: Working Group Last Call for draft-ietf-bfd-intervals (ending Jul= y 15) >=20 > Working Group, >=20 > We would like to initiate the start of Working Group Last Call for Common > Interval Support in BFD: >=20 > http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 >=20 > Note that the intended status of this document is INFORMATIONAL. >=20 > Please send your comments, including whether you think the draft is ready > for publication or not, to the list no later than July 15. >=20 > -- Jeff and Nobo From nobody Wed Jul 2 07:10:05 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501A41A00F8 for ; Wed, 2 Jul 2014 07:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwKVrxGlgl2i for ; Wed, 2 Jul 2014 07:10:02 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 09DC71A0065 for ; Wed, 2 Jul 2014 07:10:02 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7C1A3C20F; Wed, 2 Jul 2014 10:10:01 -0400 (EDT) Date: Wed, 2 Jul 2014 10:10:01 -0400 From: Jeffrey Haas To: Manav Bhatia Subject: Re: New Version Notification for draft-ashesh-bfd-stability-00.txt Message-ID: <20140702141001.GG16649@pfrc> References: <20140630233047.16868.79679.idtracker@ietfa.amsl.com> <20140701030851.GB23688@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/D_zdVEQYmU1wOWU02nC2_6t0i-s Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 14:10:03 -0000 Manav, On Wed, Jul 02, 2014 at 11:24:30AM +0530, Manav Bhatia wrote: > > Exactly how well that survives the sieve of real-world deployment of > > authentication is itself somewhat tenuous grounds. :-) > > You never know! ;-) > > We'll be publishing a draft on authentication which might just make > using authentication for BFD very much usable. The idea will be to > only carry the digest when there is a BFD state change. All other > times, the BFD packet just goes without any authentication TLV. > > If you think about this, then this really solves all your problems! ;-) > > The draft is coming your way that describes this very soon. That proposal seems one of those things that in retrospect should have been obvious. It sounds quite useful. This typically means some security expert will tell us it's a bad idea, but I look forward to that discussion! -- Jeff From nobody Wed Jul 2 10:15:45 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06921A01BD; Wed, 2 Jul 2014 10:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_XYIWxZzWOx; Wed, 2 Jul 2014 10:15:32 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC1BC1B284C; Wed, 2 Jul 2014 10:15:32 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-6c-53b3ec47dc74 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 76.87.05330.74CE3B35; Wed, 2 Jul 2014 13:25:59 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Wed, 2 Jul 2014 13:15:24 -0400 From: Gregory Mirsky To: Mach Chen , "mpls@ietf.org" Subject: RE: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Topic: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Index: AQHPlLkmcHLo4kmCjEWzfUskF7x6bpuLglYggAB+rECAAQbgIA== Date: Wed, 2 Jul 2014 17:15:23 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7E5B9B@eusaamb103.ericsson.se> References: <20140630231508.5203.4775.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B7E50F6@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXRPgq77m83BBs+W2VhcWCtscWvpSlaL z3+2MTowe7QcecvqsWTJT6YApigum5TUnMyy1CJ9uwSujCdT7rIXPJKvmNG4gb2B8YdcFyMn h4SAicSBu8sZIWwxiQv31rOB2EICRxklbr/0g7CXMUo8WisCYrMJGEm82NjDDmKLCLhKzNm4 mRXEZhbQlGg68RksLiwQKLGt8zIbRE2QxMKFvVC2k8TNS5PBbBYBFYlH3/rBbF4BX4mnH38A zeEC2nWeUWLq3UNggzgFwiT6Lx8AsxmBjvt+ag0TxDJxiVtP5jNBHC0gsWTPeWYIW1Ti5eN/ rBC2osS+/ulAvRxgx63fpQ/RqigxpfshO8ReQYmTM5+wTGAUm4Vk6iyEjllIOmYh6VjAyLKK kaO0OLUsN93IYBMjMFKOSbDp7mDc89LyEKMAB6MSD++DfZuChVgTy4orcw8xSnOwKInzzqqd FywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMWvXpU/WcyotqqKZPG+3d2jcNvC1/l9vcKWF QX7KeT3RTYH7V25u2fBaXc/Mt/vRrm2Z8hw8WtazFlk6feXZ06Cqmv/fy0JmxYFMrfIVn5yO 5rYVLM4KlhKJ9bbLe7dx0tWvU35wc/G59L9vN9LOmXnpysNH09/E73VhEHl0csMk+YTZhtPW K7EUZyQaajEXFScCADxjwSF1AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ZCcomE8Y3aYNgsORTmn_4VaUN38 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 17:15:37 -0000 SGkgTWFjaCwNCnRoYW5rIHlvdSBmb3IgeW91ciBmZWVkYmFjay4NCkluZGVlZCwgYm90aCBkcmFm dHMgaGF2ZSBjb21tb25hbGl0aWVzLg0KSSdtIGxvb2tpbmcgZm9yd2FyZCB0byB0aGUgZGlzY3Vz c2lvbiBpbiBUb3JvbnRvIGFuZCBob3cgd2UgY2FuIGJyaW5nIHRoaXMgaWRlYSBmdXJ0aGVyLg0K DQoJUmVnYXJkcywNCgkJR3JlZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog TWFjaCBDaGVuIFttYWlsdG86bWFjaC5jaGVuQGh1YXdlaS5jb21dIA0KU2VudDogVHVlc2RheSwg SnVseSAwMSwgMjAxNCA2OjU3IFBNDQpUbzogR3JlZ29yeSBNaXJza3kNCkNjOiBydGctYmZkQGll dGYub3JnDQpTdWJqZWN0OiBSRTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1t aXJza3ktbXBscy1iZmQtZGlyZWN0ZWQtMDAudHh0DQoNCkhpIEdyZWcsDQoNCkkgaGF2ZSBhIHF1 aWNrIHJldmlldyBvbiB0aGUgZHJhZnQsIHdlbGwgd3JpdHRlbiBhbmQgdXNlZnVsIGRyYWZ0IQ0K DQpDb3VwbGUgeWVhcnMgYWdvLCB3ZSBzdWJtaXR0ZWQgYSBkcmFmdCAoaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtY2hlbi1tcGxzLWJmZC1lbmhhbmNlbWVudC0wMSkgdGhhdCBpbnRl bmQgdG8gc29sdmUgdGhlIHNpbWlsYXIgaXNzdWUsIGdsYWQgd2UgaGF2ZSB0aGUgc2ltaWxhciB0 aG91Z2h0Oi0pLg0KDQpJdCBhbHNvIGRlZmluZXMgZXh0ZW5zaW9ucyB0byBMU1AgUGluZyB0byBk aXJlY3QgdGhlIGNob29zZSBvZiB0aGUgcmV0dXJuIHBhdGggb2YgQkZEIGNvbnRyb2wgcGFja2V0 cy4gUGxlYXNlIHRha2UgYSBsb29rLg0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNoDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdyZWdvcnkgDQo+IE1pcnNreQ0KPiBTZW50OiBX ZWRuZXNkYXksIEp1bHkgMDIsIDIwMTQgMjoxOSBBTQ0KPiBUbzogbXBsc0BpZXRmLm9yZzsgcnRn LWJmZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciANCj4gZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkLTAwLnR4dA0KPiANCj4gRGVhciBB bGwsDQo+IHdlJ3ZlIHBvc3RlZCBhIG5ldyBkcmFmdC4gTFNQIFBpbmcgYWxyZWFkeSBpcyB1c2Vk IHRvIGJvb3RzdHJhcCBhIEJGRCANCj4gc2Vzc2lvbiB3aXRoIEJGRCBEaXNjcmltaW5hdG9yIFRM Vi4gQSBuZXcgQkZEIFJldmVyc2UgUGF0aCBUTFYgaXMgDQo+IGludHJvZHVjZWQgaW4gb3JkZXIg dG8gaW5zdHJ1Y3QgYSBmYXItZW5kIEJGRCBwZWVyIHRvIHVzZSBwYXJ0aWN1bGFyIA0KPiBwYXRo IGZvciByZXZlcnNlIGRpcmVjdGlvbiBvZiB0aGUgQkZEIHNlc3Npb24uDQo+IA0KPiBHcmVhdGx5 IGFwcHJlY2lhdGUgeW91ciBxdWVzdGlvbnMsIGNvbW1lbnRzLg0KPiANCj4gCVJlZ2FyZHMsDQo+ IAkJR3JlZw0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiBT ZW50OiBNb25kYXksIEp1bmUgMzAsIDIwMTQgNDoxNSBQTQ0KPiBUbzogR3JlZ29yeSBNaXJza3k7 IElseWEgVmFybGFzaGtpbjsgSmVmZiBUYW50c3VyYTsgR3JlZ29yeSBNaXJza3k7IA0KPiBKZWZm IFRhbnRzdXJhOyBJbHlhIFZhcmxhc2hraW4NCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciANCj4gZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkLTAwLnR4dA0KPiAN Cj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0 ZWQtMDAudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgR3JlZyBNaXJz a3kgYW5kIHBvc3RlZCB0byB0aGUgSUVURiANCj4gcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlk cmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQNCj4gUmV2aXNpb246CTAwDQo+IFRpdGxlOgkJ QmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBEaXJlY3RlZCBSZXR1cm4g UGF0aA0KPiBEb2N1bWVudCBkYXRlOgkyMDE0LTA2LTMwDQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBT dWJtaXNzaW9uDQo+IFBhZ2VzOgkJOA0KPiBVUkw6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMC4NCj4gdHh0DQo+ IFN0YXR1czoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWlyc2t5 LW1wbHMtYmZkLWRpcmVjdGVkLw0KPiBIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkLTAwDQo+IA0KPiANCj4gQWJz dHJhY3Q6DQo+ICAgIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgaXMg ZXhwZWN0ZWQgdG8gbW9uaXRvciBiaS0NCj4gICAgZGlyZWN0aW9uYWwgcGF0aHMuICBXaGVuIGZv cndhcmQgZGlyZWN0aW9uIG9mIGEgQkZEIHNlc3Npb24gaXMgdG8NCj4gICAgbW9uaXRvciBleHBs aWNpdGx5IHJvdXRlZCBwYXRoIHRoZXJlIGlzXCBhIG5lZWQgdG8gYmUgYWJsZSB0byBkaXJlY3QN Cj4gICAgZmFyLWVuZCBCRkQgcGVlciB0byB1c2Ugc3BlY2lmaWMgcGF0aCBhcyByZXZlcnNlIGRp cmVjdGlvbiBvZiB0aGUgQkZEDQo+ICAgIHNlc3Npb24uDQo+IA0KPiANCj4gDQo+IA0KPiBQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZiANCj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJp YXQNCg0K From nobody Wed Jul 2 11:51:47 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D925A1A0395 for ; Wed, 2 Jul 2014 11:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6OGtVeR9CpX for ; Wed, 2 Jul 2014 11:51:42 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76F2B1B284F for ; Wed, 2 Jul 2014 11:51:42 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-6f-53b4006968f4 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id AB.8D.25146.96004B35; Wed, 2 Jul 2014 14:51:53 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Wed, 2 Jul 2014 14:51:40 -0400 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15) Thread-Topic: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15) Thread-Index: AQHPlIHIBsIOBJkus0+CAihl2Ab3jJuM1HOQgABPSCA= Date: Wed, 2 Jul 2014 18:51:38 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7E5CAF@eusaamb103.ericsson.se> References: <20140630163846.GA11842@pfrc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyuXRPgm4mw5Zgg09nFCz2H3zLajG7I97i 859tjA7MHlN+b2T1WLLkJ5PH5d6trAHMUVw2Kak5mWWpRfp2CVwZp7Z3shWc46p4uXk/WwPj WY4uRg4OCQETiU0bg7oYOYFMMYkL99azdTFycQgJHGWUuLjyHTOEs4xRYv7vBlaQKjYBI4kX G3vYQWwRgQKJj9N2sIHYwgIhEhem9TNBxEMl1m85xwphW0lM3vWUDWQZi4CKxJ5FgSBhXgFf idMXWhhBbCGBHIk17c1g5ZxA8YbXd1lAbEagg76fWgM2kllAXOLWk/lMEIcKSCzZc54ZwhaV ePn4HyuErSixr386O0S9jsSC3Z/YIGxtiWULXzND7BWUODnzCcsERtFZSMbOQtIyC0nLLCQt CxhZVjFylBanluWmGxluYgRGxzEJNscdjAs+WR5iFOBgVOLhfbBvU7AQa2JZcWXuIUZpDhYl cV7N6nnBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgNrt74XiKx7XDvXXUlfyeHF6Ese70f TZutd6i44GHKS9UZBbu7zU0jsleIt2YoveW6nrq6QOR+2o8XN4q3z9x37NPzibdsT+Wtjb6z /JRll2PMqt/lQsFiFx9LBF2/Zsus0BBbtfgqh9f6F9luP1+sNkvfpvfxwR51u8Bin09P5ae9 uXpv4frNSizFGYmGWsxFxYkAKhx/ZW8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/hi9Gu58vIzelyBuF4_h_qXJE2p0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 18:51:45 -0000 Hi Jeff, I completely agree with my co-author Nobo. The document is concise and would help to improve interoperability of BFD i= mplementations. The document is ready for publication. Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (no= bo) Sent: Wednesday, July 02, 2014 7:07 AM To: Jeffrey Haas; rtg-bfd@ietf.org Subject: RE: Working Group Last Call for draft-ietf-bfd-intervals (ending J= uly 15) Hi Jeff, As a co-author of this document, I believe the document provides helpful in= formation and is ready for publication. Thanks! -Nobo > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey=20 > Haas > Sent: Monday, June 30, 2014 12:39 PM > To: rtg-bfd@ietf.org > Subject: Working Group Last Call for draft-ietf-bfd-intervals (ending=20 > July 15) >=20 > Working Group, >=20 > We would like to initiate the start of Working Group Last Call for=20 > Common Interval Support in BFD: >=20 > http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 >=20 > Note that the intended status of this document is INFORMATIONAL. >=20 > Please send your comments, including whether you think the draft is=20 > ready for publication or not, to the list no later than July 15. >=20 > -- Jeff and Nobo From nobody Wed Jul 2 12:45:16 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D498D1B289E for ; Wed, 2 Jul 2014 12:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAGxBGcQFIOM for ; Wed, 2 Jul 2014 12:45:12 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E08C1B289A for ; Wed, 2 Jul 2014 12:45:12 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-c1-53b40f5f9b91 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id DC.60.05330.F5F04B35; Wed, 2 Jul 2014 15:55:44 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Wed, 2 Jul 2014 15:45:09 -0400 From: Jeff Tantsura To: Jeffrey Haas Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15) Thread-Topic: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15) Thread-Index: AQHPlIHItRQ+GpYAf0CwGjX5BtQOoZuNF9wAgABPfQD//8vmCg== Date: Wed, 2 Jul 2014 19:45:09 +0000 Message-ID: <4E7F539A-3E04-44BA-BC03-F59A316ADF7F@ericsson.com> References: <20140630163846.GA11842@pfrc> , <7347100B5761DC41A166AC17F22DF1121B7E5CAF@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7E5CAF@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyuXRPrG4C/5Zgg5X9vBb7D75ltZjdEW/x +c82Rgdmjym/N7J6LFnyk8njcu9W1gDmKC6blNSczLLUIn27BK6MmftPMBZ846lYsnonYwPj Rq4uRg4OCQETiQPfrboYOYFMMYkL99azdTFycQgJHGWUuPDsFyuEs4xR4tSuB8wgVWwCBhL/ vx1nAbFFBBQl5v/vZAOxmQUCJda/esYOYgsLhEhMn7KaHaImVGL9lnOsELaTxPSNrUwgNouA isTL3yvAangF7CUefe+GWraOUWLe2nlgCzgF/CRu7LsI1sAIdN73U2uYIJaJS9x6Mp8J4mwB iSV7zjND2KISLx//Y4Wo0ZFYsPsT1HHaEssWvmaGWCYocXLmE5YJjKKzkIyahaRlFpKWWUha FjCyrGLkKC1OLctNNzLYxAiMkGMSbLo7GPe8tDzEKMDBqMTD+2DfpmAh1sSy4srcQ4zSHCxK 4ryzaucFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBk/73V6c5kkxm9zzWO8m/pVFj+b0Np i8bTzgpV9aNlLYH79t78v0qob55xUvrbfYUPJ/B1XNJneHh1ZlfR7imxu5sLWic9Pvrh1uEt 1u0aFpN2tZacY797gf0Rl+QL6TPRliqcHCVMGzclLVh1r+PUPP/JXzXvRPyMVZ8qN33Z4Zdv 9yaXPkk+rMRSnJFoqMVcVJwIAGI3ZqRxAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/h9EKRZt_d7vsUaV8Cwi4u_VcqV4 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 19:45:14 -0000 Hi, Support this draft, not much to add to the points authors have already brou= ght. Regards, Jeff > On Jul 2, 2014, at 11:51 AM, "Gregory Mirsky" wrote: >=20 > Hi Jeff, > I completely agree with my co-author Nobo. > The document is concise and would help to improve interoperability of BFD= implementations. > The document is ready for publication. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (= nobo) > Sent: Wednesday, July 02, 2014 7:07 AM > To: Jeffrey Haas; rtg-bfd@ietf.org > Subject: RE: Working Group Last Call for draft-ietf-bfd-intervals (ending= July 15) >=20 > Hi Jeff, >=20 > As a co-author of this document, I believe the document provides helpful = information and is ready for publication. >=20 > Thanks! >=20 > -Nobo >=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey=20 >> Haas >> Sent: Monday, June 30, 2014 12:39 PM >> To: rtg-bfd@ietf.org >> Subject: Working Group Last Call for draft-ietf-bfd-intervals (ending=20 >> July 15) >>=20 >> Working Group, >>=20 >> We would like to initiate the start of Working Group Last Call for=20 >> Common Interval Support in BFD: >>=20 >> http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 >>=20 >> Note that the intended status of this document is INFORMATIONAL. >>=20 >> Please send your comments, including whether you think the draft is=20 >> ready for publication or not, to the list no later than July 15. >>=20 >> -- Jeff and Nobo >=20 From nobody Wed Jul 2 15:52:23 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A041B2916 for ; Wed, 2 Jul 2014 15:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.152 X-Spam-Level: X-Spam-Status: No, score=-114.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_BACKHAIR_42=1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyX5sqspcyYN for ; Wed, 2 Jul 2014 15:52:12 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7203F1A0ACB for ; Wed, 2 Jul 2014 15:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22893; q=dns/txt; s=iport; t=1404341532; x=1405551132; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=87rPbNOy4CewynoS+MVSDU/BfT9vMjH8Vm7Qezr2hZE=; b=MiLu2nU2KGCxx1tk+eJ3aqJ0vfJaiVAnjNUghCP1oK9uiLp7KVKi25LY RkjWx29bwJ1KXYF5NpkId+K/85VWsuKAswM1CFaB1SrUjNtJUZva8ry1x 1N4vgvVUQAfrr1FjihtaAcwyzT7AsNL7zdI38avgdsbCpPrIPyNj6RFvj c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroFAHCMtFOtJV2a/2dsb2JhbABagmkkUk0GB8YjAYEJFnWEAwEBAQMBGg0TPwUHBAIBCBEEAQEBChQJBzIUCQgCBA4FCAGIMQgBBwXHWheJZYUMMQcGgyeBFgWcNZJCg0NsgUQ X-IronPort-AV: E=Sophos;i="5.01,591,1400025600"; d="scan'208";a="337463809" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 02 Jul 2014 22:52:11 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s62MqAQH018076 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jul 2014 22:52:10 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Wed, 2 Jul 2014 17:52:10 -0500 From: "Nobo Akiya (nobo)" To: "Marc Binderberger (mbinderb)" Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt Thread-Topic: I-D Action: draft-ietf-bfd-seamless-base-01.txt Thread-Index: AQHPkW78JeCHvpBJ/EuFcrJj+qOrd5uEE1MA///0AsCABPuAAIABQrxwgADQbICAADHHoIAAecuAgAGmbbA= Date: Wed, 2 Jul 2014 22:52:10 +0000 Message-ID: References: <20140626182533.30391.72279.idtracker@ietfa.amsl.com> <8fe58c80d3ba4e0da4da3e82cf7677dc@BLUPR05MB755.namprd05.prod.outlook.com> <20140629152450732481.c07ee0d4@sniff.de> <20140630230555087199.19db4b6d@sniff.de> <20140701091959093415.e0c0ca19@cisco.com> In-Reply-To: <20140701091959093415.e0c0ca19@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.248.229] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/SUkC7ch-9q1UGsVgACQ7DAVSj0o Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 22:52:19 -0000 Hello Marc, > -----Original Message----- > From: Marc Binderberger (mbinderb) > Sent: Tuesday, July 01, 2014 12:20 PM > To: Nobo Akiya (nobo) > Cc: Marc Binderberger; Santosh P K; rtg-bfd@ietf.org > Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt >=20 > Hello Nobo, >=20 >=20 > > S-BFD on the other hand will have one port for all use of S-BFD, > > except for IP-less case. > > Ed-Note: Discuss whether we want a new associated channel type for > > S-BFD. > > > > But perhaps we should create a separate document for IP-less. >=20 > hmm, that is a bit a circle. If you have already IP-less on the todo list= then > why not structure the documents accordingly? >=20 > If I understand right what you require from the outer frame mechanism is > this: your outer frame must be able to distinguish S-BFD from other (BFD) > traffic (ex: UDP port assigned for S-BFD). >=20 > Then define the UDP port, the IP address copying/selection in seamless IP= . > I mention this as I think the structure of 5880 + 5881/5883/5884/[...] wa= s > quite useful. Agree, it's not the prettiest either way. But we also may not want IP, SR, = SFC, etc documents to repeat the UDP port and procedures either. So we figu= red we define the UDP port and procedures as a core portion in the base doc= ument, and treat IP-less as a special case. >=20 > Anyway, "yeah I think it's reasonable" still holds. :-) Thanks :) We'll proceed down the current path unless there are objections. >=20 >=20 > > Regarding SBFDReflector reflecting the state, I do see your point. If > > the state of received S-BFD packet is reflected by the SBFDReflector, > > then the SBFDInitiator requires no FSM changes (i.e. able to re-use > > FSM from RFC5880). Although that will result in time(2 * (RTT + Tr)) > > for the SBFDInitiator to reach UP state. In reality, it actually would > > be time((2 * (RTT _ Tr)) + tx_gap) where "tx_gap" is the interval > > between the 2 packets transmitted. I do think one of the strength of > > S-BFD is the fact it only takes one packet to complete the > > connectivity test. Thus I'm leaning towards standing the ground of > > SBFDReflector only being able to send [UP, ADMINDOWN] states, and not > reflecting received state. >=20 > No, you may not see my new point yet :-) While discussing with you I > realized the Reflector should not impose any state machine model. Dumb > reflection of the state provides full control to the Initiator side which= can > implement any state machine it likes. > For your Down<->Up machine, it's possible too with the state reflection. = You > need one additional rule >=20 > if (bfd.SessionType =3D=3D SBFDInitiator): > set state in outgoing BFD packet to "Up". >=20 I think it'll be more like: If (bfd.SessionType =3D=3D SBFDInitiator) { Set local state in outgoing BFD packet; /* where local state is either UP or ADMINDOWN */ } Where what you are suggesting will likely require: If (bfd.SessionType =3D=3D SBFDInitiator) { If (local state =3D=3D ADMINDOWN) { Set state in outgoing BFD packet to "ADMINDOWN"; } else { Copy received state to the state in outgoing BFD packet; } } > Carrying this a step further: I do not see why vendor X could not use a > different state machine than vendor Y. The interop is guaranteed by the > same definition of what the reflector does. Assuming you are talking about SBFDInitiator, then yes I agree: vendor can = chose any state machine. And as you said, we just have to converge and stan= dardize how SBFDReflector behaves. >=20 > And yes, I realized your state machine does it with a single packet and I= 'm > not arguing against this improvement. Frankly, I see both ways (what's currently in the document as well as what = you suggested) to work reasonable well. We may need others to chime to deci= de which way to move forward. Anyone?? >=20 >=20 > > This is a valuable comment, and I do like your suggestion of auto-foo b= eing > > in a separate document (than base). > > > > Do you think current texts in "5. S-BFD Discriminators" section is > > sufficient to imply this? >=20 > I think section 5 is fine and we can leave certain aspects between the li= nes. > Even my "complicated" comment with "M least significant bits" for a manua= l > configuration is nothing we should write down. I only mentioned it here t= o > see if it stirs up something, some concern. But otherwise common sense > and > silent agreements will probably get us towards some basic 32-bit > manual-config implementations for day-1. Well, I hope so :-) Good stew requires good stirring :) Thanks! -Nobo >=20 >=20 > Regards, Marc >=20 >=20 > On Tue, 1 Jul 2014 07:32:36 -0700, Nobo Akiya (nobo) wrote: > > Hi Marc, > > > >> -----Original Message----- > >> From: Marc Binderberger [mailto:marc@sniff.de] > >> Sent: Tuesday, July 01, 2014 2:06 AM > >> To: Nobo Akiya (nobo) > >> Cc: Santosh P K; rtg-bfd@ietf.org; Marc Binderberger (mbinderb) > >> Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt > >> > >> Hello Nobo, > >> > >>> One of the changes from draft-ietf-bfd-seamless-base-00 to > >>> draft-ietf-bfd-seamless-base-01 to take out all IP related procedures > >>> and move it over to draft-akiya-bfd-seamless-base-ip-03. Intent of th= e > >>> authors is to: > >> > >> okay, so having an IP/UDP header is a fixed part of S-BFD then? It's = not > >> as > >> agnostic as RFC5880 is regarding the frame around the BFD packets? > >> > >> I wasn't sure about this, thus my comment. If IP/UDP is an inherent pa= rt > >> of S- > >> BFD then ... > >> > >>> it would be helpful to hear "yeah above is reasonable" or "let's > >>> structure it this way" from you and the WG. > >> > >> yeah I think it's reasonable :-) > > > > Thanks! To answer your questions above ... > > > > I believe RFC5880 focuses on the BFD header alone since ports are > different > > for various use of the BFD (i.e. SH, MH, MPLS). > > S-BFD on the other hand will have one port for all use of S-BFD, except= for > > IP-less case. > > So, except for the exception case (i.e. IP-less), current S-BFD documen= t > > structure is a reasonable (or not a bad) fit. > > > > Thinking more on the exception ... S-BFD-IP document has: > > > > Ed-Note: Discuss whether we want a new associated channel type for > > S-BFD. > > > > But perhaps we should create a separate document for IP-less. > > > >> > >> > >> About the state machine > >> > >>> This comment looks familiar :) > >> > >> I think I repeat myself ;-) but there is a reason. Nothing wrong with = the > >> state > >> machine you propose but I do not see this must be part of the definiti= on. > >> As > >> an appendix, to show S-BFD allows for other state machines than 5880, > that > >> would be educational. > >> > >> As explained I prefer a more open approach, the reflector truly reflec= ting > >> the state as well. Your state engine is then solely driven by the > >> initiator. > >> Just setting the state to Up on the reflector is removing this degree = of > >> freedom, unnecessary IMHO and reducing the ability to "play" with the = S- > >> BFD definition. > >> > >>> - Move the SBFDInitiator State Machine section to appendix. > >> > >> I would like that! > > > > ACK on moving the example state machine to appendix (some texts will > still > > be kept around in the current section). > > > > Regarding SBFDReflector reflecting the state, I do see your point. If t= he > > state of received S-BFD packet is reflected by the SBFDReflector, then = the > > SBFDInitiator requires no FSM changes (i.e. able to re-use FSM from > > RFC5880). Although that will result in time(2 * (RTT + Tr)) for the > > SBFDInitiator to reach UP state. In reality, it actually would be time(= (2 * > > (RTT _ Tr)) + tx_gap) where "tx_gap" is the interval between the 2 pack= ets > > transmitted. I do think one of the strength of S-BFD is the fact it onl= y > > takes one packet to complete the connectivity test. Thus I'm leaning > > towards standing the ground of SBFDReflector only being able to send [U= P, > > ADMINDOWN] states, and not reflecting received state. > > > >> > >> From your reply > >> > >>> True, but you forgot the aspect of: > >>> > >>> BFD: > >>> - in case of MPLS, LSP ping bootstraps the session on egress > >>> - session is created > >>> - tx timer is started at no faster than 1 second > >>> > >>> S-BFD: > >>> - no LSP ping bootstrapping > >>> - session is created > >>> - packet can get tx'ed right away > >>> > >>>> From above aspect, "considerable" delay (i.e. couple of seconds) is > >>>> shaved off :) > >> > >> > >> What I like from your reply and what maybe should be more pointed in > the > >> draft are exactly the aspects that make S-BFD fast. Yes, you do say it > >> somehow in section 3 and section 1, 2nd paragraph. Maybe a nitpick bu= t > you > >> could talk about your design principles more explicitly. Example from > >> section > >> 3: > >> > >> Required result is that application= s, > >> on other network nodes, possess the knowledge of the mapping from > >> remote entities to S-BFD discriminators. > >> > >> What you probably want to say is that S-BFD is requiring the distribut= ion > >> of > >> the mapping before a session is even requested (principle: fast setup)= . > >> Then > >> logically discriminators are allocated per (system, entity) and not pe= r > >> session. Again, you say it somehow in the text but you actually do not > >> demand this principle. > > > > Make sense, let us expand a bit more on why S-BFD will result in faster > > setup than BFD, in the next revision. > > > >> > >> > >>> Agree, this seems to be the direction we are heading, and I think it > >>> is reasonable. However, I (we?) do see a need for auto-foo, where foo > >>> may be "S-BFD discriminator allocation", "collision detection", > >>> "collision correction" or combination of them. > >> > >> no doubt about the auto-foo but I assume this is topic for another dra= ft? > >> If > >> so, then how can you make your S-BFD base draft working interoperable? > >> Thus my comment to define something very basic (manual) to have a > >> starting point. > >> Not because manual configs are so great. > >> (although: in these days of central controllers and software-defined > >> networks maybe "manual" or it's API equivalent is all that is needed := -) > > > > This is a valuable comment, and I do like your suggestion of auto-foo b= eing > > in a separate document (than base). > > > > Do you think current texts in "5. S-BFD Discriminators" section is > > sufficient to imply this? > > > > Thanks! > > > > -Nobo > > > >> > >> > >> Regards, Marc > >> > >> > >> > >> > >> > >> On Mon, 30 Jun 2014 23:18:00 +0000, Nobo Akiya (nobo) wrote: > >>> Hi Marc, > >>> > >>>> -----Original Message----- > >>>> From: Marc Binderberger [mailto:marc@sniff.de] > >>>> Sent: Sunday, June 29, 2014 6:25 PM > >>>> To: Nobo Akiya (nobo); Santosh P K > >>>> Cc: rtg-bfd@ietf.org; Marc Binderberger (mbinderb) > >>>> Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt > >>>> > >>>> Hello Santosh and Nobo, > >>>> > >>>> good stuff. Every time I read it I find something new to learn :-) > >>> > >>> As always, thanks for comments! > >>> > >>>> > >>>> Re-reading the draft I had a few thoughts: > >>>> > >>>> 1) the draft is a "base" but it actually defines some details I woul= d > >>>> have expected in other drafts. One example is the IP/UDP header. Yes= , > >>>> IP is everywhere but what about applications where you don't require > >>>> IP ? Or the other way around: why having an extra "bfd-seamless-ip" > >>>> draft when IP/UDP is an essential part of the base draft? > >>> > >>> One of the changes from draft-ietf-bfd-seamless-base-00 to > >>> draft-ietf-bfd-seamless-base-01 to take out all IP related procedures > >>> and move it over to draft-akiya-bfd-seamless-base-ip-03. Intent of th= e > >>> authors is to: > >>> > >>> 1) Focus s-bfd-base on the procedures for UDP header and BFD header. > >>> 2) Focus s-bfd-ip on the procedures for IP header and MPLS. > >>> 3) Add ip-less procedures (i.e. associated channel) in either s-bfd-i= p > >>> or create a separate draft (i.e. s-bfd-ip-less). > >>> 4) s-bfd-sr to be worked on at a later time. > >>> > >>> Since we are only defining one port for S-BFD, this made sense to > >>> those who worked on the recent changes to the S-BFD documents. > >>> > >>> Yes there are alternative ways to structure the documents. That being > >>> said, it would be helpful to hear "yeah above is reasonable" or "let'= s > >>> structure it this way" from you and the WG. > >>> > >>>> > >>>> > >>>> 2) similar the details of the state machine is something I think you > >>>> do not really need in the base draft (!). Just define the reflector > >>>> as truly reflecting the state from the incoming packet (plus > >>>> overwrite with AdminDown) and you then leave it to the initiator if > >>>> it uses a new state machine or the > >>>> 5880 Down-Init-Up sequence or something completely different. > >>> > >>> This comment looks familiar :) > >>> > >>> Texts above the state machine now says: > >>> > >>> For > >>> persistent SBFDInitiators, the states and the state machine descri= bed > >>> in [RFC5880] will function but are more than necessary. The > >>> following diagram provides an optimized state machine for persiste= nt > >>> SBFDInitiators. > >>> > >>> And after the diagram: > >>> > >>> Note that the above state machine is different from the base BFD > >>> specification[RFC5880]. This is because the Init state is no long= er > >>> applicable for the SBFDInitiator. Another important difference is > >>> the transition of the state machine from the Down state to the Up > >>> state when a packet with State Up is received by the initiator. > >>> > >>> I think the texts and the described state machine is helpful for > >>> reader to better understand how S-BFD operates. So I prefer that this > >>> section remains somewhere to give better ideas to readers on how > >>> SBFDInitiators can be implemented. So, I think we have few options. > >>> > >>> - Texts in the s-bfd-base-01 is sufficiently reasonable. > >>> - Further texts should be added to make it more obvious that describe > >>> state machine is not mandatory. > >>> - Move the SBFDInitiator State Machine section to appendix. > >>> > >>> Thoughts? > >>> > >>>> > >>>> S-BFD is largely about the reflector, I would say. Your draft brings > >>>> up a good > >>>> point: the state machine details are not relevant for interop as lon= g > >>>> as it stays within the definition of the reflector. > >>> > >>> Yes I agree. > >>> > >>>> > >>>> > >>>> 3) Actually I do not agree with statements in the draft about the > >>>> 5880 state machine "may not be applicable" or that your proposal is > >>>> better suited for the initial delay to bring BFD sessions up. Your > >>>> state machine requires > >>>> > >>>> RTT + Tr > >>>> > >>>> the original 5880 takes > >>>> > >>>> 2 * (RTT + Tr). > >>>> > >>>> (RTT: Round Trip Time, Tr: the processing time of the reflector) > >>>> > >>>> True, that is faster ;-) but I'm not sure you had this in mind. And > >>>> if > >>>> O(RTT+Tr) is relevant then you _do_ have a "considerable" delay too > >>>> and are not "seamless" anymore :-) > >>> > >>> True, but you forgot the aspect of: > >>> > >>> BFD: > >>> - in case of MPLS, LSP ping bootstraps the session on egress > >>> - session is created > >>> - tx timer is started at no faster than 1 second > >>> > >>> S-BFD: > >>> - no LSP ping bootstrapping > >>> - session is created > >>> - packet can get tx'ed right away > >>> > >>>> From above aspect, "considerable" delay (i.e. couple of seconds) is > >>>> shaved off :) > >>> > >>>> > >>>> > >>>> 4) The D-Flag ... forgot what I wanted to say :-) > >>> > >>> LOL, I do that often too. > >>> > >>>> 4) The D-Flag ... forgot what I wanted to say :-) > >>> > >>> LOL, I do that often too. > >>> > >>>> 4) The D-Flag ... forgot what I wanted to say :-) > >>> > >>> Wait, didn't I reply to this already? :) > >>> > >>>> Mainly, if you define the > >>>> behaviour you expect on the reflector then you don't need to make > any > >>>> statements or attempts to be "5880 compliant". > >>> > >>> Agree, I don't think S-BFD is trying to be compliant with RFC5880, bu= t > >>> S-BFD is trying to keep as much the same semantics possible with BFD > >>> so that we are not re-inventing everything. > >>> > >>>> > >>>> > >>>>> - Greatly seeking comments on how we move forward with S-BFD > >>>>> discriminator uniqueness requirements. > >>>> > >>>> You mean how to be unique? Or if uniqueness is necessary? > >>>> For the "how", I propose that a manual option to set a "unique > >>>> discriminator" > >>>> is a requirement. Does not exclude smarter, automatic methods but it > >>>> gets you started. > >>> > >>> Agree, this seems to be the direction we are heading, and I think it > >>> is reasonable. However, I (we?) do see a need for auto-foo, where foo > >>> may be "S-BFD discriminator allocation", "collision detection", > >>> "collision correction" or combination of them. > >>> > >>>> > >>>> Every implementation must allow to configure a unique value within > >>>> the least significant M bits of the discriminator. M is > >>>> implementation specific, recommendation is M >=3D 16. So yes, this > >>>> wouldn't be the router-id then but a bfd-id. Pardon, sbfd_id ;-) > >>> > >>> For connectivity (i.e. reachability) test purpose, a system will need > >>> one sbfd-id [or more]. For other applications of S-BFD, there may be = a > >>> need for a system to allocate few tens of S-BFD discriminators. So, > >>> this really places more weight on the "uniqueness" requirement and > the > >>> need for auto-foo. > >>> > >>> Thanks! > >>> > >>> -Nobo > >>> > >>>> > >>>> > >>>> Regards, Marc > >>>> > >>>> > >>>> > >>>> On Thu, 26 Jun 2014 23:32:03 +0000, Nobo Akiya (nobo) wrote: > >>>>> Hello BFDers, > >>>>> > >>>>> Yes, many thanks to those provided comments on S-BFD. > >>>>> > >>>>> Couple of additional things: > >>>>> > >>>>> draft-ietf-bfd-seamless-base-01 > >>>>> - Contains significant changes from the previous version. > >>>>> - There should not be any technical changes. > >>>>> - Greatly seeking comments on how we move forward with S-BFD > >>>>> discriminator uniqueness requirements. > >>>>> > >>>>> draft-akiya-bfd-seamless-ip-03 > >>>>> - Just published, links below. > >>>>> - Seeking comments on whether we want to define a new > associated > >>>>> channel type for S-BFD. > >>>>> > >>>>> URL: > >>>>> http://www.ietf.org/internet-drafts/draft-akiya-bfd-seamless-ip-03.= t > >>>>> xt > >>>>> Status: > >>>>> https://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ > >>>>> Htmlized: > >>>>> http://tools.ietf.org/html/draft-akiya-bfd-seamless-ip-03 > >>>>> Diff: > >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-akiya-bfd-seamless-ip-03 > >>>>> > >>>>> Thanks! > >>>>> > >>>>> -Nobo > >>>>> > >>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > Santosh > >>>>> P K > >>>>> Sent: Thursday, June 26, 2014 3:03 PM > >>>>> To: rtg-bfd@ietf.org > >>>>> Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt > >>>>> > >>>>> Hello All, > >>>>> S-BFD version 1 is published. Thanks to all who had provided > >> comments. > >>>>> Diff between version 0 and 1 is significant but there are no > >>>>> technical changes. Below are the changes. > >>>>> > >>>>> 1. Taken care of all review comments. > >>>>> 2. "Full/partial reachability" is removed and focus is on the > >>>>> reachability. > >>>>> 3. SPRING dependency is removed. > >>>>> 4. IP specific details has been moved to > >>>>> "draft-akiya-bfd-seamless- > >>>>> ip". > >>>>> 5. Consistent terminology. > >>>>> 6. Lots of rephrasing for better readability. > >>>>> > >>>>> Thanks > >>>>> Santosh P K > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > >>>>> internet-drafts@ietf.org > >>>>> Sent: Thursday, June 26, 2014 11:56 PM > >>>>> To: i-d-announce@ietf.org > >>>>> Cc: rtg-bfd@ietf.org > >>>>> Subject: I-D Action: draft-ietf-bfd-seamless-base-01.txt > >>>>> > >>>>> > >>>>> 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 : Seamless Bidirectional Forwarding Detecti= on > >>>>> (S-BFD) > >>>>> Authors : Nobo Akiya > >>>>> Carlos Pignataro > >>>>> Dave Ward > >>>>> Manav Bhatia > >>>>> Juniper Networks > >>>>> Filename : draft-ietf-bfd-seamless-base-01.t= xt > >>>>> Pages : 17 > >>>>> Date : 2014-06-26 > >>>>> > >>>>> Abstract: > >>>>> This document defines a simplified mechanism to use Bidirectiona= l > >>>>> Forwarding Detection (BFD) with large portions of negotiation > aspects > >>>>> eliminated, thus providing benefits such as quick provisioning a= s > >>>>> well as improved control and flexibility to network nodes initia= ting > >>>>> the path monitoring. > >>>>> > >>>>> This document updates RFC5880. > >>>>> > >>>>> > >>>>> > >>>>> The IETF datatracker status page for this draft is: > >>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ > >>>>> > >>>>> There's also a htmlized version available at: > >>>>> http://tools.ietf.org/html/draft-ietf-bfd-seamless-base-01 > >>>>> > >>>>> A diff from the previous version is available at: > >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-seamless-base-01 > >>>>> > >>>>> > >>>>> Please note that it may take a couple of minutes from the time of > >>>>> submission until the htmlized version and diff are available at > >>>>> tools.ietf.org. > >>>>> > >>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>> > >>> From nobody Wed Jul 2 17:15:17 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A021A0AC7; Wed, 2 Jul 2014 17:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCH8HVUrJj9M; Wed, 2 Jul 2014 17:15:10 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEFCA1A0AC6; Wed, 2 Jul 2014 17:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7386; q=dns/txt; s=iport; t=1404346510; x=1405556110; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gBJBtnUfQSM1nPSg6a2HFOoHM9S0e/oSXTizf+q3+lY=; b=hDICCV7N3KNekAuXFsuPT4dTk2y8j96ZvJ9aUjq16bMnnQu3ITb1nIVe /6U950g/c/xCv/2l7dulqyR+CbQgZaU2fRzhQydbx/X6p3WkKGQp0PO5b LyC6NE7+srawWE66/JB733Ebm0Atg3Y6YLYMKLYg9CkV4CVYwCqlqtLM4 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFABagtFOtJA2I/2dsb2JhbABagmkkUlqCbsM1ARlwFnWEAwEBAQQjEUMCDAQCAQgRBAEBAwIGHQMCAgIwFAEICAIEAQ0FCAESiCcBDKtXnBEXgSyNRTEHBoJxNoEWBZZVhWCSQoNDgjA X-IronPort-AV: E=Sophos;i="5.01,591,1400025600"; d="scan'208";a="337366936" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP; 03 Jul 2014 00:15:09 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s630F8YI019039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jul 2014 00:15:09 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Wed, 2 Jul 2014 19:15:08 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , Mach Chen , "mpls@ietf.org" Subject: RE: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Topic: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Index: AQHPlLkmcHLo4kmCjEWzfUskF7x6bpuLglYggAB+rECAAQbgIIAAZ8Zg Date: Thu, 3 Jul 2014 00:15:08 +0000 Message-ID: References: <20140630231508.5203.4775.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B7E50F6@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7E5B9B@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7E5B9B@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.248.229] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/xFnaB6nAaRkqIlMA-hkEFA3J2II Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 00:15:12 -0000 SGkgR3JlZywgZXQgYWwsDQoNCkkgYWdyZWUgd2l0aCB0aGUgdG9waWMgYW5kIHVzZWZ1bG5lc3Mg b2YgY29udHJvbGxpbmcgdGhlIEJGRCByZXR1cm4gcGF0aCwgZXNwZWNpYWxseSBpbiBTZWdtZW50 IFJvdXRpbmcuDQoNCkEgcXVlc3Rpb24gYW5kIGNvdXBsZSBjb21tZW50cy4NCg0KT25lIHdheSB0 byBhY2hpZXZlIHRoZSBzYW1lIHNlbWF0aWMgaXMgdG8gaW50cm9kdWNlICJTZWdtZW50IFJvdXRp bmcgTVBMUyBUdW5uZWwgc3ViLVRMViIgYW5kICJTZWdtZW50IFJvdXRpbmcgSVB2NiBUdW5uZWwg c3ViLVRMViIgdW5kZXIgUmVwbHkgUGF0aCAoUlApIFRMViBkZWZpbmVkIGluIFJGQzcxMTAuIElz IHRoZXJlIGFueSBwYXJ0aWN1bGFyIHJlYXNvbiB3aHkgbmV3IFRMViB3YXMgaW50cm9kdWNlZD8g SSdtIG1haW5seSBqdXN0IGN1cmlvdXMgOikNCg0KVGhlcmUgYXJlIGNvdXBsZSBvZiB0aGluZ3Mg d29ydGggaGlnaGxpZ2h0aW5nIGFib3V0IHRoZSBCRkQgRGlzY3JpbWluYXRvciBUTFYgKGRlZmlu ZWQgaW4gUkZDNTg4NCksIG5vdCBkaXJlY3RseSBpbiB0aGUgc2NvcGUgb2YgeW91ciBkb2N1bWVu dCBidXQgdmVyeSByZWxldmFudCB3aGVuIGxvb2tpbmcgYXQgdXNpbmcgeW91ciBwcm9wb3NhbCBp biBTZWdtZW50IFJvdXRpbmcuDQoNCjEuIFRoZSBCRkQgRGlzY3JpbWluYXRvciBUTFYgYWxsb3dz IGJvb3RzdHJhcHBpbmcgb2Ygb25lIEJGRCBzZXNzaW9uIHBlciBGRUMuIFdoZW4gYm9vdHN0cmFw cGluZyBtb3JlIHRoYW4gb25lIEJGRCBzZXNzaW9uIHBlciBGRUMsIGl0IGlzIGRpZmZpY3VsdCB0 byBkbyBzbyB3aXRob3V0IG1ha2luZyBhc3N1bXB0aW9ucywgYXMgdGhlcmUgaXMgbm8gZGVmaW5l ZCBmaWVsZHMvcHJvY2VkdXJlcyB0byBkbyBzby4gVGhpcyB3aWxsIGJlY29tZSBtb3JlIG9mIGFu IGlzc3VlIHdpdGggU2VnbWVudCBSb3V0aW5nLCB3aGVuIHRoZXJlIGFyZSBtdWx0aXBsZSBleHBs aWNpdCBwYXRocyBjcmVhdGVkIGJldHdlZW4gYSBwYWlyIG9mIG5vZGVzLg0KDQoyLiBNYWludGVu YW5jZSBvZiBib290c3RyYXBwZWQgQkZEIHNlc3Npb25zIGlzIGZ1enp5LCBtZWFuaW5nIHdoZW4g c2hvdWxkIHRoZSBlZ3Jlc3MgZGVsZXRlIGJvb3RzdHJhcHBlZCBCRkQgc2Vzc2lvbnMuIE9uZSBj b3VsZCBpbXBsZW1lbnQgc3VjaCB0aGF0IHRoZSBlZ3Jlc3MgZGVsZXRlcyBCRkQgc2Vzc2lvbnMg d2hlbiBjb3JyZXNwb25kaW5nIEZFQyBpcyBkZWxldGVkLCBvciBYIGFtb3VudCBvZiB0aW1lIGFm dGVyIHNlc3Npb25zIGdvICJkb3duIi4gVGhlcmUncyBubyBGRUMvc3RhdGUgb24gdGhlIGVncmVz cyBmb3IgU2VnbWVudCBSb3V0aW5nLiAgVGh1cyBvbmx5IHJlbWFpbmluZyBvcHRpb24gdG9kYXkg aXMgdG8gZGVsZXRlIHRoZSBzZXNzaW9uIGFmdGVyIFggc2Vjb25kcy9taW51dGVzIG9uY2UgdGhl IHNlc3Npb24gaXMgaW4gImRvd24iIHN0YXRlLiBQZXJoYXBzIHRoaXMgZnV6emluZXNzIGlzIHJl YXNvbmFibGUsIG9yIHBlcmhhcHMgd2Ugd2FudCBleHBsaWNpdCAiZGVsZXRlIiBpbnN0cnVjdGlv biBmcm9tIHRoZSBpbmdyZXNzIHRvIHRoZSBlZ3Jlc3MuDQoNCkkgYmVsaWV2ZSBteSBjb2xsZWFn dWUgaXMgYWJvdXQgdG8gcm9sbCBvdXQgYSBkb2N1bWVudCBmb3IgRXh0ZW5kZWQgQkZEIERpc2Ny aW1pbmF0b3IgVExWIHdoaWNoIGFkZHJlc3NlcyAoMSkgYW5kICgyKSBhYm92ZS4gUHJpbWFyeSBt b3RpdmF0aW9uIG9mIHRoYXQgZG9jdW1lbnQgaXMgRVZQTiBCRkQsIGJ1dCBpdCBsb29rcyB2ZXJ5 IGFwcGxpY2FibGUgdG8gU2VnbWVudCBSb3V0aW5nIGFzIHdlbGwuDQoNCkxhc3RseSwgaG93IGRv IHdlIHVzZSB0aGlzIGZvciBTLUJGRD8gOikNCg0KTGV0J3MgZGlzY3VzcyBpbiBUb3JvbnRvIG9u IGhvdyB3ZSBjYW4gYmVzdCBkZWZpbmUgdGhlIG1vc3QgdXNlZnVsIHNvbHV0aW9uLg0KDQpUaGFu a3MhDQoNCi1Ob2JvDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUnRn LWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdyZWdv cnkNCj4gTWlyc2t5DQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAwMiwgMjAxNCAxOjE1IFBNDQo+ IFRvOiBNYWNoIENoZW47IG1wbHNAaWV0Zi5vcmcNCj4gQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4g U3ViamVjdDogUkU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWlyc2t5LW1w bHMtYmZkLWRpcmVjdGVkLQ0KPiAwMC50eHQNCj4gDQo+IEhpIE1hY2gsDQo+IHRoYW5rIHlvdSBm b3IgeW91ciBmZWVkYmFjay4NCj4gSW5kZWVkLCBib3RoIGRyYWZ0cyBoYXZlIGNvbW1vbmFsaXRp ZXMuDQo+IEknbSBsb29raW5nIGZvcndhcmQgdG8gdGhlIGRpc2N1c3Npb24gaW4gVG9yb250byBh bmQgaG93IHdlIGNhbiBicmluZyB0aGlzDQo+IGlkZWEgZnVydGhlci4NCj4gDQo+IAlSZWdhcmRz LA0KPiAJCUdyZWcNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1h Y2ggQ2hlbiBbbWFpbHRvOm1hY2guY2hlbkBodWF3ZWkuY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBK dWx5IDAxLCAyMDE0IDY6NTcgUE0NCj4gVG86IEdyZWdvcnkgTWlyc2t5DQo+IENjOiBydGctYmZk QGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0NCj4gMDAudHh0DQo+IA0KPiBIaSBHcmVnLA0K PiANCj4gSSBoYXZlIGEgcXVpY2sgcmV2aWV3IG9uIHRoZSBkcmFmdCwgd2VsbCB3cml0dGVuIGFu ZCB1c2VmdWwgZHJhZnQhDQo+IA0KPiBDb3VwbGUgeWVhcnMgYWdvLCB3ZSBzdWJtaXR0ZWQgYSBk cmFmdCAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtDQo+IGNoZW4tbXBscy1iZmQt ZW5oYW5jZW1lbnQtMDEpIHRoYXQgaW50ZW5kIHRvIHNvbHZlIHRoZSBzaW1pbGFyIGlzc3VlLCBn bGFkDQo+IHdlIGhhdmUgdGhlIHNpbWlsYXIgdGhvdWdodDotKS4NCj4gDQo+IEl0IGFsc28gZGVm aW5lcyBleHRlbnNpb25zIHRvIExTUCBQaW5nIHRvIGRpcmVjdCB0aGUgY2hvb3NlIG9mIHRoZSBy ZXR1cm4gcGF0aA0KPiBvZiBCRkQgY29udHJvbCBwYWNrZXRzLiBQbGVhc2UgdGFrZSBhIGxvb2su DQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IE1hY2gNCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPiBGcm9tOiBSdGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgR3JlZ29yeQ0KPiA+IE1pcnNreQ0KPiA+IFNlbnQ6IFdlZG5lc2Rh eSwgSnVseSAwMiwgMjAxNCAyOjE5IEFNDQo+ID4gVG86IG1wbHNAaWV0Zi5vcmc7IHJ0Zy1iZmRA aWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0K PiA+IGRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMC50eHQNCj4gPg0KPiA+IERlYXIg QWxsLA0KPiA+IHdlJ3ZlIHBvc3RlZCBhIG5ldyBkcmFmdC4gTFNQIFBpbmcgYWxyZWFkeSBpcyB1 c2VkIHRvIGJvb3RzdHJhcCBhIEJGRA0KPiA+IHNlc3Npb24gd2l0aCBCRkQgRGlzY3JpbWluYXRv ciBUTFYuIEEgbmV3IEJGRCBSZXZlcnNlIFBhdGggVExWIGlzDQo+ID4gaW50cm9kdWNlZCBpbiBv cmRlciB0byBpbnN0cnVjdCBhIGZhci1lbmQgQkZEIHBlZXIgdG8gdXNlIHBhcnRpY3VsYXINCj4g PiBwYXRoIGZvciByZXZlcnNlIGRpcmVjdGlvbiBvZiB0aGUgQkZEIHNlc3Npb24uDQo+ID4NCj4g PiBHcmVhdGx5IGFwcHJlY2lhdGUgeW91ciBxdWVzdGlvbnMsIGNvbW1lbnRzLg0KPiA+DQo+ID4g CVJlZ2FyZHMsDQo+ID4gCQlHcmVnDQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiA+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZ10NCj4gPiBTZW50OiBNb25kYXksIEp1bmUgMzAsIDIwMTQgNDoxNSBQTQ0K PiA+IFRvOiBHcmVnb3J5IE1pcnNreTsgSWx5YSBWYXJsYXNoa2luOyBKZWZmIFRhbnRzdXJhOyBH cmVnb3J5IE1pcnNreTsNCj4gPiBKZWZmIFRhbnRzdXJhOyBJbHlhIFZhcmxhc2hraW4NCj4gPiBT dWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4gZHJhZnQtbWlyc2t5LW1w bHMtYmZkLWRpcmVjdGVkLTAwLnR4dA0KPiA+DQo+ID4NCj4gPiBBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkLTAwLnR4dA0KPiA+IGhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgR3JlZyBNaXJza3kgYW5kIHBvc3RlZCB0byB0aGUgSUVU Rg0KPiA+IHJlcG9zaXRvcnkuDQo+ID4NCj4gPiBOYW1lOgkJZHJhZnQtbWlyc2t5LW1wbHMtYmZk LWRpcmVjdGVkDQo+ID4gUmV2aXNpb246CTAwDQo+ID4gVGl0bGU6CQlCaWRpcmVjdGlvbmFsIEZv cndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpIERpcmVjdGVkIFJldHVybg0KPiBQYXRoDQo+ID4gRG9j dW1lbnQgZGF0ZToJMjAxNC0wNi0zMA0KPiA+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQo+ID4gUGFnZXM6CQk4DQo+ID4gVVJMOg0KPiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMC4NCj4gPiB0eHQNCj4g PiBTdGF0dXM6DQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWly c2t5LW1wbHMtYmZkLWRpcmVjdGVkLw0KPiA+IEh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQtMDANCj4gPg0KPiA+ DQo+ID4gQWJzdHJhY3Q6DQo+ID4gICAgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlv biAoQkZEKSBpcyBleHBlY3RlZCB0byBtb25pdG9yIGJpLQ0KPiA+ICAgIGRpcmVjdGlvbmFsIHBh dGhzLiAgV2hlbiBmb3J3YXJkIGRpcmVjdGlvbiBvZiBhIEJGRCBzZXNzaW9uIGlzIHRvDQo+ID4g ICAgbW9uaXRvciBleHBsaWNpdGx5IHJvdXRlZCBwYXRoIHRoZXJlIGlzXCBhIG5lZWQgdG8gYmUg YWJsZSB0byBkaXJlY3QNCj4gPiAgICBmYXItZW5kIEJGRCBwZWVyIHRvIHVzZSBzcGVjaWZpYyBw YXRoIGFzIHJldmVyc2UgZGlyZWN0aW9uIG9mIHRoZSBCRkQNCj4gPiAgICBzZXNzaW9uLg0KPiA+ DQo+ID4NCj4gPg0KPiA+DQo+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4gdG9vbHMuaWV0Zi5v cmcuDQo+ID4NCj4gPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Wed Jul 2 22:50:22 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B941A0A94; Wed, 2 Jul 2014 22:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaQBcm3ud0kx; Wed, 2 Jul 2014 22:50:17 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91E1D1A0336; Wed, 2 Jul 2014 22:50:17 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-24-53b49abf3e05 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 52.F0.25146.FBA94B35; Thu, 3 Jul 2014 01:50:23 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Thu, 3 Jul 2014 01:50:15 -0400 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , Mach Chen , "mpls@ietf.org" Subject: RE: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Topic: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Index: AQHPlLkmcHLo4kmCjEWzfUskF7x6bpuLglYggAB+rECAAQbgIIAAZ8ZggABmrLA= Date: Thu, 3 Jul 2014 05:50:15 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7E61F9@eusaamb103.ericsson.se> References: <20140630231508.5203.4775.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B7E50F6@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7E5B9B@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXRPlO7+WVuCDTpmy1lcWCtscWvpSlaL 2R3xFp//bGN0YPGY8nsjq0fLkbesHkuW/GQKYI7isklJzcksSy3St0vgyjjf/Iq1YIpXxe4F k1kbGBd4dDFyckgImEi0X2tmhbDFJC7cW88GYgsJHGWUmNJb28XIBWQvY5Q4tGg7E0iCTcBI 4sXGHnYQW0QgV+Jb+1ZmEJtZQFOi6cRnsLiwQKDEts7LbBA1QRILF/ZC2X4S5/6/ArNZBFQk NjxdBtbLK+ArsWnZSjaIZdeYJA53tTGCJDiBEhvWnAQrYgS67vupNUwQy8Qlbj2ZzwRxtYDE kj3nmSFsUYmXj/9BfaMk8fH3fKCDOMCOW79LH6JVUWJK90N2iL2CEidnPmGZwCg2C8nUWQgd s5B0zELSsYCRZRUjR2lxalluupHhJkZg9ByTYHPcwbjgk+UhRgEORiUe3gSBLcFCrIllxZW5 hxilOViUxHk1q+cFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCcfLvGelO0CN+lvda5c1xc nrIfZLniX9AqZTbBYEuEyL1wwwy/qID4fV2OSVeXtqlni8q71/OrT78xa1vrilkbGbfbLN1t yXC9tcOiZOWSs/4uGrOvLpm9J+DIxurYOr5i5fP9gYXhR19WLNwSNktU0D4xZ+sbrx3zZG68 KpzamvPZagqjmKgSS3FGoqEWc1FxIgABUh6ofwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/GYpEQNbD_iy3H0g27UNvImLRjsM Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 05:50:19 -0000 SGkgTm9ibywNCm1hbnkgdGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgdGhvdWdodGZ1bCBjb21t ZW50cy4gUGxlYXNlIGZpbmQgbXkgYW5zd2VycyBhbmQgbm90ZXMgaW4tbGluZWQgYW5kIHRhZ2dl ZCB3aXRoIEdJTT4+Lg0KDQoJUmVnYXJkcywNCgkJR3JlZw0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogTm9ibyBBa2l5YSAobm9ibykgW21haWx0bzpub2JvQGNpc2NvLmNvbV0g DQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMDIsIDIwMTQgNToxNSBQTQ0KVG86IEdyZWdvcnkgTWly c2t5OyBNYWNoIENoZW47IG1wbHNAaWV0Zi5vcmcNCkNjOiBydGctYmZkQGlldGYub3JnDQpTdWJq ZWN0OiBSRTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1taXJza3ktbXBscy1i ZmQtZGlyZWN0ZWQtMDAudHh0DQoNCkhpIEdyZWcsIGV0IGFsLA0KDQpJIGFncmVlIHdpdGggdGhl IHRvcGljIGFuZCB1c2VmdWxuZXNzIG9mIGNvbnRyb2xsaW5nIHRoZSBCRkQgcmV0dXJuIHBhdGgs IGVzcGVjaWFsbHkgaW4gU2VnbWVudCBSb3V0aW5nLg0KDQpBIHF1ZXN0aW9uIGFuZCBjb3VwbGUg Y29tbWVudHMuDQoNCk9uZSB3YXkgdG8gYWNoaWV2ZSB0aGUgc2FtZSBzZW1hdGljIGlzIHRvIGlu dHJvZHVjZSAiU2VnbWVudCBSb3V0aW5nIE1QTFMgVHVubmVsIHN1Yi1UTFYiIGFuZCAiU2VnbWVu dCBSb3V0aW5nIElQdjYgVHVubmVsIHN1Yi1UTFYiIHVuZGVyIFJlcGx5IFBhdGggKFJQKSBUTFYg ZGVmaW5lZCBpbiBSRkM3MTEwLiBJcyB0aGVyZSBhbnkgcGFydGljdWxhciByZWFzb24gd2h5IG5l dyBUTFYgd2FzIGludHJvZHVjZWQ/IEknbSBtYWlubHkganVzdCBjdXJpb3VzIDopDQpHSU0+PiBU aG91Z2ggaXQgaXMgdW5saWtlbHkgdGhhdCBib3RoIEJGRCBEaXNjcmltaW5hdG9yIFRMViBhbmQg UlAgVExWIHdvdWxkIGJlIHVzZWQgaW4gdGhlIHNhbWUgTFNQIHBpbmcsIHdlIGRpZG4ndCB3YW50 IHRvIHJ1bGUgdGhpcyBvdXQgYW5kIHRob3VnaHQgdGhhdCBvdmVybG9hZGluZyBSUCB3aXRoIGFu b3RoZXIgcm9sZSwgY29uZGl0aW9uYWwgdG8gcHJlc2VuY2Ugb2YgQkZEIFRMViBtYXkgYm90IHN1 Y2ggYSBnb29kIGlkZWEuIEJ1dCB3aGF0IHdlIGRpc2N1c3NlZCB3YXMgaW50cm9kdWN0aW9uIG9m IEJGRCBDb250cm9sIFRMViB0byBoYXZlIG9wdGlvbmFsIHN1Yi1UTFY6IEJGRCBEaXNjcmltaW5h dG9yIHN1Yi1UTFYsIFJldHVybiBQYXRoIHN1Yi1UTFYsIGV0Yy4gSXQgbWF5IGJlIHRoYXQgdGhh dCB3YXMgbm90IGEgYmFkIGlkZWEgYWZ0ZXIgYWxsLg0KDQpUaGVyZSBhcmUgY291cGxlIG9mIHRo aW5ncyB3b3J0aCBoaWdobGlnaHRpbmcgYWJvdXQgdGhlIEJGRCBEaXNjcmltaW5hdG9yIFRMViAo ZGVmaW5lZCBpbiBSRkM1ODg0KSwgbm90IGRpcmVjdGx5IGluIHRoZSBzY29wZSBvZiB5b3VyIGRv Y3VtZW50IGJ1dCB2ZXJ5IHJlbGV2YW50IHdoZW4gbG9va2luZyBhdCB1c2luZyB5b3VyIHByb3Bv c2FsIGluIFNlZ21lbnQgUm91dGluZy4NCg0KMS4gVGhlIEJGRCBEaXNjcmltaW5hdG9yIFRMViBh bGxvd3MgYm9vdHN0cmFwcGluZyBvZiBvbmUgQkZEIHNlc3Npb24gcGVyIEZFQy4gV2hlbiBib290 c3RyYXBwaW5nIG1vcmUgdGhhbiBvbmUgQkZEIHNlc3Npb24gcGVyIEZFQywgaXQgaXMgZGlmZmlj dWx0IHRvIGRvIHNvIHdpdGhvdXQgbWFraW5nIGFzc3VtcHRpb25zLCBhcyB0aGVyZSBpcyBubyBk ZWZpbmVkIGZpZWxkcy9wcm9jZWR1cmVzIHRvIGRvIHNvLiBUaGlzIHdpbGwgYmVjb21lIG1vcmUg b2YgYW4gaXNzdWUgd2l0aCBTZWdtZW50IFJvdXRpbmcsIHdoZW4gdGhlcmUgYXJlIG11bHRpcGxl IGV4cGxpY2l0IHBhdGhzIGNyZWF0ZWQgYmV0d2VlbiBhIHBhaXIgb2Ygbm9kZXMuDQoNCjIuIE1h aW50ZW5hbmNlIG9mIGJvb3RzdHJhcHBlZCBCRkQgc2Vzc2lvbnMgaXMgZnV6enksIG1lYW5pbmcg d2hlbiBzaG91bGQgdGhlIGVncmVzcyBkZWxldGUgYm9vdHN0cmFwcGVkIEJGRCBzZXNzaW9ucy4g T25lIGNvdWxkIGltcGxlbWVudCBzdWNoIHRoYXQgdGhlIGVncmVzcyBkZWxldGVzIEJGRCBzZXNz aW9ucyB3aGVuIGNvcnJlc3BvbmRpbmcgRkVDIGlzIGRlbGV0ZWQsIG9yIFggYW1vdW50IG9mIHRp bWUgYWZ0ZXIgc2Vzc2lvbnMgZ28gImRvd24iLiBUaGVyZSdzIG5vIEZFQy9zdGF0ZSBvbiB0aGUg ZWdyZXNzIGZvciBTZWdtZW50IFJvdXRpbmcuICBUaHVzIG9ubHkgcmVtYWluaW5nIG9wdGlvbiB0 b2RheSBpcyB0byBkZWxldGUgdGhlIHNlc3Npb24gYWZ0ZXIgWCBzZWNvbmRzL21pbnV0ZXMgb25j ZSB0aGUgc2Vzc2lvbiBpcyBpbiAiZG93biIgc3RhdGUuIFBlcmhhcHMgdGhpcyBmdXp6aW5lc3Mg aXMgcmVhc29uYWJsZSwgb3IgcGVyaGFwcyB3ZSB3YW50IGV4cGxpY2l0ICJkZWxldGUiIGluc3Ry dWN0aW9uIGZyb20gdGhlIGluZ3Jlc3MgdG8gdGhlIGVncmVzcy4NCkdJTT4+IEJGRCAoc2hvdWxk IHdlIHJlZmVyIHRvIGl0IG5vdyBhcyAiY2xhc3NpY2FsIiBCRkQpIG11c3QgYmUgY29uZmlndXJl ZCBiZWZvcmUgaXQgYmUgYm9vdHN0cmFwcGVkIGJ5IExTUCBwaW5nLiBUbyBjbGVhbiB1cCBhbnkg cmVzaWR1YWwgc3RhdGUgaW4gdGhlIGRhdGEgcGxhbmUgb3BlcmF0b3Igd291bGQgbmVlZCBqdXN0 IHRvIHJlbW92ZSBjb3JyZXNwb25kaW5nICBCRkQgc2Vzc2lvbiBjb25maWd1cmF0aW9uLiBTLUJG RCB3b3VsZCBiZSBkaWZmZXJlbnQgY2FzZS4gVGhlIGZhci1lbmQgQkZEIHBlZXIgaXMsIGluIGEg d2F5LCBzdGF0ZWxlc3MgYnV0IGlmIHdhcyBpbnN0cnVjdGVkIHRvIHVzZSBzcGVjaWZpYyBwYXRo IHZpYSBCRkQgUmV2ZXJzZSBQYXRoIFRMViwgdGhlbiB0aGF0IHdpbGwgY3JlYXRlIGEgc3RhdGUg aW4gdGhlIGRhdGEgcGxhbmUuIENsZWFuaW5nIGl0IHVwIG1heSBiZSByZXF1aXJlZCB0byBwcmV2 ZW50IGV4aGF1c3Rpb24gb2YgYSByZXNvdXJjZSBpbiB0aGUgZGF0YSBwbGFuZS4gQ2VydGFpbmx5 IGdyZWF0IHRvcGljIGZvciBkaXNjdXNzaW9uIGluIFRvcm9udG8uIA0KDQpJIGJlbGlldmUgbXkg Y29sbGVhZ3VlIGlzIGFib3V0IHRvIHJvbGwgb3V0IGEgZG9jdW1lbnQgZm9yIEV4dGVuZGVkIEJG RCBEaXNjcmltaW5hdG9yIFRMViB3aGljaCBhZGRyZXNzZXMgKDEpIGFuZCAoMikgYWJvdmUuIFBy aW1hcnkgbW90aXZhdGlvbiBvZiB0aGF0IGRvY3VtZW50IGlzIEVWUE4gQkZELCBidXQgaXQgbG9v a3MgdmVyeSBhcHBsaWNhYmxlIHRvIFNlZ21lbnQgUm91dGluZyBhcyB3ZWxsLg0KR0lNPj4gVmVy eSBpbnRlcmVzdGluZyBpbmRlZWQuIExvb2tpbmcgZm9yd2FyZCB0byByZWFkIHRoZSBwcm9wb3Nh bC4NCg0KTGFzdGx5LCBob3cgZG8gd2UgdXNlIHRoaXMgZm9yIFMtQkZEPyA6KQ0KDQpMZXQncyBk aXNjdXNzIGluIFRvcm9udG8gb24gaG93IHdlIGNhbiBiZXN0IGRlZmluZSB0aGUgbW9zdCB1c2Vm dWwgc29sdXRpb24uDQpHSU0+PiBUaGFuayB5b3UhDQoNClRoYW5rcyENCg0KLU5vYm8NCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSdGctYmZkIFttYWlsdG86cnRnLWJm ZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR3JlZ29yeSANCj4gTWlyc2t5DQo+IFNl bnQ6IFdlZG5lc2RheSwgSnVseSAwMiwgMjAxNCAxOjE1IFBNDQo+IFRvOiBNYWNoIENoZW47IG1w bHNAaWV0Zi5vcmcNCj4gQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+IGRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3Rl ZC0gMDAudHh0DQo+IA0KPiBIaSBNYWNoLA0KPiB0aGFuayB5b3UgZm9yIHlvdXIgZmVlZGJhY2su DQo+IEluZGVlZCwgYm90aCBkcmFmdHMgaGF2ZSBjb21tb25hbGl0aWVzLg0KPiBJJ20gbG9va2lu ZyBmb3J3YXJkIHRvIHRoZSBkaXNjdXNzaW9uIGluIFRvcm9udG8gYW5kIGhvdyB3ZSBjYW4gYnJp bmcgDQo+IHRoaXMgaWRlYSBmdXJ0aGVyLg0KPiANCj4gCVJlZ2FyZHMsDQo+IAkJR3JlZw0KPiAN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFjaCBDaGVuIFttYWlsdG86 bWFjaC5jaGVuQGh1YXdlaS5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMDEsIDIwMTQgNjo1 NyBQTQ0KPiBUbzogR3JlZ29yeSBNaXJza3kNCj4gQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUkU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+IGRyYWZ0LW1pcnNreS1t cGxzLWJmZC1kaXJlY3RlZC0gMDAudHh0DQo+IA0KPiBIaSBHcmVnLA0KPiANCj4gSSBoYXZlIGEg cXVpY2sgcmV2aWV3IG9uIHRoZSBkcmFmdCwgd2VsbCB3cml0dGVuIGFuZCB1c2VmdWwgZHJhZnQh DQo+IA0KPiBDb3VwbGUgeWVhcnMgYWdvLCB3ZSBzdWJtaXR0ZWQgYSBkcmFmdCANCj4gKGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LQ0KPiBjaGVuLW1wbHMtYmZkLWVuaGFuY2VtZW50 LTAxKSB0aGF0IGludGVuZCB0byBzb2x2ZSB0aGUgc2ltaWxhciBpc3N1ZSwgDQo+IGdsYWQgd2Ug aGF2ZSB0aGUgc2ltaWxhciB0aG91Z2h0Oi0pLg0KPiANCj4gSXQgYWxzbyBkZWZpbmVzIGV4dGVu c2lvbnMgdG8gTFNQIFBpbmcgdG8gZGlyZWN0IHRoZSBjaG9vc2Ugb2YgdGhlIA0KPiByZXR1cm4g cGF0aCBvZiBCRkQgY29udHJvbCBwYWNrZXRzLiBQbGVhc2UgdGFrZSBhIGxvb2suDQo+IA0KPiBC ZXN0IHJlZ2FyZHMsDQo+IE1hY2gNCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPiBGcm9tOiBSdGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgR3JlZ29yeSANCj4gPiBNaXJza3kNCj4gPiBTZW50OiBXZWRuZXNkYXksIEp1bHkg MDIsIDIwMTQgMjoxOSBBTQ0KPiA+IFRvOiBtcGxzQGlldGYub3JnOyBydGctYmZkQGlldGYub3Jn DQo+ID4gU3ViamVjdDogRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+ID4gZHJh ZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkLTAwLnR4dA0KPiA+DQo+ID4gRGVhciBBbGwsDQo+ ID4gd2UndmUgcG9zdGVkIGEgbmV3IGRyYWZ0LiBMU1AgUGluZyBhbHJlYWR5IGlzIHVzZWQgdG8g Ym9vdHN0cmFwIGEgDQo+ID4gQkZEIHNlc3Npb24gd2l0aCBCRkQgRGlzY3JpbWluYXRvciBUTFYu IEEgbmV3IEJGRCBSZXZlcnNlIFBhdGggVExWIA0KPiA+IGlzIGludHJvZHVjZWQgaW4gb3JkZXIg dG8gaW5zdHJ1Y3QgYSBmYXItZW5kIEJGRCBwZWVyIHRvIHVzZSANCj4gPiBwYXJ0aWN1bGFyIHBh dGggZm9yIHJldmVyc2UgZGlyZWN0aW9uIG9mIHRoZSBCRkQgc2Vzc2lvbi4NCj4gPg0KPiA+IEdy ZWF0bHkgYXBwcmVjaWF0ZSB5b3VyIHF1ZXN0aW9ucywgY29tbWVudHMuDQo+ID4NCj4gPiAJUmVn YXJkcywNCj4gPiAJCUdyZWcNCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnXQ0KPiA+IFNlbnQ6IE1vbmRheSwgSnVuZSAzMCwgMjAxNCA0OjE1IFBNDQo+ID4g VG86IEdyZWdvcnkgTWlyc2t5OyBJbHlhIFZhcmxhc2hraW47IEplZmYgVGFudHN1cmE7IEdyZWdv cnkgTWlyc2t5OyANCj4gPiBKZWZmIFRhbnRzdXJhOyBJbHlhIFZhcmxhc2hraW4NCj4gPiBTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KPiA+IGRyYWZ0LW1pcnNreS1tcGxz LWJmZC1kaXJlY3RlZC0wMC50eHQNCj4gPg0KPiA+DQo+ID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMC50eHQNCj4gPiBoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEdyZWcgTWlyc2t5IGFuZCBwb3N0ZWQgdG8gdGhlIA0KPiA+ IElFVEYgcmVwb3NpdG9yeS4NCj4gPg0KPiA+IE5hbWU6CQlkcmFmdC1taXJza3ktbXBscy1iZmQt ZGlyZWN0ZWQNCj4gPiBSZXZpc2lvbjoJMDANCj4gPiBUaXRsZToJCUJpZGlyZWN0aW9uYWwgRm9y d2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgRGlyZWN0ZWQgUmV0dXJuDQo+IFBhdGgNCj4gPiBEb2N1 bWVudCBkYXRlOgkyMDE0LTA2LTMwDQo+ID4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24N Cj4gPiBQYWdlczoJCTgNCj4gPiBVUkw6DQo+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkLTAwLg0KPiA+IHR4dA0KPiA+ IFN0YXR1czoNCj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1taXJz a3ktbXBscy1iZmQtZGlyZWN0ZWQvDQo+ID4gSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMA0KPiA+DQo+ID4N Cj4gPiBBYnN0cmFjdDoNCj4gPiAgICBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9u IChCRkQpIGlzIGV4cGVjdGVkIHRvIG1vbml0b3IgYmktDQo+ID4gICAgZGlyZWN0aW9uYWwgcGF0 aHMuICBXaGVuIGZvcndhcmQgZGlyZWN0aW9uIG9mIGEgQkZEIHNlc3Npb24gaXMgdG8NCj4gPiAg ICBtb25pdG9yIGV4cGxpY2l0bHkgcm91dGVkIHBhdGggdGhlcmUgaXNcIGEgbmVlZCB0byBiZSBh YmxlIHRvIGRpcmVjdA0KPiA+ICAgIGZhci1lbmQgQkZEIHBlZXIgdG8gdXNlIHNwZWNpZmljIHBh dGggYXMgcmV2ZXJzZSBkaXJlY3Rpb24gb2YgdGhlIEJGRA0KPiA+ICAgIHNlc3Npb24uDQo+ID4N Cj4gPg0KPiA+DQo+ID4NCj4gPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiANCj4gPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4gdG9vbHMuaWV0Zi5v cmcuDQo+ID4NCj4gPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Thu Jul 3 03:17:41 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990A21B2821; Thu, 3 Jul 2014 03:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIjZIm4lChVC; Thu, 3 Jul 2014 03:17:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C42931B2815; Thu, 3 Jul 2014 03:17:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGT14870; Thu, 03 Jul 2014 10:17:34 +0000 (GMT) Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 3 Jul 2014 11:17:33 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.190]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Thu, 3 Jul 2014 18:17:25 +0800 From: Mach Chen To: Gregory Mirsky , "Nobo Akiya (nobo)" , "mpls@ietf.org" Subject: RE: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Topic: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Index: AQHPlLkmcHLo4kmCjEWzfUskF7x6bpuLglYggAB+rECAAQbgIIAAZ8ZggABmrLCAAEjfoA== Date: Thu, 3 Jul 2014 10:17:25 +0000 Message-ID: References: <20140630231508.5203.4775.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B7E50F6@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7E5B9B@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7E61F9@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7E61F9@eusaamb103.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/kterbS4HriptyRGCZYKFkQB4cjI Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 10:17:38 -0000 SGkgR3JlZywNCg0KUGxlYXNlIHNlZSBteSBjb21tZW50cyBpbmxpbmUuLi4NCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBHcmVnb3J5IE1pcnNreSBbbWFpbHRvOmdyZWdv cnkubWlyc2t5QGVyaWNzc29uLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIEp1bHkgMDMsIDIwMTQg MTo1MCBQTQ0KPiBUbzogTm9ibyBBa2l5YSAobm9ibyk7IE1hY2ggQ2hlbjsgbXBsc0BpZXRmLm9y Zw0KPiBDYzogcnRnLWJmZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQtMDAudHh0DQo+IA0K PiBIaSBOb2JvLA0KPiBtYW55IHRoYW5rcyBmb3IgeW91ciByZXZpZXcgYW5kIHRob3VnaHRmdWwg Y29tbWVudHMuIFBsZWFzZSBmaW5kIG15IGFuc3dlcnMNCj4gYW5kIG5vdGVzIGluLWxpbmVkIGFu ZCB0YWdnZWQgd2l0aCBHSU0+Pi4NCj4gDQo+IAlSZWdhcmRzLA0KPiAJCUdyZWcNCj4gDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE5vYm8gQWtpeWEgKG5vYm8pIFttYWls dG86bm9ib0BjaXNjby5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAwMiwgMjAxNCA1OjE1 IFBNDQo+IFRvOiBHcmVnb3J5IE1pcnNreTsgTWFjaCBDaGVuOyBtcGxzQGlldGYub3JnDQo+IENj OiBydGctYmZkQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMC50eHQNCj4gDQo+IEhpIEdy ZWcsIGV0IGFsLA0KPiANCj4gSSBhZ3JlZSB3aXRoIHRoZSB0b3BpYyBhbmQgdXNlZnVsbmVzcyBv ZiBjb250cm9sbGluZyB0aGUgQkZEIHJldHVybiBwYXRoLA0KPiBlc3BlY2lhbGx5IGluIFNlZ21l bnQgUm91dGluZy4NCj4gDQo+IEEgcXVlc3Rpb24gYW5kIGNvdXBsZSBjb21tZW50cy4NCj4gDQo+ IE9uZSB3YXkgdG8gYWNoaWV2ZSB0aGUgc2FtZSBzZW1hdGljIGlzIHRvIGludHJvZHVjZSAiU2Vn bWVudCBSb3V0aW5nIE1QTFMNCj4gVHVubmVsIHN1Yi1UTFYiIGFuZCAiU2VnbWVudCBSb3V0aW5n IElQdjYgVHVubmVsIHN1Yi1UTFYiIHVuZGVyIFJlcGx5IFBhdGgNCj4gKFJQKSBUTFYgZGVmaW5l ZCBpbiBSRkM3MTEwLiBJcyB0aGVyZSBhbnkgcGFydGljdWxhciByZWFzb24gd2h5IG5ldyBUTFYg d2FzDQo+IGludHJvZHVjZWQ/IEknbSBtYWlubHkganVzdCBjdXJpb3VzIDopDQo+IEdJTT4+IFRo b3VnaCBpdCBpcyB1bmxpa2VseSB0aGF0IGJvdGggQkZEIERpc2NyaW1pbmF0b3IgVExWIGFuZCBS UCBUTFYgd291bGQgYmUNCj4gdXNlZCBpbiB0aGUgc2FtZSBMU1AgcGluZywgd2UgZGlkbid0IHdh bnQgdG8gcnVsZSB0aGlzIG91dCBhbmQgdGhvdWdodCB0aGF0DQo+IG92ZXJsb2FkaW5nIFJQIHdp dGggYW5vdGhlciByb2xlLCBjb25kaXRpb25hbCB0byBwcmVzZW5jZSBvZiBCRkQgVExWIG1heSBi b3QNCg0KSSBtYXkgaGF2ZSBkaWZmZXJlbnQgdmlldyBoZXJlLCB0aGlua2luZyBhYm91dCB0aGUg Y3VycmVudCBMU1AgUGluZyBiYXNlZCBib290c3RyYXBwaW5nLCB0aGUgZWNobyByZXF1ZXN0IHdp bGwgY2FycnkgYm90aCBUYXJnZXQgc3RhY2sgRkVDIFRMViBhbmQgQkZEIERpc2NyaW1pbmF0b3Ig VExWLCBUYXJnZXQgc3RhY2sgRkVDIFRMViBpcyB1c2VkIHRvIGlkZW50aWZ5IHRoZSBMU1AgdG8g d2hpY2ggdGhhdCB0aGUgQkZEIHNlc3Npb24gaXMgYm91bmQsIEJGRCBEaXNjcmltaW5hdG9yIFRM ViBpcyB1c2VkIHRvIGluZGljYXRlIHRoaXMgaXMgYSBCRkQgYm9vdHN0cmFwcGluZyBpbnN0ZWFk IG9mIGEgbm9ybWFsIExTUCBQaW5nLiBBbmFsb2cgdG8gdGhpcywgaWYgd2Ugd2FudCB0byBzcGVj aWZ5IHRoZSByZXR1cm4gcGF0aCBvZiBCRkQgc2Vzc2lvbiwgc2VlbXMgYWRkIHRoZSBSUCBUTFYg dG8gaWRlbnRpZnkgdGhlIHJldHVybiBwYXRoIGlzIG5hdHVyYWwgY2hvaWNlLiBBbmQgZm9yIHRo ZSBzZWdtZW50IHJvdXRpbmcsIHdlIGp1c3QgbmVlZCBkZWZpbmUgbmV3IHN1Yi1UTFZzLiANCg0K PiBzdWNoIGEgZ29vZCBpZGVhLiBCdXQgd2hhdCB3ZSBkaXNjdXNzZWQgd2FzIGludHJvZHVjdGlv biBvZiBCRkQgQ29udHJvbCBUTFYgdG8NCj4gaGF2ZSBvcHRpb25hbCBzdWItVExWOiBCRkQgRGlz Y3JpbWluYXRvciBzdWItVExWLCBSZXR1cm4gUGF0aCBzdWItVExWLCBldGMuIEl0DQo+IG1heSBi ZSB0aGF0IHRoYXQgd2FzIG5vdCBhIGJhZCBpZGVhIGFmdGVyIGFsbC4NCg0KQ3VycmVudGx5LCBU YXJnZXQgU3RhY2sgRkVDIFRMViBhbmQgUmVwbHkgUGF0aCBUTFYgc2hhcmUgdGhlIHNhbWUgc3Vi LVRMVnMuIEF0IHRoZSBiZWdpbm5pbmcsIFJlcGx5IFBhdGggVExWIHdhbnRzIGl0cyBvd24gcmVn aXN0cnkgYW5kIGhvcGUgdG8gYm9ycm93IHNvbWUgc3ViLVRMVnMgZnJvbSB0aGUgVGFyZ2V0IFN0 YWNrIEZFQyBUTFYsIGJ1dCBpdCB0dXJuZWQgb3V0IHRvIGJlIGFuIHVuc3VjY2Vzc2Z1bCBjaG9p Y2UsIGFuZCBpdCB3YXMgdmVyeSBwYWluZnVsIHRvIGRldGVybWluZSBob3cgdG8gcHJvY2VzcyB0 aGUgcmVnaXN0cnksIHRoZXJlIHdhcyBhIGxvbmcgbG9uZyBkaXNjdXNzaW9uIGFib3V0IHdoZW4g cHVibGlzaCBSRkM3MTEwLiANCg0KU28sIGlmIHlvdSBpbnRyb2R1Y2UgdGhlIG5ldyBCRkQgQ29u dHJvbCBUTFYsIHRoZSBzYW1lIHNpdHVhdGlvbiB3aWxsIG9jY3VyIGFnYWluLCB5b3UgaGF2ZSBt YWtlIGEgZGVjaXNpb24gd2hldGhlciBCRkQgQ29udHJvbCBUTFYgaGFzIGl0cyBvd24gcmVnaXN0 cnksIHdoaWNoIHN1Yi1UTFZzIGNhbiBiZSBjYXJyaWVkIGluIEJGRCBDb250cm9sIFRMViwgaG93 IHRvIHByb2Nlc3MgdGhlIGZ1dHVyZSBkZWZpbmVkIFJlcGx5IFBhdGggc3ViLVRMVnMsIGV0Yy4g IA0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNoDQo+IA0KPiBUaGVyZSBhcmUgY291cGxlIG9mIHRoaW5n cyB3b3J0aCBoaWdobGlnaHRpbmcgYWJvdXQgdGhlIEJGRCBEaXNjcmltaW5hdG9yIFRMVg0KPiAo ZGVmaW5lZCBpbiBSRkM1ODg0KSwgbm90IGRpcmVjdGx5IGluIHRoZSBzY29wZSBvZiB5b3VyIGRv Y3VtZW50IGJ1dCB2ZXJ5DQo+IHJlbGV2YW50IHdoZW4gbG9va2luZyBhdCB1c2luZyB5b3VyIHBy b3Bvc2FsIGluIFNlZ21lbnQgUm91dGluZy4NCj4gDQo+IDEuIFRoZSBCRkQgRGlzY3JpbWluYXRv ciBUTFYgYWxsb3dzIGJvb3RzdHJhcHBpbmcgb2Ygb25lIEJGRCBzZXNzaW9uIHBlciBGRUMuDQo+ IFdoZW4gYm9vdHN0cmFwcGluZyBtb3JlIHRoYW4gb25lIEJGRCBzZXNzaW9uIHBlciBGRUMsIGl0 IGlzIGRpZmZpY3VsdCB0byBkbyBzbw0KPiB3aXRob3V0IG1ha2luZyBhc3N1bXB0aW9ucywgYXMg dGhlcmUgaXMgbm8gZGVmaW5lZCBmaWVsZHMvcHJvY2VkdXJlcyB0byBkbyBzby4NCj4gVGhpcyB3 aWxsIGJlY29tZSBtb3JlIG9mIGFuIGlzc3VlIHdpdGggU2VnbWVudCBSb3V0aW5nLCB3aGVuIHRo ZXJlIGFyZQ0KPiBtdWx0aXBsZSBleHBsaWNpdCBwYXRocyBjcmVhdGVkIGJldHdlZW4gYSBwYWly IG9mIG5vZGVzLg0KPiANCj4gMi4gTWFpbnRlbmFuY2Ugb2YgYm9vdHN0cmFwcGVkIEJGRCBzZXNz aW9ucyBpcyBmdXp6eSwgbWVhbmluZyB3aGVuIHNob3VsZCB0aGUNCj4gZWdyZXNzIGRlbGV0ZSBi b290c3RyYXBwZWQgQkZEIHNlc3Npb25zLiBPbmUgY291bGQgaW1wbGVtZW50IHN1Y2ggdGhhdCB0 aGUNCj4gZWdyZXNzIGRlbGV0ZXMgQkZEIHNlc3Npb25zIHdoZW4gY29ycmVzcG9uZGluZyBGRUMg aXMgZGVsZXRlZCwgb3IgWCBhbW91bnQgb2YNCj4gdGltZSBhZnRlciBzZXNzaW9ucyBnbyAiZG93 biIuIFRoZXJlJ3Mgbm8gRkVDL3N0YXRlIG9uIHRoZSBlZ3Jlc3MgZm9yIFNlZ21lbnQNCj4gUm91 dGluZy4gIFRodXMgb25seSByZW1haW5pbmcgb3B0aW9uIHRvZGF5IGlzIHRvIGRlbGV0ZSB0aGUg c2Vzc2lvbiBhZnRlciBYDQo+IHNlY29uZHMvbWludXRlcyBvbmNlIHRoZSBzZXNzaW9uIGlzIGlu ICJkb3duIiBzdGF0ZS4gUGVyaGFwcyB0aGlzIGZ1enppbmVzcyBpcw0KPiByZWFzb25hYmxlLCBv ciBwZXJoYXBzIHdlIHdhbnQgZXhwbGljaXQgImRlbGV0ZSIgaW5zdHJ1Y3Rpb24gZnJvbSB0aGUg aW5ncmVzcyB0bw0KPiB0aGUgZWdyZXNzLg0KPiBHSU0+PiBCRkQgKHNob3VsZCB3ZSByZWZlciB0 byBpdCBub3cgYXMgImNsYXNzaWNhbCIgQkZEKSBtdXN0IGJlIGNvbmZpZ3VyZWQNCj4gYmVmb3Jl IGl0IGJlIGJvb3RzdHJhcHBlZCBieSBMU1AgcGluZy4gVG8gY2xlYW4gdXAgYW55IHJlc2lkdWFs IHN0YXRlIGluIHRoZSBkYXRhDQo+IHBsYW5lIG9wZXJhdG9yIHdvdWxkIG5lZWQganVzdCB0byBy ZW1vdmUgY29ycmVzcG9uZGluZyAgQkZEIHNlc3Npb24NCj4gY29uZmlndXJhdGlvbi4gUy1CRkQg d291bGQgYmUgZGlmZmVyZW50IGNhc2UuIFRoZSBmYXItZW5kIEJGRCBwZWVyIGlzLCBpbiBhIHdh eSwNCj4gc3RhdGVsZXNzIGJ1dCBpZiB3YXMgaW5zdHJ1Y3RlZCB0byB1c2Ugc3BlY2lmaWMgcGF0 aCB2aWEgQkZEIFJldmVyc2UgUGF0aCBUTFYsIHRoZW4NCj4gdGhhdCB3aWxsIGNyZWF0ZSBhIHN0 YXRlIGluIHRoZSBkYXRhIHBsYW5lLiBDbGVhbmluZyBpdCB1cCBtYXkgYmUgcmVxdWlyZWQgdG8N Cj4gcHJldmVudCBleGhhdXN0aW9uIG9mIGEgcmVzb3VyY2UgaW4gdGhlIGRhdGEgcGxhbmUuIENl cnRhaW5seSBncmVhdCB0b3BpYyBmb3INCj4gZGlzY3Vzc2lvbiBpbiBUb3JvbnRvLg0KPiANCj4g SSBiZWxpZXZlIG15IGNvbGxlYWd1ZSBpcyBhYm91dCB0byByb2xsIG91dCBhIGRvY3VtZW50IGZv ciBFeHRlbmRlZCBCRkQNCj4gRGlzY3JpbWluYXRvciBUTFYgd2hpY2ggYWRkcmVzc2VzICgxKSBh bmQgKDIpIGFib3ZlLiBQcmltYXJ5IG1vdGl2YXRpb24gb2YgdGhhdA0KPiBkb2N1bWVudCBpcyBF VlBOIEJGRCwgYnV0IGl0IGxvb2tzIHZlcnkgYXBwbGljYWJsZSB0byBTZWdtZW50IFJvdXRpbmcg YXMgd2VsbC4NCj4gR0lNPj4gVmVyeSBpbnRlcmVzdGluZyBpbmRlZWQuIExvb2tpbmcgZm9yd2Fy ZCB0byByZWFkIHRoZSBwcm9wb3NhbC4NCj4gDQo+IExhc3RseSwgaG93IGRvIHdlIHVzZSB0aGlz IGZvciBTLUJGRD8gOikNCj4gDQo+IExldCdzIGRpc2N1c3MgaW4gVG9yb250byBvbiBob3cgd2Ug Y2FuIGJlc3QgZGVmaW5lIHRoZSBtb3N0IHVzZWZ1bCBzb2x1dGlvbi4NCj4gR0lNPj4gVGhhbmsg eW91IQ0KPiANCj4gVGhhbmtzIQ0KPiANCj4gLU5vYm8NCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBSdGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgR3JlZ29yeQ0KPiA+IE1pcnNreQ0KPiA+IFNlbnQ6IFdlZG5l c2RheSwgSnVseSAwMiwgMjAxNCAxOjE1IFBNDQo+ID4gVG86IE1hY2ggQ2hlbjsgbXBsc0BpZXRm Lm9yZw0KPiA+IENjOiBydGctYmZkQGlldGYub3JnDQo+ID4gU3ViamVjdDogUkU6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gPiBkcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQt IDAwLnR4dA0KPiA+DQo+ID4gSGkgTWFjaCwNCj4gPiB0aGFuayB5b3UgZm9yIHlvdXIgZmVlZGJh Y2suDQo+ID4gSW5kZWVkLCBib3RoIGRyYWZ0cyBoYXZlIGNvbW1vbmFsaXRpZXMuDQo+ID4gSSdt IGxvb2tpbmcgZm9yd2FyZCB0byB0aGUgZGlzY3Vzc2lvbiBpbiBUb3JvbnRvIGFuZCBob3cgd2Ug Y2FuIGJyaW5nDQo+ID4gdGhpcyBpZGVhIGZ1cnRoZXIuDQo+ID4NCj4gPiAJUmVnYXJkcywNCj4g PiAJCUdyZWcNCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTog TWFjaCBDaGVuIFttYWlsdG86bWFjaC5jaGVuQGh1YXdlaS5jb21dDQo+ID4gU2VudDogVHVlc2Rh eSwgSnVseSAwMSwgMjAxNCA2OjU3IFBNDQo+ID4gVG86IEdyZWdvcnkgTWlyc2t5DQo+ID4gQ2M6 IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSRTogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvcg0KPiA+IGRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0gMDAudHh0DQo+ID4N Cj4gPiBIaSBHcmVnLA0KPiA+DQo+ID4gSSBoYXZlIGEgcXVpY2sgcmV2aWV3IG9uIHRoZSBkcmFm dCwgd2VsbCB3cml0dGVuIGFuZCB1c2VmdWwgZHJhZnQhDQo+ID4NCj4gPiBDb3VwbGUgeWVhcnMg YWdvLCB3ZSBzdWJtaXR0ZWQgYSBkcmFmdA0KPiA+IChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC0NCj4gPiBjaGVuLW1wbHMtYmZkLWVuaGFuY2VtZW50LTAxKSB0aGF0IGludGVuZCB0 byBzb2x2ZSB0aGUgc2ltaWxhciBpc3N1ZSwNCj4gPiBnbGFkIHdlIGhhdmUgdGhlIHNpbWlsYXIg dGhvdWdodDotKS4NCj4gPg0KPiA+IEl0IGFsc28gZGVmaW5lcyBleHRlbnNpb25zIHRvIExTUCBQ aW5nIHRvIGRpcmVjdCB0aGUgY2hvb3NlIG9mIHRoZQ0KPiA+IHJldHVybiBwYXRoIG9mIEJGRCBj b250cm9sIHBhY2tldHMuIFBsZWFzZSB0YWtlIGEgbG9vay4NCj4gPg0KPiA+IEJlc3QgcmVnYXJk cywNCj4gPiBNYWNoDQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g PiBGcm9tOiBSdGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgR3JlZ29yeQ0KPiA+ID4gTWlyc2t5DQo+ID4gPiBTZW50OiBXZWRuZXNkYXksIEp1bHkg MDIsIDIwMTQgMjoxOSBBTQ0KPiA+ID4gVG86IG1wbHNAaWV0Zi5vcmc7IHJ0Zy1iZmRAaWV0Zi5v cmcNCj4gPiA+IFN1YmplY3Q6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4g PiBkcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQtMDAudHh0DQo+ID4gPg0KPiA+ID4gRGVh ciBBbGwsDQo+ID4gPiB3ZSd2ZSBwb3N0ZWQgYSBuZXcgZHJhZnQuIExTUCBQaW5nIGFscmVhZHkg aXMgdXNlZCB0byBib290c3RyYXAgYQ0KPiA+ID4gQkZEIHNlc3Npb24gd2l0aCBCRkQgRGlzY3Jp bWluYXRvciBUTFYuIEEgbmV3IEJGRCBSZXZlcnNlIFBhdGggVExWDQo+ID4gPiBpcyBpbnRyb2R1 Y2VkIGluIG9yZGVyIHRvIGluc3RydWN0IGEgZmFyLWVuZCBCRkQgcGVlciB0byB1c2UNCj4gPiA+ IHBhcnRpY3VsYXIgcGF0aCBmb3IgcmV2ZXJzZSBkaXJlY3Rpb24gb2YgdGhlIEJGRCBzZXNzaW9u Lg0KPiA+ID4NCj4gPiA+IEdyZWF0bHkgYXBwcmVjaWF0ZSB5b3VyIHF1ZXN0aW9ucywgY29tbWVu dHMuDQo+ID4gPg0KPiA+ID4gCVJlZ2FyZHMsDQo+ID4gPiAJCUdyZWcNCj4gPiA+DQo+ID4gPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiA+ID4gU2VudDogTW9u ZGF5LCBKdW5lIDMwLCAyMDE0IDQ6MTUgUE0NCj4gPiA+IFRvOiBHcmVnb3J5IE1pcnNreTsgSWx5 YSBWYXJsYXNoa2luOyBKZWZmIFRhbnRzdXJhOyBHcmVnb3J5IE1pcnNreTsNCj4gPiA+IEplZmYg VGFudHN1cmE7IElseWEgVmFybGFzaGtpbg0KPiA+ID4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvcg0KPiA+ID4gZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkLTAwLnR4 dA0KPiA+ID4NCj4gPiA+DQo+ID4gPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWlyc2t5 LW1wbHMtYmZkLWRpcmVjdGVkLTAwLnR4dA0KPiA+ID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBHcmVnIE1pcnNreSBhbmQgcG9zdGVkIHRvIHRoZQ0KPiA+ID4gSUVURiByZXBv c2l0b3J5Lg0KPiA+ID4NCj4gPiA+IE5hbWU6CQlkcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0 ZWQNCj4gPiA+IFJldmlzaW9uOgkwMA0KPiA+ID4gVGl0bGU6CQlCaWRpcmVjdGlvbmFsIEZvcndh cmRpbmcgRGV0ZWN0aW9uIChCRkQpIERpcmVjdGVkIFJldHVybg0KPiA+IFBhdGgNCj4gPiA+IERv Y3VtZW50IGRhdGU6CTIwMTQtMDYtMzANCj4gPiA+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNz aW9uDQo+ID4gPiBQYWdlczoJCTgNCj4gPiA+IFVSTDoNCj4gPiA+IGh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMC4NCj4g PiA+IHR4dA0KPiA+ID4gU3RhdHVzOg0KPiA+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkLw0KPiA+ID4gSHRtbGl6ZWQ6DQo+ IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3Rl ZC0wMA0KPiA+ID4NCj4gPiA+DQo+ID4gPiBBYnN0cmFjdDoNCj4gPiA+ICAgIEJpZGlyZWN0aW9u YWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgaXMgZXhwZWN0ZWQgdG8gbW9uaXRvciBiaS0N Cj4gPiA+ICAgIGRpcmVjdGlvbmFsIHBhdGhzLiAgV2hlbiBmb3J3YXJkIGRpcmVjdGlvbiBvZiBh IEJGRCBzZXNzaW9uIGlzIHRvDQo+ID4gPiAgICBtb25pdG9yIGV4cGxpY2l0bHkgcm91dGVkIHBh dGggdGhlcmUgaXNcIGEgbmVlZCB0byBiZSBhYmxlIHRvIGRpcmVjdA0KPiA+ID4gICAgZmFyLWVu ZCBCRkQgcGVlciB0byB1c2Ugc3BlY2lmaWMgcGF0aCBhcyByZXZlcnNlIGRpcmVjdGlvbiBvZiB0 aGUgQkZEDQo+ID4gPiAgICBzZXNzaW9uLg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4g PiA+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mDQo+ID4gPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4gPiB0b29scy5pZXRmLm9yZy4NCj4gPiA+DQo+ ID4gPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Thu Jul 3 06:09:19 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E4F1B296A; Thu, 3 Jul 2014 06:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbZfbyWdv8I4; Thu, 3 Jul 2014 06:09:12 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A71A1B2965; Thu, 3 Jul 2014 06:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7214; q=dns/txt; s=iport; t=1404392953; x=1405602553; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aqNVZwMMzEtDpZuWH49fyytuwQwsZmHqFEk/xORz7iE=; b=VKxdDLKYNJ8L+1ZFpN1DQ0ey45MjOGWmVSAHvJ5vk55fyrzMYhqMgX7R 5Q6+L4hnwxPyR7M/+z+HUVb8Cc6RbtmfYn73MTc//czMpXgFUGFceEYM6 c+RdkqLx4+NYo016aYTo2ptcfiv1Ht2nSf7wyxbPM9BmYAgzWJnaRrsEX 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAJBUtVOtJV2S/2dsb2JhbABQCoJpJIEsgm/DLwEZbBZ1hAMBAQEDASMRMxACEAIBCBoCBiACAgIwFRACBAENDYgyCAGtA5tyF4EsiDmEYSsxB4J3NoEWAQSud4NDgjA X-IronPort-AV: E=Sophos;i="5.01,595,1400025600"; d="scan'208";a="337527660" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-5.cisco.com with ESMTP; 03 Jul 2014 13:09:12 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s63D9BaF009404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jul 2014 13:09:11 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 3 Jul 2014 08:09:11 -0500 From: "Nobo Akiya (nobo)" To: Mach Chen , Gregory Mirsky , "mpls@ietf.org" Subject: RE: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Topic: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Index: AQHPlLkmcHLo4kmCjEWzfUskF7x6bpuLglYggAB+rECAAQbgIIAAZ8ZggABmrLCAAEjfoIAAME/A Date: Thu, 3 Jul 2014 13:09:10 +0000 Message-ID: References: <20140630231508.5203.4775.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B7E50F6@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7E5B9B@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7E61F9@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/nSTKmi5i8iHTxCe932TNkNcN_Yc Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 13:09:15 -0000 SGkgR3JlZywgTWFjaCwNCg0KPiA+IE9uZSB3YXkgdG8gYWNoaWV2ZSB0aGUgc2FtZSBzZW1hdGlj IGlzIHRvIGludHJvZHVjZSAiU2VnbWVudCBSb3V0aW5nDQo+ID4gTVBMUyBUdW5uZWwgc3ViLVRM ViIgYW5kICJTZWdtZW50IFJvdXRpbmcgSVB2NiBUdW5uZWwgc3ViLVRMViIgdW5kZXINCj4gPiBS ZXBseSBQYXRoDQo+ID4gKFJQKSBUTFYgZGVmaW5lZCBpbiBSRkM3MTEwLiBJcyB0aGVyZSBhbnkg cGFydGljdWxhciByZWFzb24gd2h5IG5ldw0KPiA+IFRMViB3YXMgaW50cm9kdWNlZD8gSSdtIG1h aW5seSBqdXN0IGN1cmlvdXMgOikNCj4gPiBHSU0+PiBUaG91Z2ggaXQgaXMgdW5saWtlbHkgdGhh dCBib3RoIEJGRCBEaXNjcmltaW5hdG9yIFRMViBhbmQgUlAgVExWDQo+ID4gR0lNPj4gd291bGQg YmUNCj4gPiB1c2VkIGluIHRoZSBzYW1lIExTUCBwaW5nLCB3ZSBkaWRuJ3Qgd2FudCB0byBydWxl IHRoaXMgb3V0IGFuZCB0aG91Z2h0DQo+ID4gdGhhdCBvdmVybG9hZGluZyBSUCB3aXRoIGFub3Ro ZXIgcm9sZSwgY29uZGl0aW9uYWwgdG8gcHJlc2VuY2Ugb2YgQkZEDQo+ID4gVExWIG1heSBib3QN Cj4gDQo+IEkgbWF5IGhhdmUgZGlmZmVyZW50IHZpZXcgaGVyZSwgdGhpbmtpbmcgYWJvdXQgdGhl IGN1cnJlbnQgTFNQIFBpbmcgYmFzZWQNCj4gYm9vdHN0cmFwcGluZywgdGhlIGVjaG8gcmVxdWVz dCB3aWxsIGNhcnJ5IGJvdGggVGFyZ2V0IHN0YWNrIEZFQyBUTFYgYW5kIEJGRA0KPiBEaXNjcmlt aW5hdG9yIFRMViwgVGFyZ2V0IHN0YWNrIEZFQyBUTFYgaXMgdXNlZCB0byBpZGVudGlmeSB0aGUg TFNQIHRvIHdoaWNoDQo+IHRoYXQgdGhlIEJGRCBzZXNzaW9uIGlzIGJvdW5kLCBCRkQgRGlzY3Jp bWluYXRvciBUTFYgaXMgdXNlZCB0byBpbmRpY2F0ZSB0aGlzDQo+IGlzIGEgQkZEIGJvb3RzdHJh cHBpbmcgaW5zdGVhZCBvZiBhIG5vcm1hbCBMU1AgUGluZy4gQW5hbG9nIHRvIHRoaXMsIGlmIHdl DQo+IHdhbnQgdG8gc3BlY2lmeSB0aGUgcmV0dXJuIHBhdGggb2YgQkZEIHNlc3Npb24sIHNlZW1z IGFkZCB0aGUgUlAgVExWIHRvDQo+IGlkZW50aWZ5IHRoZSByZXR1cm4gcGF0aCBpcyBuYXR1cmFs IGNob2ljZS4gQW5kIGZvciB0aGUgc2VnbWVudCByb3V0aW5nLCB3ZQ0KPiBqdXN0IG5lZWQgZGVm aW5lIG5ldyBzdWItVExWcy4NCg0KSSBzZWUgd2hlcmUgeW91IGFyZSBjb21pbmcgZnJvbSBNYWNo LCBidXQgbGV0IGNvdW50ZXItYXJndWUgZm9yIHRoZSBzYWtlIG9mIGRpc2N1c3Npb24gOikNCg0K VGFyZ2V0IEZFQyBTdGFjayBUTFYgKFRGUykgaXMgYSBUTFYgdGhhdCBpcyBhbHdheXMgcHJlc2Vu dCBpbiBhbiBNUExTIGVjaG8gcmVxdWVzdCBtZXNzYWdlLg0KDQpbU2VjdGlvbiAzLjIgb2YgUkZD NDM3OV0NCiAgIEFuIE1QTFMgZWNobyByZXF1ZXN0IE1VU1QgaGF2ZSBhIFRhcmdldCBGRUMgU3Rh Y2sgdGhhdCBkZXNjcmliZXMgdGhlDQogICBGRUMgU3RhY2sgYmVpbmcgdGVzdGVkLg0KDQpTbyBt b3N0IG90aGVyIFRMVnMgaW4gdGhlIE1QTFMgZWNobyByZXF1ZXN0IGFzc3VtZXMgdGhhdCBURlMg aXMgcHJlc2VudCBhbmQgaGFzIGluc3RydWN0aW9ucyB0byBkbyBmb28gZm9yIHRoZSBGRUMgZGVz Y3JpYmVkIGluIHRoZSBURlMsIHdoaWNoIGlzIHBlcmZlY3RseSBmaW5lIElNTy4gU28gSSB0aGlu ayBpdCBpcyBzdGlsbCBhcmd1YWJsZSB0aGF0IGlmIHdlIHdlcmUgdG8gaGF2ZSBCRkQtZm9vLTEs IEJGRC1mb28tMiBhbmQgQkZELWZvby0zIGluc3RydWN0aW9ucywgdGhlbiBwZXJoYXBzIGl0IGlz IG1vcmUgYmVuZWZpY2lhbCB0byBidW5kbGUgdGhlbSBpbnRvIGEgc2luZ2xlIEJGRC1mb28tVExW LCBhbmQgbWFrZSBlYWNoIGludG8gc3ViLVRMVnMgLi4uIGluc3RlYWQgb2YgaGF2aW5nIHNlcGFy YXRlIFRMVnMgZm9yIDEvMi8zLg0KDQo+IA0KPiA+IHN1Y2ggYSBnb29kIGlkZWEuIEJ1dCB3aGF0 IHdlIGRpc2N1c3NlZCB3YXMgaW50cm9kdWN0aW9uIG9mIEJGRA0KPiA+IENvbnRyb2wgVExWIHRv IGhhdmUgb3B0aW9uYWwgc3ViLVRMVjogQkZEIERpc2NyaW1pbmF0b3Igc3ViLVRMViwNCj4gPiBS ZXR1cm4gUGF0aCBzdWItVExWLCBldGMuIEl0IG1heSBiZSB0aGF0IHRoYXQgd2FzIG5vdCBhIGJh ZCBpZGVhIGFmdGVyIGFsbC4NCj4gDQo+IEN1cnJlbnRseSwgVGFyZ2V0IFN0YWNrIEZFQyBUTFYg YW5kIFJlcGx5IFBhdGggVExWIHNoYXJlIHRoZSBzYW1lIHN1Yi1UTFZzLg0KPiBBdCB0aGUgYmVn aW5uaW5nLCBSZXBseSBQYXRoIFRMViB3YW50cyBpdHMgb3duIHJlZ2lzdHJ5IGFuZCBob3BlIHRv IGJvcnJvdw0KPiBzb21lIHN1Yi1UTFZzIGZyb20gdGhlIFRhcmdldCBTdGFjayBGRUMgVExWLCBi dXQgaXQgdHVybmVkIG91dCB0byBiZSBhbg0KPiB1bnN1Y2Nlc3NmdWwgY2hvaWNlLCBhbmQgaXQg d2FzIHZlcnkgcGFpbmZ1bCB0byBkZXRlcm1pbmUgaG93IHRvIHByb2Nlc3MNCj4gdGhlIHJlZ2lz dHJ5LCB0aGVyZSB3YXMgYSBsb25nIGxvbmcgZGlzY3Vzc2lvbiBhYm91dCB3aGVuIHB1Ymxpc2gg UkZDNzExMC4NCj4gDQo+IFNvLCBpZiB5b3UgaW50cm9kdWNlIHRoZSBuZXcgQkZEIENvbnRyb2wg VExWLCB0aGUgc2FtZSBzaXR1YXRpb24gd2lsbCBvY2N1cg0KPiBhZ2FpbiwgeW91IGhhdmUgbWFr ZSBhIGRlY2lzaW9uIHdoZXRoZXIgQkZEIENvbnRyb2wgVExWIGhhcyBpdHMgb3duDQo+IHJlZ2lz dHJ5LCB3aGljaCBzdWItVExWcyBjYW4gYmUgY2FycmllZCBpbiBCRkQgQ29udHJvbCBUTFYsIGhv dyB0byBwcm9jZXNzDQo+IHRoZSBmdXR1cmUgZGVmaW5lZCBSZXBseSBQYXRoIHN1Yi1UTFZzLCBl dGMuDQoNClRoYXQncyBhIGdvb2QgcG9pbnQuIElmIEdyZWcncyBSZXZlcnNlIFBhdGggVExWIGFs c28gbmVlZHMgdG8gZGVzY3JpYmUgRkVDcyBvdGhlciB0aGFuIFNlZ21lbnRzLCB0aGVuIHdlIHBy b2JhYmx5IHdhbnQgdG8gbWFrZSBzdXJlIHRoYXQgdHlwZSBkb2VzIG5vdCBjb2xsaWRlIHdpdGgg RkVDIHR5cGVzIGluIHRoZSBURlMuDQoNCj4gPiAyLiBNYWludGVuYW5jZSBvZiBib290c3RyYXBw ZWQgQkZEIHNlc3Npb25zIGlzIGZ1enp5LCBtZWFuaW5nIHdoZW4NCj4gPiBzaG91bGQgdGhlIGVn cmVzcyBkZWxldGUgYm9vdHN0cmFwcGVkIEJGRCBzZXNzaW9ucy4gT25lIGNvdWxkDQo+ID4gaW1w bGVtZW50IHN1Y2ggdGhhdCB0aGUgZWdyZXNzIGRlbGV0ZXMgQkZEIHNlc3Npb25zIHdoZW4gY29y cmVzcG9uZGluZw0KPiA+IEZFQyBpcyBkZWxldGVkLCBvciBYIGFtb3VudCBvZiB0aW1lIGFmdGVy IHNlc3Npb25zIGdvICJkb3duIi4gVGhlcmUncw0KPiA+IG5vIEZFQy9zdGF0ZSBvbiB0aGUgZWdy ZXNzIGZvciBTZWdtZW50IFJvdXRpbmcuICBUaHVzIG9ubHkgcmVtYWluaW5nDQo+ID4gb3B0aW9u IHRvZGF5IGlzIHRvIGRlbGV0ZSB0aGUgc2Vzc2lvbiBhZnRlciBYIHNlY29uZHMvbWludXRlcyBv bmNlIHRoZQ0KPiA+IHNlc3Npb24gaXMgaW4gImRvd24iIHN0YXRlLiBQZXJoYXBzIHRoaXMgZnV6 emluZXNzIGlzIHJlYXNvbmFibGUsIG9yDQo+ID4gcGVyaGFwcyB3ZSB3YW50IGV4cGxpY2l0ICJk ZWxldGUiIGluc3RydWN0aW9uIGZyb20gdGhlIGluZ3Jlc3MgdG8gdGhlDQo+IGVncmVzcy4NCj4g PiBHSU0+PiBCRkQgKHNob3VsZCB3ZSByZWZlciB0byBpdCBub3cgYXMgImNsYXNzaWNhbCIgQkZE KSBtdXN0IGJlDQo+ID4gR0lNPj4gY29uZmlndXJlZA0KPiA+IGJlZm9yZSBpdCBiZSBib290c3Ry YXBwZWQgYnkgTFNQIHBpbmcuIFRvIGNsZWFuIHVwIGFueSByZXNpZHVhbCBzdGF0ZQ0KPiA+IGlu IHRoZSBkYXRhIHBsYW5lIG9wZXJhdG9yIHdvdWxkIG5lZWQganVzdCB0byByZW1vdmUgY29ycmVz cG9uZGluZw0KPiA+IEJGRCBzZXNzaW9uIGNvbmZpZ3VyYXRpb24uIFMtQkZEIHdvdWxkIGJlIGRp ZmZlcmVudCBjYXNlLiBUaGUgZmFyLWVuZA0KPiA+IEJGRCBwZWVyIGlzLCBpbiBhIHdheSwgc3Rh dGVsZXNzIGJ1dCBpZiB3YXMgaW5zdHJ1Y3RlZCB0byB1c2Ugc3BlY2lmaWMNCj4gPiBwYXRoIHZp YSBCRkQgUmV2ZXJzZSBQYXRoIFRMViwgdGhlbiB0aGF0IHdpbGwgY3JlYXRlIGEgc3RhdGUgaW4g dGhlDQo+ID4gZGF0YSBwbGFuZS4gQ2xlYW5pbmcgaXQgdXAgbWF5IGJlIHJlcXVpcmVkIHRvIHBy ZXZlbnQgZXhoYXVzdGlvbiBvZiBhDQo+ID4gcmVzb3VyY2UgaW4gdGhlIGRhdGEgcGxhbmUuIENl cnRhaW5seSBncmVhdCB0b3BpYyBmb3IgZGlzY3Vzc2lvbiBpbiBUb3JvbnRvLg0KDQpbQ2xhc3Np Y2FsIEJGRF0NCldlbGwsIHllcyBjbGFzc2ljYWwgQkZEIHNlc3Npb25zIGFyZSBjb25maWd1cmVk IG9uIHRoZSBpbmdyZXNzLCBidXQgbm90IGV4cGxpY2l0bHkgY29uZmlndXJlZCBvbiB0aGUgZWdy ZXNzLCBoZW5jZSB0aGUgbmVlZCBmb3IgYm9vdHN0cmFwcGluZy4gTGlrZWx5LCBlZ3Jlc3Mgd2ls bCBoYXZlIGNvbmZpZ3VyYXRpb24gbGlrZSAiYWxsb3cgQkZEIGJvb3N0cmFwIHJlcXVlc3QgZnJv bSB0aGVzZSBub2RlcyIgYnV0IG5vdCAiYWxsb3cgQkZEIGJvb3RzdHJhcCByZXF1ZXN0IGZvciB0 aGVzZSBGRUNzIGZyb20gdGhlc2Ugbm9kZXMiLCBiZWNhdXNlIHRoZSBsYXR0ZXIgd2lsbCBiZSB2 ZXJ5IGRpZmZpY3VsdCB0byBtYWludGFpbiBub3QgdG8gbWVudGlvbiBpdCBnb2VzIGFnYWluc3Qg dGhlIHN0YXRlbGVzcyBuYXR1cmUgb2YgU2VnbWVudCBSb3V0aW5nIGF0IHRoZSBjb25maWd1cmF0 aW9uIGxldmVsLiBQb3NzaWJseToNCmEuIEJGRCBUTFYgY2FuIGluc3RydWN0IGVncmVzcyB0byBk ZWxldGUgdGhlIHNlc3Npb24uDQpiLiBCRkQgVExWIGhhcyAicHVyZ2UgdGltZXIiIGZpZWxkIHdo ZXJlIGVncmVzcyBpcyBleHBlY3RlZCB0byBkZWxldGUgdGhlIHNlc3Npb24gYWZ0ZXIgInB1cmdl IHRpbWVyIiBvbmNlIHRoZSBzZXNzaW9uIGdvZXMgZG93bi4NCmMuIEp1c3QgZGVzY3JpYmUgcHJv Y2VkdXJlcyBmb3IgZWdyZXNzIHRoYXQgaXQgY2FuIGRlbGV0ZSB0aGUgc2Vzc2lvbiBhZnRlciBz b21ldGltZSBvbmNlIHRoZSBzZXNzaW9uIGdvZXMgZG93bi4NCg0KW1MtQkZEXQ0KQWdyZWUsIEkg ZG9uJ3Qgc2VlIGhvdyB3ZSBjYW4gYWRkcmVzcyB0aGlzIHdpdGhvdXQgZWdyZXNzIGJlY29taW5n IGEgbGl0dGxlIHN0YXRlZnVsLiBBdCB0aGUgbGVhc3QsIGFuIFNCRkRSZWZsZWN0b3IgbmVlZHMg dG8ga2VlcCBbcmVtb3RlIElQIGFkZHJlc3MsIHJlbW90ZSBCRkQgZGlzY3JpbWluYXRvcl0gPSBy ZXR1cm4gcGF0aC4gQW5kIGluZ3Jlc3MgbmVlZHMgdG8gYmUgYWJsZSB0byBtYWludGFpbiB0aGlz Lg0KDQpUaGFua3MhDQoNCi1Ob2JvDQoNCg== From nobody Thu Jul 3 22:15:10 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8525C1B2BDB; Thu, 3 Jul 2014 22:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmAjv0bqZiwb; Thu, 3 Jul 2014 22:15:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 631D01B2BA8; Thu, 3 Jul 2014 22:15:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGT95787; Fri, 04 Jul 2014 05:15:03 +0000 (GMT) Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Jul 2014 06:15:02 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.190]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0158.001; Fri, 4 Jul 2014 13:14:56 +0800 From: Mach Chen To: "Nobo Akiya (nobo)" , Gregory Mirsky , "mpls@ietf.org" Subject: =?utf-8?B?562U5aSNOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1p?= =?utf-8?Q?rsky-mpls-bfd-directed-00.txt?= Thread-Topic: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Index: AQHPlLkmcHLo4kmCjEWzfUskF7x6bpuLglYggAB+rECAAQbgIIAAZ8ZggABmrLCAAEjfoIAAME/AgAERiwA= Date: Fri, 4 Jul 2014 05:14:56 +0000 Message-ID: References: <20140630231508.5203.4775.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B7E50F6@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7E5B9B@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7E61F9@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.28.44] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/CYOgURnlrnH9gQ_J66L0Xg8DJq0 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 05:15:06 -0000 SGkgTm9ibyBhbmQgR3JlZywNCg0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu2 5Lq6OiBOb2JvIEFraXlhIChub2JvKSBbbWFpbHRvOm5vYm9AY2lzY28uY29tXQ0KPiDlj5HpgIHm l7bpl7Q6IDIwMTTlubQ35pyIM+aXpSAyMTowOQ0KPiDmlLbku7bkuro6IE1hY2ggQ2hlbjsgR3Jl Z29yeSBNaXJza3k7IG1wbHNAaWV0Zi5vcmcNCj4g5oqE6YCBOiBydGctYmZkQGlldGYub3JnDQo+ IOS4u+mimDogUkU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWlyc2t5LW1w bHMtYmZkLWRpcmVjdGVkLTAwLnR4dA0KPiANCj4gSGkgR3JlZywgTWFjaCwNCj4gDQo+ID4gPiBP bmUgd2F5IHRvIGFjaGlldmUgdGhlIHNhbWUgc2VtYXRpYyBpcyB0byBpbnRyb2R1Y2UgIlNlZ21l bnQgUm91dGluZw0KPiA+ID4gTVBMUyBUdW5uZWwgc3ViLVRMViIgYW5kICJTZWdtZW50IFJvdXRp bmcgSVB2NiBUdW5uZWwgc3ViLVRMViIgdW5kZXINCj4gPiA+IFJlcGx5IFBhdGgNCj4gPiA+IChS UCkgVExWIGRlZmluZWQgaW4gUkZDNzExMC4gSXMgdGhlcmUgYW55IHBhcnRpY3VsYXIgcmVhc29u IHdoeSBuZXcNCj4gPiA+IFRMViB3YXMgaW50cm9kdWNlZD8gSSdtIG1haW5seSBqdXN0IGN1cmlv dXMgOikNCj4gPiA+IEdJTT4+IFRob3VnaCBpdCBpcyB1bmxpa2VseSB0aGF0IGJvdGggQkZEIERp c2NyaW1pbmF0b3IgVExWIGFuZCBSUA0KPiA+ID4gR0lNPj4gVExWIHdvdWxkIGJlDQo+ID4gPiB1 c2VkIGluIHRoZSBzYW1lIExTUCBwaW5nLCB3ZSBkaWRuJ3Qgd2FudCB0byBydWxlIHRoaXMgb3V0 IGFuZA0KPiA+ID4gdGhvdWdodCB0aGF0IG92ZXJsb2FkaW5nIFJQIHdpdGggYW5vdGhlciByb2xl LCBjb25kaXRpb25hbCB0bw0KPiA+ID4gcHJlc2VuY2Ugb2YgQkZEIFRMViBtYXkgYm90DQo+ID4N Cj4gPiBJIG1heSBoYXZlIGRpZmZlcmVudCB2aWV3IGhlcmUsIHRoaW5raW5nIGFib3V0IHRoZSBj dXJyZW50IExTUCBQaW5nDQo+ID4gYmFzZWQgYm9vdHN0cmFwcGluZywgdGhlIGVjaG8gcmVxdWVz dCB3aWxsIGNhcnJ5IGJvdGggVGFyZ2V0IHN0YWNrIEZFQw0KPiA+IFRMViBhbmQgQkZEIERpc2Ny aW1pbmF0b3IgVExWLCBUYXJnZXQgc3RhY2sgRkVDIFRMViBpcyB1c2VkIHRvDQo+ID4gaWRlbnRp ZnkgdGhlIExTUCB0byB3aGljaCB0aGF0IHRoZSBCRkQgc2Vzc2lvbiBpcyBib3VuZCwgQkZEDQo+ ID4gRGlzY3JpbWluYXRvciBUTFYgaXMgdXNlZCB0byBpbmRpY2F0ZSB0aGlzIGlzIGEgQkZEIGJv b3RzdHJhcHBpbmcNCj4gPiBpbnN0ZWFkIG9mIGEgbm9ybWFsIExTUCBQaW5nLiBBbmFsb2cgdG8g dGhpcywgaWYgd2Ugd2FudCB0byBzcGVjaWZ5DQo+ID4gdGhlIHJldHVybiBwYXRoIG9mIEJGRCBz ZXNzaW9uLCBzZWVtcyBhZGQgdGhlIFJQIFRMViB0byBpZGVudGlmeSB0aGUNCj4gPiByZXR1cm4g cGF0aCBpcyBuYXR1cmFsIGNob2ljZS4gQW5kIGZvciB0aGUgc2VnbWVudCByb3V0aW5nLCB3ZSBq dXN0IG5lZWQNCj4gZGVmaW5lIG5ldyBzdWItVExWcy4NCj4gDQo+IEkgc2VlIHdoZXJlIHlvdSBh cmUgY29taW5nIGZyb20gTWFjaCwgYnV0IGxldCBjb3VudGVyLWFyZ3VlIGZvciB0aGUgc2FrZSBv Zg0KPiBkaXNjdXNzaW9uIDopDQo+IA0KPiBUYXJnZXQgRkVDIFN0YWNrIFRMViAoVEZTKSBpcyBh IFRMViB0aGF0IGlzIGFsd2F5cyBwcmVzZW50IGluIGFuIE1QTFMgZWNobw0KPiByZXF1ZXN0IG1l c3NhZ2UuDQo+IA0KPiBbU2VjdGlvbiAzLjIgb2YgUkZDNDM3OV0NCj4gICAgQW4gTVBMUyBlY2hv IHJlcXVlc3QgTVVTVCBoYXZlIGEgVGFyZ2V0IEZFQyBTdGFjayB0aGF0IGRlc2NyaWJlcyB0aGUN Cj4gICAgRkVDIFN0YWNrIGJlaW5nIHRlc3RlZC4NCj4gDQo+IFNvIG1vc3Qgb3RoZXIgVExWcyBp biB0aGUgTVBMUyBlY2hvIHJlcXVlc3QgYXNzdW1lcyB0aGF0IFRGUyBpcyBwcmVzZW50IGFuZA0K PiBoYXMgaW5zdHJ1Y3Rpb25zIHRvIGRvIGZvbyBmb3IgdGhlIEZFQyBkZXNjcmliZWQgaW4gdGhl IFRGUywgd2hpY2ggaXMgcGVyZmVjdGx5DQo+IGZpbmUgSU1PLiBTbyBJIHRoaW5rIGl0IGlzIHN0 aWxsIGFyZ3VhYmxlIHRoYXQgaWYgd2Ugd2VyZSB0byBoYXZlIEJGRC1mb28tMSwNCj4gQkZELWZv by0yIGFuZCBCRkQtZm9vLTMgaW5zdHJ1Y3Rpb25zLCB0aGVuIHBlcmhhcHMgaXQgaXMgbW9yZSBi ZW5lZmljaWFsIHRvDQo+IGJ1bmRsZSB0aGVtIGludG8gYSBzaW5nbGUgQkZELWZvby1UTFYsIGFu ZCBtYWtlIGVhY2ggaW50byBzdWItVExWcyAuLi4gaW5zdGVhZA0KPiBvZiBoYXZpbmcgc2VwYXJh dGUgVExWcyBmb3IgMS8yLzMuDQoNClllcywgSSBhZ3JlZSB0aGUgcHJpbmNpcGxlLiBMZXQnIGNv bnRpbnVlIGRpc2N1c3NpbmcgOi0pDQoNCj4gDQo+ID4NCj4gPiA+IHN1Y2ggYSBnb29kIGlkZWEu IEJ1dCB3aGF0IHdlIGRpc2N1c3NlZCB3YXMgaW50cm9kdWN0aW9uIG9mIEJGRA0KPiA+ID4gQ29u dHJvbCBUTFYgdG8gaGF2ZSBvcHRpb25hbCBzdWItVExWOiBCRkQgRGlzY3JpbWluYXRvciBzdWIt VExWLA0KPiA+ID4gUmV0dXJuIFBhdGggc3ViLVRMViwgZXRjLiBJdCBtYXkgYmUgdGhhdCB0aGF0 IHdhcyBub3QgYSBiYWQgaWRlYSBhZnRlciBhbGwuDQo+ID4NCj4gPiBDdXJyZW50bHksIFRhcmdl dCBTdGFjayBGRUMgVExWIGFuZCBSZXBseSBQYXRoIFRMViBzaGFyZSB0aGUgc2FtZSBzdWItVExW cy4NCj4gPiBBdCB0aGUgYmVnaW5uaW5nLCBSZXBseSBQYXRoIFRMViB3YW50cyBpdHMgb3duIHJl Z2lzdHJ5IGFuZCBob3BlIHRvDQo+ID4gYm9ycm93IHNvbWUgc3ViLVRMVnMgZnJvbSB0aGUgVGFy Z2V0IFN0YWNrIEZFQyBUTFYsIGJ1dCBpdCB0dXJuZWQgb3V0DQo+ID4gdG8gYmUgYW4gdW5zdWNj ZXNzZnVsIGNob2ljZSwgYW5kIGl0IHdhcyB2ZXJ5IHBhaW5mdWwgdG8gZGV0ZXJtaW5lIGhvdw0K PiA+IHRvIHByb2Nlc3MgdGhlIHJlZ2lzdHJ5LCB0aGVyZSB3YXMgYSBsb25nIGxvbmcgZGlzY3Vz c2lvbiBhYm91dCB3aGVuIHB1Ymxpc2gNCj4gUkZDNzExMC4NCj4gPg0KPiA+IFNvLCBpZiB5b3Ug aW50cm9kdWNlIHRoZSBuZXcgQkZEIENvbnRyb2wgVExWLCB0aGUgc2FtZSBzaXR1YXRpb24gd2ls bA0KPiA+IG9jY3VyIGFnYWluLCB5b3UgaGF2ZSBtYWtlIGEgZGVjaXNpb24gd2hldGhlciBCRkQg Q29udHJvbCBUTFYgaGFzIGl0cw0KPiA+IG93biByZWdpc3RyeSwgd2hpY2ggc3ViLVRMVnMgY2Fu IGJlIGNhcnJpZWQgaW4gQkZEIENvbnRyb2wgVExWLCBob3cgdG8NCj4gPiBwcm9jZXNzIHRoZSBm dXR1cmUgZGVmaW5lZCBSZXBseSBQYXRoIHN1Yi1UTFZzLCBldGMuDQo+IA0KPiBUaGF0J3MgYSBn b29kIHBvaW50LiBJZiBHcmVnJ3MgUmV2ZXJzZSBQYXRoIFRMViBhbHNvIG5lZWRzIHRvIGRlc2Ny aWJlIEZFQ3MNCj4gb3RoZXIgdGhhbiBTZWdtZW50cywgdGhlbiB3ZSBwcm9iYWJseSB3YW50IHRv IG1ha2Ugc3VyZSB0aGF0IHR5cGUgZG9lcyBub3QNCj4gY29sbGlkZSB3aXRoIEZFQyB0eXBlcyBp biB0aGUgVEZTLg0KDQpFeGFjdGx5Lg0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNoDQo+IA0KPiA+ID4g Mi4gTWFpbnRlbmFuY2Ugb2YgYm9vdHN0cmFwcGVkIEJGRCBzZXNzaW9ucyBpcyBmdXp6eSwgbWVh bmluZyB3aGVuDQo+ID4gPiBzaG91bGQgdGhlIGVncmVzcyBkZWxldGUgYm9vdHN0cmFwcGVkIEJG RCBzZXNzaW9ucy4gT25lIGNvdWxkDQo+ID4gPiBpbXBsZW1lbnQgc3VjaCB0aGF0IHRoZSBlZ3Jl c3MgZGVsZXRlcyBCRkQgc2Vzc2lvbnMgd2hlbg0KPiA+ID4gY29ycmVzcG9uZGluZyBGRUMgaXMg ZGVsZXRlZCwgb3IgWCBhbW91bnQgb2YgdGltZSBhZnRlciBzZXNzaW9ucyBnbw0KPiA+ID4gImRv d24iLiBUaGVyZSdzIG5vIEZFQy9zdGF0ZSBvbiB0aGUgZWdyZXNzIGZvciBTZWdtZW50IFJvdXRp bmcuDQo+ID4gPiBUaHVzIG9ubHkgcmVtYWluaW5nIG9wdGlvbiB0b2RheSBpcyB0byBkZWxldGUg dGhlIHNlc3Npb24gYWZ0ZXIgWA0KPiA+ID4gc2Vjb25kcy9taW51dGVzIG9uY2UgdGhlIHNlc3Np b24gaXMgaW4gImRvd24iIHN0YXRlLiBQZXJoYXBzIHRoaXMNCj4gPiA+IGZ1enppbmVzcyBpcyBy ZWFzb25hYmxlLCBvciBwZXJoYXBzIHdlIHdhbnQgZXhwbGljaXQgImRlbGV0ZSINCj4gPiA+IGlu c3RydWN0aW9uIGZyb20gdGhlIGluZ3Jlc3MgdG8gdGhlDQo+ID4gZWdyZXNzLg0KPiA+ID4gR0lN Pj4gQkZEIChzaG91bGQgd2UgcmVmZXIgdG8gaXQgbm93IGFzICJjbGFzc2ljYWwiIEJGRCkgbXVz dCBiZQ0KPiA+ID4gR0lNPj4gY29uZmlndXJlZA0KPiA+ID4gYmVmb3JlIGl0IGJlIGJvb3RzdHJh cHBlZCBieSBMU1AgcGluZy4gVG8gY2xlYW4gdXAgYW55IHJlc2lkdWFsDQo+ID4gPiBzdGF0ZSBp biB0aGUgZGF0YSBwbGFuZSBvcGVyYXRvciB3b3VsZCBuZWVkIGp1c3QgdG8gcmVtb3ZlDQo+ID4g PiBjb3JyZXNwb25kaW5nIEJGRCBzZXNzaW9uIGNvbmZpZ3VyYXRpb24uIFMtQkZEIHdvdWxkIGJl IGRpZmZlcmVudA0KPiA+ID4gY2FzZS4gVGhlIGZhci1lbmQgQkZEIHBlZXIgaXMsIGluIGEgd2F5 LCBzdGF0ZWxlc3MgYnV0IGlmIHdhcw0KPiA+ID4gaW5zdHJ1Y3RlZCB0byB1c2Ugc3BlY2lmaWMg cGF0aCB2aWEgQkZEIFJldmVyc2UgUGF0aCBUTFYsIHRoZW4gdGhhdA0KPiA+ID4gd2lsbCBjcmVh dGUgYSBzdGF0ZSBpbiB0aGUgZGF0YSBwbGFuZS4gQ2xlYW5pbmcgaXQgdXAgbWF5IGJlDQo+ID4g PiByZXF1aXJlZCB0byBwcmV2ZW50IGV4aGF1c3Rpb24gb2YgYSByZXNvdXJjZSBpbiB0aGUgZGF0 YSBwbGFuZS4gQ2VydGFpbmx5DQo+IGdyZWF0IHRvcGljIGZvciBkaXNjdXNzaW9uIGluIFRvcm9u dG8uDQo+IA0KPiBbQ2xhc3NpY2FsIEJGRF0NCj4gV2VsbCwgeWVzIGNsYXNzaWNhbCBCRkQgc2Vz c2lvbnMgYXJlIGNvbmZpZ3VyZWQgb24gdGhlIGluZ3Jlc3MsIGJ1dCBub3QgZXhwbGljaXRseQ0K PiBjb25maWd1cmVkIG9uIHRoZSBlZ3Jlc3MsIGhlbmNlIHRoZSBuZWVkIGZvciBib290c3RyYXBw aW5nLiBMaWtlbHksIGVncmVzcyB3aWxsDQo+IGhhdmUgY29uZmlndXJhdGlvbiBsaWtlICJhbGxv dyBCRkQgYm9vc3RyYXAgcmVxdWVzdCBmcm9tIHRoZXNlIG5vZGVzIiBidXQgbm90DQo+ICJhbGxv dyBCRkQgYm9vdHN0cmFwIHJlcXVlc3QgZm9yIHRoZXNlIEZFQ3MgZnJvbSB0aGVzZSBub2RlcyIs IGJlY2F1c2UgdGhlDQo+IGxhdHRlciB3aWxsIGJlIHZlcnkgZGlmZmljdWx0IHRvIG1haW50YWlu IG5vdCB0byBtZW50aW9uIGl0IGdvZXMgYWdhaW5zdCB0aGUNCj4gc3RhdGVsZXNzIG5hdHVyZSBv ZiBTZWdtZW50IFJvdXRpbmcgYXQgdGhlIGNvbmZpZ3VyYXRpb24gbGV2ZWwuIFBvc3NpYmx5Og0K PiBhLiBCRkQgVExWIGNhbiBpbnN0cnVjdCBlZ3Jlc3MgdG8gZGVsZXRlIHRoZSBzZXNzaW9uLg0K PiBiLiBCRkQgVExWIGhhcyAicHVyZ2UgdGltZXIiIGZpZWxkIHdoZXJlIGVncmVzcyBpcyBleHBl Y3RlZCB0byBkZWxldGUgdGhlDQo+IHNlc3Npb24gYWZ0ZXIgInB1cmdlIHRpbWVyIiBvbmNlIHRo ZSBzZXNzaW9uIGdvZXMgZG93bi4NCj4gYy4gSnVzdCBkZXNjcmliZSBwcm9jZWR1cmVzIGZvciBl Z3Jlc3MgdGhhdCBpdCBjYW4gZGVsZXRlIHRoZSBzZXNzaW9uIGFmdGVyDQo+IHNvbWV0aW1lIG9u Y2UgdGhlIHNlc3Npb24gZ29lcyBkb3duLg0KPiANCj4gW1MtQkZEXQ0KPiBBZ3JlZSwgSSBkb24n dCBzZWUgaG93IHdlIGNhbiBhZGRyZXNzIHRoaXMgd2l0aG91dCBlZ3Jlc3MgYmVjb21pbmcgYSBs aXR0bGUNCj4gc3RhdGVmdWwuIEF0IHRoZSBsZWFzdCwgYW4gU0JGRFJlZmxlY3RvciBuZWVkcyB0 byBrZWVwIFtyZW1vdGUgSVAgYWRkcmVzcywNCj4gcmVtb3RlIEJGRCBkaXNjcmltaW5hdG9yXSA9 IHJldHVybiBwYXRoLiBBbmQgaW5ncmVzcyBuZWVkcyB0byBiZSBhYmxlIHRvDQo+IG1haW50YWlu IHRoaXMuDQo+IA0KPiBUaGFua3MhDQo+IA0KPiAtTm9ibw0KDQo= From nobody Fri Jul 4 00:40:36 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0461B2C3A for ; Fri, 4 Jul 2014 00:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GM8bLKc2JkV7 for ; Fri, 4 Jul 2014 00:40:33 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 165A81B2C39 for ; Fri, 4 Jul 2014 00:40:33 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 38D542AA0F; Fri, 4 Jul 2014 07:40:31 +0000 (GMT) Date: Fri, 4 Jul 2014 00:40:30 -0700 From: Marc Binderberger To: Jeffrey Haas Message-ID: <20140704004030131466.d8356ce3@sniff.de> In-Reply-To: <20140630163846.GA11842@pfrc> References: <20140630163846.GA11842@pfrc> Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/9jqpxMVubmWh7QkEy2w9s4gqeKo Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 07:40:35 -0000 Hello Jeff et al., it won't surprise you when I think it's an awesome draft and that I support the publication :-) Seriously: the draft will help vendors to support the "right" intervals and customers will benefit from the interoperability. I consider the set of intervals a fair compromise of the various objectives and the feedback received from this list. Regards, Marc On Mon, 30 Jun 2014 12:38:46 -0400, Jeffrey Haas wrote: > Working Group, > > We would like to initiate the start of Working Group Last Call for > Common Interval Support in BFD: > > http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 > > Note that the intended status of this document is INFORMATIONAL. > > Please send your comments, including whether you think the draft is ready > for publication or not, to the list no later than July 15. > > -- Jeff and Nobo > From nobody Fri Jul 4 01:02:36 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB2A1A01AC for ; Fri, 4 Jul 2014 01:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Nszm4OjSNZI for ; Fri, 4 Jul 2014 01:02:34 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D75E91B2C63 for ; Fri, 4 Jul 2014 01:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=633; q=dns/txt; s=iport; t=1404460954; x=1405670554; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=8R73xnbV45+ta8EdQgwSms1SAlVa0DoLgWy4Yf7r+tE=; b=FZb/plPcq4hoXmaCsmWtAmeg8jfy0KdU2AyO5y/gGVvbpIsdRu7JOzBm Xv15sh6J8hKOZAycqykQ9KW0zoZdnh/uggJYdpaxVCVUa5/4u4uJU+ezn 8RMnvuZG+bh3hqki0nHxQ6nc+z8DXw6HFxr09+FpgoTQsAX12jXK0E3cA g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAE1ftlOtJV2R/2dsb2JhbABagw1SWsYmAYEMFnWEBAEBBB0dTwIBCA4oEDIlAgQBEohCDcl8F4t9gyyEQwWadoFIkkSDQ4Iw X-IronPort-AV: E=Sophos;i="5.01,599,1400025600"; d="scan'208";a="58295025" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP; 04 Jul 2014 08:02:13 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6482CBH006175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jul 2014 08:02:12 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.244]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 03:02:12 -0500 From: "Srihari Raghavan (srihari)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15) Thread-Topic: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15) Thread-Index: AQHPlIHI+cmWUxkPeEG8th+y8HuYL5uQRNqA Date: Fri, 4 Jul 2014 08:02:11 +0000 Message-ID: References: <20140630163846.GA11842@pfrc> In-Reply-To: <20140630163846.GA11842@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.219] Content-Type: text/plain; charset="us-ascii" Content-ID: <1DD62AE239D90F43AB11DA18B59A7F6A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/xpU838-DaeL5crrhVe8LGHARbww X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 08:02:35 -0000 As a member of the team which is involved in the contents of the draft, I support this draft and find it ready for publication. Thanks Srihari On 30/06/14 10:08 pm, "Jeffrey Haas" wrote: >Working Group, > >We would like to initiate the start of Working Group Last Call for >Common Interval Support in BFD: > >http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 > >Note that the intended status of this document is INFORMATIONAL. > >Please send your comments, including whether you think the draft is ready >for publication or not, to the list no later than July 15. > >-- Jeff and Nobo > From nobody Fri Jul 4 02:43:44 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63991B2CB7 for ; Fri, 4 Jul 2014 02:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YSHK8x5c-TD for ; Fri, 4 Jul 2014 02:43:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 343221B27BD for ; Fri, 4 Jul 2014 02:43:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGU18569; Fri, 04 Jul 2014 09:43:35 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Jul 2014 10:43:34 +0100 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.225]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 4 Jul 2014 17:43:27 +0800 From: Mingui Zhang To: Gregory Mirsky , "Nobo Akiya (nobo)" , "Jeff Haas (jhaas@juniper.net)" , "rtg-bfd@ietf.org" Subject: RE: [Tentative] BFD WG Agenda for IETF90 Thread-Topic: [Tentative] BFD WG Agenda for IETF90 Thread-Index: Ac+UiZAWL5Mu2kjMROSJ/nHy59ZzAwBAGTDgAGwDVjA= Date: Fri, 4 Jul 2014 09:43:26 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E76A0E0757@nkgeml508-mbx.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B7E544A@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7E544A@eusaamb103.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/QgRbHCsZEjR64-On-n3hP8rp77w X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 09:43:43 -0000 Hi WG Chairs, Is there more room for another draft?:) We would like to get suggestions an= d directions from the WG. -Title Use Cases Requiring New Features of BFD -Draft draft-zhang-bfd-new-use-cases-00.txt=20 -Presenter Mingui Zhang Comments are welcome! Thanks, Mingui=20 >-----Original Message----- >From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsk= y >Sent: Wednesday, July 02, 2014 8:15 AM >To: Nobo Akiya (nobo); Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org >Subject: RE: [Tentative] BFD WG Agenda for IETF90 > >Dear Nobo and Jeff, >hope you would accept another presentation request for the meeting in >Toronto: > >* Title - BFD Directed Return Path >* Draft - draft-mirsky-mpls-bfd-directed-00 >* Presenter - Greg Mirsky >* Duration - 10 min > > > Regards, > Greg > >-----Original Message----- >From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (n= obo) >Sent: Monday, June 30, 2014 10:44 AM >To: rtg-bfd@ietf.org >Cc: Jeff Haas (jhaas@juniper.net) >Subject: [Tentative] BFD WG Agenda for IETF90 > >Hello BFDers, > >Tentative BFD WG Agenda for IETF90 has been posted. > >http://www.ietf.org/proceedings/90/agenda/agenda-90-bfd >(tentative agenda also pasted below for easier reference) > >If: >- Your presentation information is not accurate; >- Your presentation information is missing; >- You do not agree with the agenda or a specific presentation listed; > >please provide your comment via replying to this thread (with WG list incl= uded or >just the chairs). > >Reminder to presenters: > >Please email your slides to the chairs no later than 2014-07-14 (Monday). > >Thanks! > >-Nobo and Jeff > > >IETF 90 - BFD WG Meeting Session Agenda > >MONDAY, July 21, 2014 >1520-1650 Afternoon Session II >Salon B >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > >CHAIR(s): Jeffrey Haas > Nobo Akiya > >- WG Statuses and Administrivia 15 minutes > Presenter > Co-chairs > >- BFD Proxy for Connections over Monitored Links 10 minutes > Draft > draft-snyder-bfd-proxy-connections-monitored-links-00 > Presenter > Brian Snyder > >- BFD Stability 10 minutes > Draft > draft-ashesh-bfd-stability-00 > Presenter > Ashesh Mishra > >- Seamless BFD Use-Case 10 minutes > Draft > draft-ietf-bfd-seamless-use-case-00 > Presenter > Sam K. Aldrin > >- Seamless BFD Base/IP 10 minutes > Draft > draft-ietf-bfd-seamless-base-01 > draft-akiya-bfd-seamless-ip-03 > Presenter > Nobo Akiya > >- L2VPN EVPN BFD 10 minutes > Draft > draft-vgovindan-l2vpn-evpn-bfd-02 > Presenter > Vengada Prasad Govindan > > From nobody Fri Jul 4 06:28:41 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5291B2CE9; Fri, 4 Jul 2014 06:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFrDfaTEvprY; Fri, 4 Jul 2014 06:28:36 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72DA91B2CA3; Fri, 4 Jul 2014 06:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10412; q=dns/txt; s=iport; t=1404480516; x=1405690116; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZCc+02sgpype8WtQV8SmIGDTA6JOrXzzvsMsDf9ek3c=; b=B7TY8ZQTy4Z751VJ1CiGDBTMMLbaIMgcMNXTacLpCY57Zrz3nlp84qJd 1F8sA4zb0joz4lALcIdav8InJO10tMnfta7qu5APjTJJ+8DpVwZUDguF5 xQxpyZW7Nvf8nTfX7pXBtOj6eXxd/tXS7tLpGrRsp8a9kkx+ehLFkIew8 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAHertlOtJA2D/2dsb2JhbABagw5SWoJvwzoBGXEWdYQDAQEBBCMRQwIMBAIBCBEEAQEDAgYdAwICAjAUAQgIAgQBDQUIARKIJw2vD5shF4EsiDmFDBYbBwaCcTaBFgWWXIVikkSDQ2yBRA X-IronPort-AV: E=Sophos;i="5.01,601,1400025600"; d="scan'208";a="337583825" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-1.cisco.com with ESMTP; 04 Jul 2014 13:28:35 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s64DSZiB005605 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jul 2014 13:28:35 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.202]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 08:28:35 -0500 From: "Vengada Prasad Govindan (venggovi)" To: Gregory Mirsky , "Nobo Akiya (nobo)" , Mach Chen , "mpls@ietf.org" Subject: RE: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Topic: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Index: AQHPlLkmcHLo4kmCjEWzfUskF7x6bpuLglYggAB+rECAAQbgIIAAZ8ZggABmrLCAAheN8A== Date: Fri, 4 Jul 2014 13:28:34 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D34623DD1@xmb-rcd-x15.cisco.com> References: <20140630231508.5203.4775.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B7E50F6@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7E5B9B@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7E61F9@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7E61F9@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.51.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/fYz2XIuGfECFuO8f5n_scL144t4 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 13:28:38 -0000 SGVsbG8gYWxsLCANCiBQbGVhc2UgZmluZCB0aGUgc3VibWlzc2lvbiBOb2JvIHJlZmVycyB0byBi ZWxvdyBhdDoNCg0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LXZnb3ZpbmRhbi1tcGxzLWV4dGVuZGVkLWJmZC1kaXNjLXRsdi0wMC50eHQN ClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12 Z292aW5kYW4tbXBscy1leHRlbmRlZC1iZmQtZGlzYy10bHYvDQpIdG1saXplZDogICAgICAgaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdmdvdmluZGFuLW1wbHMtZXh0ZW5kZWQtYmZk LWRpc2MtdGx2LTAwDQoNClRoYW5rcw0KUHJhc2FkDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBSdGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgR3JlZ29yeSBNaXJza3kNClNlbnQ6IFRodXJzZGF5LCBKdWx5IDAzLCAyMDE0IDEx OjIwIEFNDQpUbzogTm9ibyBBa2l5YSAobm9ibyk7IE1hY2ggQ2hlbjsgbXBsc0BpZXRmLm9yZw0K Q2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMC50eHQNCg0KSGkgTm9ibywN Cm1hbnkgdGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgdGhvdWdodGZ1bCBjb21tZW50cy4gUGxl YXNlIGZpbmQgbXkgYW5zd2VycyBhbmQgbm90ZXMgaW4tbGluZWQgYW5kIHRhZ2dlZCB3aXRoIEdJ TT4+Lg0KDQoJUmVnYXJkcywNCgkJR3JlZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogTm9ibyBBa2l5YSAobm9ibykgW21haWx0bzpub2JvQGNpc2NvLmNvbV0NClNlbnQ6IFdl ZG5lc2RheSwgSnVseSAwMiwgMjAxNCA1OjE1IFBNDQpUbzogR3JlZ29yeSBNaXJza3k7IE1hY2gg Q2hlbjsgbXBsc0BpZXRmLm9yZw0KQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3Rl ZC0wMC50eHQNCg0KSGkgR3JlZywgZXQgYWwsDQoNCkkgYWdyZWUgd2l0aCB0aGUgdG9waWMgYW5k IHVzZWZ1bG5lc3Mgb2YgY29udHJvbGxpbmcgdGhlIEJGRCByZXR1cm4gcGF0aCwgZXNwZWNpYWxs eSBpbiBTZWdtZW50IFJvdXRpbmcuDQoNCkEgcXVlc3Rpb24gYW5kIGNvdXBsZSBjb21tZW50cy4N Cg0KT25lIHdheSB0byBhY2hpZXZlIHRoZSBzYW1lIHNlbWF0aWMgaXMgdG8gaW50cm9kdWNlICJT ZWdtZW50IFJvdXRpbmcgTVBMUyBUdW5uZWwgc3ViLVRMViIgYW5kICJTZWdtZW50IFJvdXRpbmcg SVB2NiBUdW5uZWwgc3ViLVRMViIgdW5kZXIgUmVwbHkgUGF0aCAoUlApIFRMViBkZWZpbmVkIGlu IFJGQzcxMTAuIElzIHRoZXJlIGFueSBwYXJ0aWN1bGFyIHJlYXNvbiB3aHkgbmV3IFRMViB3YXMg aW50cm9kdWNlZD8gSSdtIG1haW5seSBqdXN0IGN1cmlvdXMgOikNCkdJTT4+IFRob3VnaCBpdCBp cyB1bmxpa2VseSB0aGF0IGJvdGggQkZEIERpc2NyaW1pbmF0b3IgVExWIGFuZCBSUCBUTFYgd291 bGQgYmUgdXNlZCBpbiB0aGUgc2FtZSBMU1AgcGluZywgd2UgZGlkbid0IHdhbnQgdG8gcnVsZSB0 aGlzIG91dCBhbmQgdGhvdWdodCB0aGF0IG92ZXJsb2FkaW5nIFJQIHdpdGggYW5vdGhlciByb2xl LCBjb25kaXRpb25hbCB0byBwcmVzZW5jZSBvZiBCRkQgVExWIG1heSBib3Qgc3VjaCBhIGdvb2Qg aWRlYS4gQnV0IHdoYXQgd2UgZGlzY3Vzc2VkIHdhcyBpbnRyb2R1Y3Rpb24gb2YgQkZEIENvbnRy b2wgVExWIHRvIGhhdmUgb3B0aW9uYWwgc3ViLVRMVjogQkZEIERpc2NyaW1pbmF0b3Igc3ViLVRM ViwgUmV0dXJuIFBhdGggc3ViLVRMViwgZXRjLiBJdCBtYXkgYmUgdGhhdCB0aGF0IHdhcyBub3Qg YSBiYWQgaWRlYSBhZnRlciBhbGwuDQoNClRoZXJlIGFyZSBjb3VwbGUgb2YgdGhpbmdzIHdvcnRo IGhpZ2hsaWdodGluZyBhYm91dCB0aGUgQkZEIERpc2NyaW1pbmF0b3IgVExWIChkZWZpbmVkIGlu IFJGQzU4ODQpLCBub3QgZGlyZWN0bHkgaW4gdGhlIHNjb3BlIG9mIHlvdXIgZG9jdW1lbnQgYnV0 IHZlcnkgcmVsZXZhbnQgd2hlbiBsb29raW5nIGF0IHVzaW5nIHlvdXIgcHJvcG9zYWwgaW4gU2Vn bWVudCBSb3V0aW5nLg0KDQoxLiBUaGUgQkZEIERpc2NyaW1pbmF0b3IgVExWIGFsbG93cyBib290 c3RyYXBwaW5nIG9mIG9uZSBCRkQgc2Vzc2lvbiBwZXIgRkVDLiBXaGVuIGJvb3RzdHJhcHBpbmcg bW9yZSB0aGFuIG9uZSBCRkQgc2Vzc2lvbiBwZXIgRkVDLCBpdCBpcyBkaWZmaWN1bHQgdG8gZG8g c28gd2l0aG91dCBtYWtpbmcgYXNzdW1wdGlvbnMsIGFzIHRoZXJlIGlzIG5vIGRlZmluZWQgZmll bGRzL3Byb2NlZHVyZXMgdG8gZG8gc28uIFRoaXMgd2lsbCBiZWNvbWUgbW9yZSBvZiBhbiBpc3N1 ZSB3aXRoIFNlZ21lbnQgUm91dGluZywgd2hlbiB0aGVyZSBhcmUgbXVsdGlwbGUgZXhwbGljaXQg cGF0aHMgY3JlYXRlZCBiZXR3ZWVuIGEgcGFpciBvZiBub2Rlcy4NCg0KMi4gTWFpbnRlbmFuY2Ug b2YgYm9vdHN0cmFwcGVkIEJGRCBzZXNzaW9ucyBpcyBmdXp6eSwgbWVhbmluZyB3aGVuIHNob3Vs ZCB0aGUgZWdyZXNzIGRlbGV0ZSBib290c3RyYXBwZWQgQkZEIHNlc3Npb25zLiBPbmUgY291bGQg aW1wbGVtZW50IHN1Y2ggdGhhdCB0aGUgZWdyZXNzIGRlbGV0ZXMgQkZEIHNlc3Npb25zIHdoZW4g Y29ycmVzcG9uZGluZyBGRUMgaXMgZGVsZXRlZCwgb3IgWCBhbW91bnQgb2YgdGltZSBhZnRlciBz ZXNzaW9ucyBnbyAiZG93biIuIFRoZXJlJ3Mgbm8gRkVDL3N0YXRlIG9uIHRoZSBlZ3Jlc3MgZm9y IFNlZ21lbnQgUm91dGluZy4gIFRodXMgb25seSByZW1haW5pbmcgb3B0aW9uIHRvZGF5IGlzIHRv IGRlbGV0ZSB0aGUgc2Vzc2lvbiBhZnRlciBYIHNlY29uZHMvbWludXRlcyBvbmNlIHRoZSBzZXNz aW9uIGlzIGluICJkb3duIiBzdGF0ZS4gUGVyaGFwcyB0aGlzIGZ1enppbmVzcyBpcyByZWFzb25h YmxlLCBvciBwZXJoYXBzIHdlIHdhbnQgZXhwbGljaXQgImRlbGV0ZSIgaW5zdHJ1Y3Rpb24gZnJv bSB0aGUgaW5ncmVzcyB0byB0aGUgZWdyZXNzLg0KR0lNPj4gQkZEIChzaG91bGQgd2UgcmVmZXIg dG8gaXQgbm93IGFzICJjbGFzc2ljYWwiIEJGRCkgbXVzdCBiZSBjb25maWd1cmVkIGJlZm9yZSBp dCBiZSBib290c3RyYXBwZWQgYnkgTFNQIHBpbmcuIFRvIGNsZWFuIHVwIGFueSByZXNpZHVhbCBz dGF0ZSBpbiB0aGUgZGF0YSBwbGFuZSBvcGVyYXRvciB3b3VsZCBuZWVkIGp1c3QgdG8gcmVtb3Zl IGNvcnJlc3BvbmRpbmcgIEJGRCBzZXNzaW9uIGNvbmZpZ3VyYXRpb24uIFMtQkZEIHdvdWxkIGJl IGRpZmZlcmVudCBjYXNlLiBUaGUgZmFyLWVuZCBCRkQgcGVlciBpcywgaW4gYSB3YXksIHN0YXRl bGVzcyBidXQgaWYgd2FzIGluc3RydWN0ZWQgdG8gdXNlIHNwZWNpZmljIHBhdGggdmlhIEJGRCBS ZXZlcnNlIFBhdGggVExWLCB0aGVuIHRoYXQgd2lsbCBjcmVhdGUgYSBzdGF0ZSBpbiB0aGUgZGF0 YSBwbGFuZS4gQ2xlYW5pbmcgaXQgdXAgbWF5IGJlIHJlcXVpcmVkIHRvIHByZXZlbnQgZXhoYXVz dGlvbiBvZiBhIHJlc291cmNlIGluIHRoZSBkYXRhIHBsYW5lLiBDZXJ0YWlubHkgZ3JlYXQgdG9w aWMgZm9yIGRpc2N1c3Npb24gaW4gVG9yb250by4gDQoNCkkgYmVsaWV2ZSBteSBjb2xsZWFndWUg aXMgYWJvdXQgdG8gcm9sbCBvdXQgYSBkb2N1bWVudCBmb3IgRXh0ZW5kZWQgQkZEIERpc2NyaW1p bmF0b3IgVExWIHdoaWNoIGFkZHJlc3NlcyAoMSkgYW5kICgyKSBhYm92ZS4gUHJpbWFyeSBtb3Rp dmF0aW9uIG9mIHRoYXQgZG9jdW1lbnQgaXMgRVZQTiBCRkQsIGJ1dCBpdCBsb29rcyB2ZXJ5IGFw cGxpY2FibGUgdG8gU2VnbWVudCBSb3V0aW5nIGFzIHdlbGwuDQpHSU0+PiBWZXJ5IGludGVyZXN0 aW5nIGluZGVlZC4gTG9va2luZyBmb3J3YXJkIHRvIHJlYWQgdGhlIHByb3Bvc2FsLg0KDQpMYXN0 bHksIGhvdyBkbyB3ZSB1c2UgdGhpcyBmb3IgUy1CRkQ/IDopDQoNCkxldCdzIGRpc2N1c3MgaW4g VG9yb250byBvbiBob3cgd2UgY2FuIGJlc3QgZGVmaW5lIHRoZSBtb3N0IHVzZWZ1bCBzb2x1dGlv bi4NCkdJTT4+IFRoYW5rIHlvdSENCg0KVGhhbmtzIQ0KDQotTm9ibw0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHcmVnb3J5IA0KPiBNaXJza3kNCj4gU2VudDogV2VkbmVz ZGF5LCBKdWx5IDAyLCAyMDE0IDE6MTUgUE0NCj4gVG86IE1hY2ggQ2hlbjsgbXBsc0BpZXRmLm9y Zw0KPiBDYzogcnRnLWJmZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvcg0KPiBkcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQtIDAwLnR4dA0K PiANCj4gSGkgTWFjaCwNCj4gdGhhbmsgeW91IGZvciB5b3VyIGZlZWRiYWNrLg0KPiBJbmRlZWQs IGJvdGggZHJhZnRzIGhhdmUgY29tbW9uYWxpdGllcy4NCj4gSSdtIGxvb2tpbmcgZm9yd2FyZCB0 byB0aGUgZGlzY3Vzc2lvbiBpbiBUb3JvbnRvIGFuZCBob3cgd2UgY2FuIGJyaW5nIA0KPiB0aGlz IGlkZWEgZnVydGhlci4NCj4gDQo+IAlSZWdhcmRzLA0KPiAJCUdyZWcNCj4gDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1hY2ggQ2hlbiBbbWFpbHRvOm1hY2guY2hlbkBo dWF3ZWkuY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDAxLCAyMDE0IDY6NTcgUE0NCj4gVG86 IEdyZWdvcnkgTWlyc2t5DQo+IENjOiBydGctYmZkQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+IGRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJl Y3RlZC0gMDAudHh0DQo+IA0KPiBIaSBHcmVnLA0KPiANCj4gSSBoYXZlIGEgcXVpY2sgcmV2aWV3 IG9uIHRoZSBkcmFmdCwgd2VsbCB3cml0dGVuIGFuZCB1c2VmdWwgZHJhZnQhDQo+IA0KPiBDb3Vw bGUgeWVhcnMgYWdvLCB3ZSBzdWJtaXR0ZWQgYSBkcmFmdA0KPiAoaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtDQo+IGNoZW4tbXBscy1iZmQtZW5oYW5jZW1lbnQtMDEpIHRoYXQgaW50 ZW5kIHRvIHNvbHZlIHRoZSBzaW1pbGFyIGlzc3VlLCANCj4gZ2xhZCB3ZSBoYXZlIHRoZSBzaW1p bGFyIHRob3VnaHQ6LSkuDQo+IA0KPiBJdCBhbHNvIGRlZmluZXMgZXh0ZW5zaW9ucyB0byBMU1Ag UGluZyB0byBkaXJlY3QgdGhlIGNob29zZSBvZiB0aGUgDQo+IHJldHVybiBwYXRoIG9mIEJGRCBj b250cm9sIHBhY2tldHMuIFBsZWFzZSB0YWtlIGEgbG9vay4NCj4gDQo+IEJlc3QgcmVnYXJkcywN Cj4gTWFjaA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IFJ0 Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHcmVn b3J5IA0KPiA+IE1pcnNreQ0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAwMiwgMjAxNCAyOjE5 IEFNDQo+ID4gVG86IG1wbHNAaWV0Zi5vcmc7IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0 OiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciANCj4gPiBkcmFmdC1taXJza3ktbXBs cy1iZmQtZGlyZWN0ZWQtMDAudHh0DQo+ID4NCj4gPiBEZWFyIEFsbCwNCj4gPiB3ZSd2ZSBwb3N0 ZWQgYSBuZXcgZHJhZnQuIExTUCBQaW5nIGFscmVhZHkgaXMgdXNlZCB0byBib290c3RyYXAgYSAN Cj4gPiBCRkQgc2Vzc2lvbiB3aXRoIEJGRCBEaXNjcmltaW5hdG9yIFRMVi4gQSBuZXcgQkZEIFJl dmVyc2UgUGF0aCBUTFYgDQo+ID4gaXMgaW50cm9kdWNlZCBpbiBvcmRlciB0byBpbnN0cnVjdCBh IGZhci1lbmQgQkZEIHBlZXIgdG8gdXNlIA0KPiA+IHBhcnRpY3VsYXIgcGF0aCBmb3IgcmV2ZXJz ZSBkaXJlY3Rpb24gb2YgdGhlIEJGRCBzZXNzaW9uLg0KPiA+DQo+ID4gR3JlYXRseSBhcHByZWNp YXRlIHlvdXIgcXVlc3Rpb25zLCBjb21tZW50cy4NCj4gPg0KPiA+IAlSZWdhcmRzLA0KPiA+IAkJ R3JlZw0KPiA+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+ ID4gU2VudDogTW9uZGF5LCBKdW5lIDMwLCAyMDE0IDQ6MTUgUE0NCj4gPiBUbzogR3JlZ29yeSBN aXJza3k7IElseWEgVmFybGFzaGtpbjsgSmVmZiBUYW50c3VyYTsgR3JlZ29yeSBNaXJza3k7IA0K PiA+IEplZmYgVGFudHN1cmE7IElseWEgVmFybGFzaGtpbg0KPiA+IFN1YmplY3Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+ID4gZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVk LTAwLnR4dA0KPiA+DQo+ID4NCj4gPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWlyc2t5 LW1wbHMtYmZkLWRpcmVjdGVkLTAwLnR4dA0KPiA+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgR3JlZyBNaXJza3kgYW5kIHBvc3RlZCB0byB0aGUgDQo+ID4gSUVURiByZXBvc2l0 b3J5Lg0KPiA+DQo+ID4gTmFtZToJCWRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZA0KPiA+ IFJldmlzaW9uOgkwMA0KPiA+IFRpdGxlOgkJQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVj dGlvbiAoQkZEKSBEaXJlY3RlZCBSZXR1cm4NCj4gUGF0aA0KPiA+IERvY3VtZW50IGRhdGU6CTIw MTQtMDYtMzANCj4gPiBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiA+IFBhZ2VzOgkJ OA0KPiA+IFVSTDoNCj4gPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQtMDAuDQo+ID4gdHh0DQo+ID4gU3RhdHVzOg0KPiA+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1pcnNreS1tcGxzLWJmZC1k aXJlY3RlZC8NCj4gPiBIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkLTAwDQo+ID4NCj4gPg0KPiA+IEFic3RyYWN0 Og0KPiA+ICAgIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgaXMgZXhw ZWN0ZWQgdG8gbW9uaXRvciBiaS0NCj4gPiAgICBkaXJlY3Rpb25hbCBwYXRocy4gIFdoZW4gZm9y d2FyZCBkaXJlY3Rpb24gb2YgYSBCRkQgc2Vzc2lvbiBpcyB0bw0KPiA+ICAgIG1vbml0b3IgZXhw bGljaXRseSByb3V0ZWQgcGF0aCB0aGVyZSBpc1wgYSBuZWVkIHRvIGJlIGFibGUgdG8gZGlyZWN0 DQo+ID4gICAgZmFyLWVuZCBCRkQgcGVlciB0byB1c2Ugc3BlY2lmaWMgcGF0aCBhcyByZXZlcnNl IGRpcmVjdGlvbiBvZiB0aGUgQkZEDQo+ID4gICAgc2Vzc2lvbi4NCj4gPg0KPiA+DQo+ID4NCj4g Pg0KPiA+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm cm9tIHRoZSB0aW1lIG9mIA0KPiA+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0KPiB0b29scy5pZXRmLm9yZy4NCj4gPg0KPiA+ IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Fri Jul 4 08:33:07 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1471B29E0 for ; Fri, 4 Jul 2014 08:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsqvujK2Qn00 for ; Fri, 4 Jul 2014 08:33:04 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9921E1B29DA for ; Fri, 4 Jul 2014 08:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2538; q=dns/txt; s=iport; t=1404487984; x=1405697584; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0Pdmwa3O+YLQmEDvWafhz4LZpAtFngk7Zdyu8V+LFZI=; b=QtWiKekWDLTEW3EV7Ed6bebxjbLdn2nwd5w4RAJNM79vw4y6tMOCKdTl +Nlrc5YZfpYpV5EE5c6g8WRKoUtLf0yzQH2zPZElAIBGWNSeA/uH2DjvY cu/EtSgCXNZY9Pxk6UA8YKks+ITItz0LAyWVWUf894vXJzT+dfKMEMSCD w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAMHItlOtJA2G/2dsb2JhbABagw5SWoJvwzoBGXIWdYQDAQEBBCMRQwIMBAIBCBEEAQEDAgYdAwICAjAUAQYBAQUDAgQOBQgBiDkNryibHheBLI1FBisHBAKCcTaBFgWcPpJEggGBQmyBRA X-IronPort-AV: E=Sophos;i="5.01,601,1400025600"; d="scan'208";a="58315605" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP; 04 Jul 2014 15:32:48 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s64FWlkP013138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 4 Jul 2014 15:32:47 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.202]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 10:32:47 -0500 From: "Vengada Prasad Govindan (venggovi)" To: "rtg-bfd@ietf.org" Subject: FW: New Version Notification for draft-vgovindan-mpls-extended-bfd-disc-tlv-00.txt Thread-Topic: New Version Notification for draft-vgovindan-mpls-extended-bfd-disc-tlv-00.txt Thread-Index: AQHPl4mFNgiJ7lBGzEawoL9A5AVhppuQCexw Date: Fri, 4 Jul 2014 15:32:47 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D34623EBA@xmb-rcd-x15.cisco.com> References: <20140704131127.29231.56989.idtracker@ietfa.amsl.com> In-Reply-To: <20140704131127.29231.56989.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.51.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/fQ4ruU-Nq0z0glpGAXYy-t7s-4c X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 15:33:06 -0000 SGVsbG8gYWxsLA0KICBXZSBoYXZlIHBvc3RlZCBhIG5ldyBkcmFmdCBvdXRsaW5pbmcgYSBwcm9w b3NhbCB0byBleHRlbmQgdGhlIEJGRCBEaXNjcmltaW5hdG9yIFRMViBvZiB0aGUgTVBMUyBwaW5n IHRvIGJvb3RzdHJhcCBtdWx0aXBsZSBCRkQgc2Vzc2lvbnMgZm9yIGEgPE1QTFMgRkVDLCBMU1A+ IHR1cGxlLiBQbGVhc2UgbGV0IHVzIGtub3cgeW91ciBxdWVzdGlvbnMsIGNvbW1lbnRzLCBzdWdn ZXN0aW9ucyBhYm91dCB0aGlzIGRyYWZ0Lg0KVGhhbmtzDQpQcmFzYWQNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBGcmlkYXksIEp1bHkgMDQsIDIwMTQgNjo0 MSBQTQ0KVG86IE5vYm8gQWtpeWEgKG5vYm8pOyBWZW5nYWRhIFByYXNhZCBHb3ZpbmRhbiAodmVu Z2dvdmkpOyBOb2JvIEFraXlhIChub2JvKTsgVmVuZ2FkYSBQcmFzYWQgR292aW5kYW4gKHZlbmdn b3ZpKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC12Z292aW5k YW4tbXBscy1leHRlbmRlZC1iZmQtZGlzYy10bHYtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LXZnb3ZpbmRhbi1tcGxzLWV4dGVuZGVkLWJmZC1kaXNjLXRsdi0wMC50eHQN CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVmVuZ2FkYSBQcmFzYWQgR292aW5k YW4gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtdmdv dmluZGFuLW1wbHMtZXh0ZW5kZWQtYmZkLWRpc2MtdGx2DQpSZXZpc2lvbjoJMDANClRpdGxlOgkJ TGFiZWwgU3dpdGNoZWQgUGF0aCAoTFNQKSBQaW5nIEV4dGVuZGVkIEJpZGlyZWN0aW9uYWwgRm9y d2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgRGlzY3JpbWluYXRvciBUTFYNCkRvY3VtZW50IGRhdGU6 CTIwMTQtMDctMDQNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTgNClVS TDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC12 Z292aW5kYW4tbXBscy1leHRlbmRlZC1iZmQtZGlzYy10bHYtMDAudHh0DQpTdGF0dXM6ICAgICAg ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdmdvdmluZGFuLW1wbHMt ZXh0ZW5kZWQtYmZkLWRpc2MtdGx2Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXZnb3ZpbmRhbi1tcGxzLWV4dGVuZGVkLWJmZC1kaXNjLXRsdi0wMA0K DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGFuIGV4dGVuZGVkIEJpZGly ZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24NCiAgIChCRkQpIGRpc2NyaW1pbmF0b3IgVExW IGZvciB0aGUgTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgKE1QTFMpDQogICBMYWJlbCBT d2l0Y2hlZCBQYXRoIChMU1ApIFBpbmcgbWVjaGFuaXNtLCB0byBhbGxvdyBib290c3RyYXBwaW5n IG9mDQogICBtdWx0aXBsZSBCRkQgc2Vzc2lvbnMgZm9yIGEgZ2l2ZW4gRkVDLg0KDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Fri Jul 4 08:50:13 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9263A1A0233 for ; Fri, 4 Jul 2014 08:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id en411oYfDgPx for ; Fri, 4 Jul 2014 08:50:08 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3E91A0353 for ; Fri, 4 Jul 2014 08:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3718; q=dns/txt; s=iport; t=1404489008; x=1405698608; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=qZhvlRF7hDB81duAQNDTE328wP/3bmha6jVAHT42rb4=; b=GU/zcuvgsoAJJRC6VZo+Q7rquAeNIoEYrECbgSx2N2SwRKHiXfVbVpId ctzqk2ryK3BAnmgvxVEIjLShVGB0l5rp8y/MpV0ez9bBzRBuPirBKFXEc TrVAVDCVJMjLUeoJ8CJVOGiKERjvj83+ru71YJPsZVsn4eSkBqck26dTz E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAEHMtlOtJV2U/2dsb2JhbABagmokUlrGKQGBCxZ1hAMBAQEEOksEAgEIEQQBAQsUCQcyFAkIAQEEARIIAYg5AQzKSBeOQBEBHzgGgyeBFgWvAoNDgXc5 X-IronPort-AV: E=Sophos;i="5.01,601,1400025600"; d="scan'208";a="58373035" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP; 04 Jul 2014 15:50:07 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s64Fo7tW012011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jul 2014 15:50:07 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 10:50:06 -0500 From: "Nobo Akiya (nobo)" To: Mingui Zhang , "Jeff Haas (jhaas@juniper.net)" , "rtg-bfd@ietf.org" Subject: RE: [Tentative] BFD WG Agenda for IETF90 Thread-Topic: [Tentative] BFD WG Agenda for IETF90 Thread-Index: Ac+UiZAWL5Mu2kjMROSJ/nHy59ZzAwBAGTDgAGwDVjAAGUChEA== Date: Fri, 4 Jul 2014 15:50:06 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7E544A@eusaamb103.ericsson.se> <4552F0907735844E9204A62BBDD325E76A0E0757@nkgeml508-mbx.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E76A0E0757@nkgeml508-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/eSDXFiueEHLkwdebeZlbBOjoAj4 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 15:50:10 -0000 Hi Mingui, Your document is now in the agenda, please send us the slides by no later t= han 2014-07-14 (Monday). Thanks! -Nobo > -----Original Message----- > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Friday, July 04, 2014 5:43 AM > To: Gregory Mirsky; Nobo Akiya (nobo); Jeff Haas (jhaas@juniper.net); rtg= - > bfd@ietf.org > Subject: RE: [Tentative] BFD WG Agenda for IETF90 >=20 > Hi WG Chairs, >=20 > Is there more room for another draft?:) We would like to get suggestions > and directions from the WG. >=20 > -Title > Use Cases Requiring New Features of BFD -Draft draft-zhang-bfd-new-use- > cases-00.txt > -Presenter > Mingui Zhang >=20 > Comments are welcome! >=20 > Thanks, > Mingui >=20 > >-----Original Message----- > >From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory > >Mirsky > >Sent: Wednesday, July 02, 2014 8:15 AM > >To: Nobo Akiya (nobo); Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org > >Subject: RE: [Tentative] BFD WG Agenda for IETF90 > > > >Dear Nobo and Jeff, > >hope you would accept another presentation request for the meeting in > >Toronto: > > > >* Title - BFD Directed Return Path > >* Draft - draft-mirsky-mpls-bfd-directed-00 > >* Presenter - Greg Mirsky > >* Duration - 10 min > > > > > > Regards, > > Greg > > > >-----Original Message----- > >From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya > >(nobo) > >Sent: Monday, June 30, 2014 10:44 AM > >To: rtg-bfd@ietf.org > >Cc: Jeff Haas (jhaas@juniper.net) > >Subject: [Tentative] BFD WG Agenda for IETF90 > > > >Hello BFDers, > > > >Tentative BFD WG Agenda for IETF90 has been posted. > > > >http://www.ietf.org/proceedings/90/agenda/agenda-90-bfd > >(tentative agenda also pasted below for easier reference) > > > >If: > >- Your presentation information is not accurate; > >- Your presentation information is missing; > >- You do not agree with the agenda or a specific presentation listed; > > > >please provide your comment via replying to this thread (with WG list > >included or just the chairs). > > > >Reminder to presenters: > > > >Please email your slides to the chairs no later than 2014-07-14 (Monday)= . > > > >Thanks! > > > >-Nobo and Jeff > > > > > >IETF 90 - BFD WG Meeting Session Agenda > > > >MONDAY, July 21, 2014 > >1520-1650 Afternoon Session II > >Salon B > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > >CHAIR(s): Jeffrey Haas > > Nobo Akiya > > > >- WG Statuses and Administrivia 15 minutes > > Presenter > > Co-chairs > > > >- BFD Proxy for Connections over Monitored Links 10 minutes > > Draft > > draft-snyder-bfd-proxy-connections-monitored-links-00 > > Presenter > > Brian Snyder > > > >- BFD Stability 10 minutes > > Draft > > draft-ashesh-bfd-stability-00 > > Presenter > > Ashesh Mishra > > > >- Seamless BFD Use-Case 10 minutes > > Draft > > draft-ietf-bfd-seamless-use-case-00 > > Presenter > > Sam K. Aldrin > > > >- Seamless BFD Base/IP 10 minutes > > Draft > > draft-ietf-bfd-seamless-base-01 > > draft-akiya-bfd-seamless-ip-03 > > Presenter > > Nobo Akiya > > > >- L2VPN EVPN BFD 10 minutes > > Draft > > draft-vgovindan-l2vpn-evpn-bfd-02 > > Presenter > > Vengada Prasad Govindan > > > > From nobody Sun Jul 6 15:51:06 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A511B27AA for ; Sun, 6 Jul 2014 15:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gx6ADwnHuW1 for ; Sun, 6 Jul 2014 15:51:04 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 471EA1B27A4 for ; Sun, 6 Jul 2014 15:51:04 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A95E9C077; Sun, 6 Jul 2014 18:51:03 -0400 (EDT) Date: Sun, 6 Jul 2014 18:51:03 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15) Message-ID: <20140706225103.GB21814@pfrc> References: <20140630163846.GA11842@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140630163846.GA11842@pfrc> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/IbnMVjC4WDFiZ0eyKjfTcPdceC0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 22:51:05 -0000 We are coming up on the second week of this WGLC and have thus far only heard from one non-author. :-) Please take a moment and review this draft, especially if you are an implementor. -- Jeff On Mon, Jun 30, 2014 at 12:38:46PM -0400, Jeffrey Haas wrote: > Working Group, > > We would like to initiate the start of Working Group Last Call for > Common Interval Support in BFD: > > http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 > > Note that the intended status of this document is INFORMATIONAL. > > Please send your comments, including whether you think the draft is ready > for publication or not, to the list no later than July 15. > > -- Jeff and Nobo From nobody Mon Jul 7 00:38:02 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFD81A0B0E for ; Mon, 7 Jul 2014 00:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UkLFS9tPkCs for ; Mon, 7 Jul 2014 00:37:56 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3646A1B278F for ; Mon, 7 Jul 2014 00:37:56 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id s7so2569081lbd.18 for ; Mon, 07 Jul 2014 00:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4sELiald7ivVYAtTVj0ivHhEJN5MvyUFVozdnzIZvoQ=; b=E3llBF2SiqiJHjct5pNjjCebVQy/3OhWTHSWiWBZicHiRKqN4kmrxdavnW53IIKRnX POc/PK+6Ft4V9vAyqQ0SEbQseL187CECymRJQfmKtFnclo8PuZB/RX3HXgiBHwCpwYKd ZhTE54sGhNqEnOEVrbzkh6dzEKEnIcHWXsOzjoesi8y8eKxYfb5H+3nlr5TK2dzG9GG3 qZNo+qaeyits2/MuQqHRv+xHSlrhTsdMivcWkq7ihDWSQAPnOQoIhHg7C2EQ9A+VEBHZ nz9mP2Pvle0/5Kddd1lcffkZUFGInEpRQHzZ/Cc634K8pA2QUh3kWuPJLg28gEV0DutX rBnQ== MIME-Version: 1.0 X-Received: by 10.152.22.4 with SMTP id z4mr6008500lae.2.1404718674515; Mon, 07 Jul 2014 00:37:54 -0700 (PDT) Received: by 10.114.57.166 with HTTP; Mon, 7 Jul 2014 00:37:54 -0700 (PDT) In-Reply-To: <20140706225103.GB21814@pfrc> References: <20140630163846.GA11842@pfrc> <20140706225103.GB21814@pfrc> Date: Mon, 7 Jul 2014 13:07:54 +0530 Message-ID: Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15) From: Binny Jeshan To: Jeffrey Haas Content-Type: multipart/alternative; boundary=089e0158b8e29a9c7f04fd958d39 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/bTxX17AhGPp4ER5V_KhcH7BUbcQ Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 07:38:00 -0000 --089e0158b8e29a9c7f04fd958d39 Content-Type: text/plain; charset=UTF-8 Hi, I honestly do not support a need of a new draft to impose Timing standards to BFD Intervals. As someone who had implemented BFD across various granularity of intervals and testing them with interop environment, i would say it wasn't difficult to get things right. And as a SW implementor, i just see that if this Draft is referred in my System Requirements, i may just verify BFD sessions with these timers to ensure conformance. I do not see any additional pain relief :) AFAIK, Just like the SW flexibility, HW was too able to pick up varied timer intervals - and if it did not, it was known and agreed with the requirements. However, as i see that its an Informational Document, and i do remember a discussion about an year back to make it so. So, you may keep this as a guide of operators to set requirements to Vendors. That's it what i would look at it. Thanks, Binny. On 7 July 2014 04:21, Jeffrey Haas wrote: > We are coming up on the second week of this WGLC and have thus far only > heard from one non-author. :-) Please take a moment and review this draft, > especially if you are an implementor. > > -- Jeff > > On Mon, Jun 30, 2014 at 12:38:46PM -0400, Jeffrey Haas wrote: > > Working Group, > > > > We would like to initiate the start of Working Group Last Call for > > Common Interval Support in BFD: > > > > http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 > > > > Note that the intended status of this document is INFORMATIONAL. > > > > Please send your comments, including whether you think the draft is ready > > for publication or not, to the list no later than July 15. > > > > -- Jeff and Nobo > > --089e0158b8e29a9c7f04fd958d39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi,

    I honestly do not support = a need of a new draft to impose Timing standards to BFD Intervals.
    As so= meone who had implemented BFD across various granularity of intervals and t= esting them with interop environment, i would say it wasn't difficult t= o get things right. And as a SW implementor, i just see that if this Draft = is referred in my System Requirements, i may just verify BFD sessions with = these timers to ensure conformance. I do not see any additional pain relief= :)

    AFAIK, Just like the SW flexibility, HW was too able to pick= up varied timer intervals - and if it did not, it was known and agreed wit= h the requirements.

    However, as i see that it= s an Informational Document, and i do remember a discussion about an year b= ack to make it so.

    So, you may keep this as a guide of operators to set requirements to Ve= ndors. That's it what i would look at it.

    Thanks,
    =
    Binny.


    On 7 July 2014 04:21, Jeffrey Haas <jhaas@pfrc.org> wrote:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> We are coming up on the second week of this WGLC and have thus far only
    heard from one non-author. :-) =C2=A0Please take a moment and review this d= raft,
    especially if you are an implementor.

    -- Jeff

    On Mon, Jun 30, 2014 at 12:38:46PM -0400, Jeffrey Haas wrote:
    > Working Group,
    >
    > We would like to initiate the start of Working Group Last Call for
    > Common Interval Support in BFD:
    >
    > http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 >
    > Note that the intended status of this document is INFORMATIONAL.
    >
    > Please send your comments, including whether you think the draft is re= ady
    > for publication or not, to the list no later than July 15.
    >
    > -- Jeff and Nobo


    --089e0158b8e29a9c7f04fd958d39-- From nobody Mon Jul 7 07:31:11 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA1A1A0166 for ; Mon, 7 Jul 2014 07:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0XSHXakisf3 for ; Mon, 7 Jul 2014 07:31:07 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 35A9C1A011C for ; Mon, 7 Jul 2014 07:31:07 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id BBEF1C2D8; Mon, 7 Jul 2014 10:31:06 -0400 (EDT) Date: Mon, 7 Jul 2014 10:31:06 -0400 From: Jeffrey Haas To: Binny Jeshan Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15) Message-ID: <20140707143106.GA23523@pfrc> References: <20140630163846.GA11842@pfrc> <20140706225103.GB21814@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/T0H7roOShiLySaL5KovxaU6cpXA Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 14:31:08 -0000 Binny, On Mon, Jul 07, 2014 at 01:07:54PM +0530, Binny Jeshan wrote: > However, as i see that its an Informational Document, and i do remember a > discussion about an year back to make it so. It is. > So, you may keep this as a guide of operators to set requirements to > Vendors. That's it what i would look at it. And given that context, would you support the document? -- Jeff From nobody Mon Jul 7 08:14:50 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0B91A0162 for ; Mon, 7 Jul 2014 08:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YE6TswPvictR for ; Mon, 7 Jul 2014 08:14:45 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A11C1A0183 for ; Mon, 7 Jul 2014 08:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=686; q=dns/txt; s=iport; t=1404746080; x=1405955680; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=aa3mMJukC37/II5gqA4BbnJGNvAKnj8VyE7b+8EwmGs=; b=K2sUb/XsIXFMl5dBku84sGlFOPWbxW0O+n5Pzenc0ZdDH0rutUy9XKDc v92jvVZBjhzL/ghCjWQtL63Qz9dDW1Bo0BGJs9SaFEA5oVaWcj9/wPB9y e+d71jJJXothsdkaUwjUCcvU4Ccc45y0aXEtH0OB3uPaL1EvGo3VLV4ab 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFANS4ulOtJA2J/2dsb2JhbABagmokUlrGPAGBFhZ1hAUBBDpRASoUQiYBBBuIOgEMoQGpCBMEjnGDZYEWBa8Cg0OCMA X-IronPort-AV: E=Sophos;i="5.01,618,1400025600"; d="scan'208";a="338222053" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-5.cisco.com with ESMTP; 07 Jul 2014 15:14:39 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s67FEdid022508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 7 Jul 2014 15:14:39 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 10:14:38 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: IETF90 BFD WG Session Thread-Topic: IETF90 BFD WG Session Thread-Index: Ac+Z9XIv/Mb/ktCaR0m4KvL9tjDOuw== Date: Mon, 7 Jul 2014 15:14:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/3e3_4VZHpmtp9A0m_Zn9XVIfL7Q X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 15:14:47 -0000 Hello BFDers, IETF90 BFD WG session is: MONDAY, July 21, 2014 1520-1650 Afternoon Session II Salon B IETF90 BFD WG agenda has been updated. https://datatracker.ietf.org/meeting/90/agenda/bfd/ We have a fairly tight schedule, and we need to allocate a buffer for discu= ssions that are beneficial to happen/continue. Due to this: - Some presentation slots were reduced from 10 minutes to 8 minutes. - The session will start on-time, starting with WG status and Administrivia= . Presenters, please plan your presentation accordingly, and send the chairs = your slides by no later than 2014-07-14 (Monday). Thanks and see you in 2 weeks! -Nobo and Jeff From nobody Mon Jul 7 09:12:21 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195041A033D for ; Mon, 7 Jul 2014 09:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbLhXQscJO9S for ; Mon, 7 Jul 2014 09:12:16 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54E41A035A for ; Mon, 7 Jul 2014 09:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1168; q=dns/txt; s=iport; t=1404749535; x=1405959135; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=/rZjrU8sYew9swSSku/zv80j9+iOJOG6EM4IL+SEYNU=; b=OykeyNIHHvGo2exO2ebMaqCisqpGwVd7cmzrg8rTaCqDWUfce+/R2Av9 XZemzpXkjj8BW7jK0yVS5v/zojxicDrSA8Em2PV/xHJm+GxPN745uCJnc lARycEMYcPGYwo9LhDpAvSWOib2Ezq2utsdUA7hYrXHvyUoFqq6+GVWMf I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAO3FulOtJV2U/2dsb2JhbABagw5SWsY8AYEXFnWEAwEBAQQdHUsEAgEIDgMEAQEBChQJBzIUCQgCBAESCIg6DcoCF4t9gnQ4BoMngRYFnD6SRINDgjA X-IronPort-AV: E=Sophos;i="5.01,618,1400025600"; d="scan'208";a="58850011" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-3.cisco.com with ESMTP; 07 Jul 2014 16:12:15 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s67GCEN4026796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jul 2014 16:12:15 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.202]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 11:12:14 -0500 From: "Vengada Prasad Govindan (venggovi)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15) Thread-Topic: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15) Thread-Index: AQHPlIHI5AreR73OI0qwzQpOBuNpCpuUBFSAgADOPRA= Date: Mon, 7 Jul 2014 16:12:13 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D346263F3@xmb-rcd-x15.cisco.com> References: <20140630163846.GA11842@pfrc> <20140706225103.GB21814@pfrc> In-Reply-To: <20140706225103.GB21814@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.68.21.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/SR3U-_uZVsZ88MitX_CEzl3dz_c X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 16:12:18 -0000 Hello Jeff, From an implementer's perspective, I see this draft adds value by steerin= g implementations towards a point of convergence. I support this draft for = publication. Thanks Prasad -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Monday, July 07, 2014 4:21 AM To: rtg-bfd@ietf.org Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals (ending J= uly 15) We are coming up on the second week of this WGLC and have thus far only hea= rd from one non-author. :-) Please take a moment and review this draft, es= pecially if you are an implementor.=20 -- Jeff On Mon, Jun 30, 2014 at 12:38:46PM -0400, Jeffrey Haas wrote: > Working Group, >=20 > We would like to initiate the start of Working Group Last Call for=20 > Common Interval Support in BFD: >=20 > http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 >=20 > Note that the intended status of this document is INFORMATIONAL. >=20 > Please send your comments, including whether you think the draft is=20 > ready for publication or not, to the list no later than July 15. >=20 > -- Jeff and Nobo From nobody Mon Jul 7 11:49:45 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225AB1B27ED for ; Mon, 7 Jul 2014 11:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxXmtT-WLqej for ; Mon, 7 Jul 2014 11:49:42 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467AC1A028B for ; Mon, 7 Jul 2014 11:49:42 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jw12so4436308veb.25 for ; Mon, 07 Jul 2014 11:49:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e1FjH9W623YrCQ/2/adgEvGeQqKnBIUm/WfH9nyhsqM=; b=e4JzgzVZ5YYOFYSk3Jtb9CKr+5nOq9nJyCC2mzxv5kv8GzeTnEC9kRqDFVzkHgc9IP aKeMAbxRe28Sisv94qGWd4JyMWLlzgBhyBNowNCOKe0Eo4FUvsHLvHvcvkibdy1hED5G g6R+Wfhf+FiJgcHLRMWSdhexiHgHwyb073kZlmOnNwvTtNxAMrqhOcc12tHp8GW68uGC Snn0XKqMg6r5DJpS4jx6C7sLdLzEp3W7/7/Lhab7YUzqE9wH/kIviHxv8wQCKL0gP2Xc 4dEsOkFZGBnzqmrE4fD48AZmqDHrWuPVw/13N8rHTMeknza93p/4GybBJDHJGiC9XH04 +p9A== MIME-Version: 1.0 X-Received: by 10.220.69.68 with SMTP id y4mr29254847vci.21.1404758981358; Mon, 07 Jul 2014 11:49:41 -0700 (PDT) Received: by 10.52.100.129 with HTTP; Mon, 7 Jul 2014 11:49:41 -0700 (PDT) In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D346263F3@xmb-rcd-x15.cisco.com> References: <20140630163846.GA11842@pfrc> <20140706225103.GB21814@pfrc> <315041E4211CB84E86EF7C25A2AB583D346263F3@xmb-rcd-x15.cisco.com> Date: Mon, 7 Jul 2014 14:49:41 -0400 Message-ID: Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15) From: Pablo Frank To: "Vengada Prasad Govindan (venggovi)" Content-Type: multipart/alternative; boundary=047d7b3a9252143d7504fd9ef02a Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/_C6hWRoxxnruMhWxa74nJC41CfE Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 18:49:44 -0000 --047d7b3a9252143d7504fd9ef02a Content-Type: text/plain; charset=UTF-8 I'm working on a HW implementation that supports the proposed intervals and the draft was useful in that context. I can see that the non-Y.1731 standard intervals (i.e. 20ms, 50ms) could prove a challenge for some existing hardware implementations, but these rates should be within the capability of most software implementations. Even for existing hardware implementations, since the new rates are a multiple of 10ms, it's usually not *that* challenging. So yes/support. regards, Pablo On Mon, Jul 7, 2014 at 12:12 PM, Vengada Prasad Govindan (venggovi) < venggovi@cisco.com> wrote: > Hello Jeff, > From an implementer's perspective, I see this draft adds value by > steering implementations towards a point of convergence. I support this > draft for publication. > Thanks > Prasad > > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Monday, July 07, 2014 4:21 AM > To: rtg-bfd@ietf.org > Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals (ending > July 15) > > We are coming up on the second week of this WGLC and have thus far only > heard from one non-author. :-) Please take a moment and review this draft, > especially if you are an implementor. > > -- Jeff > > On Mon, Jun 30, 2014 at 12:38:46PM -0400, Jeffrey Haas wrote: > > Working Group, > > > > We would like to initiate the start of Working Group Last Call for > > Common Interval Support in BFD: > > > > http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 > > > > Note that the intended status of this document is INFORMATIONAL. > > > > Please send your comments, including whether you think the draft is > > ready for publication or not, to the list no later than July 15. > > > > -- Jeff and Nobo > > --047d7b3a9252143d7504fd9ef02a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    I'm working on a HW implementation that supports the p= roposed intervals and the draft was useful in that context. =C2=A0I can see= that the non-Y.1731 standard intervals (i.e. 20ms, 50ms) could prove a cha= llenge for some existing hardware implementations, but these rates should b= e within the capability of most software implementations. =C2=A0Even for ex= isting hardware implementations, since the new rates are a multiple of 10ms= , it's usually not *that* challenging. =C2=A0So yes/support.

    regards,
    Pablo



    On Mon, Jul 7, 2014 at= 12:12 PM, Vengada Prasad Govindan (venggovi) <venggovi@cisco.com>= wrote:
    Hello Jeff,
    =C2=A0 From an implementer's perspective, I see this draft adds value b= y steering implementations towards a point of convergence. I support this d= raft for publication.
    Thanks
    Prasad

    -----Original Message-----
    From: Rtg-bfd [mailto:rtg-bfd-b= ounces@ietf.org] On Behalf Of Jeffrey Haas
    Sent: Monday, July 07, 2014 4= :21 AM
    To: rtg-bfd@ietf.org
    Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals (ending J= uly 15)

    We are coming up on the second week of this WGLC and have thus far only hea= rd from one non-author. :-) =C2=A0Please take a moment and review this draf= t, especially if you are an implementor.

    -- Jeff

    On Mon, Jun 30, 2014 at 12:38:46PM -0400, Jeffrey Haas wrote:
    > Working Group,
    >
    > We would like to initiate the start of Working Group Last Call for
    > Common Interval Support in BFD:
    >
    > http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 >
    > Note that the intended status of this document is INFORMATIONAL.
    >
    > Please send your comments, including whether you think the draft is > ready for publication or not, to the list no later than July 15.
    >
    > -- Jeff and Nobo


    --047d7b3a9252143d7504fd9ef02a-- From nobody Mon Jul 7 14:29:31 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FCF1B2938; Mon, 7 Jul 2014 14:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OZBObihcAJZ; Mon, 7 Jul 2014 14:29:28 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5110E1B2933; Mon, 7 Jul 2014 14:29:27 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-c7-53babf0dbb87 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 18.CF.05330.D0FBAB35; Mon, 7 Jul 2014 17:38:53 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Mon, 7 Jul 2014 17:29:26 -0400 From: Gregory Mirsky To: "Vengada Prasad Govindan (venggovi)" , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-vgovindan-mpls-extended-bfd-disc-tlv-00.txt Thread-Topic: New Version Notification for draft-vgovindan-mpls-extended-bfd-disc-tlv-00.txt Thread-Index: AQHPl4mFNgiJ7lBGzEawoL9A5AVhppuQCexwgAUYmzA= Date: Mon, 7 Jul 2014 21:29:25 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7E7AC7@eusaamb103.ericsson.se> References: <20140704131127.29231.56989.idtracker@ietfa.amsl.com> <315041E4211CB84E86EF7C25A2AB583D34623EBA@xmb-rcd-x15.cisco.com> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D34623EBA@xmb-rcd-x15.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B7E7AC7eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXRPiC7v/l3BBpc6DC1uLV3JavH5zzZG i5kfNjE7MHtM+b2R1WPJkp9MAUxRXDYpqTmZZalF+nYJXBl3T/oVtMRUXJyzhbWB8UBkFyMn h4SAicTDB9PZIGwxiQv31gPZXBxCAkcZJRZc3sgO4SxjlJg/dQJYFZuAkcSLjT1ACQ4OEYE0 iaddsiAms4CyxKm7MiAVwgKxEk1/L7CD2CICcRKrXnxmgbCtJK7O28EIYrMIqEi0/u9mArF5 BXwl2q+9ZIRY1cIosfBNA9gqTqDE1iUrmUFsRqDjvp9aA9bALCAucevJfCaIowUkluw5zwxh i0q8fPyPFcJWlNjXP50doj5f4k1/EzPEMkGJkzOfsExgFJ2FZNQsJGWzkJTNAntNU2L9Ln2I EkWJKd0P2SFsDYnWOXPZkcUXMLKvYuQoLU4ty003MtjECIytYxJsujsY97y0PMQowMGoxMO7 IH9XsBBrYllxZe4hRmkOFiVx3lm184KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MHoVy3zx P+dZVT6lKAQYmqkMy2J+7wpfVRticORH/LUMsSV639+v2TpnUlJ+3O5Q6X8TXd5xzTzUOP+v /8XzHjxJy/fk3pj3oflRilUJg8OOKv0NloHXKzX6HH8eK79SN2Fj5cJomYUbDOZeMXEoa1xk v3Xdz0vLvuXcfPhYev/cSxVz95Xy71diKc5INNRiLipOBAA4x2FXjgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/lZJvdyaX9r5s7XrSUQwBBZXunHo Cc: "mpls@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 21:29:30 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B7E7AC7eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUHJhc2FkLA0KdGhpcyBpcyB2ZXJ5IGludGVyZXN0aW5nIHByb3Bvc2FsIGFuZCBJIHRoaW5r IHRoYXQgdGhlIE1QTFMgV0cgd2lsbCBiZSBpbnRlcmVzdGVkIGluIHRoZSBkaXNjdXNzaW9uLiBD b3VwbGUgY29tbWVudHMgYW5kIHF1ZXN0aW9uczoNCuKAoiAgICAgICBJIGJlbGlldmUgdGhhdCBt b25pdG9yaW5nIG9mIEVDTVAgc2VnbWVudHMgb24gbGluayBsYXllciBpcyBtb3JlIGVmZmljaWVu dCBjb21wYXJpbmcgdG8gZTJlIG1vbml0b3JpbmcuIFRoZSBkb2N1bWVudCBzdWdnZXN0cyBvdGhl cndpc2UuIENvdWxkIHlvdSBnaXZlIHNjZW5hcmlvcyBvciB1c2UgY2FzZXMgdGhhdCBzdXBwb3J0 IHVzZWZ1bG5lc3Mgb2YgbXVsdGlwbGUgQkZEIHNlc3Npb25zIGJldHdlZW4gdGhlIHNhbWUgcGVl cnMsIGdpdmVuIHRoYXQgeW91IG5lZWQgdG8gY29udHJvbCBtYXBwaW5nIG9mIEJGRCBzZXNzaW9u cyB0byBhIHBhcnRpY3VsYXIgcGF0aDsNCuKAoiAgICAgICBhbm90aGVyIHVzZSBjYXNlIHRvIHN1 cHBvcnQgbXVsdGlwbGUgQkZEIHNlc3Npb25zIGJldHdlZW4gdGhlIHNhbWUgcGVlcnMgaXMgT0FN IHJlZHVuZGFuY3kuIFdoYXQgeW91IHNlZSBhcyB0aGUgbWFpbiBiZW5lZml0IHRoZXJlPyBIb3cg dG8gbWFuYWdlIGRldGVjdGlvbiB0aW1lcyBhbW9uZyBtdWx0aXBsZSBCRkQgc2Vzc2lvbnM/DQri gKIgICAgICAgaGF2ZSB5b3UgbG9va2VkIGF0IFNlY3Rpb24gMi4yLjE8aHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLW1wbHMtdHAtb2FtLWNvbmYtMDY+ IG9mIHRoZSBkcmFmdC1pZXRmLW1wbHMtbHNwLXBpbmctbXBscy10cC1vYW0tY29uZiBhbmQgU2Vj dGlvbiAzLjM8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1yc3Zw LXRlLW1wbHMtdHAtb2FtLWV4dC0xMj4gb2YgdGhlIGRyYWZ0LWlldGYtY2NhbXAtcnN2cC10ZS1t cGxzLXRwLW9hbS1leHQNCg0KICAgUmVnYXJkcywNCiAgICAgICAgR3JlZw0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFZlbmdhZGEgUHJhc2FkIEdvdmluZGFuICh2ZW5nZ292aSkN ClNlbnQ6IEZyaWRheSwgSnVseSAwNCwgMjAxNCA4OjMzIEFNDQpUbzogcnRnLWJmZEBpZXRmLm9y Zw0KU3ViamVjdDogRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdmdvdmlu ZGFuLW1wbHMtZXh0ZW5kZWQtYmZkLWRpc2MtdGx2LTAwLnR4dA0KDQpIZWxsbyBhbGwsDQogIFdl IGhhdmUgcG9zdGVkIGEgbmV3IGRyYWZ0IG91dGxpbmluZyBhIHByb3Bvc2FsIHRvIGV4dGVuZCB0 aGUgQkZEIERpc2NyaW1pbmF0b3IgVExWIG9mIHRoZSBNUExTIHBpbmcgdG8gYm9vdHN0cmFwIG11 bHRpcGxlIEJGRCBzZXNzaW9ucyBmb3IgYSA8TVBMUyBGRUMsIExTUD4gdHVwbGUuIFBsZWFzZSBs ZXQgdXMga25vdyB5b3VyIHF1ZXN0aW9ucywgY29tbWVudHMsIHN1Z2dlc3Rpb25zIGFib3V0IHRo aXMgZHJhZnQuDQpUaGFua3MNClByYXNhZA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc+IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KU2VudDogRnJpZGF5LCBK dWx5IDA0LCAyMDE0IDY6NDEgUE0NClRvOiBOb2JvIEFraXlhIChub2JvKTsgVmVuZ2FkYSBQcmFz YWQgR292aW5kYW4gKHZlbmdnb3ZpKTsgTm9ibyBBa2l5YSAobm9ibyk7IFZlbmdhZGEgUHJhc2Fk IEdvdmluZGFuICh2ZW5nZ292aSkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtdmdvdmluZGFuLW1wbHMtZXh0ZW5kZWQtYmZkLWRpc2MtdGx2LTAwLnR4dA0KDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC12Z292aW5kYW4tbXBscy1leHRlbmRlZC1iZmQt ZGlzYy10bHYtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFZlbmdh ZGEgUHJhc2FkIEdvdmluZGFuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0K TmFtZTogICAgICAgICAgIGRyYWZ0LXZnb3ZpbmRhbi1tcGxzLWV4dGVuZGVkLWJmZC1kaXNjLXRs dg0KUmV2aXNpb246ICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgTGFiZWwgU3dpdGNoZWQgUGF0 aCAoTFNQKSBQaW5nIEV4dGVuZGVkIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24g KEJGRCkgRGlzY3JpbWluYXRvciBUTFYNCkRvY3VtZW50IGRhdGU6ICAyMDE0LTA3LTA0DQpHcm91 cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgOA0KVVJM OiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXZn b3ZpbmRhbi1tcGxzLWV4dGVuZGVkLWJmZC1kaXNjLXRsdi0wMC50eHQNClN0YXR1czogICAgICAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12Z292aW5kYW4tbXBscy1l eHRlbmRlZC1iZmQtZGlzYy10bHYvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtdmdvdmluZGFuLW1wbHMtZXh0ZW5kZWQtYmZkLWRpc2MtdGx2LTAwDQoN Cg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYW4gZXh0ZW5kZWQgQmlkaXJl Y3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbg0KICAgKEJGRCkgZGlzY3JpbWluYXRvciBUTFYg Zm9yIHRoZSBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoTVBMUykNCiAgIExhYmVsIFN3 aXRjaGVkIFBhdGggKExTUCkgUGluZyBtZWNoYW5pc20sIHRvIGFsbG93IGJvb3RzdHJhcHBpbmcg b2YNCiAgIG11bHRpcGxlIEJGRCBzZXNzaW9ucyBmb3IgYSBnaXZlbiBGRUMuDQoNCg0KDQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K DQoNCg== --_000_7347100B5761DC41A166AC17F22DF1121B7E7AC7eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+SGkgUHJhc2FkLDwvZGl2Pg0KPGRpdj50aGlzIGlz IHZlcnkgaW50ZXJlc3RpbmcgcHJvcG9zYWwgYW5kIEkgdGhpbmsgdGhhdCB0aGUgTVBMUyBXRyB3 aWxsIGJlIGludGVyZXN0ZWQgaW4gdGhlIGRpc2N1c3Npb24uIENvdXBsZSBjb21tZW50cyBhbmQg cXVlc3Rpb25zOjwvZGl2Pg0KPHVsIHN0eWxlPSJtYXJnaW46MDtwYWRkaW5nLWxlZnQ6MzZwdDsi Pg0KPGxpPkkgYmVsaWV2ZSB0aGF0IG1vbml0b3Jpbmcgb2YgRUNNUCBzZWdtZW50cyBvbiBsaW5r IGxheWVyIGlzIG1vcmUgZWZmaWNpZW50IGNvbXBhcmluZyB0byBlMmUgbW9uaXRvcmluZy4gVGhl IGRvY3VtZW50IHN1Z2dlc3RzIG90aGVyd2lzZS4gQ291bGQgeW91IGdpdmUgc2NlbmFyaW9zIG9y IHVzZSBjYXNlcyB0aGF0IHN1cHBvcnQgdXNlZnVsbmVzcyBvZiBtdWx0aXBsZSBCRkQgc2Vzc2lv bnMgYmV0d2VlbiB0aGUgc2FtZSBwZWVycywgZ2l2ZW4NCnRoYXQgeW91IG5lZWQgdG8gY29udHJv bCBtYXBwaW5nIG9mIEJGRCBzZXNzaW9ucyB0byBhIHBhcnRpY3VsYXIgcGF0aDs8L2xpPjxsaT5h bm90aGVyIHVzZSBjYXNlIHRvIHN1cHBvcnQgbXVsdGlwbGUgQkZEIHNlc3Npb25zIGJldHdlZW4g dGhlIHNhbWUgcGVlcnMgaXMgT0FNIHJlZHVuZGFuY3kuIFdoYXQgeW91IHNlZSBhcyB0aGUgbWFp biBiZW5lZml0IHRoZXJlPyBIb3cgdG8gbWFuYWdlIGRldGVjdGlvbiB0aW1lcyBhbW9uZyBtdWx0 aXBsZSBCRkQgc2Vzc2lvbnM/PC9saT48bGk+aGF2ZSB5b3UgbG9va2VkIGF0IDxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1tcGxzLXRw LW9hbS1jb25mLTA2Ij48Zm9udCBjb2xvcj0iYmx1ZSI+PHU+U2VjdGlvbiAyLjIuMTwvdT48L2Zv bnQ+PC9hPiBvZiB0aGUgZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLW1wbHMtdHAtb2FtLWNvbmYg YW5kIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2NhbXAt cnN2cC10ZS1tcGxzLXRwLW9hbS1leHQtMTIiPjxmb250IGNvbG9yPSJibHVlIj48dT5TZWN0aW9u DQozLjM8L3U+PC9mb250PjwvYT4gb2YgdGhlIGRyYWZ0LWlldGYtY2NhbXAtcnN2cC10ZS1tcGxz LXRwLW9hbS1leHQ8L2xpPjwvdWw+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0icGFk ZGluZy1sZWZ0OjE4cHQ7Ij5SZWdhcmRzLDwvZGl2Pg0KPGRpdiBzdHlsZT0icGFkZGluZy1sZWZ0 OjE4cHQ7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JlZzwv ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+DQoNCkZyb206IFJ0Zy1iZmQgWzxhIGhyZWY9Im1haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0 Zi5vcmciPm1haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2Yg VmVuZ2FkYSBQcmFzYWQgR292aW5kYW4gKHZlbmdnb3ZpKTxicj4NCg0KU2VudDogRnJpZGF5LCBK dWx5IDA0LCAyMDE0IDg6MzMgQU08YnI+DQoNClRvOiBydGctYmZkQGlldGYub3JnPGJyPg0KDQpT dWJqZWN0OiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC12Z292aW5kYW4t bXBscy1leHRlbmRlZC1iZmQtZGlzYy10bHYtMDAudHh0PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPGRpdj5IZWxsbyBhbGwsPC9kaXY+DQo8ZGl2PiZuYnNwOyBXZSBoYXZlIHBvc3RlZCBhIG5l dyBkcmFmdCBvdXRsaW5pbmcgYSBwcm9wb3NhbCB0byBleHRlbmQgdGhlIEJGRCBEaXNjcmltaW5h dG9yIFRMViBvZiB0aGUgTVBMUyBwaW5nIHRvIGJvb3RzdHJhcCBtdWx0aXBsZSBCRkQgc2Vzc2lv bnMgZm9yIGEgJmx0O01QTFMgRkVDLCBMU1AmZ3Q7IHR1cGxlLiBQbGVhc2UgbGV0IHVzIGtub3cg eW91ciBxdWVzdGlvbnMsIGNvbW1lbnRzLCBzdWdnZXN0aW9ucyBhYm91dCB0aGlzIGRyYWZ0Ljwv ZGl2Pg0KPGRpdj5UaGFua3M8L2Rpdj4NCjxkaXY+UHJhc2FkPC9kaXY+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvZGl2Pg0KPGRpdj5Gcm9tOiA8 YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5t YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPl0gPC9kaXY+DQo8ZGl2PlNlbnQ6IEZy aWRheSwgSnVseSAwNCwgMjAxNCA2OjQxIFBNPC9kaXY+DQo8ZGl2PlRvOiBOb2JvIEFraXlhIChu b2JvKTsgVmVuZ2FkYSBQcmFzYWQgR292aW5kYW4gKHZlbmdnb3ZpKTsgTm9ibyBBa2l5YSAobm9i byk7IFZlbmdhZGEgUHJhc2FkIEdvdmluZGFuICh2ZW5nZ292aSk8L2Rpdj4NCjxkaXY+U3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC12Z292aW5kYW4tbXBscy1leHRl bmRlZC1iZmQtZGlzYy10bHYtMDAudHh0PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4m bmJzcDs8L2Rpdj4NCjxkaXY+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXZnb3ZpbmRhbi1t cGxzLWV4dGVuZGVkLWJmZC1kaXNjLXRsdi0wMC50eHQ8L2Rpdj4NCjxkaXY+aGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBWZW5nYWRhIFByYXNhZCBHb3ZpbmRhbiBhbmQgcG9zdGVk IHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5O YW1lOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBkcmFmdC12Z292aW5kYW4tbXBscy1leHRlbmRlZC1iZmQtZGlzYy10bHY8L2Rpdj4N CjxkaXY+UmV2aXNpb246Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAwPC9k aXY+DQo8ZGl2PlRpdGxlOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBMYWJlbCBTd2l0Y2hlZCBQYXRoIChMU1ApIFBpbmcgRXh0ZW5kZWQgQmlk aXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBEaXNjcmltaW5hdG9yIFRMVjwv ZGl2Pg0KPGRpdj5Eb2N1bWVudCBkYXRlOiZuYnNwOyAyMDE0LTA3LTA0PC9kaXY+DQo8ZGl2Pkdy b3VwOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248L2Rpdj4NCjxkaXY+UGFnZXM6Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDg8L2Rpdj4NCjxkaXY+VVJM OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC12Z292aW5kYW4tbXBscy1leHRlbmRlZC1iZmQtZGlzYy10bHYtMDAudHh0Ij5odHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC12Z292aW5kYW4tbXBscy1leHRlbmRl ZC1iZmQtZGlzYy10bHYtMDAudHh0PC9hPjwvZGl2Pg0KPGRpdj5TdGF0dXM6Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZnb3ZpbmRhbi1tcGxzLWV4dGVuZGVkLWJmZC1k aXNjLXRsdi8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZnb3ZpbmRh bi1tcGxzLWV4dGVuZGVkLWJmZC1kaXNjLXRsdi88L2E+PC9kaXY+DQo8ZGl2Pkh0bWxpemVkOiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC12Z292aW5kYW4tbXBscy1leHRlbmRlZC1iZmQtZGlzYy10bHYt MDAiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZnb3ZpbmRhbi1tcGxzLWV4dGVu ZGVkLWJmZC1kaXNjLXRsdi0wMDwvYT48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZu YnNwOzwvZGl2Pg0KPGRpdj5BYnN0cmFjdDo8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IFRoaXMg ZG9jdW1lbnQgZGVmaW5lcyBhbiBleHRlbmRlZCBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0 ZWN0aW9uPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyAoQkZEKSBkaXNjcmltaW5hdG9yIFRMViBm b3IgdGhlIE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIChNUExTKTwvZGl2Pg0KPGRpdj4m bmJzcDsmbmJzcDsgTGFiZWwgU3dpdGNoZWQgUGF0aCAoTFNQKSBQaW5nIG1lY2hhbmlzbSwgdG8g YWxsb3cgYm9vdHN0cmFwcGluZyBvZjwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgbXVsdGlwbGUg QkZEIHNlc3Npb25zIGZvciBhIGdpdmVuIEZFQy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8 ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8 ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPC9k aXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGUgSUVURiBTZWNyZXRhcmlhdDwvZGl2Pg0K PGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L3NwYW4+PC9mb250Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_7347100B5761DC41A166AC17F22DF1121B7E7AC7eusaamb103erics_-- From nobody Mon Jul 7 16:34:02 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD4B1B298B for ; Mon, 7 Jul 2014 16:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.793 X-Spam-Level: X-Spam-Status: No, score=-100.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=1.107, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHXY88roMV9F for ; Mon, 7 Jul 2014 16:33:57 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4B631B2985 for ; Mon, 7 Jul 2014 16:33:57 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-99-53badc3ae3b1 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 53.34.05330.A3CDAB35; Mon, 7 Jul 2014 19:43:22 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Mon, 7 Jul 2014 19:33:56 -0400 From: Gregory Mirsky To: "draft-snyder-bfd-proxy-connections-monitored-links@tools.ietf.org" Subject: draft-snyder-bfd-proxy-connections-monitored-links Thread-Topic: draft-snyder-bfd-proxy-connections-monitored-links Thread-Index: Ac+aOogzobfTZHj0Tm2iFq7Ht5HUBQ== Date: Mon, 7 Jul 2014 23:33:54 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7E7C32@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B7E7C32eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyuXSPt67VnV3BBqfOaFpcmPaByeLzn22M DkweS5b8ZPL4cvkzWwBTFJdNSmpOZllqkb5dAlfG6W19jAV3JCueX1jO2MC4Q6yLkYNDQsBE 4tg03y5GTiBTTOLCvfVsXYxcHEICRxklNs9/ygThLGOU+N2wgBmkik3ASOLFxh52kISIQC+j xJblE9lBEswCmhJNJz6zg0wVFrCRaPsmBBIWEXCU+LGsjR3C1pO49mwrE4jNIqAicenrYbA4 r4CvxLYp/8FsRqArvp9awwQxUlzi1pP5TBDXCUgs2XOeGcIWlXj5+B8rhK0osa9/OtQJ+RJn 2u+yQcwUlDg58wnLBEbhWUhGzUJSNgtJGURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/F yFFanFqWm25ksIkRGCXHJNh0dzDueWl5iFGAg1GJh3dB/q5gIdbEsuLK3EOM0hwsSuK8s2rn BQsJpCeWpGanphakFsUXleakFh9iZOLglGpgnNjJY/5sXfTmxoDnrh4h2p17XCtq/HbePuzv rbjud8v+q2mvr25J15ml588hptVRGdruv6J4yY/nMcmbJ39p3WAn8U3zuZ5T+v0Er8MLeX/L pyuJlm2+9axw4h53EUG3138tfb8ZGxQI/vt346aIkdo91Q9b3Y98cTebMC9JLvBkRubryQ8y lViKMxINtZiLihMBkOa9LHMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/v2amnmDocmAv_lUo-x91cGegwSs Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 23:33:59 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B7E7C32eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et. al, I've read the document with lots of interest. I think that the use case you= 've described may be looked as case of interworking between two OAM mechani= sms. Have you considered addressing the use case through DLEP and BFD inter= working? I think that may become part of broader BFD - Foo OAM (e.g. CFM/Y.= 1731) interworking document. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B7E7C32eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Dear Authors, et. al,

    I’ve read the document with lots of interest. = I think that the use case you’ve described may be looked as case of i= nterworking between two OAM mechanisms. Have you considered addressing the = use case through DLEP and BFD interworking? I think that may become part of broader BFD – Foo OAM (e.g. CFM/Y.1731= ) interworking document.

     

            &nbs= p;       Regards,

            &nbs= p;            &= nbsp;          Greg=

    --_000_7347100B5761DC41A166AC17F22DF1121B7E7C32eusaamb103erics_-- From nobody Mon Jul 7 18:31:08 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22AC41B29DB for ; Mon, 7 Jul 2014 18:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkT5ds29MG0L for ; Mon, 7 Jul 2014 18:31:07 -0700 (PDT) Received: from ironport.idirect.net (ironport.dmz.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id EFEE31B29D7 for ; Mon, 7 Jul 2014 18:31:06 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.128 is permitted sender) identity=mailfrom; client-ip=10.250.250.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.01,622,1400040000"; d="scan'208";a="10826032" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.128]) by ironport.idirect.net with ESMTP; 07 Jul 2014 21:31:05 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB01.idirect.net ([::1]) with mapi id 14.02.0387.000; Mon, 7 Jul 2014 21:31:06 -0400 From: "Snyder, Brian" To: Gregory Mirsky Subject: Re: draft-snyder-bfd-proxy-connections-monitored-links Thread-Topic: draft-snyder-bfd-proxy-connections-monitored-links Thread-Index: Ac+aOogzobfTZHj0Tm2iFq7Ht5HUBQAM0auA Date: Tue, 8 Jul 2014 01:31:04 +0000 Message-ID: <10FC1648-6ABB-4AEC-B00D-3578139135CB@idirect.net> References: <7347100B5761DC41A166AC17F22DF1121B7E7C32@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7E7C32@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/pOCPzDl-vP0TVAxddvBV6nBt19k Cc: "rtg-bfd@ietf.org" , "draft-snyder-bfd-proxy-connections-monitored-links@tools.ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 01:31:08 -0000 Greg, Hello. I initially started trying to solve my problem solely with DLEP but = it didn=92t fit the bill for a few reasons. Mainly the ad-hoc nature of DLE= P, the ubiquitous availability of BFD vs. DLEP, the scalability, and most i= mportantly BFD worked with more protocols (like BGP) that I needed=85. and= a few other reasons that I=92d be happy to discuss at IETF meeting (or fur= ther via email). Ultimately, I did not need a lot of the fancier features = of DLEP - I was only interested in link up / down not link quality metrics = - so BFD was a natural and simpler fit. I was also very interested in kee= ping all the =91chattiness=92 of BFD of the monitored links as my monitored= links are very expensive (satellite bandwidth) and so proxying it seemed l= ike a great solution. I=92ll be presenting this in idea further in Toronto= =85 I=92m happy to hear others have interest=85 Feel free to ask for furthe= r details if you=92re so inclined=85. Thanks, Brian On Jul 7, 2014, at 7:33 PM, Gregory Mirsky > wrote: Dear Authors, et. al, I=92ve read the document with lots of interest. I think that the use case y= ou=92ve described may be looked as case of interworking between two OAM mec= hanisms. Have you considered addressing the use case through DLEP and BFD i= nterworking? I think that may become part of broader BFD =96 Foo OAM (e.g. = CFM/Y.1731) interworking document. Regards, Greg From nobody Tue Jul 8 06:40:04 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3041B2AB7 for ; Tue, 8 Jul 2014 06:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_41=0.6, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgHNcSGlUV7Y for ; Tue, 8 Jul 2014 06:39:57 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE731B2A51 for ; Tue, 8 Jul 2014 06:39:57 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B0327C21A; Tue, 8 Jul 2014 09:39:56 -0400 (EDT) Date: Tue, 8 Jul 2014 09:39:56 -0400 From: Jeffrey Haas To: "Snyder, Brian" Subject: Re: draft-snyder-bfd-proxy-connections-monitored-links Message-ID: <20140708133956.GB19932@pfrc> References: <7347100B5761DC41A166AC17F22DF1121B7E7C32@eusaamb103.ericsson.se> <10FC1648-6ABB-4AEC-B00D-3578139135CB@idirect.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10FC1648-6ABB-4AEC-B00D-3578139135CB@idirect.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/M9fga9FIEr377OWGiqEi5rBS9Ic Cc: "rtg-bfd@ietf.org" , "draft-snyder-bfd-proxy-connections-monitored-links@tools.ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 13:39:58 -0000 On Tue, Jul 08, 2014 at 01:31:04AM +0000, Snyder, Brian wrote: > Hello. I initially started trying to solve my problem solely with DLEP but > it didn?t fit the bill for a few reasons. Mainly the ad-hoc nature of > DLEP, the ubiquitous availability of BFD vs. DLEP, the scalability, and > most importantly BFD worked with more protocols (like BGP) that I needed?. > and a few other reasons that I?d be happy to discuss at IETF meeting (or > further via email). Ultimately, I did not need a lot of the fancier > features of DLEP - I was only interested in link up / down not link > quality metrics - so BFD was a natural and simpler fit. I was also very > interested in keeping all the ?chattiness? of BFD of the monitored links > as my monitored links are very expensive (satellite bandwidth) and so > proxying it seemed like a great solution. I?ll be presenting this in idea > further in Toronto? I?m happy to hear others have interest? Feel free to > ask for further details if you?re so inclined?. This is a great time to mention that while we're looking forward to presentations at the upcoming IETF session, the agenda has gotten a bit crowded. Seeding in-session discussion from things on the mailing list a great way to best use our time. :-) -- Jeff From nobody Tue Jul 8 17:42:22 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE3E1A01BA for ; Tue, 8 Jul 2014 17:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzNSjXdNmpO7 for ; Tue, 8 Jul 2014 17:42:18 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 254E31A01A7 for ; Tue, 8 Jul 2014 17:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3464; q=dns/txt; s=iport; t=1404866538; x=1406076138; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=5n52YaXoGvWsI9dbCqY1QBUDd3GY8S+BGUx/9+yFTwI=; b=BdyxNzRN000gHVNrEpkn/jXEhKThKAzlbK8t2xOPrPmVAcZiMqWFILqA TiN+TAZrsmKWcOE7QHWSW89Tly2H9iqWwPTmFo6oohiR7rl+8FXq6wdKJ 9+4RujSUOhkdu2/kbu6J+PXycvHKr15ucqp9Rbr5oTNd6bmcf2ogzfKzw M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFADSPvFOtJA2N/2dsb2JhbABagmokUlq/MYc/AYEWFnWEAwEBAQMBOj8FDQEqFEImAQQODYgyCAEMyCEXjxExgzSBFgWWXIVikkSDQ4Iw X-IronPort-AV: E=Sophos;i="5.01,629,1400025600"; d="scan'208";a="338602881" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-2.cisco.com with ESMTP; 09 Jul 2014 00:42:17 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s690gHUO032210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 00:42:17 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 19:42:16 -0500 From: "Nobo Akiya (nobo)" To: "draft-zhang-bfd-new-use-cases@tools.ietf.org" Subject: Comments on draft-zhang-bfd-new-use-cases Thread-Topic: Comments on draft-zhang-bfd-new-use-cases Thread-Index: Ac+bDbnw0pb1AQkCSB+fwnEmQFkztA== Date: Wed, 9 Jul 2014 00:42:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.80] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/skLMcjzZa11YTCd7KrQmzdSwk0I Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 00:42:20 -0000 [chair hat off] Hi Authors, Interesting use cases. Please see below for some questions/comments. > 3.1. Use Case #1: Reliable Detection for Multipath In Figure 3.1, do R1-R2-R3-R5 and R1-R4-R5 have same cost? If Figure 3.1, if there was a link between R4 and R3, and all possible path= s between R1 and R5 were same cost, then how many BFD sessions do you want = at R1 and to which node? > 3.2. Use Case #2: Application Consistence I tend to think that the system should simply take the most aggressive dete= ction time out of all the applications for the same target. Are there any a= pplications that can get negatively impacted by BFD running more aggressive= than requested detection time? > 3.3. Use Case #3: Capability Inquiry and Feedback >=20 > If the local system restarts, it may resume the BFD session. Suppose > the link has been failed or the peer has no resources to create the > BFD session or the peer had been taken down administratively during > the absence of the local system. By "system restarts", do you mean a BFD module has gone through a graceful = restart, or a system hosting the BFD module has gone through a graceful rel= oad (w/o forwarding impact)? And by "it may resume the BFD session", doesn'= t that imply that BFD sessions exist locally as well as on the peer? If tha= t is true, then I'm not clear on what you mean by " or the peer has no reso= urces to create the BFD session". Additionally, RFC5880 states: > BFD Control packets > MAY be transmitted indefinitely after transitioning to AdminDown > state in order to maintain session state in each system (see section > 6.8.18 below). So if the BFD session on the peer went AdminDown during the absence of loca= l BFD module, and if peer BFD session continued to send AdminDown, then the= last case of "or the peer had been taken down administratively during the = absence of the local system" is no longer an issue, since local (resumed) B= FD session will receive AdminDown packet? If the two cases are handled, then that only leaves "the link has been fail= ed", which is no longer ambiguous and failing the local session is the righ= t thing to do. Just some thoughts. Perhaps you can further elaborate the ex= act requirement/use-case on this one. > 3.4. Use Case #4: State Relay Sounds like a similar concept to the BFD proxy described in this document. http://datatracker.ietf.org/doc/draft-snyder-bfd-proxy-connections-monitore= d-links/ Do look through the document to see if the concept is similar. Question is, how do we provision the proxy BFD that is tied to specific "re= mote" session. > 3.5. Use Case #5: Detection of Asymmetric LSPs Controlling the reverse path for BFD control packets, like: http://tools.ietf.org/html/rfc7110 http://datatracker.ietf.org/doc/draft-mirsky-mpls-bfd-directed/ makes sense. But I'm not convinced if similar is required for BFD echo pack= ets. If you really require this, then you probably want a mechanism to disc= over the local label on the egress for the reverse LSP so that BFD echo pac= kets can be sent with label stack [forward label, egress local label for re= verse LSP], so cause the packets to u-turn. That mechanism will not be anyt= hing BFD specific. Looking forward for discussions/clarifications on the use cases, and also y= our presentation at IETF90/Toronto. Thanks! -Nobo From nobody Tue Jul 8 17:42:48 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276741A01A7 for ; Tue, 8 Jul 2014 17:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtASFn610p9U for ; Tue, 8 Jul 2014 17:42:42 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 343D81A01BA for ; Tue, 8 Jul 2014 17:42:42 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id z60so5665945qgd.38 for ; Tue, 08 Jul 2014 17:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lGCa3DFjcwBPaSamaeEWGRJjasSQ+3XwkNaKuBnR4sM=; b=Uvdz+7tS9G4XtHRavhSqrshVmXBcawxnwfNZcinDMN4NNdFh3JMM++08nVi9Zf5w3E eZ7eqFQ6Q6lY7tpmb/CeFXK4YxnfkGPcQLXTm40hicZ1j99fQowTFgmumufPIxYwO6IE rDXZTcgPA9lpsuOk6aKecP6f59AnMXzh8gAqOL2E/UBY23mMtqIwe2Ak01NHi86x9YLX roK8+WuzGPz8abdM1p3K5mPdZyhK/XWnm82w+G2xd8ImYNwuvtOOBinTrCDuKo+1EFCB 4kRZMIN4F/95kP+mfsIac+GgOowr4urx/cJ/ME8x1/Ipas02jiA5qeH8antOvzj3jJI3 PtLQ== MIME-Version: 1.0 X-Received: by 10.140.36.149 with SMTP id p21mr61324327qgp.54.1404866561451; Tue, 08 Jul 2014 17:42:41 -0700 (PDT) Received: by 10.140.42.81 with HTTP; Tue, 8 Jul 2014 17:42:41 -0700 (PDT) In-Reply-To: References: <20140630163846.GA11842@pfrc> <20140706225103.GB21814@pfrc> <315041E4211CB84E86EF7C25A2AB583D346263F3@xmb-rcd-x15.cisco.com> Date: Tue, 8 Jul 2014 17:42:41 -0700 Message-ID: Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15) From: Mahesh Jethanandani To: Pablo Frank Content-Type: multipart/alternative; boundary=001a11c13f445a2cad04fdb7fcb8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/hakZoOcJ1OmHnMV0j5sFmqtFjdU Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 00:42:47 -0000 --001a11c13f445a2cad04fdb7fcb8 Content-Type: text/plain; charset=UTF-8 Jeff et. all, Having just tried an interoperability BFD test between two vendor boxes, I can see why having the defined common intervals would be useful. So yes, a support for the draft. Would it be helpful to have some rational for why the said intervals were selected? Typical rationals that I have heard for the faster intervals are that operators want a 50ms protection switchover. For that 3.3ms and 10ms meet the detection requirements. What goal is 20ms trying to achieve? A 100ms and 1s intervals are helpful for applications that do not have stringent requirements (e.g. protection of a voice stream) but can benefit from a quick detection. Examples include routing protocols that use BFD as a hello protocol. On Mon, Jul 7, 2014 at 11:49 AM, Pablo Frank wrote: > I'm working on a HW implementation that supports the proposed intervals > and the draft was useful in that context. I can see that the non-Y.1731 > standard intervals (i.e. 20ms, 50ms) could prove a challenge for some > existing hardware implementations, but these rates should be within the > capability of most software implementations. Even for existing hardware > implementations, since the new rates are a multiple of 10ms, it's usually > not *that* challenging. So yes/support. > > regards, > Pablo > > > > On Mon, Jul 7, 2014 at 12:12 PM, Vengada Prasad Govindan (venggovi) < > venggovi@cisco.com> wrote: > >> Hello Jeff, >> From an implementer's perspective, I see this draft adds value by >> steering implementations towards a point of convergence. I support this >> draft for publication. >> Thanks >> Prasad >> >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas >> Sent: Monday, July 07, 2014 4:21 AM >> To: rtg-bfd@ietf.org >> Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals (ending >> July 15) >> >> We are coming up on the second week of this WGLC and have thus far only >> heard from one non-author. :-) Please take a moment and review this draft, >> especially if you are an implementor. >> >> -- Jeff >> >> On Mon, Jun 30, 2014 at 12:38:46PM -0400, Jeffrey Haas wrote: >> > Working Group, >> > >> > We would like to initiate the start of Working Group Last Call for >> > Common Interval Support in BFD: >> > >> > http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 >> > >> > Note that the intended status of this document is INFORMATIONAL. >> > >> > Please send your comments, including whether you think the draft is >> > ready for publication or not, to the list no later than July 15. >> > >> > -- Jeff and Nobo >> >> > -- Mahesh Jethanandani mjethanandani@gmail.com --001a11c13f445a2cad04fdb7fcb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Jeff et. all,

    Having just tried an inte= roperability BFD test between two vendor boxes, I can see why having the de= fined common intervals would be useful. So yes, a support for the draft.

    Would it be helpful to have some rational for why the s= aid intervals were selected? Typical rationals that I have heard for the fa= ster intervals are that operators want a 50ms protection switchover. For th= at 3.3ms and 10ms meet the detection requirements. What goal is 20ms trying= to achieve?

    A 100ms and 1s intervals are helpful for applications t= hat do not have stringent requirements (e.g. protection of a voice stream) = but can benefit from a quick detection. Examples include routing protocols = that use BFD as a hello protocol.


    On Mon,= Jul 7, 2014 at 11:49 AM, Pablo Frank <pabloisnot@gmail.com> wrote:
    I'm working on a HW imp= lementation that supports the proposed intervals and the draft was useful i= n that context. =C2=A0I can see that the non-Y.1731 standard intervals (i.e= . 20ms, 50ms) could prove a challenge for some existing hardware implementa= tions, but these rates should be within the capability of most software imp= lementations. =C2=A0Even for existing hardware implementations, since the n= ew rates are a multiple of 10ms, it's usually not *that* challenging. = =C2=A0So yes/support.

    regards,
    Pablo



    On Mon, Jul 7, 2014 at 12:12 PM, Vengada Prasad Govindan = (venggovi) <venggovi@cisco.com> wrote:
    Hello Jeff,
    =C2=A0 From an implementer's perspective, I see this draft adds value b= y steering implementations towards a point of convergence. I support this d= raft for publication.
    Thanks
    Prasad

    -----Original Message-----
    From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas
    Sent: Monday, July 07, 2014 4:21 AM
    To: rtg-bfd@ietf.org<= /a>
    Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals (ending J= uly 15)

    We are coming up on the second week of this WGLC and have thus far only hea= rd from one non-author. :-) =C2=A0Please take a moment and review this draf= t, especially if you are an implementor.

    -- Jeff

    On Mon, Jun 30, 2014 at 12:38:46PM -0400, Jeffrey Haas wrote:
    > Working Group,
    >
    > We would like to initiate the start of Working Group Last Call for
    > Common Interval Support in BFD:
    >
    >     http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 >
    > Note that the intended status of this document is INFORMATIONAL.
    >
    > Please send your comments, including whether you think the draft is > ready for publication or not, to the list no later than July 15.
    >
    > -- Jeff and Nobo





    --
    =
    Mahesh Jethanandani
    mjethanandani@gmail.com
    --001a11c13f445a2cad04fdb7fcb8-- From nobody Tue Jul 8 18:23:56 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B891A01C3; Tue, 8 Jul 2014 18:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNJIFr1xQvE1; Tue, 8 Jul 2014 18:23:53 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69D6E1A011B; Tue, 8 Jul 2014 18:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6860; q=dns/txt; s=iport; t=1404869033; x=1406078633; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0RwxNhp2JxsGaFwtOQBCHYSgb/qOinP3jMeW6OLFoYU=; b=WrQibg62f/QelHq8sF2KMq4ONH48h99uh2n3T9nElT7HzjlUMpFrDsLo 69Y+aywgwFE9C+6+kVjm0kNqcDNloOstmEM9afrHCMmjVKos3ezSXI5rV sO433ImncT1DZcJ718Eu8JAVLZ2OtH+PxtYZkt8wWVEGqmmFjI7UGRjMv M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAICZvFOtJV2b/2dsb2JhbABagmokUlqCb7xAh0EBGX0WdYQDAQEBAwEjEUMCDAQCAQYCEQQBAQMCBh0DAgICMBQBCAgCBAENBQgBiDEIAQySJZwnhU+UDheBLI1lBisHBAKCcTaBFgWcPpJEggGBQoIw X-IronPort-AV: E=Sophos;i="5.01,629,1400025600"; d="scan'208";a="338657813" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 09 Jul 2014 01:23:43 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s691NhPF005166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 01:23:43 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 20:23:43 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , "Vengada Prasad Govindan (venggovi)" , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-vgovindan-mpls-extended-bfd-disc-tlv-00.txt Thread-Topic: New Version Notification for draft-vgovindan-mpls-extended-bfd-disc-tlv-00.txt Thread-Index: AQHPl4mF1OunTubKs0CpX824dSlWBZuQXyiAgAUao4CAAXaOAA== Date: Wed, 9 Jul 2014 01:23:42 +0000 Message-ID: References: <20140704131127.29231.56989.idtracker@ietfa.amsl.com> <315041E4211CB84E86EF7C25A2AB583D34623EBA@xmb-rcd-x15.cisco.com> <7347100B5761DC41A166AC17F22DF1121B7E7AC7@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7E7AC7@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.80] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/9Sw-qxJ0dKBnl6pveIgF6JVvlH4 Cc: "mpls@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 01:23:55 -0000 SGkgR3JlZywgUHJhc2FkLCBldCBhbCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg R3JlZ29yeSBNaXJza3kNCj4gU2VudDogTW9uZGF5LCBKdWx5IDA3LCAyMDE0IDU6MjkgUE0NCj4g VG86IFZlbmdhZGEgUHJhc2FkIEdvdmluZGFuICh2ZW5nZ292aSk7IHJ0Zy1iZmRAaWV0Zi5vcmcN Cj4gQ2M6IG1wbHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFttcGxzXSBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LXZnb3ZpbmRhbi1tcGxzLQ0KPiBleHRlbmRlZC1iZmQtZGlz Yy10bHYtMDAudHh0DQo+IA0KPiBIaSBQcmFzYWQsDQo+IHRoaXMgaXMgdmVyeSBpbnRlcmVzdGlu ZyBwcm9wb3NhbCBhbmQgSSB0aGluayB0aGF0IHRoZSBNUExTIFdHIHdpbGwgYmUNCj4gaW50ZXJl c3RlZCBpbiB0aGUgZGlzY3Vzc2lvbi4gQ291cGxlIGNvbW1lbnRzIGFuZCBxdWVzdGlvbnM6DQo+ IOKAoiBJIGJlbGlldmUgdGhhdCBtb25pdG9yaW5nIG9mIEVDTVAgc2VnbWVudHMgb24gbGluayBs YXllciBpcyBtb3JlIGVmZmljaWVudA0KPiBjb21wYXJpbmcgdG8gZTJlIG1vbml0b3JpbmcuIFRo ZSBkb2N1bWVudCBzdWdnZXN0cyBvdGhlcndpc2UuIENvdWxkIHlvdQ0KPiBnaXZlIHNjZW5hcmlv cyBvciB1c2UgY2FzZXMgdGhhdCBzdXBwb3J0IHVzZWZ1bG5lc3Mgb2YgbXVsdGlwbGUgQkZEIHNl c3Npb25zDQo+IGJldHdlZW4gdGhlIHNhbWUgcGVlcnMsIGdpdmVuIHRoYXQgeW91IG5lZWQgdG8g Y29udHJvbCBtYXBwaW5nIG9mIEJGRA0KPiBzZXNzaW9ucyB0byBhIHBhcnRpY3VsYXIgcGF0aDsN Cg0KQSBiaXQgb2YgYSBiYWNrZ3JvdW5kIG9uIHRoaXMgZG9jdW1lbnQuDQoNCkVWUE4gaXMgdmVy eSBrZWVuIG9uIHdhbnRpbmcgdG8gdXNlIEJGRCBwZXIgRUwgKG9yIHN1YnNldCBvZiB0aGUgRUxz KSB0byBtZWV0IHRoZWlyIHJlcXVpcmVtZW50cy4gVGhlc2UgYXJlIGRlc2NyaWJlZCBpbjoNCg0K ZHJhZnQtc2FsYW0tbDJ2cG4tZXZwbi1vYW0tcmVxLWZybXdrDQpkcmFmdC12Z292aW5kYW4tbDJ2 cG4tZXZwbi1iZmQNCg0KV2l0aCB0aGF0IHNhaWQsIEkgZnVsbHkgYWdyZWUgdGhhdCB0aGVyZSBp cyBnb2luZyB0byBiZSBhIGh1Z2UgaW1wYWN0IHRvIEJGRCBzY2FsZSBpZiB3ZSBhcmUgdG8gcHJv Y2VlZCBkb3duIHRoaXMgcGF0aCwgYW5kIHRoaXMgc2hvdWxkIGJlIGNvbnNpZGVyZWQvZGlzY3Vz c2VkIGluIGEgZ3JvdXAgdGhhdCBpbmNsdWRlcyBCRkQgZm9sa3MuDQoNCk5vdGUgdGhhdCB0aGUg Zm9ybWF0IG9mIHRoZSBkcmFmdC12Z292aW5kYW4tbXBscy1leHRlbmRlZC1iZmQtZGlzYy10bHYg aXMga2VwdCBnZW5lcmljIHNvIHRoYXQgbXVsdGlwbGUgc2Vzc2lvbnMgYXJlIGFic3RyYWN0ZWQg YnkgIkluc3RhbmNlIElkZW50aWZpZXIiIHJhdGhlciB0aGFuIGJvb3N0cmFwcGVkIEJGRCBzZXNz aW9ucyBiZWluZyBzdHJpY3RseSB0aWVkIHRvIHNvbWV0aGluZyBlbHNlIChsaWtlIEVMIHZhbHVl KS4gU28gdGhlIGRyYWZ0LXZnb3ZpbmRhbi1tcGxzLWV4dGVuZGVkLWJmZC1kaXNjLXRsdiB3YXMg Y3JlYXRlZCBhcyByZXN1bHQgb2YgRVZQTiByZXF1aXJlbWVudCBidXQgZHJhZnQtdmdvdmluZGFu LW1wbHMtZXh0ZW5kZWQtYmZkLWRpc2MtdGx2IGl0c2VsZiBpcyBhIGdlbmVyaWMgZG9jdW1lbnQu DQoNCj4g4oCiIGFub3RoZXIgdXNlIGNhc2UgdG8gc3VwcG9ydCBtdWx0aXBsZSBCRkQNCj4gc2Vz c2lvbnMgYmV0d2VlbiB0aGUgc2FtZSBwZWVycyBpcyBPQU0gcmVkdW5kYW5jeS4gV2hhdCB5b3Ug c2VlIGFzIHRoZQ0KPiBtYWluIGJlbmVmaXQgdGhlcmU/IEhvdyB0byBtYW5hZ2UgZGV0ZWN0aW9u IHRpbWVzIGFtb25nIG11bHRpcGxlIEJGRA0KPiBzZXNzaW9ucz8NCg0KSG93IG1hbnkgc2Vzc2lv bnMgYSBub2RlIGJvb3RzdHJhcHMgZm9yIGEgc2FtZSBGRUMvcGF0aCB0byB0aGUgcmVtb3RlIG5v ZGUsIHdoeSBhbmQgaG93IHRob3NlIHNlc3Npb25zIGFyZSByZWxhdGVkIGlzIGEgbG9jYWwgbWF0 dGVyLiBQZXJoYXBzIHRoYXQgc2hvdWxkIGJlIHN0YXRlZCBpbiB0aGUgZG9jdW1lbnQuDQoNCj4g 4oCiIGhhdmUgeW91IGxvb2tlZCBhdCBTZWN0aW9uIDIuMi4xIG9mIHRoZSBkcmFmdC1pZXRmLW1w bHMtbHNwLXBpbmctbXBscy10cC0NCj4gb2FtLWNvbmYgYW5kIFNlY3Rpb24gMy4zIG9mIHRoZSBk cmFmdC1pZXRmLWNjYW1wLXJzdnAtdGUtbXBscy10cC1vYW0tZXh0DQoNClRoYW5rcyBmb3IgdGhl IHBvaW50ZXIuIFllcyB3ZSBjYW4gY2VydGFpbmx5IGV4dGVuZCB0aG9zZSBUTFZzIGluc3RlYWQg aWYgdGhhdCBpcyB0aGUgY29uc2Vuc3VzLg0KDQpUaGUgb3RoZXIgYXNwZWN0IG9mIGRyYWZ0LXZn b3ZpbmRhbi1tcGxzLWV4dGVuZGVkLWJmZC1kaXNjLXRsdiB0aGF0IHdpbGwgYmUgYmVuZWZpY2lh bCB0byBnZXQtZmVlZGJhY2svZGlzY3VzcyBpcyBBcHBlbmRpeCBBIGluIHRoZSBkb2N1bWVudCwg d2hldGhlciBvciBub3Qgd2UgYXJlIGhhcHB5IHdpdGggaW1wbGljaXQgYXNzdW1wdGlvbiBvZiBi b290c3RyYXBwZWQgQkZEIHNlc3Npb24gYmVpbmcgZGVsZXRlZCBbc29tZXRpbWUgYWZ0ZXJdIHRo b3NlIHNlc3Npb25zIGdvIGRvd24uDQoNClRoYW5rcyENCg0KLU5vYm8NCg0KPiANCj4gUmVnYXJk cywNCj4gwqDCoMKgwqDCoMKgwqAgR3JlZw0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFZlbmdhZGENCj4gUHJhc2FkIEdvdmluZGFuICh2ZW5nZ292aSkNCj4gU2VudDog RnJpZGF5LCBKdWx5IDA0LCAyMDE0IDg6MzMgQU0NCj4gVG86IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4g U3ViamVjdDogRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdmdvdmluZGFu LW1wbHMtZXh0ZW5kZWQtDQo+IGJmZC1kaXNjLXRsdi0wMC50eHQNCj4gDQo+IEhlbGxvIGFsbCwN Cj4gwqAgV2UgaGF2ZSBwb3N0ZWQgYSBuZXcgZHJhZnQgb3V0bGluaW5nIGEgcHJvcG9zYWwgdG8g ZXh0ZW5kIHRoZSBCRkQNCj4gRGlzY3JpbWluYXRvciBUTFYgb2YgdGhlIE1QTFMgcGluZyB0byBi b290c3RyYXAgbXVsdGlwbGUgQkZEIHNlc3Npb25zIGZvciBhDQo+IDxNUExTIEZFQywgTFNQPiB0 dXBsZS4gUGxlYXNlIGxldCB1cyBrbm93IHlvdXIgcXVlc3Rpb25zLCBjb21tZW50cywNCj4gc3Vn Z2VzdGlvbnMgYWJvdXQgdGhpcyBkcmFmdC4NCj4gVGhhbmtzDQo+IFByYXNhZA0KPiANCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiBTZW50OiBGcmlkYXksIEp1bHkg MDQsIDIwMTQgNjo0MSBQTQ0KPiBUbzogTm9ibyBBa2l5YSAobm9ibyk7IFZlbmdhZGEgUHJhc2Fk IEdvdmluZGFuICh2ZW5nZ292aSk7IE5vYm8gQWtpeWENCj4gKG5vYm8pOyBWZW5nYWRhIFByYXNh ZCBHb3ZpbmRhbiAodmVuZ2dvdmkpDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtdmdvdmluZGFuLW1wbHMtZXh0ZW5kZWQtYmZkLQ0KPiBkaXNjLXRsdi0wMC50 eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdmdvdmluZGFuLW1wbHMt ZXh0ZW5kZWQtYmZkLWRpc2MtdGx2LTAwLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IFZlbmdhZGEgUHJhc2FkIEdvdmluZGFuIGFuZCBwb3N0ZWQgdG8NCj4gdGhlIElF VEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6wqDCoMKgwqDCoMKgwqDCoMKgwqAgZHJhZnQtdmdv dmluZGFuLW1wbHMtZXh0ZW5kZWQtYmZkLWRpc2MtdGx2DQo+IFJldmlzaW9uOsKgwqDCoMKgwqDC oCAwMA0KPiBUaXRsZTrCoMKgwqDCoMKgwqDCoMKgwqAgTGFiZWwgU3dpdGNoZWQgUGF0aCAoTFNQ KSBQaW5nIEV4dGVuZGVkIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZw0KPiBEZXRlY3Rpb24gKEJG RCkgRGlzY3JpbWluYXRvciBUTFYgRG9jdW1lbnQgZGF0ZTrCoCAyMDE0LTA3LTA0DQo+IEdyb3Vw OsKgwqDCoMKgwqDCoMKgwqDCoCBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gUGFnZXM6wqDCoMKg wqDCoMKgwqDCoMKgIDgNCj4gVVJMOsKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdmdvdmluZGFuLW1wbHMtDQo+IGV4dGVuZGVk LWJmZC1kaXNjLXRsdi0wMC50eHQNCj4gU3RhdHVzOsKgwqDCoMKgwqDCoMKgwqAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdmdvdmluZGFuLW1wbHMtDQo+IGV4dGVuZGVk LWJmZC1kaXNjLXRsdi8NCj4gSHRtbGl6ZWQ6wqDCoMKgwqDCoMKgIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXZnb3ZpbmRhbi1tcGxzLWV4dGVuZGVkLQ0KPiBiZmQtZGlzYy10bHYt MDANCj4gDQo+IA0KPiBBYnN0cmFjdDoNCj4gwqDCoCBUaGlzIGRvY3VtZW50IGRlZmluZXMgYW4g ZXh0ZW5kZWQgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbg0KPiDCoMKgIChCRkQp IGRpc2NyaW1pbmF0b3IgVExWIGZvciB0aGUgTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcg KE1QTFMpDQo+IMKgwqAgTGFiZWwgU3dpdGNoZWQgUGF0aCAoTFNQKSBQaW5nIG1lY2hhbmlzbSwg dG8gYWxsb3cgYm9vdHN0cmFwcGluZyBvZg0KPiDCoMKgIG11bHRpcGxlIEJGRCBzZXNzaW9ucyBm b3IgYSBnaXZlbiBGRUMuDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gDQo+IA0K From nobody Tue Jul 8 20:14:27 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776411A02F6 for ; Tue, 8 Jul 2014 20:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ae3RHiaJX0IV for ; Tue, 8 Jul 2014 20:14:22 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0CA91A00B2 for ; Tue, 8 Jul 2014 20:14:21 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id r10so8210831pdi.18 for ; Tue, 08 Jul 2014 20:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:cc:from:subject:date:content-type; bh=Ly5IHa4smYk1mFeF2TzHBtCoHbkZKsoj8zqdS+CoFWw=; b=rztogH9xcwKYJBOzbXFmS0qR2HpTAxh+I+eBT5gqPSsPXMo1pq4E61o9w9pr4NUjFK F10bi0Pi2GuZn2N04bCMV3/yThwgUWoOd18tC7VJ2FT6x9GKtBFXi7LsKudyoex5+FHL Rap7vAIZoK6iZKg137o07U09h0zMpZbaHLwkrdk4xLM+0yCyVaoa0fp0QRhfCmokPQgn CClef/r8ja0rHpunXoLPLswED/ZywCbhwZfw10sGzyUhTefv8mB2CDeTPcYtf/K37Lma kSczxhaRrt4KlhlhP7gs9TRih2pyz1kWAKlj7oZ8r/FiaBa/qzCmbeBHikAvK+EWgjTd akbQ== X-Received: by 10.66.147.99 with SMTP id tj3mr39105268pab.47.1404875661547; Tue, 08 Jul 2014 20:14:21 -0700 (PDT) Received: from [223.177.24.158] ([223.177.24.158]) by mx.google.com with ESMTPSA id rm9sm210252637pab.4.2014.07.08.20.14.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Jul 2014 20:14:19 -0700 (PDT) Message-ID: <53bcb38b.498d420a.60fd.ffffc5a6@mx.google.com> MIME-Version: 1.0 To: Jeffrey Haas From: Binny Jeshan Subject: RE: Working Group Last Call for draft-ietf-bfd-intervals (ending July15) Date: Wed, 9 Jul 2014 08:43:37 +0530 Content-Type: multipart/alternative; boundary="_A6569894-712B-495F-B6A1-D1881B8E9F2E_" Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/C9NNG1Xi66Q58CAmciK-L3ag51A Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 03:14:23 -0000 --_A6569894-712B-495F-B6A1-D1881B8E9F2E_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Yes, in that context I would. Regards, Binny. Sent from Nokia Lumia. -----Original Message----- From: "Jeffrey Haas" Sent: =E2=80=8E07-=E2=80=8E07-=E2=80=8E2014 08:01 PM To: "Binny Jeshan" Cc: "Jeffrey Haas" ; "rtg-bfd@ietf.org" Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals (ending J= uly15) Binny, On Mon, Jul 07, 2014 at 01:07:54PM +0530, Binny Jeshan wrote: > However, as i see that its an Informational Document, and i do remember a > discussion about an year back to make it so. It is. > So, you may keep this as a guide of operators to set requirements to > Vendors. That's it what i would look at it. And given that context, would you support the document? -- Jeff --_A6569894-712B-495F-B6A1-D1881B8E9F2E_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
    Yes, in tha= t context I would.

    Regards,
    Binny.

    Sent from Nokia Lumia.<= /DIV>
    From: Jeffrey Haas
    Sent: =E2=80=8E07-=E2=80=8E07-=E2=80=8E2014 08:01 PM
    To: Binny Jeshan
    Cc: Jeffrey Haas; rtg-bfd@ietf.org
    Subject: <= SPAN style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif">Re: Working= Group Last Call for draft-ietf-bfd-intervals (ending July15)
    Binny,

    On Mon, Jul 07, 2014 at 01:07:54PM +0530, Binny Jeshan= wrote:
    > However, as i see that its an Informational Document, and i= do remember a
    > discussion about an year back to make it so.

    = It is.

    > So, you may keep this as a guide of operators to set req= uirements to
    > Vendors. That's it what i would look at it.

    And= given that context, would you support the document?

    -- Jeff
    = --_A6569894-712B-495F-B6A1-D1881B8E9F2E_-- From nobody Tue Jul 8 21:27:52 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959561A0322 for ; Tue, 8 Jul 2014 21:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G749vmRKowTX for ; Tue, 8 Jul 2014 21:27:47 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 836C51A031C for ; Tue, 8 Jul 2014 21:27:47 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 5E07C2AA0F; Wed, 9 Jul 2014 04:27:44 +0000 (GMT) Date: Tue, 8 Jul 2014 21:27:58 -0700 From: Marc Binderberger To: Mahesh Jethanandani Message-ID: <20140708212758846800.0b3e2246@sniff.de> In-Reply-To: References: <20140630163846.GA11842@pfrc> <20140706225103.GB21814@pfrc> <315041E4211CB84E86EF7C25A2AB583D346263F3@xmb-rcd-x15.cisco.com> Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/0hx_ZIZvrcznZTy5ss7u3JSdF-s Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 04:27:50 -0000 Hello Mahesh, appendix A of the draft is explaining the selection. Best regards, Marc On Tue, 8 Jul 2014 17:42:41 -0700, Mahesh Jethanandani wrote: > Jeff et. all, > > Having just tried an interoperability BFD test between two vendor boxes, I > can see why having the defined common intervals would be useful. So yes, a > support for the draft. > > Would it be helpful to have some rational for why the said intervals were > selected? Typical rationals that I have heard for the faster intervals are > that operators want a 50ms protection switchover. For that 3.3ms and 10ms > meet the detection requirements. What goal is 20ms trying to achieve? > > A 100ms and 1s intervals are helpful for applications that do not have > stringent requirements (e.g. protection of a voice stream) but can benefit > from a quick detection. Examples include routing protocols that use BFD as > a hello protocol. > > > On Mon, Jul 7, 2014 at 11:49 AM, Pablo Frank wrote: >> I'm working on a HW implementation that supports the proposed intervals >> and the draft was useful in that context. I can see that the non-Y.1731 >> standard intervals (i.e. 20ms, 50ms) could prove a challenge for some >> existing hardware implementations, but these rates should be within the >> capability of most software implementations. Even for existing hardware >> implementations, since the new rates are a multiple of 10ms, it's usually >> not *that* challenging. So yes/support. >> >> regards, >> Pablo >> >> >> >> On Mon, Jul 7, 2014 at 12:12 PM, Vengada Prasad Govindan (venggovi) >> wrote: >>> Hello Jeff, >>> From an implementer's perspective, I see this draft adds value by >>> steering implementations towards a point of convergence. I support this >>> draft for publication. >>> Thanks >>> Prasad >>> >>> -----Original Message----- >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas >>> Sent: Monday, July 07, 2014 4:21 AM >>> To: rtg-bfd@ietf.org >>> Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals (ending >>> July 15) >>> >>> We are coming up on the second week of this WGLC and have thus far only >>> heard from one non-author. :-) Please take a moment and review this >>> draft, especially if you are an implementor. >>> >>> -- Jeff >>> >>> On Mon, Jun 30, 2014 at 12:38:46PM -0400, Jeffrey Haas wrote: >>>> Working Group, >>>> >>>> We would like to initiate the start of Working Group Last Call for >>>> Common Interval Support in BFD: >>>> >>>> http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 >>>> >>>> Note that the intended status of this document is INFORMATIONAL. >>>> >>>> Please send your comments, including whether you think the draft is >>>> ready for publication or not, to the list no later than July 15. >>>> >>>> -- Jeff and Nobo >>> >> > > > > -- > Mahesh Jethanandani > mjethanandani@gmail.com From nobody Wed Jul 9 13:40:24 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B04F1A0421 for ; Wed, 9 Jul 2014 13:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.793 X-Spam-Level: X-Spam-Status: No, score=-100.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=1.107, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVLnEOlVGxJ8 for ; Wed, 9 Jul 2014 13:40:20 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E762A1ACAD6 for ; Wed, 9 Jul 2014 13:40:19 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-a9-53bd53f87a4f Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 79.D6.25146.8F35DB35; Wed, 9 Jul 2014 16:38:48 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Wed, 9 Jul 2014 16:40:03 -0400 From: Gregory Mirsky To: "draft-ietf-bfd-seamless-base@tools.ietf.org" Subject: draft-ietf-bfd-seamless-base Thread-Topic: draft-ietf-bfd-seamless-base Thread-Index: Ac+bm6XqGsvLHk/VStWUJNiaXNCUoA== Date: Wed, 9 Jul 2014 20:40:02 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7E8E88@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B7E8E88eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyuXRPiO6P4L3BBo/PSVt0TWaz+PxnG6MD k8eSJT+ZPL5c/swWwBTFZZOSmpNZllqkb5fAlbHx/y+2gluFFQsm1DQwNid1MXJySAiYSPya towFwhaTuHBvPVsXIxeHkMBRRomHX+8yQjjLGCVOrrjLDFLFJmAk8WJjDzuILSKQKHF9dwdY nFlAU6LpxGewuLCAmsS7/0/ZIGq0JbrPbYey9SRmLzvPCGKzCKhILD7xH8zmFfCVWH/1Llgv I9AV30+tYYKYKS5x68l8JojrBCSW7DnPDGGLSrx8/I8VwlaU2Nc/nR2iPl9iYtceNoiZghIn Zz5hmcAoPAvJqFlIymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGDlKi1PLctON DDcxAmPkmASb4w7GBZ8sDzEKcDAq8fA+8NobLMSaWFZcmXuIUZqDRUmcV7N6XrCQQHpiSWp2 ampBalF8UWlOavEhRiYOTqkGRsf15x6Vbnda+2PC9323P33k2x/S1bC88/5F2bc3fmisi8g4 PEXn/w++0jOLJA9tPfpQ/ej3AMkLL8/6bGraMs21dadMrg2LxgTzdNH8xcs1nJVfrbgX42Q1 4ekind6tS17dm5L6xM9tvZGk3G+5xRVCgrmd045Uvc6fN+mucPqMpz5BcmquHbVKLMUZiYZa zEXFiQD0DpTwcgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/vVnvRq9NPKp4SqQo_JPrB8xUTDA Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 20:40:22 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B7E8E88eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et. al, this is great progress, my congratulations to all! Please find my notes and= editorial nits below: * Introduction, second para refers to connectivity testing. I belie= ve that BFD been used and defined primarily as continuity checking tool tho= ugh there's at least one example of building connectivity verification base= d on it. I think that changing from "connectivity test" to "continuity test= ", throughout the document, would make it more accurate. * s/state changes from DOWN to UP is/state changes from DOWN to UP = are | state change from DOWN to UP is/; * Section 4 suggests that both S-BFD Initiator and Responder send S= -BFD control packets to the same well-known UDP port; * Section 5, not clear why S-BFD discriminator appears to have diff= erent uniqueness requirement depending of its use (discriminator collision)= . I think that there should be consistency. There seems to be disagreement = between the first paragraph and the second that requires AS uniqueness of S= -BFD discriminators. Or "discriminator collision" is not the same as "uniqu= eness"? * Section 5, second para discusses mis-connectivity case. True, it = easier to detect with IP data plane then with MPLS, whether IP or ACH encap= sulation (where PHP is not the only problem but label merge as well). If S-= BFD to be used as true Connectivity Verification tool, then in all encapsul= ations source must be clearly identifiable. For MPLS data plane it could be= done with help of Source MEP-ID TLV as in RFC 6428. Would note that even w= ith strong requirement of AS/AD scope of S-BFD discriminator there must be = mechanism to detect and act upon, e.g. drop or enter mis-connectivity error= state, "re-use" of discriminators as that likely to pose security threat (= DDoS). * Section 8.1 suggests, when distinct pools of BFD and S-BFD discri= minators used, that "My discriminator" must be always allocated from BFD po= ol. Would note that unless BFD and S-BFD pools made explicitly separated th= ere's no, IMO, way to determine from which pool particular discriminator be= en allocated from. Thus node's own S-BFD discriminators must be punched out= in BFD pool to prevent accidentally being allocated as My Discriminator. T= hat seems to complicate things and relationship between BFD and S-BFD. * And to add to the issue of My Discriminator, I don't see anything= that prevents R2 receiving pings from R1 and R2 in the same md, i.e. R1 an= d R4 allocating the same discriminator from BFD pool to be used as My discr= iminator. Where the pong will go then? In light of this, I'm more in favor = of nodes advertising discriminator(s) through IGP extensions (or being cent= rally allocated) explicitly as their My Discriminator * And last but not least, it appears that document assumes that S-B= FD capable node would always have BFD functionality supported. I think that= not necessarily the case and S-BFD only node must be considered in the doc= ument. Thus, my question, if there's no BFD and BFD pool of discriminators,= where from My Discriminator would be allocated for S-BFD? * Section 8.1.1 may benefit from introduction of terms of "stateful= initiator" and "stateless initiator" when characterizing different behavio= r of SBFDInitiator. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B7E8E88eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Dear Authors, et. al,

    this is great progress, my congratulations to all! P= lease find my notes and editorial nits below:

    ·         Introduction, second para refers to connecti= vity testing. I believe that BFD been used and defined primarily as continu= ity checking tool though there’s at least one example of building con= nectivity verification based on it. I think that changing from “connectivity test” to “continu= ity test”, throughout the document, would make it more accurate.=

    ·         s/state changes from DOWN to UP is/state cha= nges from DOWN to UP are | state change from DOWN to UP is/;

    ·         Section 4 suggests that both S-BFD Initiator= and Responder send S-BFD control packets to the same well-known UDP port;<= o:p>

    ·         Section 5, not clear why S-BFD discriminator= appears to have different uniqueness requirement depending of its use (dis= criminator collision). I think that there should be consistency. There seem= s to be disagreement between the first paragraph and the second that requires AS uniqueness of S-BFD discri= minators. Or “discriminator collision” is not the same as ̶= 0;uniqueness”?

    ·         Section 5, second para discusses mis-connect= ivity case. True, it easier to detect with IP data plane then with MPLS, wh= ether IP or ACH encapsulation (where PHP is not the only problem but label = merge as well). If S-BFD to be used as true Connectivity Verification tool, then in all encapsulations source = must be clearly identifiable. For MPLS data plane it could be done with hel= p of Source MEP-ID TLV as in RFC 6428. Would note that even with strong req= uirement of AS/AD scope of S-BFD discriminator there must be mechanism to detect and act upon, e.g. drop or= enter mis-connectivity error state, “re-use” of discriminators= as that likely to pose security threat (DDoS).

    ·         Section 8.1 suggests, when distinct pools of= BFD and S-BFD discriminators used, that “My discriminator” mus= t be always allocated from BFD pool. Would note that unless BFD and S-BFD p= ools made explicitly separated there’s no, IMO, way to determine from which pool particular discriminator been allocated f= rom. Thus node’s own S-BFD discriminators must be punched out in BFD = pool to prevent accidentally being allocated as My Discriminator. That seem= s to complicate things and relationship between BFD and S-BFD.

    ·         And to add to the issue of My Discriminator,= I don’t see anything that prevents R2 receiving pings from R1 and R2= in the same md, i.e. R1 and R4 allocating the same discriminator from BFD = pool to be used as My discriminator. Where the pong will go then? In light of this, I’m more in favor of nodes = advertising discriminator(s) through IGP extensions (or being centrally all= ocated) explicitly as their My Discriminator

    ·         And last but not least, it appears that docu= ment assumes that S-BFD capable node would always have BFD functionality su= pported. I think that not necessarily the case and S-BFD only node must be = considered in the document. Thus, my question, if there’s no BFD and BFD pool of discriminators, where= from My Discriminator would be allocated for S-BFD?

    ·         Section 8.1.1 may benefit from introduction = of terms of “stateful initiator” and “stateless initiator= ” when characterizing different behavior of SBFDInitiator.=

     

    Regards,

        =     Greg

    --_000_7347100B5761DC41A166AC17F22DF1121B7E8E88eusaamb103erics_-- From nobody Wed Jul 9 15:21:19 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9F61A0109; Wed, 9 Jul 2014 15:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKfntsADPmTP; Wed, 9 Jul 2014 15:21:14 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3ABF1A0065; Wed, 9 Jul 2014 15:21:13 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-be-53bd6ba727d9 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 5C.AB.25146.7AB6DB35; Wed, 9 Jul 2014 18:19:52 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Wed, 9 Jul 2014 18:21:11 -0400 From: Gregory Mirsky To: "draft-akiya-bfd-seamless-ip@tools.ietf.org" Subject: Mail regarding draft-akiya-bfd-seamless-ip Thread-Topic: Mail regarding draft-akiya-bfd-seamless-ip Thread-Index: Ac+bu+vYh1eB6vZtTcCR1YUv3xMn0w== Date: Wed, 9 Jul 2014 22:21:10 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7E8F2D@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B7E8F2Deusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyuXRPrO6K7L3BBv/72C1apn1ls7i1dCWr xec/2xgdmD2WLPnJ5PHl8me2AKYoLpuU1JzMstQifbsEroye3stsBRs9K062H2RqYHxv38XI ySEhYCIxdcJBdghbTOLCvfVsXYxcHEICRxklLiycwQ7hLGOU6F33nBmkik3ASOLFxh6wDhGB eIkHb7aygNjMAl4S/yd+ZAKxhQWMJVrbJrBA1FhIzNz5HapeT2LGs26wOSwCKhIn938Gi/MK +Eqs+DYDrJ4R6Irvp9YwQcwUl7j1ZD4TxHUCEkv2nGeGsEUlXj7+xwphK0rs65/ODlGfL3Fo /SaomYISJ2c+YZnAKDwLyahZSMpmISmDiOtILNj9iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxg5 SotTy3LTjQw3MQIj5pgEm+MOxgWfLA8xCnAwKvHwPvDaGyzEmlhWXJl7iFGag0VJnFezel6w kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsaitHkztW5+LjN6uo9101Gnicdb8tpPdebzzFP2 Co4VVdD6/uN7/v76KXObinPSnnP77ytQSAncdtfmCD/rnt/GO+Zyf3Nxmn9J7rz2y+XOJ66n nv6V5BS18m22+r/+hWl5SlLZh4W5WaNavBxcmuTUnBUPFS23nu3bdWTi+bt7HrydoMdo6q7E UpyRaKjFXFScCABSoXBfeQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/h5ySB7bam_Os3oVwRJ_wEoxHKQg Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 22:21:16 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B7E8F2Deusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, as the scope of the document includes MPLS data plane I've included MPLS WG= in the discussion. Hope you don't mind. Please find my notes to the draft below: * Section 2 states "S-BFD packets are transmitted with IP header, = UDP header and BFD control header". Does that mean that ACH encapsulation i= s outside the scope of this document as in that case S-BFD packets would no= t have IP and UDP headers. If that is the case, then clarification of the s= cope seems appropriate. * Section 2 introduces "explicitly label switched" scenario. What i= s it? * Section 2.1, bullet describing selection of Destination IP addres= s. The RFC 5884 allows use of the whole range rather than one address: "The destination IP address MUST be randomly chosen from the 127/8 range fo= r IPv4 and from the 0:0:0:0:0:FFFF:7F00/104 range for IPv6 with the follow= ing exception." The document, as worded, restricts use of Destination IP address to exercis= e particular path among available multi-paths, as suggested in the RFC 5884= . I'd suggest to use explanation from Section 7 of the RFC 5884. * Note that if IP/UDP encapsulation used for S-BFD there could not = be "new associated channel type for S-BFD" as 0x0021 and 0x0057 must be use= d for IPv4 and IPv6 accordingly. Or was the Ed.Note for PW-ACH encapsulatio= n? But Section 3 discusses only IP routing of S-BFD pong. Thank you for your kind consideration. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B7E8F2Deusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Dear Authors,

    as the scope of the document includes MPLS data plan= e I’ve included MPLS WG in the discussion. Hope you don’t mind.=

    Please find my notes to the draft below:<= /p>

    ·         Section 2 states  “S-BFD packets = are transmitted with IP header, UDP header and BFD control header”. D= oes that mean that ACH encapsulation is outside the scope of this document = as in that case S-BFD packets would not have IP and UDP headers. If that is the case, then clarification of the scope seems ap= propriate.

    ·         Section 2 introduces “explicitly label= switched” scenario. What is it?

    ·         Section 2.1, bullet describing selection of = Destination IP address. The RFC 5884 allows use of the whole range rather t= han one address:

    “The destination IP= address MUST be randomly chosen from the 127/8 range for IPv4 and  fr= om the 0:0:0:0:0:FFFF:7F00/104 range for IPv6 with the following exception.= ”

    The document, as worded, = restricts use of Destination IP address to exercise particular path among a= vailable multi-paths, as suggested in the RFC 5884.

    I’d suggest to use = explanation from Section 7 of the RFC 5884.

    ·         Note that if IP/UDP encapsulation used for S= -BFD there could not be “new associated channel type for S-BFD”= as 0x0021 and 0x0057 must be used for IPv4 and IPv6 accordingly. Or was th= e Ed.Note for PW-ACH encapsulation? But Section 3 discusses only IP routing of S-BFD pong.

     

    Thank you for your kind = consideration.

     

    Regards,

        =     Greg

    --_000_7347100B5761DC41A166AC17F22DF1121B7E8F2Deusaamb103erics_-- From nobody Wed Jul 9 16:26:57 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56C21A016E for ; Wed, 9 Jul 2014 16:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvQfVYZ9rCGd for ; Wed, 9 Jul 2014 16:26:53 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84EFF1A0169 for ; Wed, 9 Jul 2014 16:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2497; q=dns/txt; s=iport; t=1404948428; x=1406158028; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=O+l1t5D+t6BU6rbNDUCriTxfRQfb3U8zdSOwl7C0qss=; b=nFyIEjhREqcD3uvfcrvglwtXnd3mcDr7pIBujv5bwdr6DJfyWzgIswNH vL+Lgw1t8A2XQ6zXCT9zWMVYY5aibexbny3QVtggvsVIf/aLcF2co48Bf AjQmOb4nIrS/fnZ+gfQTwQO5jRPHyNC8MMLdnG5L4eDMF2TaoGdf7GdTW M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAKTOvVOtJA2B/2dsb2JhbABZgmokUlq/JIdBAYEIFnWEAwEBAQQ6PwwEAgEIEQQBAQEKFAkHMhQJCAEBBAENBQgBEognAQzISBeOYBEBHzEHBoMngRYFrwKDQ2yBCzk X-IronPort-AV: E=Sophos;i="5.01,634,1400025600"; d="scan'208";a="338910700" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-5.cisco.com with ESMTP; 09 Jul 2014 23:27:07 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s69NQqrE029936 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 23:26:52 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 18:26:52 -0500 From: "Nobo Akiya (nobo)" To: "Snyder, Brian" , Gregory Mirsky Subject: RE: draft-snyder-bfd-proxy-connections-monitored-links Thread-Topic: draft-snyder-bfd-proxy-connections-monitored-links Thread-Index: Ac+aOogzobfTZHj0Tm2iFq7Ht5HUBQAM0auAAFeKOSA= Date: Wed, 9 Jul 2014 23:26:51 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7E7C32@eusaamb103.ericsson.se> <10FC1648-6ABB-4AEC-B00D-3578139135CB@idirect.net> In-Reply-To: <10FC1648-6ABB-4AEC-B00D-3578139135CB@idirect.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/FRuJkBv4lycVEVeQgypIIX6opJg Cc: "rtg-bfd@ietf.org" , "draft-snyder-bfd-proxy-connections-monitored-links@tools.ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 23:26:55 -0000 Hi Brian, Greg, To me, usage of BFD proxy technique described in the document for monitored= links (ex: Satellite) make sense and functions well. However, Greg does raise an interesting point. BFD Foo Proxy, where Foo can be: 1. Monitored links (covered in this document). 2. State of OAM in other layers. 3. State of another BFD session. And (3) seems to be described as a new requirement here. http://www.ietf.org/id/draft-zhang-bfd-new-use-cases-00.txt, Section 3.4. Let us keep an open mind about this and discuss. Thanks! -Nobo > -----Original Message----- > From: Snyder, Brian [mailto:bsnyder@idirect.net] > Sent: Monday, July 07, 2014 9:31 PM > To: Gregory Mirsky > Cc: draft-snyder-bfd-proxy-connections-monitored-links@tools.ietf.org; > rtg-bfd@ietf.org > Subject: Re: draft-snyder-bfd-proxy-connections-monitored-links >=20 > Greg, >=20 > Hello. I initially started trying to solve my problem solely with DLEP bu= t it > didn't fit the bill for a few reasons. Mainly the ad-hoc nature of DLEP, = the > ubiquitous availability of BFD vs. DLEP, the scalability, and most import= antly > BFD worked with more protocols (like BGP) that I needed.... and a few ot= her > reasons that I'd be happy to discuss at IETF meeting (or further via emai= l). > Ultimately, I did not need a lot of the fancier features of DLEP - I was = only > interested in link up / down not link quality metrics - so BFD was a natu= ral > and simpler fit. I was also very interested in keeping all the 'chattin= ess' of > BFD of the monitored links as my monitored links are very expensive > (satellite bandwidth) and so proxying it seemed like a great solution. I= 'll be > presenting this in idea further in Toronto... I'm happy to hear others ha= ve > interest... Feel free to ask for further details if you're so inclined...= . >=20 > Thanks, > Brian >=20 >=20 > On Jul 7, 2014, at 7:33 PM, Gregory Mirsky > > > wrote: >=20 > Dear Authors, et. al, > I've read the document with lots of interest. I think that the use case y= ou've > described may be looked as case of interworking between two OAM > mechanisms. Have you considered addressing the use case through DLEP > and BFD interworking? I think that may become part of broader BFD - Foo > OAM (e.g. CFM/Y.1731) interworking document. >=20 > Regards, > Greg From nobody Wed Jul 9 18:42:31 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51321A0113 for ; Wed, 9 Jul 2014 18:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CchoetUfIrwA for ; Wed, 9 Jul 2014 18:42:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2158C1A0126 for ; Wed, 9 Jul 2014 18:42:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJU63090; Thu, 10 Jul 2014 01:42:22 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Jul 2014 02:36:58 +0100 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.225]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 10 Jul 2014 09:36:52 +0800 From: Mingui Zhang To: "Nobo Akiya (nobo)" , "Snyder, Brian" , Gregory Mirsky Subject: RE: draft-snyder-bfd-proxy-connections-monitored-links Thread-Topic: draft-snyder-bfd-proxy-connections-monitored-links Thread-Index: Ac+aOogzobfTZHj0Tm2iFq7Ht5HUBQAM0auAAFeKOSAAA88HYA== Date: Thu, 10 Jul 2014 01:36:51 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E76A0E2604@nkgeml508-mbx.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B7E7C32@eusaamb103.ericsson.se> <10FC1648-6ABB-4AEC-B00D-3578139135CB@idirect.net> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/P0gFGoBHZgRApP0NnTGOqlpIQaU Cc: "rtg-bfd@ietf.org" , "draft-snyder-bfd-proxy-connections-monitored-links@tools.ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 01:42:28 -0000 Hi Nobo, This is a very clear description. Now I can understand the difference betwe= en (1) and (3) very well. I think "Section 6.8.17. Concatenated Paths in [RFC5880]" should be on the= table for discussion. The proxy here is close to the "interworking system"= there. Thanks, Mingui >-----Original Message----- >From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (n= obo) >Sent: Thursday, July 10, 2014 7:27 AM >To: Snyder, Brian; Gregory Mirsky >Cc: rtg-bfd@ietf.org; >draft-snyder-bfd-proxy-connections-monitored-links@tools.ietf.org >Subject: RE: draft-snyder-bfd-proxy-connections-monitored-links > >Hi Brian, Greg, > >To me, usage of BFD proxy technique described in the document for monitore= d >links (ex: Satellite) make sense and functions well. > >However, Greg does raise an interesting point. > >BFD Foo Proxy, where Foo can be: >1. Monitored links (covered in this document). >2. State of OAM in other layers. >3. State of another BFD session. > >And (3) seems to be described as a new requirement here. > >http://www.ietf.org/id/draft-zhang-bfd-new-use-cases-00.txt, Section 3.4. > >Let us keep an open mind about this and discuss. > >Thanks! > >-Nobo > >> -----Original Message----- >> From: Snyder, Brian [mailto:bsnyder@idirect.net] >> Sent: Monday, July 07, 2014 9:31 PM >> To: Gregory Mirsky >> Cc: draft-snyder-bfd-proxy-connections-monitored-links@tools.ietf.org; >> rtg-bfd@ietf.org >> Subject: Re: draft-snyder-bfd-proxy-connections-monitored-links >> >> Greg, >> >> Hello. I initially started trying to solve my problem solely with DLEP b= ut it >> didn't fit the bill for a few reasons. Mainly the ad-hoc nature of DLEP,= the >> ubiquitous availability of BFD vs. DLEP, the scalability, and most impor= tantly >> BFD worked with more protocols (like BGP) that I needed.... and a few o= ther >> reasons that I'd be happy to discuss at IETF meeting (or further via ema= il). >> Ultimately, I did not need a lot of the fancier features of DLEP - I was= only >> interested in link up / down not link quality metrics - so BFD was a nat= ural >> and simpler fit. I was also very interested in keeping all the 'chatti= ness' of >> BFD of the monitored links as my monitored links are very expensive >> (satellite bandwidth) and so proxying it seemed like a great solution. = I'll be >> presenting this in idea further in Toronto... I'm happy to hear others h= ave >> interest... Feel free to ask for further details if you're so inclined..= .. >> >> Thanks, >> Brian >> >> >> On Jul 7, 2014, at 7:33 PM, Gregory Mirsky >> > >> wrote: >> >> Dear Authors, et. al, >> I've read the document with lots of interest. I think that the use case = you've >> described may be looked as case of interworking between two OAM >> mechanisms. Have you considered addressing the use case through DLEP >> and BFD interworking? I think that may become part of broader BFD - Foo >> OAM (e.g. CFM/Y.1731) interworking document. >> >> Regards, >> Greg From nobody Thu Jul 10 06:31:58 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0760C1B28FE for ; Thu, 10 Jul 2014 06:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTaY0Oh0ztbJ for ; Thu, 10 Jul 2014 06:31:55 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B151B28FA for ; Thu, 10 Jul 2014 06:31:55 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id m20so7924863qcx.13 for ; Thu, 10 Jul 2014 06:31:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/+BwHy+giy2KiFc/YQcbTPBbi1dr6D6rHH3KtHxSzbo=; b=i40iBpIeROuQR9lWCmiO8wxHhAX1+zCFrEOH+/P6C/TKrHbdiCD7opELomfzszr4kZ aLzlf084bAdixLCDrdRzoLTvb2hog1tCAe2Qmh5X/5R5b8tpJc3s8qbg7w8Y/4BXklIn E2ZwzmhKGeniIYiUQslDLw09U+tBXCtx+9N0JpIuW8wNDM7CitWii6LDdb0agdfUV4Yy 0W/muf384PD9auvO+PDIei+L91ljt5X4o7YeNgEZFlHfbknau9yvs9prZgaBgBmBX++G Oz3AyXiXL7GjJvQ6C2hhnnWV7bQEa2RA/6lfI/RWMTQYQohI2v5VBIIegCMtOAjBdExR 3R2A== X-Received: by 10.224.137.9 with SMTP id u9mr83039384qat.24.1404999114587; Thu, 10 Jul 2014 06:31:54 -0700 (PDT) Received: from [192.168.1.101] (108-247-124-220.lightspeed.sntcca.sbcglobal.net. [108.247.124.220]) by mx.google.com with ESMTPSA id j110sm35216319qga.40.2014.07.10.06.31.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jul 2014 06:31:53 -0700 (PDT) Subject: Re: Comments on draft-zhang-bfd-new-use-cases Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Mahesh Jethanandani In-Reply-To: Date: Thu, 10 Jul 2014 06:31:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4C7782E2-7818-456C-A24E-BB8B0E227B46@gmail.com> References: To: Nobo Akiya (nobo) X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/uu04C25l1xwI-Xc0-R0KzKl8_uc Cc: "draft-zhang-bfd-new-use-cases@tools.ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 13:31:57 -0000 Agree with Nobo, that these are interesting use cases to document. One comment/question that I have is ... 3.1. Use Case #1: Reliable Detection for Multipath Would it make more sense to run BFD on each of the possible paths and = report its individual path status to a higher level protocol? So in = Figure 3.2, would it make more sense to run 3 BFD sessions between R1 = and R4 one on each of the links, each of them reporting their status to = its listeners, be it OSPF ECMP, LAG, or MPLS link bundles and letting = them decide what is a failure scenario? On Jul 8, 2014, at 5:42 PM, Nobo Akiya (nobo) wrote: > [chair hat off] >=20 > Hi Authors, >=20 > Interesting use cases. Please see below for some questions/comments. >=20 >> 3.1. Use Case #1: Reliable Detection for Multipath >=20 > In Figure 3.1, do R1-R2-R3-R5 and R1-R4-R5 have same cost? >=20 > If Figure 3.1, if there was a link between R4 and R3, and all possible = paths between R1 and R5 were same cost, then how many BFD sessions do = you want at R1 and to which node? >=20 >> 3.2. Use Case #2: Application Consistence >=20 > I tend to think that the system should simply take the most aggressive = detection time out of all the applications for the same target. Are = there any applications that can get negatively impacted by BFD running = more aggressive than requested detection time? >=20 >> 3.3. Use Case #3: Capability Inquiry and Feedback >>=20 >> If the local system restarts, it may resume the BFD session. Suppose >> the link has been failed or the peer has no resources to create the >> BFD session or the peer had been taken down administratively during >> the absence of the local system. >=20 > By "system restarts", do you mean a BFD module has gone through a = graceful restart, or a system hosting the BFD module has gone through a = graceful reload (w/o forwarding impact)? And by "it may resume the BFD = session", doesn't that imply that BFD sessions exist locally as well as = on the peer? If that is true, then I'm not clear on what you mean by " = or the peer has no resources to create the BFD session". >=20 > Additionally, RFC5880 states: >=20 >> BFD Control packets >> MAY be transmitted indefinitely after transitioning to AdminDown >> state in order to maintain session state in each system (see section >> 6.8.18 below). >=20 > So if the BFD session on the peer went AdminDown during the absence of = local BFD module, and if peer BFD session continued to send AdminDown, = then the last case of "or the peer had been taken down administratively = during the absence of the local system" is no longer an issue, since = local (resumed) BFD session will receive AdminDown packet? >=20 > If the two cases are handled, then that only leaves "the link has been = failed", which is no longer ambiguous and failing the local session is = the right thing to do. Just some thoughts. Perhaps you can further = elaborate the exact requirement/use-case on this one. >=20 >> 3.4. Use Case #4: State Relay >=20 > Sounds like a similar concept to the BFD proxy described in this = document. >=20 > = http://datatracker.ietf.org/doc/draft-snyder-bfd-proxy-connections-monitor= ed-links/ >=20 > Do look through the document to see if the concept is similar. >=20 > Question is, how do we provision the proxy BFD that is tied to = specific "remote" session. >=20 >> 3.5. Use Case #5: Detection of Asymmetric LSPs >=20 > Controlling the reverse path for BFD control packets, like: >=20 > http://tools.ietf.org/html/rfc7110 > http://datatracker.ietf.org/doc/draft-mirsky-mpls-bfd-directed/ >=20 > makes sense. But I'm not convinced if similar is required for BFD echo = packets. If you really require this, then you probably want a mechanism = to discover the local label on the egress for the reverse LSP so that = BFD echo packets can be sent with label stack [forward label, egress = local label for reverse LSP], so cause the packets to u-turn. That = mechanism will not be anything BFD specific. >=20 > Looking forward for discussions/clarifications on the use cases, and = also your presentation at IETF90/Toronto. >=20 > Thanks! >=20 > -Nobo >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com From nobody Thu Jul 10 06:46:53 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E091B28FF for ; Thu, 10 Jul 2014 06:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEaRZmBiTsfZ for ; Thu, 10 Jul 2014 06:46:46 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09221A0502 for ; Thu, 10 Jul 2014 06:46:45 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id q108so7584642qgd.6 for ; Thu, 10 Jul 2014 06:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9FPM1wbJaHEsCpcSbzWUTj/lcBGVCZa/mNqhIMopXJs=; b=YCATRguRRPxPm1enZKEDbiQdECfxrFAZiXW7z88rvx8kRtwkxqbga6CmatdJzorhBO UGjUWwsFjm+Gor7yHscmTlaOBHmuule0mYjcFxg6tAp2M3hUxTJ4F9X5TYwGWw46TF6P P94wEUGa2VEFhGSDcW44rSnsvrZW+1G/IxFZVHR9/2A03xEbS49jyve4s9Rp06pkI5yv RowbI+lKTmQrNb8RChCIu+nMqrAciJgsGujZPcwQfOtAuj5DWLrVMBdmet8C1tVeWP0a 0XaVsj5lDLB1/0tuY8s6YOVTkfi6eO29FItlIJd/+FepI7y/gmnbfUKKZhZ1XEToG6u6 4DqA== X-Received: by 10.224.55.202 with SMTP id v10mr82299405qag.10.1405000004795; Thu, 10 Jul 2014 06:46:44 -0700 (PDT) Received: from [192.168.1.101] (108-247-124-220.lightspeed.sntcca.sbcglobal.net. [108.247.124.220]) by mx.google.com with ESMTPSA id r2sm92172543qam.35.2014.07.10.06.46.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jul 2014 06:46:44 -0700 (PDT) Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Mahesh Jethanandani In-Reply-To: <20140708212758846800.0b3e2246@sniff.de> Date: Thu, 10 Jul 2014 06:46:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7D7BEA10-A2D0-4948-AC6B-DDAE96490962@gmail.com> References: <20140630163846.GA11842@pfrc> <20140706225103.GB21814@pfrc> <315041E4211CB84E86EF7C25A2AB583D346263F3@xmb-rcd-x15.cisco.com> <20140708212758846800.0b3e2246@sniff.de> To: Marc Binderberger X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/viWnd_esK7qguEvWWDFRsredWL4 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 13:46:50 -0000 That is what happens when you have read the complete draft :-( Question around the explanation provided in Appendix A.=20 For 3.3ms: required by MPLS-TP - is there a reference you can cite? = Also, is this a requirement only for MPLS-TP? The rational for 20ms applies to 10ms (with a multiplier of 3) and = explains the why. Better than saying general consensus and not = explaining the why. Would you agree? On Jul 8, 2014, at 9:27 PM, Marc Binderberger wrote: > Hello Mahesh, >=20 > appendix A of the draft is explaining the selection. >=20 >=20 > Best regards, > Marc >=20 >=20 > On Tue, 8 Jul 2014 17:42:41 -0700, Mahesh Jethanandani wrote: >> Jeff et. all, >>=20 >> Having just tried an interoperability BFD test between two vendor = boxes, I=20 >> can see why having the defined common intervals would be useful. So = yes, a=20 >> support for the draft. >>=20 >> Would it be helpful to have some rational for why the said intervals = were=20 >> selected? Typical rationals that I have heard for the faster = intervals are=20 >> that operators want a 50ms protection switchover. For that 3.3ms and = 10ms=20 >> meet the detection requirements. What goal is 20ms trying to achieve? >>=20 >> A 100ms and 1s intervals are helpful for applications that do not = have=20 >> stringent requirements (e.g. protection of a voice stream) but can = benefit=20 >> from a quick detection. Examples include routing protocols that use = BFD as=20 >> a hello protocol. >>=20 >>=20 >> On Mon, Jul 7, 2014 at 11:49 AM, Pablo Frank = wrote: >>> I'm working on a HW implementation that supports the proposed = intervals=20 >>> and the draft was useful in that context. I can see that the = non-Y.1731=20 >>> standard intervals (i.e. 20ms, 50ms) could prove a challenge for = some=20 >>> existing hardware implementations, but these rates should be within = the=20 >>> capability of most software implementations. Even for existing = hardware=20 >>> implementations, since the new rates are a multiple of 10ms, it's = usually=20 >>> not *that* challenging. So yes/support. >>>=20 >>> regards, >>> Pablo >>>=20 >>>=20 >>>=20 >>> On Mon, Jul 7, 2014 at 12:12 PM, Vengada Prasad Govindan (venggovi)=20= >>> wrote: >>>> Hello Jeff, >>>> =46rom an implementer's perspective, I see this draft adds value = by=20 >>>> steering implementations towards a point of convergence. I support = this=20 >>>> draft for publication. >>>> Thanks >>>> Prasad >>>>=20 >>>> -----Original Message----- >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of = Jeffrey Haas >>>> Sent: Monday, July 07, 2014 4:21 AM >>>> To: rtg-bfd@ietf.org >>>> Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals = (ending=20 >>>> July 15) >>>>=20 >>>> We are coming up on the second week of this WGLC and have thus far = only=20 >>>> heard from one non-author. :-) Please take a moment and review = this=20 >>>> draft, especially if you are an implementor. >>>>=20 >>>> -- Jeff >>>>=20 >>>> On Mon, Jun 30, 2014 at 12:38:46PM -0400, Jeffrey Haas wrote: >>>>> Working Group, >>>>>=20 >>>>> We would like to initiate the start of Working Group Last Call for >>>>> Common Interval Support in BFD: >>>>>=20 >>>>> http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 >>>>>=20 >>>>> Note that the intended status of this document is INFORMATIONAL. >>>>>=20 >>>>> Please send your comments, including whether you think the draft = is >>>>> ready for publication or not, to the list no later than July 15. >>>>>=20 >>>>> -- Jeff and Nobo >>>>=20 >>>=20 >>=20 >>=20 >>=20 >> --=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com From nobody Fri Jul 11 02:35:18 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F8E1B27D0 for ; Fri, 11 Jul 2014 02:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LINKS=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKc3Q-dmO7mk for ; Fri, 11 Jul 2014 02:35:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 587EC1B27B0 for ; Fri, 11 Jul 2014 02:35:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJW01267; Fri, 11 Jul 2014 09:35:09 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 11 Jul 2014 10:35:09 +0100 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.225]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Fri, 11 Jul 2014 17:35:05 +0800 From: Mingui Zhang To: Mahesh Jethanandani , Nobo Akiya Subject: RE: Comments on draft-zhang-bfd-new-use-cases Thread-Topic: Comments on draft-zhang-bfd-new-use-cases Thread-Index: Ac+bDbnw0pb1AQkCSB+fwnEmQFkztAA8oXIAACgRj9A= Date: Fri, 11 Jul 2014 09:35:04 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E76A0E2ED7@nkgeml508-mbx.china.huawei.com> References: <4C7782E2-7818-456C-A24E-BB8B0E227B46@gmail.com> In-Reply-To: <4C7782E2-7818-456C-A24E-BB8B0E227B46@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/qg9R_yUv2S9m5SUTC6czN2-ujCw Cc: "draft-zhang-bfd-new-use-cases@tools.ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 09:35:13 -0000 Hi Mahesh, Nobo, Thanks for your comments. Please see my response inline.=20 Regards, Mingui >-----Original Message----- >From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Mahesh >Jethanandani >Sent: Thursday, July 10, 2014 9:32 PM >To: Nobo Akiya >Cc: draft-zhang-bfd-new-use-cases@tools.ietf.org; rtg-bfd@ietf.org >Subject: Re: Comments on draft-zhang-bfd-new-use-cases > >Agree with Nobo, that these are interesting use cases to document. > >One comment/question that I have is ... > >3.1. Use Case #1: Reliable Detection for Multipath > >Would it make more sense to run BFD on each of the possible paths and repo= rt >its individual path status to a higher level protocol? So in Figure 3.2, w= ould it >make more sense to run 3 BFD sessions between R1 and R4 one on each of the >links, each of them reporting their status to its listeners, be it OSPF EC= MP, LAG, >or MPLS link bundles and letting them decide what is a failure scenario? [Mingui] That's a potential method. Let me interpret it a bit further. Each= possible forwarding path gets a BFD session. The application need summariz= e all the state of these sessions to get the overall health status of the m= ultipath.=20 The difficulty is that two end systems need probe and maintain all possible= forwarding paths. For example, a failure of link in the middle of the chai= ns may affect more than one forwarding paths. Hence, the two end systems ne= ed re-establish those affected BFD sessions. Also, considering the random h= ashing that may be adopted (look at the two links between R1 and R4 in Figu= re 3.2), the probing of those forwarding paths might be inaccurate. >From the angle of the carriers, unless all possible forwarding paths are fa= iled, they wish the BFD does not report a failure. That's why we call it "r= eliable". With this bottom line requirement, we may also figure out a solution works = in another way: two end points _dynamically_ pick one of the remained activ= e interfaces to deliver the BFD control packets. There is always a single B= FD session per multipath. > >On Jul 8, 2014, at 5:42 PM, Nobo Akiya (nobo) wrote: > >> [chair hat off] >> >> Hi Authors, >> >> Interesting use cases. Please see below for some questions/comments. >> >>> 3.1. Use Case #1: Reliable Detection for Multipath >> >> In Figure 3.1, do R1-R2-R3-R5 and R1-R4-R5 have same cost? >> >> If Figure 3.1, if there was a link between R4 and R3, and all possible p= aths >between R1 and R5 were same cost, then how many BFD sessions do you want >at R1 and to which node? [Mingui] As I stated above, we may want to establish only one session. >> >>> 3.2. Use Case #2: Application Consistence >> >> I tend to think that the system should simply take the most aggressive >detection time out of all the applications for the same target. Are there = any >applications that can get negatively impacted by BFD running more aggressi= ve >than requested detection time? [Mingui] The application may not want that aggressive detection due to the = stability. Think about the dampening measures towards the state oscillation= of network devices. >> >>> 3.3. Use Case #3: Capability Inquiry and Feedback >>> >>> If the local system restarts, it may resume the BFD session. Suppose >>> the link has been failed or the peer has no resources to create the >>> BFD session or the peer had been taken down administratively during >>> the absence of the local system. >> >> By "system restarts", do you mean a BFD module has gone through a gracef= ul >restart, or a system hosting the BFD module has gone through a graceful re= load >(w/o forwarding impact)? And by "it may resume the BFD session", doesn't t= hat >imply that BFD sessions exist locally as well as on the peer? If that is t= rue, then >I'm not clear on what you mean by " or the peer has no resources to create= the >BFD session". >> >> Additionally, RFC5880 states: >> >>> BFD Control packets >>> MAY be transmitted indefinitely after transitioning to AdminDown >>> state in order to maintain session state in each system (see section >>> 6.8.18 below). >> >> So if the BFD session on the peer went AdminDown during the absence of l= ocal >BFD module, and if peer BFD session continued to send AdminDown, then the >last case of "or the peer had been taken down administratively during the >absence of the local system" is no longer an issue, since local (resumed) = BFD >session will receive AdminDown packet? [Mingui] It sounds the inquiry is still needed if the BFD control packets a= re not indefinitely sent. >> >> If the two cases are handled, then that only leaves "the link has been f= ailed", >which is no longer ambiguous and failing the local session is the right th= ing to do. >Just some thoughts. Perhaps you can further elaborate the exact >requirement/use-case on this one. >> >>> 3.4. Use Case #4: State Relay >> >> Sounds like a similar concept to the BFD proxy described in this documen= t. >> >> >http://datatracker.ietf.org/doc/draft-snyder-bfd-proxy-connections-monitor= ed-li >nks/ >> >> Do look through the document to see if the concept is similar. >> >> Question is, how do we provision the proxy BFD that is tied to specific >"remote" session. >> >>> 3.5. Use Case #5: Detection of Asymmetric LSPs >> >> Controlling the reverse path for BFD control packets, like: >> >> http://tools.ietf.org/html/rfc7110 >> http://datatracker.ietf.org/doc/draft-mirsky-mpls-bfd-directed/ >> >> makes sense. But I'm not convinced if similar is required for BFD echo p= ackets. >If you really require this, then you probably want a mechanism to discover= the >local label on the egress for the reverse LSP so that BFD echo packets can= be >sent with label stack [forward label, egress local label for reverse LSP],= so cause >the packets to u-turn. That mechanism will not be anything BFD specific. [Mingui] I agree this kind of requirements can be achieved through changing= applications rather than changing the BFD itself. >> >> Looking forward for discussions/clarifications on the use cases, and als= o your >presentation at IETF90/Toronto. >> >> Thanks! >> >> -Nobo >> >> > >Mahesh Jethanandani >mjethanandani@gmail.com > > From nobody Fri Jul 11 13:42:07 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38AE41B29AC for ; Fri, 11 Jul 2014 13:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.852 X-Spam-Level: X-Spam-Status: No, score=-12.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_LINKS=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zilwlCTxdHWs for ; Fri, 11 Jul 2014 13:42:02 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E95F1A0406 for ; Fri, 11 Jul 2014 13:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8040; q=dns/txt; s=iport; t=1405111322; x=1406320922; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2WeV5DWp3fglwf+8GhylQBH72p1UeU74NmC849ZDmwA=; b=ebVy7Sy6+6wN4Jq6CCjRtKwrIX+fRuJQ0R20NxKnflge9lOtTTqWN8U7 eZWg5zeBryoyFUS6jFR5cpF6wS9Jh9rk9hsJGRXTJZVP/EV3Kw3v8kPFG 4AwVcKs0ULWxgkf4Hj/AuFriaE9d556A5tLq/TKrR3FidN7OKsXMC4zCA c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAGtLwFOtJA2L/2dsb2JhbABZgw5SWsEAh0ABgQsWdYQDAQEBBGcSDAQCAQgRBAEBAScHIREUCQgBAQQBDQUbiBMDEQ2/VQ2HGBeNHYIsBwaEPQWKHoxNghqCAIFKjDyGFoNEgjA X-IronPort-AV: E=Sophos;i="5.01,645,1400025600"; d="scan'208";a="60135976" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP; 11 Jul 2014 20:42:01 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s6BKg19R024612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 20:42:01 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.65]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 15:42:01 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: Mingui Zhang , Mahesh Jethanandani , "Nobo Akiya (nobo)" Subject: Re: Comments on draft-zhang-bfd-new-use-cases Thread-Topic: Comments on draft-zhang-bfd-new-use-cases Thread-Index: Ac+bDbnw0pb1AQkCSB+fwnEmQFkztABX3zAAACoFvgAADujJAA== Date: Fri, 11 Jul 2014 20:42:00 +0000 Message-ID: References: <4C7782E2-7818-456C-A24E-BB8B0E227B46@gmail.com> <4552F0907735844E9204A62BBDD325E76A0E2ED7@nkgeml508-mbx.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E76A0E2ED7@nkgeml508-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [10.21.82.76] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/-mULBGFZgy2V6l6oRvHEsq5k5vI Cc: "draft-zhang-bfd-new-use-cases@tools.ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 20:42:05 -0000 Hi Mingui, Interesting document. Most of the queries that popped are already raised by Nobo and Mahesh. So I am using the same thread. For clarity, I think you should change the figure with cost mentioned so that the path really looks like ECMP. Currently it appears that the best path from R1 to R5 is R1-R4-R5. Regarding Use case #3, I am not sure I understood the use case. "If the local system restarts, it may resume the BFD session. Suppose the link has been failed or the peer has no resources to create the BFD session or the peer had been taken down administratively during the absence of the local system. Since no BFD control packets will be received from the peer system, the BFD will report a Down state. Rather, the real state of the forwarding path can either be Down or Up.=B2 Rom the above - =B3Suppose the link has been failed", I believe you meant the link between R1 and R2 failed?. If so, will not the forwarding path is also affected?. Further regarding the no resource scenario - Per my understanding, the control plane protocol packets (like hello) is sufficient to bring the session up even when the BFD didn=B9t come up right?. IOW, I believe, BFD state change from up to down will intimate the client to bring the control plane session down immediately, but I think it will not hold the protocol to change the state to up based on its own hello messages. Thanks, Nagendra On 7/11/14, 5:35 AM, "Mingui Zhang" wrote: >Hi Mahesh, Nobo, > >Thanks for your comments. Please see my response inline. > >Regards, >Mingui > >>-----Original Message----- >>From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Mahesh >>Jethanandani >>Sent: Thursday, July 10, 2014 9:32 PM >>To: Nobo Akiya >>Cc: draft-zhang-bfd-new-use-cases@tools.ietf.org; rtg-bfd@ietf.org >>Subject: Re: Comments on draft-zhang-bfd-new-use-cases >> >>Agree with Nobo, that these are interesting use cases to document. >> >>One comment/question that I have is ... >> >>3.1. Use Case #1: Reliable Detection for Multipath >> >>Would it make more sense to run BFD on each of the possible paths and >>report >>its individual path status to a higher level protocol? So in Figure 3.2, >>would it >>make more sense to run 3 BFD sessions between R1 and R4 one on each of >>the >>links, each of them reporting their status to its listeners, be it OSPF >>ECMP, LAG, >>or MPLS link bundles and letting them decide what is a failure scenario? > >[Mingui] That's a potential method. Let me interpret it a bit further. >Each possible forwarding path gets a BFD session. The application need >summarize all the state of these sessions to get the overall health >status of the multipath. > >The difficulty is that two end systems need probe and maintain all >possible forwarding paths. For example, a failure of link in the middle >of the chains may affect more than one forwarding paths. Hence, the two >end systems need re-establish those affected BFD sessions. Also, >considering the random hashing that may be adopted (look at the two links >between R1 and R4 in Figure 3.2), the probing of those forwarding paths >might be inaccurate. > >>From the angle of the carriers, unless all possible forwarding paths are >>failed, they wish the BFD does not report a failure. That's why we call >>it "reliable". >With this bottom line requirement, we may also figure out a solution >works in another way: two end points _dynamically_ pick one of the >remained active interfaces to deliver the BFD control packets. There is >always a single BFD session per multipath. > >> >>On Jul 8, 2014, at 5:42 PM, Nobo Akiya (nobo) wrote: >> >>> [chair hat off] >>> >>> Hi Authors, >>> >>> Interesting use cases. Please see below for some questions/comments. >>> >>>> 3.1. Use Case #1: Reliable Detection for Multipath >>> >>> In Figure 3.1, do R1-R2-R3-R5 and R1-R4-R5 have same cost? >>> >>> If Figure 3.1, if there was a link between R4 and R3, and all possible >>>paths >>between R1 and R5 were same cost, then how many BFD sessions do you want >>at R1 and to which node? > >[Mingui] As I stated above, we may want to establish only one session. > >>> >>>> 3.2. Use Case #2: Application Consistence >>> >>> I tend to think that the system should simply take the most aggressive >>detection time out of all the applications for the same target. Are >>there any >>applications that can get negatively impacted by BFD running more >>aggressive >>than requested detection time? > >[Mingui] The application may not want that aggressive detection due to >the stability. Think about the dampening measures towards the state >oscillation of network devices. > >>> >>>> 3.3. Use Case #3: Capability Inquiry and Feedback >>>> >>>> If the local system restarts, it may resume the BFD session. Suppose >>>> the link has been failed or the peer has no resources to create the >>>> BFD session or the peer had been taken down administratively during >>>> the absence of the local system. >>> >>> By "system restarts", do you mean a BFD module has gone through a >>>graceful >>restart, or a system hosting the BFD module has gone through a graceful >>reload >>(w/o forwarding impact)? And by "it may resume the BFD session", doesn't >>that >>imply that BFD sessions exist locally as well as on the peer? If that is >>true, then >>I'm not clear on what you mean by " or the peer has no resources to >>create the >>BFD session". >>> >>> Additionally, RFC5880 states: >>> >>>> BFD Control packets >>>> MAY be transmitted indefinitely after transitioning to AdminDown >>>> state in order to maintain session state in each system (see section >>>> 6.8.18 below). >>> >>> So if the BFD session on the peer went AdminDown during the absence of >>>local >>BFD module, and if peer BFD session continued to send AdminDown, then the >>last case of "or the peer had been taken down administratively during the >>absence of the local system" is no longer an issue, since local >>(resumed) BFD >>session will receive AdminDown packet? > >[Mingui] It sounds the inquiry is still needed if the BFD control packets >are not indefinitely sent. > >>> >>> If the two cases are handled, then that only leaves "the link has been >>>failed", >>which is no longer ambiguous and failing the local session is the right >>thing to do. >>Just some thoughts. Perhaps you can further elaborate the exact >>requirement/use-case on this one. >>> >>>> 3.4. Use Case #4: State Relay >>> >>> Sounds like a similar concept to the BFD proxy described in this >>>document. >>> >>> >>http://datatracker.ietf.org/doc/draft-snyder-bfd-proxy-connections-monito >>red-li >>nks/ >>> >>> Do look through the document to see if the concept is similar. >>> >>> Question is, how do we provision the proxy BFD that is tied to specific >>"remote" session. >>> >>>> 3.5. Use Case #5: Detection of Asymmetric LSPs >>> >>> Controlling the reverse path for BFD control packets, like: >>> >>> http://tools.ietf.org/html/rfc7110 >>> http://datatracker.ietf.org/doc/draft-mirsky-mpls-bfd-directed/ >>> >>> makes sense. But I'm not convinced if similar is required for BFD echo >>>packets. >>If you really require this, then you probably want a mechanism to >>discover the >>local label on the egress for the reverse LSP so that BFD echo packets >>can be >>sent with label stack [forward label, egress local label for reverse >>LSP], so cause >>the packets to u-turn. That mechanism will not be anything BFD specific. > >[Mingui] I agree this kind of requirements can be achieved through >changing applications rather than changing the BFD itself. > >>> >>> Looking forward for discussions/clarifications on the use cases, and >>>also your >>presentation at IETF90/Toronto. >>> >>> Thanks! >>> >>> -Nobo >>> >>> >> >>Mahesh Jethanandani >>mjethanandani@gmail.com >> >> > From nobody Fri Jul 11 15:08:39 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2AAD1B29DF for ; Fri, 11 Jul 2014 15:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.552 X-Spam-Level: X-Spam-Status: No, score=-114.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZoAursWI_fl for ; Fri, 11 Jul 2014 15:08:33 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 775C81B29DE for ; Fri, 11 Jul 2014 15:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6942; q=dns/txt; s=iport; t=1405116513; x=1406326113; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=adwqZH3/fMoP/Zs8ulQzgJvlsZmyCLDQaosAA8yG1gs=; b=eBf+fBm7HtfgbokUcWi9ILQ1dD1MLl8r7ola7HAQg22SYfrMZgStm3M5 Qn4pVcxE+5OouQ4fUpmVe8X6TtQ2CrjlTWYiWjfanBUO5JPZ6tnKTfV6Q c/fHy9SZVIahLdstbb8WR68bpWMca44ZlZSPxRwEM95gmIruxrSmlkngA c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAN1fwFOtJA2F/2dsb2JhbABZgmokgSzIQAGBCxZ1hAMBAQEDAXIHBQcEAgEIEQQBAQsdBzIUCQgBAQQBDQUIiDIIAccCF48YMQcGgyeBFgEEih6lA4NEgjA X-IronPort-AV: E=Sophos;i="5.01,645,1400025600"; d="scan'208";a="339417226" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP; 11 Jul 2014 22:08:31 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6BM8V8b017877 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 22:08:31 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 17:08:31 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , "draft-ietf-bfd-seamless-base@tools.ietf.org" Subject: RE: draft-ietf-bfd-seamless-base Thread-Topic: draft-ietf-bfd-seamless-base Thread-Index: Ac+bm6XqGsvLHk/VStWUJNiaXNCUoABdOb7g Date: Fri, 11 Jul 2014 22:08:30 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7E8E88@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7E8E88@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.48] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/LJGStkT5rAtfFSZIcLdwV6VyS_U Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 22:08:36 -0000 Hi Greg, Many thanks for thoughtful comments! And my apologies for the delay in response. Please see in-line. > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Wednesday, July 09, 2014 4:40 PM > To: draft-ietf-bfd-seamless-base@tools.ietf.org > Cc: rtg-bfd@ietf.org > Subject: draft-ietf-bfd-seamless-base >=20 > Dear Authors, et. al, > this is great progress, my congratulations to all!=20 The authors certainly placed good effort to roll out this -01, but that was= possible largely due to many great comments on/off the list. So thanks and= congratulations to all! > Please find my notes and > editorial nits below: > . Introduction, second para refers to connectivity testing. I believe tha= t BFD > been used and defined primarily as continuity checking tool though there'= s > at least one example of building connectivity verification based on it. I= think > that changing from "connectivity test" to "continuity test", throughout t= he > document, would make it more accurate. True, scanning the document we can do s/connectivity/continuity/ in most pl= aces, and do s/connectivity/reachability/ in couple of places. ACK, in todo= list for the next revision. > . s/state changes from DOWN to UP is/state changes from DOWN to UP are | > state change from DOWN to UP is/; Good catch. Will take the first suggested. > . Section 4 suggests that both S-BFD Initiator and Responder send S-BFD > control packets to the same well-known UDP port; Oops, let's fix that. Will also update procedures in 8.1.2 and 8.2.1. Specifically: - SBFDInitiator is to set destination port to TBD1. - SBFDReflector is to swap source/destination ports when copying from ping = to pong. Agree? > . Section 5, not clear why S-BFD discriminator appears to have different > uniqueness requirement depending of its use (discriminator collision). I > think that there should be consistency. There seems to be disagreement > between the first paragraph and the second that requires AS uniqueness of > S-BFD discriminators. Or "discriminator collision" is not the same as > "uniqueness"? Right, "internal discriminator collision" is different than "S-BFD discrimi= nator uniqueness within an administrative domain". We need to break up this section into 2 subsections. 5. S-BFD Discriminators 5.1. Discriminator Pools 5.2. S-BFD Discriminator Uniqueness And re-thinking about the discriminator pool rules (along with your 2nd fro= m last comment below), they should be described as: o SBFDInitiator is to allocate a discriminator from the BFD discriminator pool. If the system also supports classical BFD that runs on [RFC5880], then the BFD discriminator pool MUST be shared by SBFDInitiators and classical BFD sessions. o SBFDReflector is to allocate a discriminator from the S-BFD discriminator pool. The S-BFD discriminator pool SHOULD be a separate pool than the BFD discriminator pool. > . Section 5, second para discusses mis-connectivity case. True, it easier= to > detect with IP data plane then with MPLS, whether IP or ACH encapsulation > (where PHP is not the only problem but label merge as well). If S-BFD to = be > used as true Connectivity Verification tool, then in all encapsulations s= ource > must be clearly identifiable. For MPLS data plane it could be done with h= elp > of Source MEP-ID TLV as in RFC 6428. Would note that even with strong > requirement of AS/AD scope of S-BFD discriminator there must be > mechanism to detect and act upon, e.g. drop or enter mis-connectivity err= or > state, "re-use" of discriminators as that likely to pose security threat = (DDoS). A lot depends on how much we (i.e. BFD WG) want to do with S-BFD, and I'd l= ike us to discuss a bit more on the topics of advertisements/s-bfd-uniquene= ss aspects. Rather this is the one of the last few strings holding down the= S-BFD before it can really start flying :) > . Section 8.1 suggests, when distinct pools of BFD and S-BFD discriminato= rs > used, that "My discriminator" must be always allocated from BFD pool. > Would note that unless BFD and S-BFD pools made explicitly separated > there's no, IMO, way to determine from which pool particular discriminato= r > been allocated from. Thus node's own S-BFD discriminators must be > punched out in BFD pool to prevent accidentally being allocated as My > Discriminator. That seems to complicate things and relationship between > BFD and S-BFD. This was a very thoughtful question. This paragraph (second paragraph of se= ction 8.1) requires a complete rewrite. Because of the S-BFD UDP port (or S= -BFD Ach if we ever define one), there is no need to punch out local S-BFD = discriminators in the BFD discriminator pool. That also means, if a classic= al BFD session or an SBFDInitiator happen to use a same discriminator value= as locally allocated S-BFD discriminators, there is problem. In other word= s, as long as received BFD control packets are first demux'ed into SBFDRefl= ector or (SBFDInitiator or classical BFD), then it's ok. The second paragraph of section 8.1 will be replaced with: Every SBFDInitiator MUST have a locally unique "my discriminator" allocated from the BFD discriminator pool. > . And to add to the issue of My Discriminator, I don't see anything that > prevents R2 receiving pings from R1 and R2 in the same md, i.e. R1 and R4 > allocating the same discriminator from BFD pool to be used as My > discriminator. Where the pong will go then? In light of this, I'm more in > favor of nodes advertising discriminator(s) through IGP extensions (or be= ing > centrally allocated) explicitly as their My Discriminator I'm not fully convinced that we need to go that length. Today (at least tod= ay), pong is IP routed, thus it can be demux'ed with destination of the pac= ket (ex: IP address). If you agree, then I can add some texts for this. > . And last but not least, it appears that document assumes that S-BFD > capable node would always have BFD functionality supported. I think that > not necessarily the case and S-BFD only node must be considered in the > document. Thus, my question, if there's no BFD and BFD pool of > discriminators, where from My Discriminator would be allocated for S-BFD? Agree, this is addressed as part of 4th comment. > . Section 8.1.1 may benefit from introduction of terms of "stateful initi= ator" > and "stateless initiator" when characterizing different behavior of > SBFDInitiator. Good suggestion, will make the changes to this section using that terminolo= gy (and thanks for coming up with good terminology!). Thanks! -Nobo P.S. Hopefully I can get to your other comments (s-bfd-ip) soon. >=20 > Regards, > =A0=A0=A0=A0=A0=A0=A0 Greg From nobody Fri Jul 11 16:24:34 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759FC1B29E5 for ; Fri, 11 Jul 2014 16:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.852 X-Spam-Level: X-Spam-Status: No, score=-112.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_LINKS=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irpA5AvUv77Z for ; Fri, 11 Jul 2014 16:24:24 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 055F51A0026 for ; Fri, 11 Jul 2014 16:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7979; q=dns/txt; s=iport; t=1405121064; x=1406330664; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BoAjguKnW8AMksibSDxiPogyFjiNPFaDOig+DHKUp9Y=; b=MYsXmVz/aCwmvmRSjGhD0PPZLYivqGDRvjuwo27HlsWqvlf8onHuW4Cw qkEAph9PEEmd5EqId/R+xI9qMCKBD59A4OqISexxi20Ukyshl4yY0+mT9 hJz3VehOn73vpR8b/pyvGPZ3x8vbT+Oeh/PZiqW0kXUUsz1rGEPn+jVWR c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAKZxwFOtJA2H/2dsb2JhbABZgmokUlrBQIdBAYEJFnWEAwEBAQMBJxMtEgUHBAIBCBEEAQEBChQJByERFAkIAQEEAQ0FCBOIEwMJCAEMvwMNhygXjR2BezEHBoMngRYFlmuCGoNKjDyGFoNEgjA X-IronPort-AV: E=Sophos;i="5.01,646,1400025600"; d="scan'208";a="339545285" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP; 11 Jul 2014 23:24:23 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6BNOMV6008034 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 23:24:22 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 18:24:22 -0500 From: "Nobo Akiya (nobo)" To: Mingui Zhang , Mahesh Jethanandani Subject: RE: Comments on draft-zhang-bfd-new-use-cases Thread-Topic: Comments on draft-zhang-bfd-new-use-cases Thread-Index: Ac+bDbnw0pb1AQkCSB+fwnEmQFkztABX3zAAACoFvgAAEcOMUA== Date: Fri, 11 Jul 2014 23:24:21 +0000 Message-ID: References: <4C7782E2-7818-456C-A24E-BB8B0E227B46@gmail.com> <4552F0907735844E9204A62BBDD325E76A0E2ED7@nkgeml508-mbx.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E76A0E2ED7@nkgeml508-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/hHQC5oamYiQAWVYledn7DAzLfX8 Cc: "draft-zhang-bfd-new-use-cases@tools.ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 23:24:28 -0000 Hi Mingui, > -----Original Message----- > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Friday, July 11, 2014 5:35 AM > To: Mahesh Jethanandani; Nobo Akiya (nobo) > Cc: draft-zhang-bfd-new-use-cases@tools.ietf.org; rtg-bfd@ietf.org > Subject: RE: Comments on draft-zhang-bfd-new-use-cases >=20 > Hi Mahesh, Nobo, >=20 > Thanks for your comments. Please see my response inline. >=20 > Regards, > Mingui >=20 > >-----Original Message----- > >From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Mahesh > >Jethanandani > >Sent: Thursday, July 10, 2014 9:32 PM > >To: Nobo Akiya > >Cc: draft-zhang-bfd-new-use-cases@tools.ietf.org; rtg-bfd@ietf.org > >Subject: Re: Comments on draft-zhang-bfd-new-use-cases > > > >Agree with Nobo, that these are interesting use cases to document. > > > >One comment/question that I have is ... > > > >3.1. Use Case #1: Reliable Detection for Multipath > > > >Would it make more sense to run BFD on each of the possible paths and > >report its individual path status to a higher level protocol? So in > >Figure 3.2, would it make more sense to run 3 BFD sessions between R1 > >and R4 one on each of the links, each of them reporting their status to > >its listeners, be it OSPF ECMP, LAG, or MPLS link bundles and letting th= em > decide what is a failure scenario? >=20 > [Mingui] That's a potential method. Let me interpret it a bit further. Ea= ch > possible forwarding path gets a BFD session. The application need > summarize all the state of these sessions to get the overall health statu= s of > the multipath. >=20 > The difficulty is that two end systems need probe and maintain all possib= le > forwarding paths. For example, a failure of link in the middle of the cha= ins > may affect more than one forwarding paths. Hence, the two end systems > need re-establish those affected BFD sessions. Also, considering the > random hashing that may be adopted (look at the two links between R1 and > R4 in Figure 3.2), the probing of those forwarding paths might be inaccur= ate. If the requirement for IP or MPLS or something else? It might be good to clarify that in this use case, as available OAM and tec= hniques differ quite a bit. >=20 > From the angle of the carriers, unless all possible forwarding paths are > failed, they wish the BFD does not report a failure. That's why we call i= t > "reliable". Well, that's a preference. You are black holing on the one failed path, and= I would not like that if I was a customer :) It's probably important to keep an open mind about how aggregation of state= from related sessions produce the final result. > With this bottom line requirement, we may also figure out a solution work= s > in another way: two end points _dynamically_ pick one of the remained > active interfaces to deliver the BFD control packets. There is always a s= ingle > BFD session per multipath. >=20 > > > >On Jul 8, 2014, at 5:42 PM, Nobo Akiya (nobo) wrote: > > > >> [chair hat off] > >> > >> Hi Authors, > >> > >> Interesting use cases. Please see below for some questions/comments. > >> > >>> 3.1. Use Case #1: Reliable Detection for Multipath > >> > >> In Figure 3.1, do R1-R2-R3-R5 and R1-R4-R5 have same cost? > >> > >> If Figure 3.1, if there was a link between R4 and R3, and all > >> possible paths > >between R1 and R5 were same cost, then how many BFD sessions do you > >want at R1 and to which node? >=20 > [Mingui] As I stated above, we may want to establish only one session. Let's further clarify the use case first. >=20 > >> > >>> 3.2. Use Case #2: Application Consistence > >> > >> I tend to think that the system should simply take the most > >> aggressive > >detection time out of all the applications for the same target. Are > >there any applications that can get negatively impacted by BFD running > >more aggressive than requested detection time? >=20 > [Mingui] The application may not want that aggressive detection due to th= e > stability. Think about the dampening measures towards the state oscillati= on > of network devices. Dampening often controls DOWN->UP sequence, not UP->DOWN. So you'll have to come up with another reason why this use case is valid :) >=20 > >> > >>> 3.3. Use Case #3: Capability Inquiry and Feedback > >>> > >>> If the local system restarts, it may resume the BFD session. > >>> Suppose the link has been failed or the peer has no resources to > >>> create the BFD session or the peer had been taken down > >>> administratively during the absence of the local system. > >> > >> By "system restarts", do you mean a BFD module has gone through a > >> graceful > >restart, or a system hosting the BFD module has gone through a graceful > >reload (w/o forwarding impact)? And by "it may resume the BFD session", > >doesn't that imply that BFD sessions exist locally as well as on the > >peer? If that is true, then I'm not clear on what you mean by " or the > >peer has no resources to create the BFD session". > >> > >> Additionally, RFC5880 states: > >> > >>> BFD Control packets > >>> MAY be transmitted indefinitely after transitioning to AdminDown > >>> state in order to maintain session state in each system (see section > >>> 6.8.18 below). > >> > >> So if the BFD session on the peer went AdminDown during the absence > >> of local > >BFD module, and if peer BFD session continued to send AdminDown, then > >the last case of "or the peer had been taken down administratively > >during the absence of the local system" is no longer an issue, since > >local (resumed) BFD session will receive AdminDown packet? >=20 > [Mingui] It sounds the inquiry is still needed if the BFD control packets= are > not indefinitely sent. So remote session having no resources is not an issue, and it's only remote= session being in AdminDown whilst absence of local session? Maybe you can = write up the sequence of what's happening in local/remote, so that we are o= n the same page about the problem. -> Toronto presentation? :) >=20 > >> > >> If the two cases are handled, then that only leaves "the link has > >> been failed", > >which is no longer ambiguous and failing the local session is the right = thing > to do. > >Just some thoughts. Perhaps you can further elaborate the exact > >requirement/use-case on this one. > >> > >>> 3.4. Use Case #4: State Relay > >> > >> Sounds like a similar concept to the BFD proxy described in this > document. > >> > >> > >http://datatracker.ietf.org/doc/draft-snyder-bfd-proxy-connections-moni > >tored-li > >nks/ > >> > >> Do look through the document to see if the concept is similar. > >> > >> Question is, how do we provision the proxy BFD that is tied to > >> specific > >"remote" session. > >> > >>> 3.5. Use Case #5: Detection of Asymmetric LSPs > >> > >> Controlling the reverse path for BFD control packets, like: > >> > >> http://tools.ietf.org/html/rfc7110 > >> http://datatracker.ietf.org/doc/draft-mirsky-mpls-bfd-directed/ > >> > >> makes sense. But I'm not convinced if similar is required for BFD echo > packets. > >If you really require this, then you probably want a mechanism to > >discover the local label on the egress for the reverse LSP so that BFD > >echo packets can be sent with label stack [forward label, egress local > >label for reverse LSP], so cause the packets to u-turn. That mechanism w= ill > not be anything BFD specific. >=20 > [Mingui] I agree this kind of requirements can be achieved through changi= ng > applications rather than changing the BFD itself. Ok. Thanks! -Nobo >=20 > >> > >> Looking forward for discussions/clarifications on the use cases, and > >> also your > >presentation at IETF90/Toronto. > >> > >> Thanks! > >> > >> -Nobo > >> > >> > > > >Mahesh Jethanandani > >mjethanandani@gmail.com > > > > From nobody Fri Jul 11 17:27:39 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1284A1A0091; Fri, 11 Jul 2014 17:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30jFuSCF_IVU; Fri, 11 Jul 2014 17:27:36 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4128B1A008F; Fri, 11 Jul 2014 17:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2920; q=dns/txt; s=iport; t=1405124856; x=1406334456; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cK/TPRmDJlsJCxR/2gtqsXlQcUnpwSXkcyRXv8Ouzks=; b=X6KhVg2KLchmSeD7QdZqLOEfnZxFdMeBWXYEHxpKBQszHdYPZz9g4nbr 4n13/3oS9bxYoIul3/f7LeadzE3mrkvelETK8LaHF/g244uL0wWG/oVut lH1OOOVKz22Qt5yMAXOTaqpd0GcifThYxTOx3hWm0Z6eCtvFN8Ni1WvOr w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIGALR/wFOtJA2D/2dsb2JhbABZgmokUlqEIr0ah0MBgQoWdYQDAQEBAwF5BQcEAgEIEQQBAQsdBzIUCQgBAQQBDQUIAYgxCAEMxkAXjngBAR4xBwaDJ4EWBYoel0GNQoNEbIELOQ X-IronPort-AV: E=Sophos;i="5.01,646,1400025600"; d="scan'208";a="339272366" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-1.cisco.com with ESMTP; 12 Jul 2014 00:27:36 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6C0RZP9006200 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 12 Jul 2014 00:27:35 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 19:27:35 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , "draft-akiya-bfd-seamless-ip@tools.ietf.org" Subject: RE: Mail regarding draft-akiya-bfd-seamless-ip Thread-Topic: Mail regarding draft-akiya-bfd-seamless-ip Thread-Index: Ac+bu+vYh1eB6vZtTcCR1YUv3xMn0wBpRplw Date: Sat, 12 Jul 2014 00:27:34 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7E8F2D@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7E8F2D@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.48] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Uy5ZPe0fFIRG0avzDaPRb7trPwI Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 00:27:38 -0000 Hi Greg, Thanks for comments! Please see in-line. > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Wednesday, July 09, 2014 6:21 PM > To: draft-akiya-bfd-seamless-ip@tools.ietf.org > Cc: rtg-bfd@ietf.org; mpls@ietf.org > Subject: Mail regarding draft-akiya-bfd-seamless-ip >=20 > Dear Authors, > as the scope of the document includes MPLS data plane I've included MPLS > WG in the discussion. Hope you don't mind. Sure, no problem at all. > Please find my notes to the draft below: > . Section 2 states =A0"S-BFD packets are transmitted with IP header, UDP > header and BFD control header". Does that mean that ACH encapsulation is > outside the scope of this document as in that case S-BFD packets would no= t > have IP and UDP headers. If that is the case, then clarification of the s= cope > seems appropriate. Good question. This is exactly one of the points that authors are looking f= or feedback on. We have two options. This is the S-BFD update slide for IETF90 to be presented in the BFD WG. http://www.ietf.org/proceedings/90/slides/slides-90-bfd-2.pptx Please see page 3 on the two options, and we welcome comments/suggestions := ) > . Section 2 introduces "explicitly label switched" scenario. What is it? On the wire, a packet may have a label stack, but ... Type 1: Those locally generated packets that are routed but happens rides o= ver an LSP (ex: IP routed but goes over LDP LSP). Type 2: Those locally generated packets that are designed to ride over a sp= ecific LSP. By "explicitly label switched", I wanted to say Type 2. But looking for sug= gestions. > . Section 2.1, bullet describing selection of Destination IP address. The= RFC > 5884 allows use of the whole range rather than one address: > "The destination IP address MUST be randomly chosen from the 127/8 range > for IPv4 and =A0from the 0:0:0:0:0:FFFF:7F00/104 range for IPv6 with the > following exception." > The document, as worded, restricts use of Destination IP address to exerc= ise > particular path among available multi-paths, as suggested in the RFC 5884= . > I'd suggest to use explanation from Section 7 of the RFC 5884. Good catch! Yes we wanted to describe the range similar to RFC5884, but wor= ded it incorrectly. We will fix that in the next revision. > . Note that if IP/UDP encapsulation used for S-BFD there could not be "ne= w > associated channel type for S-BFD" as 0x0021 and 0x0057 must be used for > IPv4 and IPv6 accordingly. Or was the Ed.Note for PW-ACH encapsulation? > But Section 3 discusses only IP routing of S-BFD pong. Let's see what the WG decides on the S-BFD document structuring (your comme= nt #1 in above). >=20 > Thank you for your kind consideration. Thanks for always thoughtful comments! -Nobo >=20 > Regards, > =A0=A0=A0=A0=A0=A0=A0 Greg From nobody Sat Jul 12 22:00:32 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF08A1B2879 for ; Sat, 12 Jul 2014 22:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.301 X-Spam-Level: X-Spam-Status: No, score=-101.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPmmBk0UtGf3 for ; Sat, 12 Jul 2014 22:00:28 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2FE01B284F for ; Sat, 12 Jul 2014 22:00:27 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-33-53c1bff53be2 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id CC.E0.05330.5FFB1C35; Sun, 13 Jul 2014 01:08:37 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Sun, 13 Jul 2014 01:00:19 -0400 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , "draft-ietf-bfd-seamless-base@tools.ietf.org" Subject: RE: draft-ietf-bfd-seamless-base Thread-Topic: draft-ietf-bfd-seamless-base Thread-Index: Ac+bm6XqGsvLHk/VStWUJNiaXNCUoABdOb7gAFD/jnA= Date: Sun, 13 Jul 2014 05:00:18 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7EC413@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B7E8E88@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyuXRPlO7X/QeDDZ53yFl0TWazmN0Rb/H5 zzZGB2aPKb83snosWfKTyePL5c9sAcxRXDYpqTmZZalF+nYJXBnLzj1kKbhnXnFlm1YD42+d LkZODgkBE4lbi5tYIWwxiQv31rN1MXJxCAkcZZS403WZBcJZzijx48MuNpAqNgEjiRcbe9hB EiICnYwS739+ZgRJMAtoSjSd+MwOYgsLaElMmrGLCcQWEdCW6D63nQ3CtpI4fuIsWD2LgKpE x8PLYPW8Ar4SxxYuZoXYNoFR4tyqu2DNnECJ7Y/Og9mMQPd9P7WGCWKZuMStJ/OZIO4WkFiy 5zwzhC0q8fLxP6h/lCQ+/p7PDlGvJ3Fj6hQ2CFtbYtnC18wQiwUlTs58wjKBUWwWkrGzkLTM QtIyC0nLAkaWVYwcpcWpZbnpRgabGIGRc0yCTXcH456XlocYBTgYlXh4F5QfDBZiTSwrrsw9 xCjNwaIkzjurdl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkbmnZd2TQz669AqUyN6agLP wmtvcrbdUl7QwX31Sv2fm67z9a+9Uy0PdZZYts5BK0ub5VZsKsO05eUBbq+PuscsUFHyWRtb L9Wer/Es/e3n36xyaud5hEq5Cjd+W7CbwVfhpv3UPKUp62Z7/JA4ZVkYwad5YbZdYvWfq8KL oyT9HJ88mpX6UVKJpTgj0VCLuag4EQDEy/YbfQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/dvyd21Xb6BEw0y37L8vKS62KxtU Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 05:00:30 -0000 Hi Nobo, many thanks for taking time in such busy period before the meeting and your= kind consideration of my notes. I've clipped topics we've agreed on. Couple more notes in-lined and tagged by GIM>>. And on some I need extra t= ime to think :) Best regards, Greg -----Original Message----- From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]=20 Sent: Friday, July 11, 2014 3:08 PM To: Gregory Mirsky; draft-ietf-bfd-seamless-base@tools.ietf.org Cc: rtg-bfd@ietf.org Subject: RE: draft-ietf-bfd-seamless-base=20 Hi Greg, Many thanks for thoughtful comments! And my apologies for the delay in response. Please see in-line. > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Wednesday, July 09, 2014 4:40 PM > To: draft-ietf-bfd-seamless-base@tools.ietf.org > Cc: rtg-bfd@ietf.org > Subject: draft-ietf-bfd-seamless-base >=20 > Dear Authors, et. al, > this is great progress, my congratulations to all!=20 The authors certainly placed good effort to roll out this -01, but that was= possible largely due to many great comments on/off the list. So thanks and= congratulations to all! [...] > . Section 4 suggests that both S-BFD Initiator and Responder send=20 > S-BFD control packets to the same well-known UDP port; Oops, let's fix that. Will also update procedures in 8.1.2 and 8.2.1. Specifically: - SBFDInitiator is to set destination port to TBD1. - SBFDReflector is to swap source/destination ports when copying from ping = to pong. Agree? GIM>> By the reference to RFC 5881 Initiator would use dynamic port number = as its Source port. How would that scale? As you probably expected, I'd pro= pose to use another well-known UDP port for pong. And the SBFDReflector the= n will follow RFC 5881 procedure in setting its UDP source port number. > . Section 5, not clear why S-BFD discriminator appears to have=20 > different uniqueness requirement depending of its use (discriminator=20 > collision). I think that there should be consistency. There seems to=20 > be disagreement between the first paragraph and the second that=20 > requires AS uniqueness of S-BFD discriminators. Or "discriminator=20 > collision" is not the same as "uniqueness"? Right, "internal discriminator collision" is different than "S-BFD discrimi= nator uniqueness within an administrative domain". We need to break up this section into 2 subsections. 5. S-BFD Discriminators 5.1. Discriminator Pools 5.2. S-BFD Discriminator Uniqueness And re-thinking about the discriminator pool rules (along with your 2nd fro= m last comment below), they should be described as: o SBFDInitiator is to allocate a discriminator from the BFD discriminator pool. If the system also supports classical BFD that runs on [RFC5880], then the BFD discriminator pool MUST be shared by SBFDInitiators and classical BFD sessions. o SBFDReflector is to allocate a discriminator from the S-BFD discriminator pool. The S-BFD discriminator pool SHOULD be a separate pool than the BFD discriminator pool. GIM>> Good plan and I like the tight text. > . Section 5, second para discusses mis-connectivity case. True, it=20 > easier to detect with IP data plane then with MPLS, whether IP or ACH=20 > encapsulation (where PHP is not the only problem but label merge as=20 > well). If S-BFD to be used as true Connectivity Verification tool,=20 > then in all encapsulations source must be clearly identifiable. For=20 > MPLS data plane it could be done with help of Source MEP-ID TLV as in=20 > RFC 6428. Would note that even with strong requirement of AS/AD scope=20 > of S-BFD discriminator there must be mechanism to detect and act upon,=20 > e.g. drop or enter mis-connectivity error state, "re-use" of discriminato= rs as that likely to pose security threat (DDoS). A lot depends on how much we (i.e. BFD WG) want to do with S-BFD, and I'd l= ike us to discuss a bit more on the topics of advertisements/s-bfd-uniquene= ss aspects. Rather this is the one of the last few strings holding down the= S-BFD before it can really start flying :) > . Section 8.1 suggests, when distinct pools of BFD and S-BFD=20 > discriminators used, that "My discriminator" must be always allocated fro= m BFD pool. > Would note that unless BFD and S-BFD pools made explicitly separated=20 > there's no, IMO, way to determine from which pool particular=20 > discriminator been allocated from. Thus node's own S-BFD=20 > discriminators must be punched out in BFD pool to prevent accidentally=20 > being allocated as My Discriminator. That seems to complicate things=20 > and relationship between BFD and S-BFD. This was a very thoughtful question. This paragraph (second paragraph of se= ction 8.1) requires a complete rewrite. Because of the S-BFD UDP port (or S= -BFD Ach if we ever define one), there is no need to punch out local S-BFD = discriminators in the BFD discriminator pool. That also means, if a classic= al BFD session or an SBFDInitiator happen to use a same discriminator value= as locally allocated S-BFD discriminators, there is problem. In other word= s, as long as received BFD control packets are first demux'ed into SBFDRefl= ector or (SBFDInitiator or classical BFD), then it's ok. The second paragraph of section 8.1 will be replaced with: Every SBFDInitiator MUST have a locally unique "my discriminator" allocated from the BFD discriminator pool. > . And to add to the issue of My Discriminator, I don't see anything=20 > that prevents R2 receiving pings from R1 and R2 in the same md, i.e.=20 > R1 and R4 allocating the same discriminator from BFD pool to be used=20 > as My discriminator. Where the pong will go then? In light of this,=20 > I'm more in favor of nodes advertising discriminator(s) through IGP=20 > extensions (or being centrally allocated) explicitly as their My=20 > Discriminator I'm not fully convinced that we need to go that length. Today (at least tod= ay), pong is IP routed, thus it can be demux'ed with destination of the pac= ket (ex: IP address). If you agree, then I can add some texts for this. > . And last but not least, it appears that document assumes that S-BFD=20 > capable node would always have BFD functionality supported. I think=20 > that not necessarily the case and S-BFD only node must be considered=20 > in the document. Thus, my question, if there's no BFD and BFD pool of=20 > discriminators, where from My Discriminator would be allocated for S-BFD? Agree, this is addressed as part of 4th comment. > . Section 8.1.1 may benefit from introduction of terms of "stateful initi= ator" > and "stateless initiator" when characterizing different behavior of=20 > SBFDInitiator. Good suggestion, will make the changes to this section using that terminolo= gy (and thanks for coming up with good terminology!). Thanks! -Nobo P.S. Hopefully I can get to your other comments (s-bfd-ip) soon. >=20 > Regards, > =A0=A0=A0=A0=A0=A0=A0 Greg From nobody Sun Jul 13 07:55:39 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CE81B2813 for ; Sun, 13 Jul 2014 07:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OyAYhYw2OHv for ; Sun, 13 Jul 2014 07:55:36 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3968A1B27F3 for ; Sun, 13 Jul 2014 07:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3008; q=dns/txt; s=iport; t=1405263336; x=1406472936; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bV4dPx7UShjktLpCzQhiLbyPsyHOrvxJtJxMIa9g6GQ=; b=BiTSkDNwPOLoMcFVOSlFCmIjPynaefafKSDNbaxr/DEm1NREz3n0Y9l3 CzjkiC/hIiX5lgAPtHAXGyeoz5YmIh5uSG+IKjj84wJY5OZQ+MZm5RrWn lJmhcyo5azQIzCdgBedm9E7FZRtDHb5UZg7HDo+IzwAqP8pDaZ6B4VUFK E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAOacwlOtJV2P/2dsb2JhbABZgmokgSzJBAGBCBZ1hAMBAQEDATo/BQcEAgEIEQQBAQsUCQcyFAkIAQEEAQ0FCIgyCAHHCRePGjEHBoMngRYBBK8rg0SCMA X-IronPort-AV: E=Sophos;i="5.01,653,1400025600"; d="scan'208";a="60444545" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP; 13 Jul 2014 14:55:35 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s6DEtZhQ013947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 13 Jul 2014 14:55:35 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Sun, 13 Jul 2014 09:55:34 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , "draft-ietf-bfd-seamless-base@tools.ietf.org" Subject: RE: draft-ietf-bfd-seamless-base Thread-Topic: draft-ietf-bfd-seamless-base Thread-Index: Ac+bm6XqGsvLHk/VStWUJNiaXNCUoABdOb7gAFD/jnAAE9i4EA== Date: Sun, 13 Jul 2014 14:55:33 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7E8E88@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7EC413@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7EC413@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/X-4F3QlpPaWZ0y1NMSUV7I1X5x8 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 14:55:38 -0000 Hi Greg, > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Sunday, July 13, 2014 1:00 AM > To: Nobo Akiya (nobo); draft-ietf-bfd-seamless-base@tools.ietf.org > Cc: rtg-bfd@ietf.org > Subject: RE: draft-ietf-bfd-seamless-base >=20 > Hi Nobo, > many thanks for taking time in such busy period before the meeting and > your kind consideration of my notes. Likewise! And thanks for flushing out many quirks from the document! > I've clipped topics we've agreed on. > Couple more notes in-lined and tagged by GIM>>. And on some I need extra > time to think :) I'm preserving just the UDP source topic to progress discussion on that. > > . Section 4 suggests that both S-BFD Initiator and Responder send > > S-BFD control packets to the same well-known UDP port; >=20 > Oops, let's fix that. Will also update procedures in 8.1.2 and 8.2.1. >=20 > Specifically: > - SBFDInitiator is to set destination port to TBD1. > - SBFDReflector is to swap source/destination ports when copying from pin= g > to pong. >=20 > Agree? > GIM>> By the reference to RFC 5881 Initiator would use dynamic port > number as its Source port. How would that scale? As you probably expected= , > I'd propose to use another well-known UDP port for pong. And the > SBFDReflector then will follow RFC 5881 procedure in setting its UDP sour= ce > port number. I see what you mean. What I should have included in my previous comment was= that source UDP port texts from RFC5881 should be modified for S-BFD as we= ll. [RFC5881] BFD Control packets MUST be transmitted in UDP packets with destination port 3784, within an IPv4 or IPv6 packet. The source port MUST be in the range 49152 through 65535. The same UDP source port number MUST be used for all BFD Control packets associated with a particular session. The source port number SHOULD be unique among all BFD sessions on the system. [S-BFD] A new UDP port is defined for the use of the S-BFD: TBD1. SBFDReflector session MUST listen for incoming S-BFD packets on the port TBD1. SBFDInitiator sessions MUST transmit S-BFD packets with destination port TBD1. The source port of the S-BFD packets transmitted by SBFDInitiator sessions MUST be in the range 49152 through 65535. The same UDP source port number MUST be used for all S-BFD packets associated with a particular SBFDInitiator session. The source port number MAY be unique among all SBFDInitiator sessions on the system. Note: The last "SHOULD" changing to "MAY" is the key. This will address the scale issue, and S-BFD pong packets are identified wi= th "source port =3D=3D TBD1", so similar hooks (ex: rate limiter) should st= ill be possible. But we can go either way (i.e. above or having a separate = well-known UDP port for pong). What would be beneficial is to have vendors = think about this, and see which we prefer more. Thanks! -Nobo From nobody Sun Jul 13 23:53:50 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090561A0320 for ; Sun, 13 Jul 2014 23:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmpR1_hpSzzv for ; Sun, 13 Jul 2014 23:53:46 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCED1A031B for ; Sun, 13 Jul 2014 23:53:45 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 1E55E2AA0F; Mon, 14 Jul 2014 06:53:42 +0000 (GMT) Date: Sun, 13 Jul 2014 23:53:55 -0700 From: Marc Binderberger To: Mahesh Jethanandani Message-ID: <20140713235355131554.386a7bfe@sniff.de> In-Reply-To: <7D7BEA10-A2D0-4948-AC6B-DDAE96490962@gmail.com> References: <20140630163846.GA11842@pfrc> <20140706225103.GB21814@pfrc> <315041E4211CB84E86EF7C25A2AB583D346263F3@xmb-rcd-x15.cisco.com> <20140708212758846800.0b3e2246@sniff.de> <7D7BEA10-A2D0-4948-AC6B-DDAE96490962@gmail.com> Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/duos5xDeG9ol5Iz5lqKcKiguf3g Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 06:53:49 -0000 Hello Mahesh, > That is what happens when you have read the complete draft :-( the full 8 pages, yes ;-) > Question around the explanation provided in Appendix A. > > For 3.3ms: required by MPLS-TP - is there a reference you can cite? Also, > is this a requirement only for MPLS-TP? MPLS-TP was at least driving this requirement. I have to ask my MPLS colleagues if this has been written down explicitly meanwhile. > The rational for 20ms applies to 10ms (with a multiplier of 3) and explains > the why. Better than saying general consensus and not explaining the why. > Would you agree? Various people have expressed their strong interest to have 10msec in the set of intervals. For various reasons. The ability to detect/restore in 50-60msec is of course important but even more important was the fact that many vendors are about to implement or have already implemented 10msec. That's why I wrote "general consensus" instead of trying to rationalize the value. Regards, Marc > > On Jul 8, 2014, at 9:27 PM, Marc Binderberger wrote: > >> Hello Mahesh, >> >> appendix A of the draft is explaining the selection. >> >> >> Best regards, >> Marc >> >> >> On Tue, 8 Jul 2014 17:42:41 -0700, Mahesh Jethanandani wrote: >>> Jeff et. all, >>> >>> Having just tried an interoperability BFD test between two vendor boxes, >>> I >>> can see why having the defined common intervals would be useful. So yes, >>> a >>> support for the draft. >>> >>> Would it be helpful to have some rational for why the said intervals were >>> selected? Typical rationals that I have heard for the faster intervals >>> are >>> that operators want a 50ms protection switchover. For that 3.3ms and 10ms >>> meet the detection requirements. What goal is 20ms trying to achieve? >>> >>> A 100ms and 1s intervals are helpful for applications that do not have >>> stringent requirements (e.g. protection of a voice stream) but can >>> benefit >>> from a quick detection. Examples include routing protocols that use BFD >>> as >>> a hello protocol. >>> >>> >>> On Mon, Jul 7, 2014 at 11:49 AM, Pablo Frank wrote: >>>> I'm working on a HW implementation that supports the proposed intervals >>>> and the draft was useful in that context. I can see that the non-Y.1731 >>>> standard intervals (i.e. 20ms, 50ms) could prove a challenge for some >>>> existing hardware implementations, but these rates should be within the >>>> capability of most software implementations. Even for existing hardware >>>> implementations, since the new rates are a multiple of 10ms, it's >>>> usually >>>> not *that* challenging. So yes/support. >>>> >>>> regards, >>>> Pablo >>>> >>>> >>>> >>>> On Mon, Jul 7, 2014 at 12:12 PM, Vengada Prasad Govindan (venggovi) >>>> wrote: >>>>> Hello Jeff, >>>>> From an implementer's perspective, I see this draft adds value by >>>>> steering implementations towards a point of convergence. I support this >>>>> draft for publication. >>>>> Thanks >>>>> Prasad >>>>> >>>>> -----Original Message----- >>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey >>>>> Haas >>>>> Sent: Monday, July 07, 2014 4:21 AM >>>>> To: rtg-bfd@ietf.org >>>>> Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals >>>>> (ending >>>>> July 15) >>>>> >>>>> We are coming up on the second week of this WGLC and have thus far only >>>>> heard from one non-author. :-) Please take a moment and review this >>>>> draft, especially if you are an implementor. >>>>> >>>>> -- Jeff >>>>> >>>>> On Mon, Jun 30, 2014 at 12:38:46PM -0400, Jeffrey Haas wrote: >>>>>> Working Group, >>>>>> >>>>>> We would like to initiate the start of Working Group Last Call for >>>>>> Common Interval Support in BFD: >>>>>> >>>>>> http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 >>>>>> >>>>>> Note that the intended status of this document is INFORMATIONAL. >>>>>> >>>>>> Please send your comments, including whether you think the draft is >>>>>> ready for publication or not, to the list no later than July 15. >>>>>> >>>>>> -- Jeff and Nobo >>>>> >>>> >>> >>> >>> >>> -- >>> Mahesh Jethanandani >>> mjethanandani@gmail.com > > Mahesh Jethanandani > mjethanandani@gmail.com > > > From nobody Mon Jul 14 02:00:09 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBF11A0051 for ; Mon, 14 Jul 2014 02:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LINKS=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKua3V8x8VR2 for ; Mon, 14 Jul 2014 02:00:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A15B51A001E for ; Mon, 14 Jul 2014 02:00:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHE00888; Mon, 14 Jul 2014 09:00:03 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 14 Jul 2014 10:00:02 +0100 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.225]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 14 Jul 2014 16:59:58 +0800 From: Mingui Zhang To: "Nobo Akiya (nobo)" , Mahesh Jethanandani Subject: RE: Comments on draft-zhang-bfd-new-use-cases Thread-Topic: Comments on draft-zhang-bfd-new-use-cases Thread-Index: Ac+bDbnw0pb1AQkCSB+fwnEmQFkztAA8oXIAACgRj9AAHuqOgACGg8og Date: Mon, 14 Jul 2014 08:59:57 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E76A0E4599@nkgeml508-mbx.china.huawei.com> References: <4C7782E2-7818-456C-A24E-BB8B0E227B46@gmail.com> <4552F0907735844E9204A62BBDD325E76A0E2ED7@nkgeml508-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/iXCe05tYlKKFGVRdE-d3OpGUL4A Cc: "draft-zhang-bfd-new-use-cases@tools.ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 09:00:08 -0000 Hi Nobo, >> From the angle of the carriers, unless all possible forwarding paths are >> failed, they wish the BFD does not report a failure. That's why we call = it >> "reliable". > >Well, that's a preference. You are black holing on the one failed path, an= d I >would not like that if I was a customer :) [Mingui] I think I should say "Detection for Reliable Multipath" rather tha= n "Reliable Detection for Multipath". :-) > >It's probably important to keep an open mind about how aggregation of stat= e >from related sessions produce the final result. [Mingui] I agree. I think the logic is to have BFD per any possible forward= ing path for the multipath. If there is any UP BFD session, the multipath i= s UP. >If the requirement for IP or MPLS or something else? >It might be good to clarify that in this use case, as available OAM and te= chniques >differ quite a bit. [Mingui] Yes, I agree. The multipath can be the multipath per [RFC7226] or = a layer3 multi-hop multipath with lower layer TRILL links on the path (e.g.= , the link between R1 and R4 in Figure 3.2). Those are the original scenari= os that cause us to bring forward use case #1. >> [Mingui] The application may not want that aggressive detection due to t= he >> stability. Think about the dampening measures towards the state oscillat= ion >> of network devices. > >Dampening often controls DOWN->UP sequence, not UP->DOWN. >So you'll have to come up with another reason why this use case is valid := ) [Mingui] Yes, dampening control the DOWN->UP sequence. Now, consider no ext= ra dampening measure is taken. Rather, the application simply expects to da= mpen oscillation using a large desired detection time.=20 The dampening use case is just used to explain that the application subscri= bes the BFD and expect it acts as subscribed. It may not need surprise:). S= o we require a method to negotiate the detection requirements. We have another use case at hand for this requirement. You can determine wh= ether it is relevant. In the following figure, suppose two different MC-LAG= links between CE and PEs share the same heart-beat link between PE1 and PE= 2. LAG1 creates bfd1 at PE1 but not at PE2. LAG2 creates bfd2 at PE2 but no= t PE1. This is a mis-configuration. But we will find the BFD session can be= set up with bfd1 talking with bfd2.=20 PE1 /| / | / | CE | \ | \ | \| PE2 >> [Mingui] It sounds the inquiry is still needed if the BFD control packet= s are >> not indefinitely sent. > >So remote session having no resources is not an issue, and it's only remot= e >session being in AdminDown whilst absence of local session? Maybe you can >write up the sequence of what's happening in local/remote, so that we are = on >the same page about the problem. -> Toronto presentation? :) [Mingui] Well. The "having no resources" is still an issue. Let me introduc= e the following scenario.=20 Suppose link (if1--if2) is the primary while link (if3--if4) is the backup.= The line card attached to if2 is pulled out. So two endpoints resort to li= nk (if3--if4). Suppose this link is working before the switching but if4 ha= s too much BFD sessions running on it, so the processor of the NP does not = have resources to create any more BFD session. The application wishes to us= e link (if3--if4), but the BFD keeps holding a DOWN state for the session.= =20 The sequence of the "AdminDown" scenario is like this: the local system fai= ls. The remote system takes down the session administratively during its fa= ilure and then ceases to transmit BFD control packets. Afterwards, the loca= l system reboots and tries to recreate the BFD session. However, the BFD wi= ll keep holding a DOWN state for the session even the forwarding path is UP= . Note that the restart here is not graceful restart. It's a local system reb= oot. I want to rectify one word in the text: resume->re-create. I will be in Toronto. See you there. Thanks, Mingui >-----Original Message----- >From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] >Sent: Saturday, July 12, 2014 7:24 AM >To: Mingui Zhang; Mahesh Jethanandani >Cc: draft-zhang-bfd-new-use-cases@tools.ietf.org; rtg-bfd@ietf.org >Subject: RE: Comments on draft-zhang-bfd-new-use-cases > >Hi Mingui, > >> -----Original Message----- >> From: Mingui Zhang [mailto:zhangmingui@huawei.com] >> Sent: Friday, July 11, 2014 5:35 AM >> To: Mahesh Jethanandani; Nobo Akiya (nobo) >> Cc: draft-zhang-bfd-new-use-cases@tools.ietf.org; rtg-bfd@ietf.org >> Subject: RE: Comments on draft-zhang-bfd-new-use-cases >> >> Hi Mahesh, Nobo, >> >> Thanks for your comments. Please see my response inline. >> >> Regards, >> Mingui >> >> >-----Original Message----- >> >From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Mahesh >> >Jethanandani >> >Sent: Thursday, July 10, 2014 9:32 PM >> >To: Nobo Akiya >> >Cc: draft-zhang-bfd-new-use-cases@tools.ietf.org; rtg-bfd@ietf.org >> >Subject: Re: Comments on draft-zhang-bfd-new-use-cases >> > >> >Agree with Nobo, that these are interesting use cases to document. >> > >> >One comment/question that I have is ... >> > >> >3.1. Use Case #1: Reliable Detection for Multipath >> > >> >Would it make more sense to run BFD on each of the possible paths and >> >report its individual path status to a higher level protocol? So in >> >Figure 3.2, would it make more sense to run 3 BFD sessions between R1 >> >and R4 one on each of the links, each of them reporting their status to >> >its listeners, be it OSPF ECMP, LAG, or MPLS link bundles and letting t= hem >> decide what is a failure scenario? >> >> [Mingui] That's a potential method. Let me interpret it a bit further. E= ach >> possible forwarding path gets a BFD session. The application need >> summarize all the state of these sessions to get the overall health stat= us of >> the multipath. >> >> The difficulty is that two end systems need probe and maintain all possi= ble >> forwarding paths. For example, a failure of link in the middle of the ch= ains >> may affect more than one forwarding paths. Hence, the two end systems >> need re-establish those affected BFD sessions. Also, considering the >> random hashing that may be adopted (look at the two links between R1 and >> R4 in Figure 3.2), the probing of those forwarding paths might be inaccu= rate. > >If the requirement for IP or MPLS or something else? >It might be good to clarify that in this use case, as available OAM and te= chniques >differ quite a bit. > >> >> From the angle of the carriers, unless all possible forwarding paths are >> failed, they wish the BFD does not report a failure. That's why we call = it >> "reliable". > >Well, that's a preference. You are black holing on the one failed path, an= d I >would not like that if I was a customer :) > >It's probably important to keep an open mind about how aggregation of stat= e >from related sessions produce the final result. > >> With this bottom line requirement, we may also figure out a solution wor= ks >> in another way: two end points _dynamically_ pick one of the remained >> active interfaces to deliver the BFD control packets. There is always a = single >> BFD session per multipath. >> >> > >> >On Jul 8, 2014, at 5:42 PM, Nobo Akiya (nobo) wrote: >> > >> >> [chair hat off] >> >> >> >> Hi Authors, >> >> >> >> Interesting use cases. Please see below for some questions/comments. >> >> >> >>> 3.1. Use Case #1: Reliable Detection for Multipath >> >> >> >> In Figure 3.1, do R1-R2-R3-R5 and R1-R4-R5 have same cost? >> >> >> >> If Figure 3.1, if there was a link between R4 and R3, and all >> >> possible paths >> >between R1 and R5 were same cost, then how many BFD sessions do you >> >want at R1 and to which node? >> >> [Mingui] As I stated above, we may want to establish only one session. > >Let's further clarify the use case first. > >> >> >> >> >>> 3.2. Use Case #2: Application Consistence >> >> >> >> I tend to think that the system should simply take the most >> >> aggressive >> >detection time out of all the applications for the same target. Are >> >there any applications that can get negatively impacted by BFD running >> >more aggressive than requested detection time? >> >> [Mingui] The application may not want that aggressive detection due to t= he >> stability. Think about the dampening measures towards the state oscillat= ion >> of network devices. > >Dampening often controls DOWN->UP sequence, not UP->DOWN. >So you'll have to come up with another reason why this use case is valid := ) > >> >> >> >> >>> 3.3. Use Case #3: Capability Inquiry and Feedback >> >>> >> >>> If the local system restarts, it may resume the BFD session. >> >>> Suppose the link has been failed or the peer has no resources to >> >>> create the BFD session or the peer had been taken down >> >>> administratively during the absence of the local system. >> >> >> >> By "system restarts", do you mean a BFD module has gone through a >> >> graceful >> >restart, or a system hosting the BFD module has gone through a graceful >> >reload (w/o forwarding impact)? And by "it may resume the BFD session", >> >doesn't that imply that BFD sessions exist locally as well as on the >> >peer? If that is true, then I'm not clear on what you mean by " or the >> >peer has no resources to create the BFD session". >> >> >> >> Additionally, RFC5880 states: >> >> >> >>> BFD Control packets >> >>> MAY be transmitted indefinitely after transitioning to AdminDown >> >>> state in order to maintain session state in each system (see section >> >>> 6.8.18 below). >> >> >> >> So if the BFD session on the peer went AdminDown during the absence >> >> of local >> >BFD module, and if peer BFD session continued to send AdminDown, then >> >the last case of "or the peer had been taken down administratively >> >during the absence of the local system" is no longer an issue, since >> >local (resumed) BFD session will receive AdminDown packet? >> >> [Mingui] It sounds the inquiry is still needed if the BFD control packet= s are >> not indefinitely sent. > >So remote session having no resources is not an issue, and it's only remot= e >session being in AdminDown whilst absence of local session? Maybe you can >write up the sequence of what's happening in local/remote, so that we are = on >the same page about the problem. -> Toronto presentation? :) > >> >> >> >> >> If the two cases are handled, then that only leaves "the link has >> >> been failed", >> >which is no longer ambiguous and failing the local session is the right= thing >> to do. >> >Just some thoughts. Perhaps you can further elaborate the exact >> >requirement/use-case on this one. >> >> >> >>> 3.4. Use Case #4: State Relay >> >> >> >> Sounds like a similar concept to the BFD proxy described in this >> document. >> >> >> >> >> >http://datatracker.ietf.org/doc/draft-snyder-bfd-proxy-connections-moni >> >tored-li >> >nks/ >> >> >> >> Do look through the document to see if the concept is similar. >> >> >> >> Question is, how do we provision the proxy BFD that is tied to >> >> specific >> >"remote" session. >> >> >> >>> 3.5. Use Case #5: Detection of Asymmetric LSPs >> >> >> >> Controlling the reverse path for BFD control packets, like: >> >> >> >> http://tools.ietf.org/html/rfc7110 >> >> http://datatracker.ietf.org/doc/draft-mirsky-mpls-bfd-directed/ >> >> >> >> makes sense. But I'm not convinced if similar is required for BFD ech= o >> packets. >> >If you really require this, then you probably want a mechanism to >> >discover the local label on the egress for the reverse LSP so that BFD >> >echo packets can be sent with label stack [forward label, egress local >> >label for reverse LSP], so cause the packets to u-turn. That mechanism = will >> not be anything BFD specific. >> >> [Mingui] I agree this kind of requirements can be achieved through chang= ing >> applications rather than changing the BFD itself. > >Ok. > >Thanks! > >-Nobo > >> >> >> >> >> Looking forward for discussions/clarifications on the use cases, and >> >> also your >> >presentation at IETF90/Toronto. >> >> >> >> Thanks! >> >> >> >> -Nobo >> >> >> >> >> > >> >Mahesh Jethanandani >> >mjethanandani@gmail.com >> > >> > From nobody Mon Jul 14 09:19:57 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0D41A0ACE for ; Mon, 14 Jul 2014 09:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pW7EujcJ8Mx1 for ; Mon, 14 Jul 2014 09:19:53 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 524CF1A0AE7 for ; Mon, 14 Jul 2014 09:19:52 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C81BFC22C; Mon, 14 Jul 2014 12:19:51 -0400 (EDT) Date: Mon, 14 Jul 2014 12:19:51 -0400 From: Jeffrey Haas To: Gregory Mirsky Subject: Re: draft-ietf-bfd-seamless-base Message-ID: <20140714161951.GJ19932@pfrc> References: <7347100B5761DC41A166AC17F22DF1121B7E8E88@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7EC413@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7EC413@eusaamb103.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ME-5iwabXfgFLtPjN_-OpDP51Sc Cc: "draft-ietf-bfd-seamless-base@tools.ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 16:19:55 -0000 On Sun, Jul 13, 2014 at 05:00:18AM +0000, Gregory Mirsky wrote: > > . Section 4 suggests that both S-BFD Initiator and Responder send > > S-BFD control packets to the same well-known UDP port; > > Oops, let's fix that. Will also update procedures in 8.1.2 and 8.2.1. > > Specifically: > - SBFDInitiator is to set destination port to TBD1. > - SBFDReflector is to swap source/destination ports when copying from ping to pong. > > Agree? > GIM>> By the reference to RFC 5881 Initiator would use dynamic port number as its Source port. How would that scale? As you probably expected, I'd propose to use another well-known UDP port for pong. And the SBFDReflector then will follow RFC 5881 procedure in setting its UDP source port number. There are two nice properties for the swap: - The ability to use UDP port partially for demux. (Yes, you should use discriminator but sometimes it's nice to get layer 4 to help.) - Additional entropy for security considerations. Not a *lot* of entropy but given we're already making discriminator values sticky in at least one direction we could use the help. (Security considerations will plague this feature.) -- Jeff From nobody Mon Jul 14 10:08:43 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E291A0AE0; Mon, 14 Jul 2014 10:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weil9ZlHFYny; Mon, 14 Jul 2014 10:08:34 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2B01A0ADF; Mon, 14 Jul 2014 10:08:34 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-d9-53c3bc0ec701 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 5B.1E.05330.E0CB3C35; Mon, 14 Jul 2014 13:16:30 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Mon, 14 Jul 2014 13:08:33 -0400 From: Gregory Mirsky To: Marc Binderberger , Mahesh Jethanandani Subject: RE: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15) Thread-Topic: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15) Thread-Index: AQHPmw63Tav428XCvEWNHGxxx+UXq5uXaUMAgAIubgCABdYBgIAAZl4A Date: Mon, 14 Jul 2014 17:08:31 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7ECAAF@eusaamb103.ericsson.se> References: <20140630163846.GA11842@pfrc> <20140706225103.GB21814@pfrc> <315041E4211CB84E86EF7C25A2AB583D346263F3@xmb-rcd-x15.cisco.com> <20140708212758846800.0b3e2246@sniff.de> <7D7BEA10-A2D0-4948-AC6B-DDAE96490962@gmail.com> <20140713235355131554.386a7bfe@sniff.de> In-Reply-To: <20140713235355131554.386a7bfe@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXRPiC7fnsPBBgv6zS1mX/nPbHH6zTo2 i1tLV7JafP6zjdGBxWPnrLvsHkuW/GTyaF3dzRLAHMVlk5Kak1mWWqRvl8CVcfLYQtaC2ToV P3qWsjUw3lLuYuTkkBAwkejq7GCBsMUkLtxbz9bFyMUhJHCUUWLuwU3sEM5yRol/774yg1Sx CRhJvNjYww5iiwiESTxcOwvMZhbwkvg/8SMTiC0sECJxYVo/E0RNqMT6LedYuxg5gGw3iQtv 1EDCLAKqEmufbQEbySvgK/HzwHkWiF0LmSW2N50GS3AKmEocPr6HDcRmBLru+6k1TBC7xCVu PZnPBHG1gMSSPeeZIWxRiZeP/7FC2EoSk5aeY4Wo15FYsPsTG4StLbFs4WuoxYISJ2c+YZnA KDYLydhZSFpmIWmZhaRlASPLKkaO0uLUstx0I4NNjMAoOibBpruDcc9Ly0OMAhyMSjy8CqsO BwuxJpYVV+YeYpTmYFES551VOy9YSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2N6YGmu75a8 wvuVR34k+sdILVbpm8yf/u+0RLcec7c+6xKJlrAga9Ftu/frrF2oL72TKaDca+ax/Ji7dodW z1t9TISxaK/JX7kwjdNBF1O72KXdnx/susPOfO10qeUh1/i3y7fMrzhXcSxxsWa8+AERU8+Z 9Tv52/eeW2kRWsnocc/SW0XHQomlOCPRUIu5qDgRACUuUqiDAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/-ErPaHPqeukddkJ0bEfKcFcZASI Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 17:08:37 -0000 Hi Marc, Mahesh, et. al, to the best of my knowledge, I've added MPLS WG to the discussion in case I= have missed it, there's no explicit requirement to support 3.3 msec for th= e benefit of MPLS-TP. But as we consider MPLS-TP to be foundation for packe= t-switched transport and that there's explicit requirement to support sub-5= 0 msec protection switchover, then we conclude that, like in TDM transport,= 10 msec is budgeted to detect a defect. Hence CFM/Y.1731 require support o= f 3.3 msec. I think that support of 3.3 msec by a BFD implementation is a r= equirement if sub-50 msec protection to be provided in a network. (Note, th= at actual detection by CFM/Y.1731 and BFD will vary slightly.) Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc Binderber= ger Sent: Sunday, July 13, 2014 11:54 PM To: Mahesh Jethanandani Cc: rtg-bfd@ietf.org Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals (ending J= uly 15) Hello Mahesh, > That is what happens when you have read the complete draft :-( the full 8 pages, yes ;-) > Question around the explanation provided in Appendix A.=20 >=20 > For 3.3ms: required by MPLS-TP - is there a reference you can cite?=20 > Also, is this a requirement only for MPLS-TP? MPLS-TP was at least driving this requirement. I have to ask my MPLS collea= gues if this has been written down explicitly meanwhile. > The rational for 20ms applies to 10ms (with a multiplier of 3) and explai= ns=20 > the why. Better than saying general consensus and not explaining the why.= =20 > Would you agree? Various people have expressed their strong interest to have 10msec in the s= et=20 of intervals. For various reasons. The ability to detect/restore in 50-60ms= ec=20 is of course important but even more important was the fact that many vendo= rs=20 are about to implement or have already implemented 10msec. That's why I wro= te=20 "general consensus" instead of trying to rationalize the value. Regards, Marc >=20 > On Jul 8, 2014, at 9:27 PM, Marc Binderberger wrote: >=20 >> Hello Mahesh, >>=20 >> appendix A of the draft is explaining the selection. >>=20 >>=20 >> Best regards, >> Marc >>=20 >>=20 >> On Tue, 8 Jul 2014 17:42:41 -0700, Mahesh Jethanandani wrote: >>> Jeff et. all, >>>=20 >>> Having just tried an interoperability BFD test between two vendor boxes= ,=20 >>> I=20 >>> can see why having the defined common intervals would be useful. So yes= ,=20 >>> a=20 >>> support for the draft. >>>=20 >>> Would it be helpful to have some rational for why the said intervals we= re=20 >>> selected? Typical rationals that I have heard for the faster intervals= =20 >>> are=20 >>> that operators want a 50ms protection switchover. For that 3.3ms and 10= ms=20 >>> meet the detection requirements. What goal is 20ms trying to achieve? >>>=20 >>> A 100ms and 1s intervals are helpful for applications that do not have= =20 >>> stringent requirements (e.g. protection of a voice stream) but can=20 >>> benefit=20 >>> from a quick detection. Examples include routing protocols that use BFD= =20 >>> as=20 >>> a hello protocol. >>>=20 >>>=20 >>> On Mon, Jul 7, 2014 at 11:49 AM, Pablo Frank wro= te: >>>> I'm working on a HW implementation that supports the proposed interval= s=20 >>>> and the draft was useful in that context. I can see that the non-Y.17= 31=20 >>>> standard intervals (i.e. 20ms, 50ms) could prove a challenge for some= =20 >>>> existing hardware implementations, but these rates should be within th= e=20 >>>> capability of most software implementations. Even for existing hardwa= re=20 >>>> implementations, since the new rates are a multiple of 10ms, it's=20 >>>> usually=20 >>>> not *that* challenging. So yes/support. >>>>=20 >>>> regards, >>>> Pablo >>>>=20 >>>>=20 >>>>=20 >>>> On Mon, Jul 7, 2014 at 12:12 PM, Vengada Prasad Govindan (venggovi)=20 >>>> wrote: >>>>> Hello Jeff, >>>>> From an implementer's perspective, I see this draft adds value by=20 >>>>> steering implementations towards a point of convergence. I support th= is=20 >>>>> draft for publication. >>>>> Thanks >>>>> Prasad >>>>>=20 >>>>> -----Original Message----- >>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey= =20 >>>>> Haas >>>>> Sent: Monday, July 07, 2014 4:21 AM >>>>> To: rtg-bfd@ietf.org >>>>> Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals=20 >>>>> (ending=20 >>>>> July 15) >>>>>=20 >>>>> We are coming up on the second week of this WGLC and have thus far on= ly=20 >>>>> heard from one non-author. :-) Please take a moment and review this= =20 >>>>> draft, especially if you are an implementor. >>>>>=20 >>>>> -- Jeff >>>>>=20 >>>>> On Mon, Jun 30, 2014 at 12:38:46PM -0400, Jeffrey Haas wrote: >>>>>> Working Group, >>>>>>=20 >>>>>> We would like to initiate the start of Working Group Last Call for >>>>>> Common Interval Support in BFD: >>>>>>=20 >>>>>> http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 >>>>>>=20 >>>>>> Note that the intended status of this document is INFORMATIONAL. >>>>>>=20 >>>>>> Please send your comments, including whether you think the draft is >>>>>> ready for publication or not, to the list no later than July 15. >>>>>>=20 >>>>>> -- Jeff and Nobo >>>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>> Mahesh Jethanandani >>> mjethanandani@gmail.com >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 From nobody Tue Jul 15 09:13:36 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 109B41B28C7 for ; Tue, 15 Jul 2014 09:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vee7fV-zsw-O for ; Tue, 15 Jul 2014 09:13:31 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 119671B287F for ; Tue, 15 Jul 2014 09:13:31 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 555BEC133; Tue, 15 Jul 2014 12:13:30 -0400 (EDT) Date: Tue, 15 Jul 2014 12:13:30 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: [iesg-secretary@ietf.org: Last Call: (Analysis of Bidirectional Forwarding Detection (BFD) Security According to KARP Design Guide) to Informational RFC] Message-ID: <20140715161330.GE25188@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/IHRAr2dpwWPGw3l0-6_wnaUSFj8 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 16:13:34 -0000 This has received some level of review in the BFD group. ----- Forwarded message from The IESG ----- Date: Tue, 15 Jul 2014 07:39:16 -0700 From: The IESG To: IETF-Announce Subject: Last Call: (Analysis of Bidirectional Forwarding Detection (BFD) Security According to KARP Design Guide) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Analysis of Bidirectional Forwarding Detection (BFD) Security According to KARP Design Guide' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-08-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document analyzes the Bidirectional Forwarding Detection protocol (BFD) according to the guidelines set forth in section 4.2 of KARP Design Guidelines [RFC6518]. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-karp-bfd-analysis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-karp-bfd-analysis/ballot/ No IPR declarations have been submitted directly on this I-D. ----- End forwarded message ----- From nobody Tue Jul 15 09:27:55 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B53871B28C3 for ; Tue, 15 Jul 2014 09:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvqGvKGdN5La for ; Tue, 15 Jul 2014 09:27:53 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D7691A0A87 for ; Tue, 15 Jul 2014 09:27:53 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-ad-53c503f2db00 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id E0.31.05330.2F305C35; Tue, 15 Jul 2014 12:35:30 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Tue, 15 Jul 2014 12:27:44 -0400 From: Gregory Mirsky To: Jeffrey Haas Subject: RE: draft-ietf-bfd-seamless-base Thread-Topic: draft-ietf-bfd-seamless-base Thread-Index: AQHPn3973vAtBm2M2USg1tn3dWsW95uhUd0g Date: Tue, 15 Jul 2014 16:27:44 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7ED494@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B7E8E88@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7EC413@eusaamb103.ericsson.se> <20140714161951.GJ19932@pfrc> In-Reply-To: <20140714161951.GJ19932@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyuXRPuO4n5qPBBos71Sy6JrNZ7D/4ltVi dke8xec/2xgdWDym/N7I6rFkyU8mj8u9W1k9vlz+zBbAEsVlk5Kak1mWWqRvl8CVsaVpInvB B76KX31/mRoYf3N3MXJySAiYSJzY0sAIYYtJXLi3nq2LkYtDSOAoo8ScRT+gnOWMEm+uzmMC qWITMJJ4sbGHHcQWEVCUmP+/E6yIWWATo8TKZ6dZQRLCApoSnXvmMkEUaUn8WviZEcI2kjh8 ZhZQDQcHi4CqROuUJJAwr4CvxNWWVhaIZV8YJRbe3A1WzwnU2359BxuIzQh03vdTa8BmMguI S9x6Mp8J4mwBiSV7zjND2KISLx//Y4WwFSX29U9nh6jXkViw+xMbhK0tsWzha2aIxYISJ2c+ YZnAKDYLydhZSFpmIWmZhaRlASPLKkaO0uLUstx0I4NNjMBoOibBpruDcc9Ly0OMAhyMSjy8 CqsOBwuxJpYVV+YeYpTmYFES551VOy9YSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2Oemdan vQ/cLNh1g383i32c4Gitpe7a+fzGy89qz36EOlYEL7lzKFdx0ZFPvrl7ePb23GjbdetozJPS Yxc2Vx7XnXLIlHWxOP/Mw3O3vA/pSuVbFH+gnjuAv+NjU1FOj17u9ng3n8kfcyol9+qZyVhf eGQcpLJskv3GRUVWDLetliRP5vh3q1OJpTgj0VCLuag4EQAwRH2PhwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/dtErba7V44C1XlbhsZSDip5SrN0 Cc: "draft-ietf-bfd-seamless-base@tools.ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 16:27:54 -0000 Hi Jeff, having additional knob to demux is certainly beneficial. =20 As for entropy, I tend to think that swapping may not be the best instrumen= t if our intention is to have both directions of S-BFD traverse the same EC= MP links. But then swapping is the least state-aware procedure to set UDP = ports for a reflected S-BFD control packet. For that, I think, I can accept= swapping. Regards, Greg -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org]=20 Sent: Monday, July 14, 2014 9:20 AM To: Gregory Mirsky Cc: Nobo Akiya (nobo); draft-ietf-bfd-seamless-base@tools.ietf.org; rtg-bfd= @ietf.org Subject: Re: draft-ietf-bfd-seamless-base On Sun, Jul 13, 2014 at 05:00:18AM +0000, Gregory Mirsky wrote: > > . Section 4 suggests that both S-BFD Initiator and Responder send=20 > > S-BFD control packets to the same well-known UDP port; >=20 > Oops, let's fix that. Will also update procedures in 8.1.2 and 8.2.1. >=20 > Specifically: > - SBFDInitiator is to set destination port to TBD1. > - SBFDReflector is to swap source/destination ports when copying from pin= g to pong. >=20 > Agree? > GIM>> By the reference to RFC 5881 Initiator would use dynamic port numbe= r as its Source port. How would that scale? As you probably expected, I'd p= ropose to use another well-known UDP port for pong. And the SBFDReflector t= hen will follow RFC 5881 procedure in setting its UDP source port number. There are two nice properties for the swap: - The ability to use UDP port partially for demux. (Yes, you should use discriminator but sometimes it's nice to get layer 4 to help.) - Additional entropy for security considerations. Not a *lot* of entropy but given we're already making discriminator values sticky in at least on= e direction we could use the help. (Security considerations will plague this feature.) -- Jeff From nobody Tue Jul 15 09:48:50 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6154B1A0AAE; Tue, 15 Jul 2014 09:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2muNqw7EqZv0; Tue, 15 Jul 2014 09:48:46 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E3E1B28B6; Tue, 15 Jul 2014 09:48:45 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id F31882AA0F; Tue, 15 Jul 2014 16:48:42 +0000 (GMT) Date: Tue, 15 Jul 2014 09:49:02 -0700 From: Marc Binderberger To: Gregory Mirsky Message-ID: <20140715094902199916.194f6b23@sniff.de> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7ECAAF@eusaamb103.ericsson.se> References: <20140630163846.GA11842@pfrc> <20140706225103.GB21814@pfrc> <315041E4211CB84E86EF7C25A2AB583D346263F3@xmb-rcd-x15.cisco.com> <20140708212758846800.0b3e2246@sniff.de> <7D7BEA10-A2D0-4948-AC6B-DDAE96490962@gmail.com> <20140713235355131554.386a7bfe@sniff.de> <7347100B5761DC41A166AC17F22DF1121B7ECAAF@eusaamb103.ericsson.se> Subject: RE: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Mqy8vOHJOtDF_s_tr9GgpnzZYi8 Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 16:48:49 -0000 Hello Greg et al., indeed, I got a similar feedback from my colleagues working on MPLS-TP. Have to look into the particular documents (e.g. G.783) to see it with my own eyes but it seems the budget is 10msec detection + 50msec restoration. Always thought it's the other way around. Then the 10msec detection time lead to 3 x 3.3msec, yes. I will update our document with a sentence, especially as I haven't found any IETF reference (draft/RFC) with an explicit requirement for MPLS-TP. It's "borrowed" from Sonet/SDH specs. Thanks for confirming! Regards, Martc On Mon, 14 Jul 2014 17:08:31 +0000, Gregory Mirsky wrote: > Hi Marc, Mahesh, et. al, > to the best of my knowledge, I've added MPLS WG to the discussion in case I > have missed it, there's no explicit requirement to support 3.3 msec for the > benefit of MPLS-TP. But as we consider MPLS-TP to be foundation for > packet-switched transport and that there's explicit requirement to support > sub-50 msec protection switchover, then we conclude that, like in TDM > transport, 10 msec is budgeted to detect a defect. Hence CFM/Y.1731 require > support of 3.3 msec. I think that support of 3.3 msec by a BFD > implementation is a requirement if sub-50 msec protection to be provided in > a network. (Note, that actual detection by CFM/Y.1731 and BFD will vary > slightly.) > > Regards, > Greg > > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc > Binderberger > Sent: Sunday, July 13, 2014 11:54 PM > To: Mahesh Jethanandani > Cc: rtg-bfd@ietf.org > Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals (ending > July 15) > > Hello Mahesh, > >> That is what happens when you have read the complete draft :-( > > the full 8 pages, yes ;-) > > >> Question around the explanation provided in Appendix A. >> >> For 3.3ms: required by MPLS-TP - is there a reference you can cite? >> Also, is this a requirement only for MPLS-TP? > > MPLS-TP was at least driving this requirement. I have to ask my MPLS > colleagues if this has been written down explicitly meanwhile. > > >> The rational for 20ms applies to 10ms (with a multiplier of 3) and >> explains >> the why. Better than saying general consensus and not explaining the why. >> Would you agree? > > Various people have expressed their strong interest to have 10msec in the > set > of intervals. For various reasons. The ability to detect/restore in > 50-60msec > is of course important but even more important was the fact that many > vendors > are about to implement or have already implemented 10msec. That's why I > wrote > "general consensus" instead of trying to rationalize the value. > > > Regards, Marc > > >> >> On Jul 8, 2014, at 9:27 PM, Marc Binderberger wrote: >> >>> Hello Mahesh, >>> >>> appendix A of the draft is explaining the selection. >>> >>> >>> Best regards, >>> Marc >>> >>> >>> On Tue, 8 Jul 2014 17:42:41 -0700, Mahesh Jethanandani wrote: >>>> Jeff et. all, >>>> >>>> Having just tried an interoperability BFD test between two vendor boxes, >>>> I >>>> can see why having the defined common intervals would be useful. So yes, >>>> a >>>> support for the draft. >>>> >>>> Would it be helpful to have some rational for why the said intervals >>>> were >>>> selected? Typical rationals that I have heard for the faster intervals >>>> are >>>> that operators want a 50ms protection switchover. For that 3.3ms and >>>> 10ms >>>> meet the detection requirements. What goal is 20ms trying to achieve? >>>> >>>> A 100ms and 1s intervals are helpful for applications that do not have >>>> stringent requirements (e.g. protection of a voice stream) but can >>>> benefit >>>> from a quick detection. Examples include routing protocols that use BFD >>>> as >>>> a hello protocol. >>>> >>>> >>>> On Mon, Jul 7, 2014 at 11:49 AM, Pablo Frank >>>> wrote: >>>>> I'm working on a HW implementation that supports the proposed intervals >>>>> and the draft was useful in that context. I can see that the >>>>> non-Y.1731 >>>>> standard intervals (i.e. 20ms, 50ms) could prove a challenge for some >>>>> existing hardware implementations, but these rates should be within the >>>>> capability of most software implementations. Even for existing >>>>> hardware >>>>> implementations, since the new rates are a multiple of 10ms, it's >>>>> usually >>>>> not *that* challenging. So yes/support. >>>>> >>>>> regards, >>>>> Pablo >>>>> >>>>> >>>>> >>>>> On Mon, Jul 7, 2014 at 12:12 PM, Vengada Prasad Govindan (venggovi) >>>>> wrote: >>>>>> Hello Jeff, >>>>>> From an implementer's perspective, I see this draft adds value by >>>>>> steering implementations towards a point of convergence. I support >>>>>> this >>>>>> draft for publication. >>>>>> Thanks >>>>>> Prasad >>>>>> >>>>>> -----Original Message----- >>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey >>>>>> Haas >>>>>> Sent: Monday, July 07, 2014 4:21 AM >>>>>> To: rtg-bfd@ietf.org >>>>>> Subject: Re: Working Group Last Call for draft-ietf-bfd-intervals >>>>>> (ending >>>>>> July 15) >>>>>> >>>>>> We are coming up on the second week of this WGLC and have thus far >>>>>> only >>>>>> heard from one non-author. :-) Please take a moment and review this >>>>>> draft, especially if you are an implementor. >>>>>> >>>>>> -- Jeff >>>>>> >>>>>> On Mon, Jun 30, 2014 at 12:38:46PM -0400, Jeffrey Haas wrote: >>>>>>> Working Group, >>>>>>> >>>>>>> We would like to initiate the start of Working Group Last Call for >>>>>>> Common Interval Support in BFD: >>>>>>> >>>>>>> http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 >>>>>>> >>>>>>> Note that the intended status of this document is INFORMATIONAL. >>>>>>> >>>>>>> Please send your comments, including whether you think the draft is >>>>>>> ready for publication or not, to the list no later than July 15. >>>>>>> >>>>>>> -- Jeff and Nobo >>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Mahesh Jethanandani >>>> mjethanandani@gmail.com >> >> Mahesh Jethanandani >> mjethanandani@gmail.com >> >> >> > From nobody Tue Jul 15 10:48:40 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491B81A0AD5 for ; Tue, 15 Jul 2014 10:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQAVuUlidKGH for ; Tue, 15 Jul 2014 10:48:38 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEFC71A0AAC for ; Tue, 15 Jul 2014 10:48:37 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 4D1E62AA0F; Tue, 15 Jul 2014 17:48:34 +0000 (GMT) Date: Tue, 15 Jul 2014 10:48:54 -0700 From: Marc Binderberger To: Jeffrey Haas , Gregory Mirsky , Nobo Akiya (nobo) Message-ID: <20140715104854507112.18a7cf2e@sniff.de> In-Reply-To: <20140714161951.GJ19932@pfrc> References: <7347100B5761DC41A166AC17F22DF1121B7E8E88@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7EC413@eusaamb103.ericsson.se> <20140714161951.GJ19932@pfrc> Subject: Re: draft-ietf-bfd-seamless-base MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/iakww3cAVdu7avyp0Fw9TRhyiNY Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@tools.ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 17:48:39 -0000 Hello everyone, bit behind with reading I found this ... >> . Section 4 suggests that both S-BFD Initiator and Responder send >> S-BFD control packets to the same well-known UDP port; > > Oops, let's fix that. Will also update procedures in 8.1.2 and 8.2.1. > > Specifically: > - SBFDInitiator is to set destination port to TBD1. > - SBFDReflector is to swap source/destination ports when copying from ping > to pong. > > Agree? Do I understand this right: initiator sends with S-BFD dst-port 7784 (not assigned yet) and src-port 50000 and you want to send the "pong" with dst-port 50000 and src-port 7784 ? Why? Using the well-know S-BFD UDP port as destination port for all S-BFD packets seems straight forward. Why would my receiver logic need an additional clause "if the source-port is the S-BFD port" ? Plus: another IP-ish detail I would argue to keep out of the base draft. It's just obfuscating the core aspects of S-BFD, IMHO. > There are two nice properties for the swap: > - The ability to use UDP port partially for demux. (Yes, you should use > discriminator but sometimes it's nice to get layer 4 to help.) maybe but again this is "IP heavy" for a base draft. These details maybe all worthwhile but should be in the IP-specific draft. > - Additional entropy for security considerations. Not a *lot* of entropy > but given we're already making discriminator values sticky in at least one > direction we could use the help. (Security considerations will plague > this feature.) you could use the UDP src port for the entropy, e.g. for filtering. "I sent out with src-port X and will only accept a packet with src-port X" Apropos security, taking the "real thing" aside and using proper authentication (*), ever thought about using the echo field as a "nonce" similar to what LISP is doing? You send out the packet with a random 32bit nonce and accept the pong only when the nonce is what you have sent out. For hardware implementation of the filtering you could keep the nonce fixed for N seconds. (*: problem is if the hardware supports the authentication, otherwise it just adds more load on the software plane) Regards, Marc On Mon, 14 Jul 2014 12:19:51 -0400, Jeffrey Haas wrote: > On Sun, Jul 13, 2014 at 05:00:18AM +0000, Gregory Mirsky wrote: >>> . Section 4 suggests that both S-BFD Initiator and Responder send >>> S-BFD control packets to the same well-known UDP port; >> >> Oops, let's fix that. Will also update procedures in 8.1.2 and 8.2.1. >> >> Specifically: >> - SBFDInitiator is to set destination port to TBD1. >> - SBFDReflector is to swap source/destination ports when copying from ping >> to pong. >> >> Agree? >> GIM>> By the reference to RFC 5881 Initiator would use dynamic port number >> as its Source port. How would that scale? As you probably expected, I'd >> propose to use another well-known UDP port for pong. And the SBFDReflector >> then will follow RFC 5881 procedure in setting its UDP source port number. > > There are two nice properties for the swap: > - The ability to use UDP port partially for demux. (Yes, you should use > discriminator but sometimes it's nice to get layer 4 to help.) > - Additional entropy for security considerations. Not a *lot* of entropy > but given we're already making discriminator values sticky in at least one > direction we could use the help. (Security considerations will plague > this feature.) > > > -- Jeff > From nobody Tue Jul 15 11:56:03 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D881B28E7 for ; Tue, 15 Jul 2014 11:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_52=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rawk_JdEk0m5 for ; Tue, 15 Jul 2014 11:55:58 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCD91A001C for ; Tue, 15 Jul 2014 11:55:58 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 639072AA0F; Tue, 15 Jul 2014 18:55:54 +0000 (GMT) Date: Tue, 15 Jul 2014 11:56:15 -0700 From: Marc Binderberger To: Nobo Akiya (nobo) , Gregory Mirsky Message-ID: <20140715115615035533.a44f4115@sniff.de> In-Reply-To: References: <7347100B5761DC41A166AC17F22DF1121B7E8E88@eusaamb103.ericsson.se> Subject: RE: draft-ietf-bfd-seamless-base MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/u-Dwp9JSEjebrS8CNAIGyY_1-90 Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@tools.ietf.org" , "Marc Binderberger \(mbinderb\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 18:56:00 -0000 Hello Nobo and Greg, reading your interesting conversation :-) > This was a very thoughtful question. This paragraph (second paragraph of > section 8.1) requires a complete rewrite. Because of the S-BFD UDP port (or > S-BFD Ach if we ever define one), there is no need to punch out local S-BFD > discriminators in the BFD discriminator pool. That also means, if a > classical BFD session or an SBFDInitiator happen to use a same > discriminator value as locally allocated S-BFD discriminators, there is > problem. In other words, as long as received BFD control packets are first > demux'ed into SBFDReflector or (SBFDInitiator or classical BFD), then it's > ok. Not sure I follow this. I think what is required is a MUST clause in the draft that the upper layer provides the information that the packet is a S-BFD packet. The whole idea of separate pools can only work when either these pools have no numerical overlap; then you can use the normal demux based on the discriminator for all BFD packets. Or if the pools have an overlap you need the "hint" from upper layer and S-BFD packets MUST use the S-BFD pool to interpret discriminators. As you mentioned the upper layer information for IP it's the UDP port, for MPLS-ish use it could be some new (G)ACH code point and so on. > The second paragraph of section 8.1 will be replaced with: > > Every SBFDInitiator MUST have a locally unique "my discriminator" > allocated from the BFD discriminator pool. How will your demux logic for an incoming packet then look like? You look into the BFD pool? But this makes sense only for the "pong" packet: your incoming packet is an S-BFD packet, so what happens when the particular router is also a reflector and the BFD pool discriminator value is identical with your entity discriminator - how do I know what to do? >> . Section 8.1.1 may benefit from introduction of terms of "stateful >> initiator" >> and "stateless initiator" when characterizing different behavior of >> SBFDInitiator. > > Good suggestion, will make the changes to this section using that > terminology (and thanks for coming up with good terminology!). I would propose - as already discussed - to move this into an appendix. It's useful information but IMO it's an implementation example and is not relevant to define S-BFD. This is of course based on my assumption that the S-BFD definition is not trying to impose a particular state machine - I don't see why we want to do this if we don't need to do it. Regards, Marc On Fri, 11 Jul 2014 22:08:30 +0000, Nobo Akiya (nobo) wrote: > Hi Greg, > > Many thanks for thoughtful comments! > And my apologies for the delay in response. > > Please see in-line. > >> -----Original Message----- >> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] >> Sent: Wednesday, July 09, 2014 4:40 PM >> To: draft-ietf-bfd-seamless-base@tools.ietf.org >> Cc: rtg-bfd@ietf.org >> Subject: draft-ietf-bfd-seamless-base >> >> Dear Authors, et. al, >> this is great progress, my congratulations to all! > > The authors certainly placed good effort to roll out this -01, but that was > possible largely due to many great comments on/off the list. So thanks and > congratulations to all! > >> Please find my notes and >> editorial nits below: >> . Introduction, second para refers to connectivity testing. I believe that >> BFD >> been used and defined primarily as continuity checking tool though there's >> at least one example of building connectivity verification based on it. I >> think >> that changing from "connectivity test" to "continuity test", throughout the >> document, would make it more accurate. > > True, scanning the document we can do s/connectivity/continuity/ in most > places, and do s/connectivity/reachability/ in couple of places. ACK, in > todo list for the next revision. > >> . s/state changes from DOWN to UP is/state changes from DOWN to UP are | >> state change from DOWN to UP is/; > > Good catch. Will take the first suggested. > >> . Section 4 suggests that both S-BFD Initiator and Responder send S-BFD >> control packets to the same well-known UDP port; > > Oops, let's fix that. Will also update procedures in 8.1.2 and 8.2.1. > > Specifically: > - SBFDInitiator is to set destination port to TBD1. > - SBFDReflector is to swap source/destination ports when copying from ping > to pong. > > Agree? > >> . Section 5, not clear why S-BFD discriminator appears to have different >> uniqueness requirement depending of its use (discriminator collision). I >> think that there should be consistency. There seems to be disagreement >> between the first paragraph and the second that requires AS uniqueness of >> S-BFD discriminators. Or "discriminator collision" is not the same as >> "uniqueness"? > > Right, "internal discriminator collision" is different than "S-BFD > discriminator uniqueness within an administrative domain". > > We need to break up this section into 2 subsections. > > 5. S-BFD Discriminators > > 5.1. Discriminator Pools > > 5.2. S-BFD Discriminator Uniqueness > > And re-thinking about the discriminator pool rules (along with your 2nd > from last comment below), they should be described as: > > o SBFDInitiator is to allocate a discriminator from the BFD > discriminator pool. If the system also supports classical BFD > that runs on [RFC5880], then the BFD discriminator pool MUST be > shared by SBFDInitiators and classical BFD sessions. > > o SBFDReflector is to allocate a discriminator from the S-BFD > discriminator pool. The S-BFD discriminator pool SHOULD be a > separate pool than the BFD discriminator pool. > >> . Section 5, second para discusses mis-connectivity case. True, it easier >> to >> detect with IP data plane then with MPLS, whether IP or ACH encapsulation >> (where PHP is not the only problem but label merge as well). If S-BFD to be >> used as true Connectivity Verification tool, then in all encapsulations >> source >> must be clearly identifiable. For MPLS data plane it could be done with >> help >> of Source MEP-ID TLV as in RFC 6428. Would note that even with strong >> requirement of AS/AD scope of S-BFD discriminator there must be >> mechanism to detect and act upon, e.g. drop or enter mis-connectivity error >> state, "re-use" of discriminators as that likely to pose security threat >> (DDoS). > > A lot depends on how much we (i.e. BFD WG) want to do with S-BFD, and I'd > like us to discuss a bit more on the topics of > advertisements/s-bfd-uniqueness aspects. Rather this is the one of the last > few strings holding down the S-BFD before it can really start flying :) > >> . Section 8.1 suggests, when distinct pools of BFD and S-BFD discriminators >> used, that "My discriminator" must be always allocated from BFD pool. >> Would note that unless BFD and S-BFD pools made explicitly separated >> there's no, IMO, way to determine from which pool particular discriminator >> been allocated from. Thus node's own S-BFD discriminators must be >> punched out in BFD pool to prevent accidentally being allocated as My >> Discriminator. That seems to complicate things and relationship between >> BFD and S-BFD. > > This was a very thoughtful question. This paragraph (second paragraph of > section 8.1) requires a complete rewrite. Because of the S-BFD UDP port (or > S-BFD Ach if we ever define one), there is no need to punch out local S-BFD > discriminators in the BFD discriminator pool. That also means, if a > classical BFD session or an SBFDInitiator happen to use a same > discriminator value as locally allocated S-BFD discriminators, there is > problem. In other words, as long as received BFD control packets are first > demux'ed into SBFDReflector or (SBFDInitiator or classical BFD), then it's > ok. > > The second paragraph of section 8.1 will be replaced with: > > Every SBFDInitiator MUST have a locally unique "my discriminator" > allocated from the BFD discriminator pool. > >> . And to add to the issue of My Discriminator, I don't see anything that >> prevents R2 receiving pings from R1 and R2 in the same md, i.e. R1 and R4 >> allocating the same discriminator from BFD pool to be used as My >> discriminator. Where the pong will go then? In light of this, I'm more in >> favor of nodes advertising discriminator(s) through IGP extensions (or >> being >> centrally allocated) explicitly as their My Discriminator > > I'm not fully convinced that we need to go that length. Today (at least > today), pong is IP routed, thus it can be demux'ed with destination of the > packet (ex: IP address). If you agree, then I can add some texts for this. > >> . And last but not least, it appears that document assumes that S-BFD >> capable node would always have BFD functionality supported. I think that >> not necessarily the case and S-BFD only node must be considered in the >> document. Thus, my question, if there's no BFD and BFD pool of >> discriminators, where from My Discriminator would be allocated for S-BFD? > > Agree, this is addressed as part of 4th comment. > >> . Section 8.1.1 may benefit from introduction of terms of "stateful >> initiator" >> and "stateless initiator" when characterizing different behavior of >> SBFDInitiator. > > Good suggestion, will make the changes to this section using that > terminology (and thanks for coming up with good terminology!). > > Thanks! > > -Nobo > > P.S. Hopefully I can get to your other comments (s-bfd-ip) soon. > >> >> Regards, >> Greg > From nobody Tue Jul 15 15:27:56 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA191A0AA0 for ; Tue, 15 Jul 2014 15:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h74dH_zG6I56 for ; Tue, 15 Jul 2014 15:27:53 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAFA91A011D for ; Tue, 15 Jul 2014 15:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=710; q=dns/txt; s=iport; t=1405463274; x=1406672874; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=UM6q/kWxP/I4JH+hbE2V6sb9hzOeVOAFgNqChGqD9nI=; b=Y/yjfS01luZrBiUw34dAidqqwZO41/KAWiKFJk0Z9dNrSe9bystraETE k8V/v9IF15jgnCRxgBNZxdl7UNse2X89J7cT38uTS/ZINkGsqE6hqLNay UAPZMQNM0Rv/NE5f1r2wrFnYK6mM7ThIuEOmPFdBwqs7ZbCY7LOD4//UP Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FABCqxVOtJV2Z/2dsb2JhbABZgmokUlcEwXWHQgGBDxZ1hAUBBDpRASoUQiYBBBuIOgEMowCnPBMEjmkKBwEfM4MygRYFrz2DRGwBgQIJFyI X-IronPort-AV: E=Sophos;i="5.01,668,1400025600"; d="scan'208";a="340347224" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 15 Jul 2014 22:27:53 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6FMRrDZ012143 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 15 Jul 2014 22:27:53 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Tue, 15 Jul 2014 17:27:52 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: IETF90 BFD WG Presentation Materials Thread-Topic: IETF90 BFD WG Presentation Materials Thread-Index: Ac+ge5mecAI+T5FxSyOYTs0auvNi1w== Date: Tue, 15 Jul 2014 22:27:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/pAuvdw1fAVnw2rHNfxaOp_8F1po X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 22:27:55 -0000 Hello BFDers, All presentation materials for the IETF90 BFD WG session has been uploaded. (except for WG Statuses and Administrivia) https://datatracker.ietf.org/meeting/90/materials.html Please spend some time reviewing the materials so that we can make most of = our [limited] time at the session. Presenters: 1. Thank you for sending the presentation materials on time! 2. If you require _minor_ updates to the presentations materials, please se= nd the chairs the updated version. 3. We do not recommend any major changes to the presentation materials to a= void confusion/double-review/etc. If needed, please an email the chairs to = first discuss. Thanks! -Nobo and Jeff From nobody Tue Jul 15 17:09:45 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4376D1A01D2 for ; Tue, 15 Jul 2014 17:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GusaOt4Pk_VN for ; Tue, 15 Jul 2014 17:09:43 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5BEF1A01D0 for ; Tue, 15 Jul 2014 17:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2799; q=dns/txt; s=iport; t=1405469383; x=1406678983; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=31NeKlYrbJYk6Q1jRaKxzB2mQBZUnG5g+yF/Pjh3muA=; b=kQnGFBAonwJkJOsT9Qa5Z9YqQrIBr2zo3yFNJGWJMr/6BlGfP3SpUEZB 2nTJxrWsHS2hW4IGuAXxOtNaXfCcmv16Z1aku3DUxPXeRWxadTuK6asTD DitDYOTZJubLW3Y44XwK1XTVKMTRlKS4FfXZ1OUdhHFDtLjZcbSzDGowo Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FALrBxVOtJV2Y/2dsb2JhbABZgmokgSkEyTsBgQ8WdYQDAQEBAwE6PwwEAgEIEQQBAQEKCwkJBzIUCQgCBAENBQiIMggByjUXjxoxBwYEgyOBFgEErz2DRGyBRQ X-IronPort-AV: E=Sophos;i="5.01,668,1400025600"; d="scan'208";a="340366090" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 16 Jul 2014 00:09:42 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6G09fDR031799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jul 2014 00:09:42 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Tue, 15 Jul 2014 19:09:41 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , Jeffrey Haas Subject: RE: draft-ietf-bfd-seamless-base Thread-Topic: draft-ietf-bfd-seamless-base Thread-Index: AQHPn39xwilsxFxxA0KhgNbGgGXyz5uhqDsAgAArMfA= Date: Wed, 16 Jul 2014 00:09:41 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7E8E88@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7EC413@eusaamb103.ericsson.se> <20140714161951.GJ19932@pfrc> <7347100B5761DC41A166AC17F22DF1121B7ED494@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7ED494@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.241.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/MbuoSdirjrXR-nc8uQES1tz4C9A Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@tools.ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 00:09:44 -0000 Hi Greg, Jeff, et al, > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Tuesday, July 15, 2014 12:28 PM > To: Jeffrey Haas > Cc: Nobo Akiya (nobo); draft-ietf-bfd-seamless-base@tools.ietf.org; rtg- > bfd@ietf.org > Subject: RE: draft-ietf-bfd-seamless-base >=20 > Hi Jeff, > having additional knob to demux is certainly beneficial. > As for entropy, I tend to think that swapping may not be the best instrum= ent > if our intention is to have both directions of S-BFD traverse the same EC= MP > links. But then swapping is the least state-aware procedure to set UDP p= orts > for a reflected S-BFD control packet. For that, I think, I can accept swa= pping. That's two big votes to push this closer to closure :) As far as same ECMP links go, as much as I wish, I don't think we can achie= ve that even if we preserved same UDP dst/src ports in ping/pong S-BFD pack= ets. IP addresses, dst/src, will be different, and sometimes implementation= s take incoming interface identifier into account. So unfortunately, that w= on't guarantee the trick. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Monday, July 14, 2014 9:20 AM > To: Gregory Mirsky > Cc: Nobo Akiya (nobo); draft-ietf-bfd-seamless-base@tools.ietf.org; rtg- > bfd@ietf.org > Subject: Re: draft-ietf-bfd-seamless-base >=20 > On Sun, Jul 13, 2014 at 05:00:18AM +0000, Gregory Mirsky wrote: > > > . Section 4 suggests that both S-BFD Initiator and Responder send > > > S-BFD control packets to the same well-known UDP port; > > > > Oops, let's fix that. Will also update procedures in 8.1.2 and 8.2.1. > > > > Specifically: > > - SBFDInitiator is to set destination port to TBD1. > > - SBFDReflector is to swap source/destination ports when copying from > ping to pong. > > > > Agree? > > GIM>> By the reference to RFC 5881 Initiator would use dynamic port > number as its Source port. How would that scale? As you probably expected= , > I'd propose to use another well-known UDP port for pong. And the > SBFDReflector then will follow RFC 5881 procedure in setting its UDP sour= ce > port number. >=20 > There are two nice properties for the swap: > - The ability to use UDP port partially for demux. (Yes, you should use > discriminator but sometimes it's nice to get layer 4 to help.) > - Additional entropy for security considerations. Not a *lot* of entropy > but given we're already making discriminator values sticky in at least = one > direction we could use the help. (Security considerations will plague > this feature.) Yes I agree that it does add a bit more security improvements. Thanks! -Nobo >=20 >=20 > -- Jeff From nobody Tue Jul 15 17:47:15 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DC21B27B0 for ; Tue, 15 Jul 2014 17:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sevUL09O-kuj for ; Tue, 15 Jul 2014 17:47:10 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EFBD1B27AA for ; Tue, 15 Jul 2014 17:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6743; q=dns/txt; s=iport; t=1405471630; x=1406681230; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4kB8MqXN5IayTkdyNkvPu+akRVAXm04unmNhxVxih5s=; b=KMEnisgTIB4G2ChFd+BsKwc93i1W9P+qmJYX3xRYjnW6pEaX70jLnei5 qJ5j1yExCofCAuIUPQbJVlKAwoqmH8Dw0PlBJWW/KVueuVJOst987O8/h 7kTXFC/Dci0qYC4457l5YZbafvlwixwSGbMJKvuR4BmBxkPogSGfy+1D2 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAKXKxVOtJV2U/2dsb2JhbABPCoJqJFJXBMF5h0IBgRAWdYQDAQEBAwE6PwwEAgEIEQQBAQEKFAkHMhQJCAIEAQ0FCAGIMQgBDMogF45vKzEHBoMngRYFln2YQINEbAGBRA X-IronPort-AV: E=Sophos;i="5.01,668,1400025600"; d="scan'208";a="61158494" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP; 16 Jul 2014 00:47:09 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6G0l983011227 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jul 2014 00:47:09 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 15 Jul 2014 19:47:08 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger , Jeffrey Haas , "Gregory Mirsky" Subject: RE: draft-ietf-bfd-seamless-base Thread-Topic: draft-ietf-bfd-seamless-base Thread-Index: AQHPn39xwilsxFxxA0KhgNbGgGXyz5uhvukAgAALlJA= Date: Wed, 16 Jul 2014 00:47:07 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7E8E88@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7EC413@eusaamb103.ericsson.se> <20140714161951.GJ19932@pfrc> <20140715104854507112.18a7cf2e@sniff.de> In-Reply-To: <20140715104854507112.18a7cf2e@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.241.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/DoJtY4M30cDLUauOy_nV30UFyEI Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@tools.ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 00:47:13 -0000 Hi Marc, > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Tuesday, July 15, 2014 1:49 PM > To: Jeffrey Haas; Gregory Mirsky; Nobo Akiya (nobo) > Cc: draft-ietf-bfd-seamless-base@tools.ietf.org; rtg-bfd@ietf.org > Subject: Re: draft-ietf-bfd-seamless-base >=20 > Hello everyone, >=20 > bit behind with reading I found this ... >=20 > >> . Section 4 suggests that both S-BFD Initiator and Responder send > >> S-BFD control packets to the same well-known UDP port; > > > > Oops, let's fix that. Will also update procedures in 8.1.2 and 8.2.1. > > > > Specifically: > > - SBFDInitiator is to set destination port to TBD1. > > - SBFDReflector is to swap source/destination ports when copying from > > ping to pong. > > > > Agree? >=20 > Do I understand this right: initiator sends with S-BFD dst-port 7784 (not > assigned yet) and src-port 50000 and you want to send the "pong" with dst= - > port 50000 and src-port 7784 ? Correct, at least that's the proposals on the table. >=20 > Why? Using the well-know S-BFD UDP port as destination port for all S-BFD > packets seems straight forward. Why would my receiver logic need an > additional clause "if the source-port is the S-BFD port" ? To explain this reason, we need to start with S-BFD discriminators for SBFD= Reflector sessions. We _want_ to be able to preserve the ability to be flexible with the S-BFD = discriminator values we allocate for local entities. To achieve this, S-BFD= base document will describe following two rules in the next revision (than= k Greg for solidifying this). This document defines following rules for discriminator management on SBFDInitiator and SBFDReflector sessions, to minimize the collision between required S-BFD discriminators on a local device. o SBFDInitiator is to allocate a discriminator from the BFD discriminator pool. If the system also supports classical BFD that runs on [RFC5880], then the BFD discriminator pool MUST be shared by SBFDInitiator sessions and classical BFD sessions. o SBFDReflector is to allocate a discriminator from the S-BFD discriminator pool. The S-BFD discriminator pool SHOULD be a separate pool than the BFD discriminator pool. If we were to do this with a single discriminator pool, then we lose the fl= exibility to allocate various S-BFD discriminator values for local entities= as many values may already being used by SBFDInitiator sessions and classi= cal BFD sessions. So two discriminator tables. Now, in order to look up the correct session object, we need to first ident= ify whether an incoming S-BFD packet is for SBFDReflector sessions or other= BFD sessions (i.e. SBFDInitiator sessions and classical BFD sessions) so t= hat correct discriminator table can be accessed with "your discriminator". If S-BFD packets from both SBFDInitiator and SBFDReflector had destination = port of 7784, then we will not be able to determine which discriminator tab= le to look up. Hence the UDP port swap by SBFDReflector sessions. Alternati= ve is to allocate well-known UDP port in one direction (i.e. SBFDInitiator = to SBFDReflector) and different well-known UDP port in the other direction = (i.e. SBFDReflector to SBFDInitiator). >=20 > Plus: another IP-ish detail I would argue to keep out of the base draft. = It's > just obfuscating the core aspects of S-BFD, IMHO. I'm willing to re-structure S-BFD document if WG consensus points that way = :) Please take a look at two possible document structures. http://www.ietf.org/proceedings/90/slides/slides-90-bfd-2.pptx As for IP-less, we could have [new] S-BFD associated channel type in one di= rection, and reuse [existing] BFD associated channel type in the other dire= ction. That will also achieve differentiating of SBFDReflector sessions and= other BFD sessions. Thanks! - Nobo >=20 >=20 > > There are two nice properties for the swap: > > - The ability to use UDP port partially for demux. (Yes, you should us= e > > discriminator but sometimes it's nice to get layer 4 to help.) >=20 > maybe but again this is "IP heavy" for a base draft. These details maybe = all > worthwhile but should be in the IP-specific draft. >=20 >=20 > > - Additional entropy for security considerations. Not a *lot* of entro= py > > but given we're already making discriminator values sticky in at leas= t one > > direction we could use the help. (Security considerations will plagu= e > > this feature.) >=20 > you could use the UDP src port for the entropy, e.g. for filtering. "I se= nt > out with src-port X and will only accept a packet with src-port X" >=20 >=20 > Apropos security, taking the "real thing" aside and using proper > authentication (*), ever thought about using the echo field as a "nonce" > similar to what LISP is doing? You send out the packet with a random 32b= it > nonce and accept the pong only when the nonce is what you have sent out. > For hardware implementation of the filtering you could keep the nonce > fixed > for N seconds. >=20 > (*: problem is if the hardware supports the authentication, otherwise it = just > adds more load on the software plane) >=20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 > On Mon, 14 Jul 2014 12:19:51 -0400, Jeffrey Haas wrote: > > On Sun, Jul 13, 2014 at 05:00:18AM +0000, Gregory Mirsky wrote: > >>> . Section 4 suggests that both S-BFD Initiator and Responder send > >>> S-BFD control packets to the same well-known UDP port; > >> > >> Oops, let's fix that. Will also update procedures in 8.1.2 and 8.2.1. > >> > >> Specifically: > >> - SBFDInitiator is to set destination port to TBD1. > >> - SBFDReflector is to swap source/destination ports when copying from > ping > >> to pong. > >> > >> Agree? > >> GIM>> By the reference to RFC 5881 Initiator would use dynamic port > number > >> as its Source port. How would that scale? As you probably expected, I'= d > >> propose to use another well-known UDP port for pong. And the > SBFDReflector > >> then will follow RFC 5881 procedure in setting its UDP source port > number. > > > > There are two nice properties for the swap: > > - The ability to use UDP port partially for demux. (Yes, you should us= e > > discriminator but sometimes it's nice to get layer 4 to help.) > > - Additional entropy for security considerations. Not a *lot* of entro= py > > but given we're already making discriminator values sticky in at leas= t one > > direction we could use the help. (Security considerations will plagu= e > > this feature.) > > > > > > -- Jeff > > From nobody Tue Jul 15 17:57:10 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCB01B29D2 for ; Tue, 15 Jul 2014 17:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.552 X-Spam-Level: X-Spam-Status: No, score=-114.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTnlA8NP3686 for ; Tue, 15 Jul 2014 17:57:03 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C9911B29CC for ; Tue, 15 Jul 2014 17:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11163; q=dns/txt; s=iport; t=1405472223; x=1406681823; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Qh4hMqVd+ivVcmZFUjivZ/zjWhyuU+XknJz2X3Yejpg=; b=KLtYJ8KQgkLPZ/Tww+c6EGUrmZ88dFEkuyXulBwHLGWXHMgaZ3kQolRD fQjHTVOORsdtW8Qow+MrbZN0fx6dMLkN/s0qY2LKE5DDH8UyNdolGaxGB zCzVbUcD42gt9HT6iB4kY27HBDFG9sWsykK3eBpCygmm79WhJiGYK2HCw k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAL7MxVOtJV2Q/2dsb2JhbABZgmokUlcEwXmHQgGBEBZ1hAMBAQEDATo4BwwEAgEIEQQBAQEKFAkHMhQJCAEBBAENBQgBiDEIAQzKIheOaREBHw8iBwaDJ4EWBa89g0RsAYELOQ X-IronPort-AV: E=Sophos;i="5.01,668,1400025600"; d="scan'208";a="340307757" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP; 16 Jul 2014 00:57:02 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6G0v2Gm003550 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jul 2014 00:57:02 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Tue, 15 Jul 2014 19:57:02 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger , Gregory Mirsky Subject: RE: draft-ietf-bfd-seamless-base Thread-Topic: draft-ietf-bfd-seamless-base Thread-Index: Ac+bm6XqGsvLHk/VStWUJNiaXNCUoABdOb7gAN3z+oAAAHIMYA== Date: Wed, 16 Jul 2014 00:57:01 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7E8E88@eusaamb103.ericsson.se> <20140715115615035533.a44f4115@sniff.de> In-Reply-To: <20140715115615035533.a44f4115@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.241.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/kgnExhgtLO1GETqgme6mqxdcPNs Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@tools.ietf.org" , "Marc Binderberger \(mbinderb\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 00:57:06 -0000 Hi again Marc, > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Tuesday, July 15, 2014 2:56 PM > To: Nobo Akiya (nobo); Gregory Mirsky > Cc: draft-ietf-bfd-seamless-base@tools.ietf.org; rtg-bfd@ietf.org; Marc > Binderberger (mbinderb) > Subject: RE: draft-ietf-bfd-seamless-base >=20 > Hello Nobo and Greg, >=20 > reading your interesting conversation :-) >=20 > > This was a very thoughtful question. This paragraph (second paragraph > > of section 8.1) requires a complete rewrite. Because of the S-BFD UDP > > port (or S-BFD Ach if we ever define one), there is no need to punch > > out local S-BFD discriminators in the BFD discriminator pool. That > > also means, if a classical BFD session or an SBFDInitiator happen to > > use a same discriminator value as locally allocated S-BFD > > discriminators, there is problem. In other words, as long as received > > BFD control packets are first demux'ed into SBFDReflector or > > (SBFDInitiator or classical BFD), then it's ok. >=20 > Not sure I follow this. >=20 > I think what is required is a MUST clause in the draft that the upper lay= er > provides the information that the packet is a S-BFD packet. The whole ide= a > of separate pools can only work when either these pools have no numerical > overlap; then you can use the normal demux based on the discriminator for > all BFD packets. Or if the pools have an overlap you need the "hint" from > upper layer and S-BFD packets MUST use the S-BFD pool to interpret > discriminators. >=20 > As you mentioned the upper layer information for IP it's the UDP port, fo= r > MPLS-ish use it could be some new (G)ACH code point and so on. >=20 Correct. Please see my response in the other email. >=20 > > The second paragraph of section 8.1 will be replaced with: > > > > Every SBFDInitiator MUST have a locally unique "my discriminator" > > allocated from the BFD discriminator pool. >=20 > How will your demux logic for an incoming packet then look like? You look > into the BFD pool? But this makes sense only for the "pong" packet: your > incoming packet is an S-BFD packet, so what happens when the particular > router is also a reflector and the BFD pool discriminator value is identi= cal > with your entity discriminator - how do I know what to do? Exactly, hence we need to demux first between S-BFD discriminator pool look= up vs. BFD discriminator pool lookup. >=20 >=20 > >> . Section 8.1.1 may benefit from introduction of terms of "stateful > >> initiator" > >> and "stateless initiator" when characterizing different behavior of > >> SBFDInitiator. > > > > Good suggestion, will make the changes to this section using that > > terminology (and thanks for coming up with good terminology!). >=20 > I would propose - as already discussed - to move this into an appendix. I= t's > useful information but IMO it's an implementation example and is not > relevant > to define S-BFD. >=20 > This is of course based on my assumption that the S-BFD definition is not > trying to impose a particular state machine - I don't see why we want to = do > this if we don't need to do it. What state is set by SBFDReflector in sending S-BFD packets is one of the t= opics in the S-BFD update at Toronto. http://www.ietf.org/proceedings/90/slides/slides-90-bfd-2.pptx Once there's a consensus on the behavior, then we can update the document a= ccordingly. Thanks! -Nobo >=20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 > On Fri, 11 Jul 2014 22:08:30 +0000, Nobo Akiya (nobo) wrote: > > Hi Greg, > > > > Many thanks for thoughtful comments! > > And my apologies for the delay in response. > > > > Please see in-line. > > > >> -----Original Message----- > >> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > >> Sent: Wednesday, July 09, 2014 4:40 PM > >> To: draft-ietf-bfd-seamless-base@tools.ietf.org > >> Cc: rtg-bfd@ietf.org > >> Subject: draft-ietf-bfd-seamless-base > >> > >> Dear Authors, et. al, > >> this is great progress, my congratulations to all! > > > > The authors certainly placed good effort to roll out this -01, but that= was > > possible largely due to many great comments on/off the list. So thanks > and > > congratulations to all! > > > >> Please find my notes and > >> editorial nits below: > >> . Introduction, second para refers to connectivity testing. I believe = that > >> BFD > >> been used and defined primarily as continuity checking tool though > there's > >> at least one example of building connectivity verification based on it= . I > >> think > >> that changing from "connectivity test" to "continuity test", throughou= t > the > >> document, would make it more accurate. > > > > True, scanning the document we can do s/connectivity/continuity/ in mos= t > > places, and do s/connectivity/reachability/ in couple of places. ACK, i= n > > todo list for the next revision. > > > >> . s/state changes from DOWN to UP is/state changes from DOWN to UP > are | > >> state change from DOWN to UP is/; > > > > Good catch. Will take the first suggested. > > > >> . Section 4 suggests that both S-BFD Initiator and Responder send S-BF= D > >> control packets to the same well-known UDP port; > > > > Oops, let's fix that. Will also update procedures in 8.1.2 and 8.2.1. > > > > Specifically: > > - SBFDInitiator is to set destination port to TBD1. > > - SBFDReflector is to swap source/destination ports when copying from > ping > > to pong. > > > > Agree? > > > >> . Section 5, not clear why S-BFD discriminator appears to have differe= nt > >> uniqueness requirement depending of its use (discriminator collision).= I > >> think that there should be consistency. There seems to be disagreement > >> between the first paragraph and the second that requires AS uniqueness > of > >> S-BFD discriminators. Or "discriminator collision" is not the same as > >> "uniqueness"? > > > > Right, "internal discriminator collision" is different than "S-BFD > > discriminator uniqueness within an administrative domain". > > > > We need to break up this section into 2 subsections. > > > > 5. S-BFD Discriminators > > > > 5.1. Discriminator Pools > > > > 5.2. S-BFD Discriminator Uniqueness > > > > And re-thinking about the discriminator pool rules (along with your 2nd > > from last comment below), they should be described as: > > > > o SBFDInitiator is to allocate a discriminator from the BFD > > discriminator pool. If the system also supports classical BFD > > that runs on [RFC5880], then the BFD discriminator pool MUST be > > shared by SBFDInitiators and classical BFD sessions. > > > > o SBFDReflector is to allocate a discriminator from the S-BFD > > discriminator pool. The S-BFD discriminator pool SHOULD be a > > separate pool than the BFD discriminator pool. > > > >> . Section 5, second para discusses mis-connectivity case. True, it eas= ier > >> to > >> detect with IP data plane then with MPLS, whether IP or ACH > encapsulation > >> (where PHP is not the only problem but label merge as well). If S-BFD = to > be > >> used as true Connectivity Verification tool, then in all encapsulation= s > >> source > >> must be clearly identifiable. For MPLS data plane it could be done wit= h > >> help > >> of Source MEP-ID TLV as in RFC 6428. Would note that even with strong > >> requirement of AS/AD scope of S-BFD discriminator there must be > >> mechanism to detect and act upon, e.g. drop or enter mis-connectivity > error > >> state, "re-use" of discriminators as that likely to pose security thre= at > >> (DDoS). > > > > A lot depends on how much we (i.e. BFD WG) want to do with S-BFD, and > I'd > > like us to discuss a bit more on the topics of > > advertisements/s-bfd-uniqueness aspects. Rather this is the one of the > last > > few strings holding down the S-BFD before it can really start flying :) > > > >> . Section 8.1 suggests, when distinct pools of BFD and S-BFD > discriminators > >> used, that "My discriminator" must be always allocated from BFD pool. > >> Would note that unless BFD and S-BFD pools made explicitly separated > >> there's no, IMO, way to determine from which pool particular > discriminator > >> been allocated from. Thus node's own S-BFD discriminators must be > >> punched out in BFD pool to prevent accidentally being allocated as My > >> Discriminator. That seems to complicate things and relationship betwee= n > >> BFD and S-BFD. > > > > This was a very thoughtful question. This paragraph (second paragraph o= f > > section 8.1) requires a complete rewrite. Because of the S-BFD UDP port > (or > > S-BFD Ach if we ever define one), there is no need to punch out local S= - > BFD > > discriminators in the BFD discriminator pool. That also means, if a > > classical BFD session or an SBFDInitiator happen to use a same > > discriminator value as locally allocated S-BFD discriminators, there is > > problem. In other words, as long as received BFD control packets are fi= rst > > demux'ed into SBFDReflector or (SBFDInitiator or classical BFD), then i= t's > > ok. > > > > The second paragraph of section 8.1 will be replaced with: > > > > Every SBFDInitiator MUST have a locally unique "my discriminator" > > allocated from the BFD discriminator pool. > > > >> . And to add to the issue of My Discriminator, I don't see anything th= at > >> prevents R2 receiving pings from R1 and R2 in the same md, i.e. R1 and= R4 > >> allocating the same discriminator from BFD pool to be used as My > >> discriminator. Where the pong will go then? In light of this, I'm more= in > >> favor of nodes advertising discriminator(s) through IGP extensions (or > >> being > >> centrally allocated) explicitly as their My Discriminator > > > > I'm not fully convinced that we need to go that length. Today (at least > > today), pong is IP routed, thus it can be demux'ed with destination of = the > > packet (ex: IP address). If you agree, then I can add some texts for th= is. > > > >> . And last but not least, it appears that document assumes that S-BFD > >> capable node would always have BFD functionality supported. I think th= at > >> not necessarily the case and S-BFD only node must be considered in the > >> document. Thus, my question, if there's no BFD and BFD pool of > >> discriminators, where from My Discriminator would be allocated for S- > BFD? > > > > Agree, this is addressed as part of 4th comment. > > > >> . Section 8.1.1 may benefit from introduction of terms of "stateful > >> initiator" > >> and "stateless initiator" when characterizing different behavior of > >> SBFDInitiator. > > > > Good suggestion, will make the changes to this section using that > > terminology (and thanks for coming up with good terminology!). > > > > Thanks! > > > > -Nobo > > > > P.S. Hopefully I can get to your other comments (s-bfd-ip) soon. > > > >> > >> Regards, > >> Greg > > From nobody Tue Jul 15 19:47:21 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A851B2A20 for ; Tue, 15 Jul 2014 19:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sy5qurzgfz0o for ; Tue, 15 Jul 2014 19:47:15 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 896031B2A17 for ; Tue, 15 Jul 2014 19:47:14 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id C2F9A2AA0F; Wed, 16 Jul 2014 02:47:10 +0000 (GMT) Date: Tue, 15 Jul 2014 19:47:30 -0700 From: Marc Binderberger To: Nobo Akiya (nobo) Message-ID: <20140715194730645130.736cbc95@sniff.de> In-Reply-To: References: <7347100B5761DC41A166AC17F22DF1121B7E8E88@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7EC413@eusaamb103.ericsson.se> <20140714161951.GJ19932@pfrc> <20140715104854507112.18a7cf2e@sniff.de> Subject: RE: draft-ietf-bfd-seamless-base MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/5kUgfAtz7zowLol3pL7AMVw7xng Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@tools.ietf.org" , "Marc Binderberger \(mbinderb\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 02:47:18 -0000 Hello Nobo, ah, thanks for the explanation! Makes sense. But I disagree (surprise!). Maybe it's just me :-) Anyway, it brings up several aspects that are probably important for the design: * the discriminator pools. Do we really need two pools and the complexity that comes with them? The new pool should help to reduce collisions. But it cannot prevent them, so collisions need to be addressed anyway. I do see the advantage by reducing collisions to the S-BFD domain as we have the chance to define collision resolution as a requirement, something we cannot do for all 588x anymore (or maybe we can?). Still we should re-think if all the complexity of a new pool is worth it. * if we go with a separate pool, does it then makes sense to "muddy the water" and mix it with the existing BFD pool on the Initiator side? Would a ships-in-the-night S-BFD not more favorable where everything of S-BFD is separated from 588x-BFD, including the pool? Would be a simple design guideline. You mention > We _want_ to be able to preserve the ability to be flexible with the S-BFD > discriminator values we allocate for local entities. have to ask: why? With flexible you mean the choice between BFD pool and S-BFD pool for the my-discriminator for a system that has the S-BFD pool implemented? What does this flexibility buy you? The draft being flexible for an implementor to use a shared pool (exclusive-)or to implement two separate and potentially overlapping pools - okay. I think your draft allows already both and it's a local matter, not affecting interop. (Yes, we do talk about separate things ;-) as I mean "separate pool" strictly separated. You have to extend your lookup with the "hint" from lower layer (IP, MPLS-TP, ...) and the "hint", e.g. the UDP dst-port or ACK for S-BFD, is always used. S-BFD would never use the 588x pool) > As for IP-less, we could have [new] S-BFD associated channel type in one > direction, and reuse [existing] BFD associated channel type in the other > direction. That will also achieve differentiating of SBFDReflector sessions > and other BFD sessions. I was wondering about this :-) So for IP/UDP we design the S-BFD base draft with the help of this additional degree of freedom that we can swap source and destination port but still know it's BFD (because the src-port is S-BFD port). For IP-less we reuse the existing ACH. The IP/UDP equivalent we should discuss then is using 3784 or 4784 as dst-port for the reflected packet. Which technically should be do-able but it also opens the discussion (again) if RFC 588x allows this or that. Personally I think mixing 588x-BFD with S-BFD is a burden unless you go to the extremes, which keeps is fairly clean: one pool, lookup as it exists already. Or two pools, strictly separated by the UDP/ACH hint of 588x-BFD vs S-BFD. S-BFD port as UDP dst-port in all cases for S-BFD packets, both Initiator and Reflector. > Please take a look at two possible document structures. > > http://www.ietf.org/proceedings/90/slides/slides-90-bfd-2.pptx Hey, you have been quite active it seems ;-) Thanks for the slides, I'll give them a look this evening. Thanks & Regards, Marc On Wed, 16 Jul 2014 00:47:07 +0000, Nobo Akiya (nobo) wrote: > Hi Marc, > >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de] >> Sent: Tuesday, July 15, 2014 1:49 PM >> To: Jeffrey Haas; Gregory Mirsky; Nobo Akiya (nobo) >> Cc: draft-ietf-bfd-seamless-base@tools.ietf.org; rtg-bfd@ietf.org >> Subject: Re: draft-ietf-bfd-seamless-base >> >> Hello everyone, >> >> bit behind with reading I found this ... >> >>>> . Section 4 suggests that both S-BFD Initiator and Responder send >>>> S-BFD control packets to the same well-known UDP port; >>> >>> Oops, let's fix that. Will also update procedures in 8.1.2 and 8.2.1. >>> >>> Specifically: >>> - SBFDInitiator is to set destination port to TBD1. >>> - SBFDReflector is to swap source/destination ports when copying from >>> ping to pong. >>> >>> Agree? >> >> Do I understand this right: initiator sends with S-BFD dst-port 7784 (not >> assigned yet) and src-port 50000 and you want to send the "pong" with dst- >> port 50000 and src-port 7784 ? > > Correct, at least that's the proposals on the table. > >> >> Why? Using the well-know S-BFD UDP port as destination port for all S-BFD >> packets seems straight forward. Why would my receiver logic need an >> additional clause "if the source-port is the S-BFD port" ? > > To explain this reason, we need to start with S-BFD discriminators for > SBFDReflector sessions. > > We _want_ to be able to preserve the ability to be flexible with the S-BFD > discriminator values we allocate for local entities. To achieve this, S-BFD > base document will describe following two rules in the next revision (thank > Greg for solidifying this). > > This document defines following rules for discriminator management on > SBFDInitiator and SBFDReflector sessions, to minimize the collision > between required S-BFD discriminators on a local device. > > o SBFDInitiator is to allocate a discriminator from the BFD > discriminator pool. If the system also supports classical BFD > that runs on [RFC5880], then the BFD discriminator pool MUST be > shared by SBFDInitiator sessions and classical BFD sessions. > > o SBFDReflector is to allocate a discriminator from the S-BFD > discriminator pool. The S-BFD discriminator pool SHOULD be a > separate pool than the BFD discriminator pool. > > If we were to do this with a single discriminator pool, then we lose the > flexibility to allocate various S-BFD discriminator values for local > entities as many values may already being used by SBFDInitiator sessions > and classical BFD sessions. So two discriminator tables. > > Now, in order to look up the correct session object, we need to first > identify whether an incoming S-BFD packet is for SBFDReflector sessions or > other BFD sessions (i.e. SBFDInitiator sessions and classical BFD sessions) > so that correct discriminator table can be accessed with "your > discriminator". > > If S-BFD packets from both SBFDInitiator and SBFDReflector had destination > port of 7784, then we will not be able to determine which discriminator > table to look up. Hence the UDP port swap by SBFDReflector sessions. > Alternative is to allocate well-known UDP port in one direction (i.e. > SBFDInitiator to SBFDReflector) and different well-known UDP port in the > other direction (i.e. SBFDReflector to SBFDInitiator). > >> >> Plus: another IP-ish detail I would argue to keep out of the base draft. >> It's >> just obfuscating the core aspects of S-BFD, IMHO. > > I'm willing to re-structure S-BFD document if WG consensus points that way > :) > > Please take a look at two possible document structures. > > http://www.ietf.org/proceedings/90/slides/slides-90-bfd-2.pptx > > As for IP-less, we could have [new] S-BFD associated channel type in one > direction, and reuse [existing] BFD associated channel type in the other > direction. That will also achieve differentiating of SBFDReflector sessions > and other BFD sessions. > > Thanks! > > - Nobo > >> >> >>> There are two nice properties for the swap: >>> - The ability to use UDP port partially for demux. (Yes, you should use >>> discriminator but sometimes it's nice to get layer 4 to help.) >> >> maybe but again this is "IP heavy" for a base draft. These details maybe >> all >> worthwhile but should be in the IP-specific draft. >> >> >>> - Additional entropy for security considerations. Not a *lot* of entropy >>> but given we're already making discriminator values sticky in at least >>> one >>> direction we could use the help. (Security considerations will plague >>> this feature.) >> >> you could use the UDP src port for the entropy, e.g. for filtering. "I sent >> out with src-port X and will only accept a packet with src-port X" >> >> >> Apropos security, taking the "real thing" aside and using proper >> authentication (*), ever thought about using the echo field as a "nonce" >> similar to what LISP is doing? You send out the packet with a random 32bit >> nonce and accept the pong only when the nonce is what you have sent out. >> For hardware implementation of the filtering you could keep the nonce >> fixed >> for N seconds. >> >> (*: problem is if the hardware supports the authentication, otherwise it >> just >> adds more load on the software plane) >> >> >> Regards, Marc >> >> >> >> >> On Mon, 14 Jul 2014 12:19:51 -0400, Jeffrey Haas wrote: >>> On Sun, Jul 13, 2014 at 05:00:18AM +0000, Gregory Mirsky wrote: >>>>> . Section 4 suggests that both S-BFD Initiator and Responder send >>>>> S-BFD control packets to the same well-known UDP port; >>>> >>>> Oops, let's fix that. Will also update procedures in 8.1.2 and 8.2.1. >>>> >>>> Specifically: >>>> - SBFDInitiator is to set destination port to TBD1. >>>> - SBFDReflector is to swap source/destination ports when copying from >> ping >>>> to pong. >>>> >>>> Agree? >>>> GIM>> By the reference to RFC 5881 Initiator would use dynamic port >> number >>>> as its Source port. How would that scale? As you probably expected, I'd >>>> propose to use another well-known UDP port for pong. And the >> SBFDReflector >>>> then will follow RFC 5881 procedure in setting its UDP source port >> number. >>> >>> There are two nice properties for the swap: >>> - The ability to use UDP port partially for demux. (Yes, you should use >>> discriminator but sometimes it's nice to get layer 4 to help.) >>> - Additional entropy for security considerations. Not a *lot* of entropy >>> but given we're already making discriminator values sticky in at least >>> one >>> direction we could use the help. (Security considerations will plague >>> this feature.) >>> >>> >>> -- Jeff >>> > From nobody Wed Jul 16 11:04:48 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2191A0163 for ; Wed, 16 Jul 2014 11:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbtG-tjeFD0h for ; Wed, 16 Jul 2014 11:04:45 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 864AA1A015F for ; Wed, 16 Jul 2014 11:04:45 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 000BAC27E; Wed, 16 Jul 2014 14:04:44 -0400 (EDT) Date: Wed, 16 Jul 2014 14:04:44 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: WGLC concluded for draft-ietf-bfd-intervals Message-ID: <20140716180444.GL25188@pfrc> References: <20140630163846.GA11842@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140630163846.GA11842@pfrc> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/MPz8FC7j6CLXVRpsmwMnEntZNA4 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 18:04:47 -0000 On Mon, Jun 30, 2014 at 12:38:46PM -0400, Jeffrey Haas wrote: > We would like to initiate the start of Working Group Last Call for > Common Interval Support in BFD: > > http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 > > Note that the intended status of this document is INFORMATIONAL. > > Please send your comments, including whether you think the draft is ready > for publication or not, to the list no later than July 15. WGLC has concluded. My judgment is that while support from non-authors is somewhat weak, there has been no objection to the draft. Given that the author set also represents multiple vendors and that the status of this Informational draft is to assist in the creation of BFD stacks that are cross-vendor interoperable, I believe this document has sufficient consensus to continue. Marc had one additional clarification regarding the 3.3ms value to be added to the document. Once an I-D has been published containing this information, the document will be submitted to the IESG. -- Jeff From nobody Wed Jul 16 16:20:53 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264771A0393 for ; Wed, 16 Jul 2014 16:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oq9qmm4Xd2GI for ; Wed, 16 Jul 2014 16:20:46 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47FEC1A011D for ; Wed, 16 Jul 2014 16:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12903; q=dns/txt; s=iport; t=1405552846; x=1406762446; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mrHdmfo5p0NnWT3WntQRH3/R+c2vOG8opIlO+l8MzY4=; b=TKm94DT/uokzOqhWv+8d4HxZHXPWIhr97XCmeyDK1Xc2iMUvemtPxKba PjTHq7z2wDk/SzLbO2vFXyBmP5k8b7kt+VU43Si/+01B5kCXC+j/jYfEa inJa+5DG2JtT3oJEtO+laYBfawtr9n16PoEJjGpHYTCJPFnD0kGJ1MgGx c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAIMHx1OtJA2E/2dsb2JhbABPCoJqJFJXBMM0h0IBgQsWdoQDAQEBAwE6PwUHBAIBCBEEAQEBChQJBzIUCQgCBA4FCAGIMQgBDMpFF45vKzEHBoMngRYFlwKYR4NEbAGBRA X-IronPort-AV: E=Sophos;i="5.01,674,1400025600"; d="scan'208";a="61464794" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP; 16 Jul 2014 23:20:45 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6GNKjIv029539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jul 2014 23:20:45 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Wed, 16 Jul 2014 18:20:44 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger Subject: RE: draft-ietf-bfd-seamless-base Thread-Topic: draft-ietf-bfd-seamless-base Thread-Index: AQHPn39xwilsxFxxA0KhgNbGgGXyz5uhvukAgAALlJCAAIroAIAA/Svg Date: Wed, 16 Jul 2014 23:20:44 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7E8E88@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7EC413@eusaamb103.ericsson.se> <20140714161951.GJ19932@pfrc> <20140715104854507112.18a7cf2e@sniff.de> <20140715194730645130.736cbc95@sniff.de> In-Reply-To: <20140715194730645130.736cbc95@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.243.219] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/jqYM1Vfsi-5WuphxT-EoYfwqj3E Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@tools.ietf.org" , "Marc Binderberger \(mbinderb\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 23:20:49 -0000 Hi Marc, > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Tuesday, July 15, 2014 10:48 PM > To: Nobo Akiya (nobo) > Cc: Jeffrey Haas; Gregory Mirsky; draft-ietf-bfd-seamless- > base@tools.ietf.org; rtg-bfd@ietf.org; Marc Binderberger (mbinderb) > Subject: RE: draft-ietf-bfd-seamless-base >=20 > Hello Nobo, >=20 > ah, thanks for the explanation! Makes sense. But I disagree (surprise!). > Maybe it's just me :-) Haha. Well, everyone's views are important to steer where we going to conve= rge to, so let's continue :) >=20 >=20 > Anyway, it brings up several aspects that are probably important for the > design: >=20 > * the discriminator pools. Do we really need two pools and the complexity > that comes with them? >=20 > The new pool should help to reduce collisions. But it cannot prevent them= , > so collisions need to be addressed anyway. I do see the advantage by > reducing collisions to the S-BFD domain as we have the chance to define > collision resolution as a requirement, something we cannot do for all 588= x > anymore (or maybe we can?). Still we should re-think if all the complexit= y > of a new pool is worth it. Personally I think separate discriminator pool is strongly desired and is w= orth it. (1) Collision between S-BFD discriminators and (2) collision between S-BFD = and other BFD sessions can be two different things. More complexity will come from needing to handle (2). Additionally, you and me have discussed a possibility of reserving some S-B= FD discriminator values. That would be another reason why separate discriminator pool is worth the e= ffort. >=20 > * if we go with a separate pool, does it then makes sense to "muddy the > water" and mix it with the existing BFD pool on the Initiator side? Would= a > ships-in-the-night S-BFD not more favorable where everything of S-BFD is > separated from 588x-BFD, including the pool? Would be a simple design > guideline. The way I see this: - BFD discriminator pool is for all sessions that can be assigned an arbitr= ary discriminator. - S-BFD discriminator pool is for all sessions that may have rules on how d= iscriminator value is derived. So placing SBFDInitiator sessions in the BFD discriminator pool along with = classical sessions make sense me. >=20 >=20 > You mention >=20 > > We _want_ to be able to preserve the ability to be flexible with the > > S-BFD discriminator values we allocate for local entities. >=20 > have to ask: why? With flexible you mean the choice between BFD pool and > S-BFD pool for the my-discriminator for a system that has the S-BFD pool > implemented? What does this flexibility buy you? >=20 > The draft being flexible for an implementor to use a shared pool (exclusi= ve- > )or to implement two separate and potentially overlapping pools - okay. I > think your draft allows already both and it's a local matter, not affecti= ng > interop. By "flexibility" I mean flexibility to use attribute Foobar of the local en= tity to derive the discriminator value to reserve in the S-BFD discriminato= r pool. For example, Router-ID is used to derive the discriminator value, and that = is reserved in the S-BFD discriminator pool. >=20 > (Yes, we do talk about separate things ;-) as I mean "separate pool" stri= ctly > separated. You have to extend your lookup with the "hint" from lower laye= r > (IP, MPLS-TP, ...) and the "hint", e.g. the UDP dst-port or ACK for S-BFD= , is > always used. S-BFD would never use the 588x pool) I'm pretty sure you meant ACh and not ACK, yes? If so, then yes that's correct. >=20 >=20 > > As for IP-less, we could have [new] S-BFD associated channel type in > > one direction, and reuse [existing] BFD associated channel type in the > > other direction. That will also achieve differentiating of > > SBFDReflector sessions and other BFD sessions. >=20 > I was wondering about this :-) So for IP/UDP we design the S-BFD base dra= ft > with the help of this additional degree of freedom that we can swap sourc= e > and destination port but still know it's BFD (because the src-port is S-B= FD > port). Yes. > For IP-less we reuse the existing ACH. The IP/UDP equivalent we > should discuss then is using 3784 or 4784 as dst-port for the reflected p= acket. Yes. >=20 > Which technically should be do-able but it also opens the discussion (aga= in) > if RFC 588x allows this or that. >=20 >=20 > Personally I think mixing 588x-BFD with S-BFD is a burden unless you go t= o > the extremes, which keeps is fairly clean: one pool, lookup as it exists > already. Or two pools, strictly separated by the UDP/ACH hint of 588x-BFD= vs > S-BFD. S-BFD port as UDP dst-port in all cases for S-BFD packets, both > Initiator and Reflector. Well, I'm sure if I see it that way. Existing code (i.e. classical BFD) can= remain the same. Implementations need to add code for SBFDInitiator and SB= FDReflector, which, one pool or two, will be fairly similar in terms of cod= e churns required. As for "cleanness", given the definition of discriminato= r pools above, I think it's still clean, but I'm very biased :) Thanks! -Nobo >=20 >=20 > > Please take a look at two possible document structures. > > > > http://www.ietf.org/proceedings/90/slides/slides-90-bfd-2.pptx >=20 > Hey, you have been quite active it seems ;-) > Thanks for the slides, I'll give them a look this evening. >=20 >=20 > Thanks & Regards, > Marc >=20 >=20 >=20 >=20 >=20 > On Wed, 16 Jul 2014 00:47:07 +0000, Nobo Akiya (nobo) wrote: > > Hi Marc, > > > >> -----Original Message----- > >> From: Marc Binderberger [mailto:marc@sniff.de] > >> Sent: Tuesday, July 15, 2014 1:49 PM > >> To: Jeffrey Haas; Gregory Mirsky; Nobo Akiya (nobo) > >> Cc: draft-ietf-bfd-seamless-base@tools.ietf.org; rtg-bfd@ietf.org > >> Subject: Re: draft-ietf-bfd-seamless-base > >> > >> Hello everyone, > >> > >> bit behind with reading I found this ... > >> > >>>> . Section 4 suggests that both S-BFD Initiator and Responder send > >>>> S-BFD control packets to the same well-known UDP port; > >>> > >>> Oops, let's fix that. Will also update procedures in 8.1.2 and 8.2.1. > >>> > >>> Specifically: > >>> - SBFDInitiator is to set destination port to TBD1. > >>> - SBFDReflector is to swap source/destination ports when copying from > >>> ping to pong. > >>> > >>> Agree? > >> > >> Do I understand this right: initiator sends with S-BFD dst-port 7784 (= not > >> assigned yet) and src-port 50000 and you want to send the "pong" with > dst- > >> port 50000 and src-port 7784 ? > > > > Correct, at least that's the proposals on the table. > > > >> > >> Why? Using the well-know S-BFD UDP port as destination port for all S- > BFD > >> packets seems straight forward. Why would my receiver logic need an > >> additional clause "if the source-port is the S-BFD port" ? > > > > To explain this reason, we need to start with S-BFD discriminators for > > SBFDReflector sessions. > > > > We _want_ to be able to preserve the ability to be flexible with the S-= BFD > > discriminator values we allocate for local entities. To achieve this, S= -BFD > > base document will describe following two rules in the next revision > (thank > > Greg for solidifying this). > > > > This document defines following rules for discriminator management o= n > > SBFDInitiator and SBFDReflector sessions, to minimize the collision > > between required S-BFD discriminators on a local device. > > > > o SBFDInitiator is to allocate a discriminator from the BFD > > discriminator pool. If the system also supports classical BFD > > that runs on [RFC5880], then the BFD discriminator pool MUST be > > shared by SBFDInitiator sessions and classical BFD sessions. > > > > o SBFDReflector is to allocate a discriminator from the S-BFD > > discriminator pool. The S-BFD discriminator pool SHOULD be a > > separate pool than the BFD discriminator pool. > > > > If we were to do this with a single discriminator pool, then we lose th= e > > flexibility to allocate various S-BFD discriminator values for local > > entities as many values may already being used by SBFDInitiator session= s > > and classical BFD sessions. So two discriminator tables. > > > > Now, in order to look up the correct session object, we need to first > > identify whether an incoming S-BFD packet is for SBFDReflector sessions > or > > other BFD sessions (i.e. SBFDInitiator sessions and classical BFD sessi= ons) > > so that correct discriminator table can be accessed with "your > > discriminator". > > > > If S-BFD packets from both SBFDInitiator and SBFDReflector had > destination > > port of 7784, then we will not be able to determine which discriminator > > table to look up. Hence the UDP port swap by SBFDReflector sessions. > > Alternative is to allocate well-known UDP port in one direction (i.e. > > SBFDInitiator to SBFDReflector) and different well-known UDP port in th= e > > other direction (i.e. SBFDReflector to SBFDInitiator). > > > >> > >> Plus: another IP-ish detail I would argue to keep out of the base draf= t. > >> It's > >> just obfuscating the core aspects of S-BFD, IMHO. > > > > I'm willing to re-structure S-BFD document if WG consensus points that > way > > :) > > > > Please take a look at two possible document structures. > > > > http://www.ietf.org/proceedings/90/slides/slides-90-bfd-2.pptx > > > > As for IP-less, we could have [new] S-BFD associated channel type in on= e > > direction, and reuse [existing] BFD associated channel type in the othe= r > > direction. That will also achieve differentiating of SBFDReflector sess= ions > > and other BFD sessions. > > > > Thanks! > > > > - Nobo > > > >> > >> > >>> There are two nice properties for the swap: > >>> - The ability to use UDP port partially for demux. (Yes, you should = use > >>> discriminator but sometimes it's nice to get layer 4 to help.) > >> > >> maybe but again this is "IP heavy" for a base draft. These details may= be > >> all > >> worthwhile but should be in the IP-specific draft. > >> > >> > >>> - Additional entropy for security considerations. Not a *lot* of ent= ropy > >>> but given we're already making discriminator values sticky in at le= ast > >>> one > >>> direction we could use the help. (Security considerations will pla= gue > >>> this feature.) > >> > >> you could use the UDP src port for the entropy, e.g. for filtering. "I= sent > >> out with src-port X and will only accept a packet with src-port X" > >> > >> > >> Apropos security, taking the "real thing" aside and using proper > >> authentication (*), ever thought about using the echo field as a "nonc= e" > >> similar to what LISP is doing? You send out the packet with a random > 32bit > >> nonce and accept the pong only when the nonce is what you have sent > out. > >> For hardware implementation of the filtering you could keep the nonce > >> fixed > >> for N seconds. > >> > >> (*: problem is if the hardware supports the authentication, otherwise = it > >> just > >> adds more load on the software plane) > >> > >> > >> Regards, Marc > >> > >> > >> > >> > >> On Mon, 14 Jul 2014 12:19:51 -0400, Jeffrey Haas wrote: > >>> On Sun, Jul 13, 2014 at 05:00:18AM +0000, Gregory Mirsky wrote: > >>>>> . Section 4 suggests that both S-BFD Initiator and Responder send > >>>>> S-BFD control packets to the same well-known UDP port; > >>>> > >>>> Oops, let's fix that. Will also update procedures in 8.1.2 and 8.2.1= . > >>>> > >>>> Specifically: > >>>> - SBFDInitiator is to set destination port to TBD1. > >>>> - SBFDReflector is to swap source/destination ports when copying fro= m > >> ping > >>>> to pong. > >>>> > >>>> Agree? > >>>> GIM>> By the reference to RFC 5881 Initiator would use dynamic port > >> number > >>>> as its Source port. How would that scale? As you probably expected, = I'd > >>>> propose to use another well-known UDP port for pong. And the > >> SBFDReflector > >>>> then will follow RFC 5881 procedure in setting its UDP source port > >> number. > >>> > >>> There are two nice properties for the swap: > >>> - The ability to use UDP port partially for demux. (Yes, you should = use > >>> discriminator but sometimes it's nice to get layer 4 to help.) > >>> - Additional entropy for security considerations. Not a *lot* of ent= ropy > >>> but given we're already making discriminator values sticky in at le= ast > >>> one > >>> direction we could use the help. (Security considerations will pla= gue > >>> this feature.) > >>> > >>> > >>> -- Jeff > >>> > > From nobody Fri Jul 18 07:37:07 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB011B29C6 for ; Fri, 18 Jul 2014 07:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScjyReu83Y1F for ; Fri, 18 Jul 2014 07:37:05 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 88F4B1B29C2 for ; Fri, 18 Jul 2014 07:37:05 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 4A550C243; Fri, 18 Jul 2014 10:37:05 -0400 (EDT) Date: Fri, 18 Jul 2014 10:37:05 -0400 From: Jeffrey Haas To: "Nobo Akiya (nobo)" Subject: Re: draft-ietf-bfd-seamless-base Message-ID: <20140718143705.GW25188@pfrc> References: <7347100B5761DC41A166AC17F22DF1121B7E8E88@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7EC413@eusaamb103.ericsson.se> <20140714161951.GJ19932@pfrc> <20140715104854507112.18a7cf2e@sniff.de> <20140715194730645130.736cbc95@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/1HziL1_EALdWruOCaWp7IsQcuzY Cc: "draft-ietf-bfd-seamless-base@tools.ietf.org" , "rtg-bfd@ietf.org" , "Marc Binderberger \(mbinderb\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 14:37:06 -0000 On Wed, Jul 16, 2014 at 11:20:44PM +0000, Nobo Akiya (nobo) wrote: > Personally I think separate discriminator pool is strongly desired and is worth it. > (1) Collision between S-BFD discriminators and (2) collision between S-BFD and other BFD sessions can be two different things. > More complexity will come from needing to handle (2). But distinguished already via UDP dest port. This is one of those things like how label assignment is done in MPLS that largely should be an implementation detail. I suspect some implementations will do pools, but you need not be able to tell from the outside. The complicating factor, of course, being if you assign your discriminator and your implementation needs unique ones and making sure that you don't have a collision from dynamic discriminator assignment in regular BFD. -- Jeff From nobody Fri Jul 18 09:17:07 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F241B2A0C for ; Fri, 18 Jul 2014 09:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twtxFV67t91y for ; Fri, 18 Jul 2014 09:17:01 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA3B1AC0D2 for ; Fri, 18 Jul 2014 09:16:56 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E9AD8C3F8; Fri, 18 Jul 2014 12:16:55 -0400 (EDT) Date: Fri, 18 Jul 2014 12:16:55 -0400 From: Jeffrey Haas To: "Nobo Akiya (nobo)" Subject: Re: Comments on draft-zhang-bfd-new-use-cases Message-ID: <20140718161655.GX25188@pfrc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/BUzeTT6DurT8Y6n20IgHcTLwOOk Cc: "draft-zhang-bfd-new-use-cases@tools.ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 16:17:02 -0000 On Wed, Jul 09, 2014 at 12:42:16AM +0000, Nobo Akiya (nobo) wrote: > > 3.2. Use Case #2: Application Consistence > > I tend to think that the system should simply take the most aggressive detection time out of all the applications for the same target. Are there any applications that can get negatively impacted by BFD running more aggressive than requested detection time? Most deployed applications that I'm aware of tend to piggy-back multiple users of BFD on the timing requirements of the most aggressive timers. Nothing stops multiple sessions from being used but of course that impacts session scaling. One point that is interesting here can be represented by the following contrived example: A---B A and B have OSPF and BGP between them. OSPF and BGP are configured to use BFD. OSPF's failure requirements are set to 100ms timers with a 3x detection interval. BGP's failure requirements are set to 500ms timers with a 3x detection interval. If both BGP and OSPF rely on OSPF's timers, the OSPF session may drop but may take BGP along with it, despite the fact that BGP is more tolerant. FWIW, I don't see any need to update specs against such a detail. Implementations are free to require separate sessions. The interesting use case is should we permit some way for detections to "fall back" to less granular timings in a pre-negotiated way? -- Jeff From nobody Fri Jul 18 09:20:50 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CFF1B2A24 for ; Fri, 18 Jul 2014 09:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UulZfgoVUTh for ; Fri, 18 Jul 2014 09:20:49 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2950B1A00C9 for ; Fri, 18 Jul 2014 09:20:49 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E1586C3F8; Fri, 18 Jul 2014 12:20:48 -0400 (EDT) Date: Fri, 18 Jul 2014 12:20:48 -0400 From: Jeffrey Haas To: Mahesh Jethanandani Subject: Re: Comments on draft-zhang-bfd-new-use-cases Message-ID: <20140718162048.GY25188@pfrc> References: <4C7782E2-7818-456C-A24E-BB8B0E227B46@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C7782E2-7818-456C-A24E-BB8B0E227B46@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/xfTfaumdqUQVE6R-Tm2lkps3b7Y Cc: "draft-zhang-bfd-new-use-cases@tools.ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 16:20:50 -0000 On Thu, Jul 10, 2014 at 06:31:50AM -0700, Mahesh Jethanandani wrote: > 3.1. Use Case #1: Reliable Detection for Multipath > > Would it make more sense to run BFD on each of the possible paths and report its individual path status to a higher level protocol? So in Figure 3.2, would it make more sense to run 3 BFD sessions between R1 and R4 one on each of the links, each of them reporting their status to its listeners, be it OSPF ECMP, LAG, or MPLS link bundles and letting them decide what is a failure scenario? One of the big challenges in the multipath or LAG scenarios is detecting the various components of the link and exercising the forwarding. In the case of LAG, we went with the simplest scenario (back to back connected links) and expose that information only to the layer managing the LAG. If you want an application BFD session, that is an additional session. Nothing stops the application sessions from being able to make use of that BFD component member state, but most views of the desired behavior is more of an end-to end exercise, much like LSPing. And that's where we run into frustrations. >From an end to end, we can't ensure that a LAG will permit forwarding to be controlled over the underlying layer 3 load balancer. Similarly, we have no way to influence non-LAG multipath link hashing. Obviously this changes when we talk about LSPs and things like entropy labels. -- Jeff From nobody Fri Jul 18 11:26:49 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAF41A0092 for ; Fri, 18 Jul 2014 11:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pyz6UjzCZXzm for ; Fri, 18 Jul 2014 11:26:46 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907191A0049 for ; Fri, 18 Jul 2014 11:26:46 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id m20so3760401qcx.0 for ; Fri, 18 Jul 2014 11:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eCR5GT2ST5XqxC6+WqVpcdzSTV7qgRrwY97Cn8r/zKM=; b=jJzOiHn0bjFIwsYXan7DMm0Mja7Mk8VHyAffEcTEP2XmQNE9kh3P02y3eTh6cw3vOg 7W7bNPk/S+u4LFn0OBi7MVCURX40et4fqa8S7+BGR6lRlA60uEIn1P9wLkd18hfUh2T9 l6xd5RiSQ4zixByT4RvXPeF83mhklZJxaHW3pfgVQvCyrhJ71ZNbXEarK70nvWfthtoh 3W/cuXOiGdvR2abGZ8iExCCgR+srkrNtOU5srMuYIQqY8FvDqE00cg9NUbOjgMsCwcLz 0LVr+S/IlUTQqwxD3AfVQHv/YHM2A9XcrNcnG9yD9+Q4GRZBVyYBT8KfKVttFtXdZ9yM Vs7Q== X-Received: by 10.224.123.8 with SMTP id n8mr11465369qar.40.1405708005612; Fri, 18 Jul 2014 11:26:45 -0700 (PDT) Received: from [192.168.1.101] (108-247-124-220.lightspeed.sntcca.sbcglobal.net. [108.247.124.220]) by mx.google.com with ESMTPSA id s2sm11107331qah.13.2014.07.18.11.26.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jul 2014 11:26:45 -0700 (PDT) Subject: Re: Comments on draft-zhang-bfd-new-use-cases Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Mahesh Jethanandani In-Reply-To: <20140718162048.GY25188@pfrc> Date: Fri, 18 Jul 2014 11:26:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C7782E2-7818-456C-A24E-BB8B0E227B46@gmail.com> <20140718162048.GY25188@pfrc> To: Jeffrey Haas X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/4lMIIu7gTuYhxM7jO7bkkaTBJHs Cc: "draft-zhang-bfd-new-use-cases@tools.ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 18:26:48 -0000 On Jul 18, 2014, at 9:20 AM, Jeffrey Haas wrote: > On Thu, Jul 10, 2014 at 06:31:50AM -0700, Mahesh Jethanandani wrote: >> 3.1. Use Case #1: Reliable Detection for Multipath >>=20 >> Would it make more sense to run BFD on each of the possible paths and = report its individual path status to a higher level protocol? So in = Figure 3.2, would it make more sense to run 3 BFD sessions between R1 = and R4 one on each of the links, each of them reporting their status to = its listeners, be it OSPF ECMP, LAG, or MPLS link bundles and letting = them decide what is a failure scenario? >=20 > One of the big challenges in the multipath or LAG scenarios is = detecting the > various components of the link and exercising the forwarding. In the = case > of LAG, we went with the simplest scenario (back to back connected = links) > and expose that information only to the layer managing the LAG. If = you want > an application BFD session, that is an additional session. Agreed.=20 The general deployment vision I have is that faster BFD sessions e.g. = 3.3ms are deployed on the member links of the multipath, and a slower = e.g. 100ms session deployed end-to-end. The faster sessions detect and = correct any errors on the multipaths before an end-to-end session can = detect a fault. Mahesh Jethanandani mjethanandani@gmail.com From nobody Fri Jul 18 16:05:48 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72221A02A2 for ; Fri, 18 Jul 2014 16:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpnIBPtN6A3a for ; Fri, 18 Jul 2014 16:05:43 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3326C1A01F1 for ; Fri, 18 Jul 2014 16:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3523; q=dns/txt; s=iport; t=1405724743; x=1406934343; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lnd64RayobcLhxAiXDvf6uz+GyWi/cGdGTNtDkJsnA8=; b=JhZDsGQ9krUoJbIHnGDNaZhWWUAPMYqSwNgZ4Xf6Us+b/vNSSe2m67jI RFPJYd0r750BPNOLieyMnpbfqc1M6hmrWKNg69Mk+95k9f0DKc5TQrdl0 1Z46w3BBGnCfNJTI5wh9re5ndcvOOtcLiYRmX7e4ypXSHYyKUDWlKycpE M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFADmnyVOtJA2I/2dsb2JhbABZgmokgSkEzEUBgQkWdoQDAQEBBDo/DAQCAQgOAwQBAQEKFAkHMhQJCAIEDgUIiDoBwwYXjxoxBwaDKIEYBY5DoRGDRGyBRQ X-IronPort-AV: E=Sophos;i="5.01,688,1400025600"; d="scan'208";a="62154410" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP; 18 Jul 2014 23:05:42 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6IN5gs0012150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Jul 2014 23:05:42 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Fri, 18 Jul 2014 18:05:42 -0500 From: "Nobo Akiya (nobo)" To: Jeffrey Haas Subject: RE: draft-ietf-bfd-seamless-base Thread-Topic: draft-ietf-bfd-seamless-base Thread-Index: AQHPn39xwilsxFxxA0KhgNbGgGXyz5uhvukAgAALlJCAAIroAIAA/SvggALtwICAABKQQA== Date: Fri, 18 Jul 2014 23:05:41 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7E8E88@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7EC413@eusaamb103.ericsson.se> <20140714161951.GJ19932@pfrc> <20140715104854507112.18a7cf2e@sniff.de> <20140715194730645130.736cbc95@sniff.de> <20140718143705.GW25188@pfrc> In-Reply-To: <20140718143705.GW25188@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/S29q1KXAuRKQF09-yzDYmew3bnM Cc: "rtg-bfd@ietf.org" , "Marc Binderberger \(mbinderb\)" , "draft-ietf-bfd-seamless-base@tools.ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 23:05:45 -0000 > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Friday, July 18, 2014 10:37 AM > To: Nobo Akiya (nobo) > Cc: Marc Binderberger; Jeffrey Haas; Gregory Mirsky; draft-ietf-bfd- > seamless-base@tools.ietf.org; rtg-bfd@ietf.org; Marc Binderberger > (mbinderb) > Subject: Re: draft-ietf-bfd-seamless-base >=20 > On Wed, Jul 16, 2014 at 11:20:44PM +0000, Nobo Akiya (nobo) wrote: > > Personally I think separate discriminator pool is strongly desired and = is > worth it. > > (1) Collision between S-BFD discriminators and (2) collision between S- > BFD and other BFD sessions can be two different things. > > More complexity will come from needing to handle (2). >=20 > But distinguished already via UDP dest port. >=20 > This is one of those things like how label assignment is done in MPLS tha= t > largely should be an implementation detail. >=20 > I suspect some implementations will do pools, but you need not be able to > tell from the outside. The complicating factor, of course, being if you = assign > your discriminator and your implementation needs unique ones and making > sure that you don't have a collision from dynamic discriminator assignmen= t > in regular BFD. That aligns with my thought. And to accommodate the comment about "... some= implementations will do ...", "MUST" is no longer used in the text that de= scribes discriminator pool, and the word "rule" has been replaced with "sug= gestion". Here's the proposal text for the next revision. 5.1. Discriminator Pools This document defines following suggestions for discriminator management on SBFDInitiator and SBFDReflector sessions, to minimize the collision between required S-BFD discriminators on a local device. o SBFDInitiator is to allocate a discriminator from the BFD discriminator pool. If the system also supports classical BFD that runs on [RFC5880], then the BFD discriminator pool SHOULD be shared by SBFDInitiator sessions and classical BFD sessions. o SBFDReflector is to allocate a discriminator from the S-BFD discriminator pool. The S-BFD discriminator pool SHOULD be a separate pool than the BFD discriminator pool. Remainder of this subsection describes the reasons for above suggestions. Locally allocated S-BFD discriminator values for entities, listened by SBFDReflector sessions, may be arbitrary allocated or derived from values provided by applications. These values may be protocol IDs (ex: System-ID, Router-ID) or network targets (ex: IP address). To avoid derived S-BFD discriminator values already being assigned to other BFD sessions (i.e. SBFDInitiator sessions and classical BFD sessions), it is RECOMMENDED that discriminator pool for SBFDReflector sessions be separate from other BFD sessions. Even when following the separate discriminator pool approach, collision is still possible between one S-BFD application to another S-BFD application, that may be using different values and algorithms to derive S-BFD discriminator values. If the two applications are using S-BFD for a same purpose (ex: network reachability), then the colliding S-BFD discriminator value can be shared. If the two applications are using S-BFD for a different purpose, then the collision must be addressed. How such collisions are addressed is outside the scope of this document. Thanks! -Nobo From nobody Fri Jul 18 16:38:54 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E34E1A02E3 for ; Fri, 18 Jul 2014 16:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVpanTG55ed2 for ; Fri, 18 Jul 2014 16:38:51 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7BCE1A02D6 for ; Fri, 18 Jul 2014 16:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3913; q=dns/txt; s=iport; t=1405726730; x=1406936330; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YuUG2XMdzQpjeyJZ29hVBFAnKC1959juqu6E4+poPO8=; b=UsQBVpXTP5valsUtZmOA1e0E6rOlwOk9xMj6Jd6L3iWPIs2kA1rw/Wr3 ntHSDkd8vZauBQLJ1nLSJpQwkqqYyuPfsI627BjeGiS21gKxUK0vYJ7Bj CU6Tr/X0acY6nKD6dWZSU7DCGfbCCJOG/DR8A3rRxGgJCItXYJ6vGQRGz k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFALKvyVOtJV2R/2dsb2JhbABZgmokgSkEzEUBgQkWdoQDAQEBAwE6PwUHBAIBCA4DBAEBAQoUCQchERQJCAEBBAENBQgTiBMDCQgBu04NhyMXjR6BfDEHBoMogRgBBI5Dil+QFoYcg0RsgUU X-IronPort-AV: E=Sophos;i="5.01,688,1400025600"; d="scan'208";a="341202430" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP; 18 Jul 2014 23:38:50 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6INcnHP025767 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Jul 2014 23:38:49 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Fri, 18 Jul 2014 18:38:49 -0500 From: "Nobo Akiya (nobo)" To: Mahesh Jethanandani , Jeffrey Haas Subject: RE: Comments on draft-zhang-bfd-new-use-cases Thread-Topic: Comments on draft-zhang-bfd-new-use-cases Thread-Index: Ac+bDbnw0pb1AQkCSB+fwnEmQFkztABX3zAAAZg7gQAABGV8gAAEs2Lw Date: Fri, 18 Jul 2014 23:38:48 +0000 Message-ID: References: <4C7782E2-7818-456C-A24E-BB8B0E227B46@gmail.com> <20140718162048.GY25188@pfrc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/-22e6vf4q4qvadjVb6DByDnGBr8 Cc: "draft-zhang-bfd-new-use-cases@tools.ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 23:38:52 -0000 > -----Original Message----- > From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com] > Sent: Friday, July 18, 2014 2:27 PM > To: Jeffrey Haas > Cc: Nobo Akiya (nobo); draft-zhang-bfd-new-use-cases@tools.ietf.org; rtg- > bfd@ietf.org > Subject: Re: Comments on draft-zhang-bfd-new-use-cases >=20 >=20 > On Jul 18, 2014, at 9:20 AM, Jeffrey Haas wrote: >=20 > > On Thu, Jul 10, 2014 at 06:31:50AM -0700, Mahesh Jethanandani wrote: > >> 3.1. Use Case #1: Reliable Detection for Multipath > >> > >> Would it make more sense to run BFD on each of the possible paths and > report its individual path status to a higher level protocol? So in Figur= e 3.2, > would it make more sense to run 3 BFD sessions between R1 and R4 one on > each of the links, each of them reporting their status to its listeners, = be it > OSPF ECMP, LAG, or MPLS link bundles and letting them decide what is a > failure scenario? > > > > One of the big challenges in the multipath or LAG scenarios is > > detecting the various components of the link and exercising the > > forwarding. In the case of LAG, we went with the simplest scenario > > (back to back connected links) and expose that information only to the > > layer managing the LAG. If you want an application BFD session, that i= s an > additional session. > >=20 > Agreed. >=20 > The general deployment vision I have is that faster BFD sessions e.g. 3.3= ms > are deployed on the member links of the multipath, and a slower e.g. 100m= s > session deployed end-to-end.=20 Concept of running "lower" sessions faster than "higher" sessions is fine, = this works (ex: single-hop BFD and multi-hop BFD). But you are now introduc= ing another layer (i.e. BFD on LAG, single-hop BFD, multipath BFD, multi-ho= p BFD) which each need to detect & converge before next "higher" sessions t= ime out. And that's just the underlay. There will be more sessions running = on the overlays. This BFD layering and ensuring they all run at appropriate= rate, manually or automatically, may itself be an interesting use-case. So= mething to think about :) Additionally, if you ran BFD sessions per member link of the multipath at t= he ECMP branch nodes, then you do eliminate the load balancing issue (via t= ying the send/receive of the session to a particular interface). However, y= ou may be introducing further problems which are likely equally complex. - BFD sessions need to be per path (i.e. prefix/LSP) to be effective (i.e. = link health monitoring is done via single-hop BFD already). - Due to per path needs, BFD sessions will likely require TTL tweaking (i.e= . BFD termination point is no longer the path target).=20 - BFD sessions will need to be tied to specific interfaces, but need to sur= vive FRR/LFA. - Packet paths are different between locally generated/terminated packets v= s. packets forwarding through the node (i.e. multipath BFD sessions being u= p does not necessary mean end-to-end path is functioning properly over all = multipath). Something to keep in mind :) Because of above, end-to-end monitoring is still seen to be attractive by s= ome, and some OAM folks are excited about the introduction of Entropy Label= s (as Jeff also wrote in his reply). That allows _a_ solution for MPLS data= plane, but AFAIK, there is _no_ solution for IP data plane. Lastly ... > The faster sessions detect and correct any > errors on the multipaths before an end-to-end session can detect a fault. It will be beneficial for authors of draft-zhang-bfd-new-use-cases to clear= ly describe the "errors" that needs to be detected to get us on the same pa= ge, as this is a use-case document. I know many of us are very technical an= d love talking about solutions, but we can talk about solutions once there'= s consensus on the use-cases/requirements. Thanks! -Nobo =20 From nobody Sun Jul 20 19:08:20 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18AA41B2AD5 for ; Sun, 20 Jul 2014 19:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qh9xcrBf3qk7 for ; Sun, 20 Jul 2014 19:08:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689B51B2AD1 for ; Sun, 20 Jul 2014 19:08:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHJ76860; Mon, 21 Jul 2014 02:08:11 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Jul 2014 03:08:10 +0100 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.225]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Mon, 21 Jul 2014 10:08:03 +0800 From: Mingui Zhang To: "Nobo Akiya (nobo)" , Mahesh Jethanandani , Jeffrey Haas Subject: RE: Comments on draft-zhang-bfd-new-use-cases Thread-Topic: Comments on draft-zhang-bfd-new-use-cases Thread-Index: Ac+bDbnw0pb1AQkCSB+fwnEmQFkztAA8oXIAAZg7gQAABGV8gAAK5ooAAHks+qA= Date: Mon, 21 Jul 2014 02:08:02 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E76A0E78EB@nkgeml508-mbx.china.huawei.com> References: <4C7782E2-7818-456C-A24E-BB8B0E227B46@gmail.com> <20140718162048.GY25188@pfrc> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.131.221] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/L2ilJgnkWyZs8pRROFPBNPvY6Us Cc: "draft-zhang-bfd-new-use-cases@tools.ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 02:08:18 -0000 Hi Nobo, Mahesh & Jeff, Thanks for the deep discussion on use case #1. >- BFD sessions will need to be tied to specific interfaces, I think the above point proposed by Nobo is highly relevant to our use case= . Since BFD session is tied to a specific pair of interfaces, when one of t= he interface card is pulled out, this session will fail and a failure will = be reported to the application. However, carriers prepare more than one pai= r of interfaces for a multipath (It can be either a MPLS or IP multipath). = Suppose a local interface card is pull out, the router is likely to quickly= fail-over to another interface card so the multipath survives. At this tim= e point, the BFD control packets are actually forwarded on a different forw= arding path as the data packets. That is the root cause of the incorrect de= tection in our use case. So we have already raised several potential solutions in our discussion: 1. BFD sessions per path 2. One dynamic BFD session which can adapt to the remained forwarding paths 3. Making use of the entropy label for a MPLS multipath 4. Two layered BFDs Thanks, Mingui -----Original Message----- From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]=20 Sent: Saturday, July 19, 2014 7:39 AM To: Mahesh Jethanandani; Jeffrey Haas Cc: draft-zhang-bfd-new-use-cases@tools.ietf.org; rtg-bfd@ietf.org Subject: RE: Comments on draft-zhang-bfd-new-use-cases > -----Original Message----- > From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com] > Sent: Friday, July 18, 2014 2:27 PM > To: Jeffrey Haas > Cc: Nobo Akiya (nobo); draft-zhang-bfd-new-use-cases@tools.ietf.org;=20 > rtg- bfd@ietf.org > Subject: Re: Comments on draft-zhang-bfd-new-use-cases >=20 >=20 > On Jul 18, 2014, at 9:20 AM, Jeffrey Haas wrote: >=20 > > On Thu, Jul 10, 2014 at 06:31:50AM -0700, Mahesh Jethanandani wrote: > >> 3.1. Use Case #1: Reliable Detection for Multipath > >> > >> Would it make more sense to run BFD on each of the possible paths=20 > >> and > report its individual path status to a higher level protocol? So in=20 > Figure 3.2, would it make more sense to run 3 BFD sessions between R1=20 > and R4 one on each of the links, each of them reporting their status=20 > to its listeners, be it OSPF ECMP, LAG, or MPLS link bundles and=20 > letting them decide what is a failure scenario? > > > > One of the big challenges in the multipath or LAG scenarios is=20 > > detecting the various components of the link and exercising the=20 > > forwarding. In the case of LAG, we went with the simplest scenario=20 > > (back to back connected links) and expose that information only to=20 > > the layer managing the LAG. If you want an application BFD session,=20 > > that is an > additional session. > >=20 > Agreed. >=20 > The general deployment vision I have is that faster BFD sessions e.g.=20 > 3.3ms are deployed on the member links of the multipath, and a slower=20 > e.g. 100ms session deployed end-to-end. Concept of running "lower" sessions faster than "higher" sessions is fine, = this works (ex: single-hop BFD and multi-hop BFD). But you are now introduc= ing another layer (i.e. BFD on LAG, single-hop BFD, multipath BFD, multi-ho= p BFD) which each need to detect & converge before next "higher" sessions t= ime out. And that's just the underlay. There will be more sessions running = on the overlays. This BFD layering and ensuring they all run at appropriate= rate, manually or automatically, may itself be an interesting use-case. So= mething to think about :) Additionally, if you ran BFD sessions per member link of the multipath at t= he ECMP branch nodes, then you do eliminate the load balancing issue (via t= ying the send/receive of the session to a particular interface). However, y= ou may be introducing further problems which are likely equally complex. - BFD sessions need to be per path (i.e. prefix/LSP) to be effective (i.e. = link health monitoring is done via single-hop BFD already). - Due to per path needs, BFD sessions will likely require TTL tweaking (i.e= . BFD termination point is no longer the path target).=20 - BFD sessions will need to be tied to specific interfaces, but need to sur= vive FRR/LFA. - Packet paths are different between locally generated/terminated packets v= s. packets forwarding through the node (i.e. multipath BFD sessions being u= p does not necessary mean end-to-end path is functioning properly over all = multipath). Something to keep in mind :) Because of above, end-to-end monitoring is still seen to be attractive by s= ome, and some OAM folks are excited about the introduction of Entropy Label= s (as Jeff also wrote in his reply). That allows _a_ solution for MPLS data= plane, but AFAIK, there is _no_ solution for IP data plane. Lastly ... > The faster sessions detect and correct any errors on the multipaths=20 > before an end-to-end session can detect a fault. It will be beneficial for authors of draft-zhang-bfd-new-use-cases to clear= ly describe the "errors" that needs to be detected to get us on the same pa= ge, as this is a use-case document. I know many of us are very technical an= d love talking about solutions, but we can talk about solutions once there'= s consensus on the use-cases/requirements. Thanks! -Nobo =20 From nobody Mon Jul 21 06:27:01 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4FE1B2DD0 for ; Mon, 21 Jul 2014 06:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kHi7IT0LQPz for ; Mon, 21 Jul 2014 06:26:46 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 19DC41B2E01 for ; Mon, 21 Jul 2014 06:25:39 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 771E6C185; Mon, 21 Jul 2014 09:25:38 -0400 (EDT) Date: Mon, 21 Jul 2014 09:25:38 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: IETF 90 session at 15:20 Eastern time Message-ID: <20140721132538.GD31818@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/0do1M4I_FmuaG1KA6M3YyT7dVaY X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 13:26:51 -0000 Working Group, Our IETF 90 session in Toronto is today at 15:20 local time. We have a very packed agenda (yay!) and we will be starting on time in order to attempt to provide as much time to speakers as possible. -- Jeff From nobody Mon Jul 21 11:12:13 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF721A0175 for ; Mon, 21 Jul 2014 11:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJ1a89FE0yfq for ; Mon, 21 Jul 2014 11:12:03 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B4861A0007 for ; Mon, 21 Jul 2014 11:12:03 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6LIBwVC020309; Mon, 21 Jul 2014 19:11:58 +0100 Received: from 950129200 (dhcp-b3fb.meeting.ietf.org [31.133.179.251]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6LIBu3o020289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Jul 2014 19:11:57 +0100 From: "Adrian Farrel" To: "'Jeffrey Haas'" , "'Nobo Akiya \(nobo\)'" References: <20140616192857.GE31387@pfrc> <20140616203814.GH31387@pfrc> In-Reply-To: <20140616203814.GH31387@pfrc> Subject: RE: S-BFD UDP Port Early Allocation Request Date: Mon, 21 Jul 2014 19:12:00 +0100 Message-ID: <085d01cfa50f$454b77e0$cfe267a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHNxoM8QgsTujN95ZAXKmci7hHEgwDyjT2SApcuoR0B060OnZuDpR8g Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20832.001 X-TM-AS-Result: No--18.971-10.0-31-10 X-imss-scan-details: No--18.971-10.0-31-10 X-TMASE-MatchedRID: hls5oAVArl8DJrf2+hNOhcqXjImgj58bVBDQSDMig9HadW4iYSMjUae7 nmhJA6kzFz+6vutNl7UXrDym7KLmMfnVY0DWsTq3nJ5tL+LbGOMfbG+50hrCQzW5h17n9B1XL3P LMlQSdmSFfeAkIODmZMMagWzFYuVBVCFefQRV3M6WLCkl1lq7BzHrq78zLkBXzUFc4X2GObKxgp AsVRsHu6nCdJ1UmfG47weYwzhvAp/vSiNEF2cf+aam63kopwnTk8bcfu7vW8W2F4a+vI22PtEQL JPlYQqE+8qgGq6IbXl3tWYijw8fOTcpdZ3fQiLdOX/V8P8ail3Yr6U3ZlQkdsRB0bsfrpPI6T/L TDsmJmg= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/3PbAFjfmWL9Hui8h2U6yXzeMxUU Cc: 'Jeff Haas' , rtg-bfd@ietf.org, 'Alia Atlas' X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 18:12:06 -0000 Yeah, sorry, I fumbled the active request in the middle of this thread... Acting now. Adrian > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: 16 June 2014 21:38 > To: Nobo Akiya (nobo) > Cc: Jeffrey Haas; Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org; > adrian@olddog.co.uk; Alia Atlas > Subject: Re: S-BFD UDP Port Early Allocation Request > > Nobo, > > On Mon, Jun 16, 2014 at 08:31:30PM +0000, Nobo Akiya (nobo) wrote: > > > I do have a minor concern that, similar to other applications of BFD that > > > there may be multiple ports required for the S-BFD application depending > > > on transport. While the case in the base draft is reasonably clear, the > > > various application drafts haven't yet reached maturity for us to be ready to > > > consider adopting them. > > > > > > Do you believe the above is incorrect? > > > > That's a very fair question. It is my belief that one port will suffice for S-BFD on > all transports, rather I strongly believe this is preferred to keep S-BFD transport > agnostic. > > > > > > > > Secondly, this is a reminder that such a request starts a timer: Upon > > > assignment, the temporary reservation is good for one year with the > > > possibility of a single one-year extension. Do you believe we're ready to > > > start that timer? > > > > Because folks are starting to implement this, we need a common port number. > Indeed this request will start the timer, but that's necessary at this point. Let us > proceed to start the timer and aim to progress the draft before the timer expiry. > > I think given the above, we have sufficient cause to advance early > allocation. It's now up to the ADs. > > -- Jeff From nobody Mon Jul 21 11:26:22 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981161A0126 for ; Mon, 21 Jul 2014 11:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jWgEukt9s6k for ; Mon, 21 Jul 2014 11:26:18 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 318001A0008 for ; Mon, 21 Jul 2014 11:26:18 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6LIO7vY025938; Mon, 21 Jul 2014 19:24:07 +0100 Received: from 950129200 (dhcp-b3fb.meeting.ietf.org [31.133.179.251]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6LIO5KV025922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Jul 2014 19:24:06 +0100 From: "Adrian Farrel" To: Subject: Early allocation of User Port for draft-ietf-bfd-seamless-base Date: Mon, 21 Jul 2014 19:24:09 +0100 Message-ID: <086401cfa510$f8132de0$e83989a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+lEPP1ZJYgI4V7TJublmMbO+jC5A== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20832.001 X-TM-AS-Result: No--4.060-10.0-31-10 X-imss-scan-details: No--4.060-10.0-31-10 X-TMASE-MatchedRID: 6Rb6MxL3kQhEXwnTCGfm3UK9qlwiTElfLJm8FOE9WLVAALVzeWYQcODG RKQQH0piSt0Q584NgVzYTvH0ZmjtCRgHZ8655DOPOX/V8P8ail3Yr6U3ZlQkdtmzcdRxL+xwKra uXd3MZDXq/G+uDIzlOzw/as7VQDfSJ48gKyVYK4jKn0wWC0n5byBZFuNiXgnmF0dk3ZO7O8Wz5c 6a62pDwqoz6H8+lKhB/tXAAD7TKWNVz1CS2Al3eKfItuohgjfnw/3NmPJsa4pNWfnUnboMLyBJE ZlhLWrQQwymtxuJ6y0= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/PgRacZTg458c2Ee3TXEo579Wyjw Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 18:26:20 -0000 Hi, The authors of draft-ietf-bfd-seamless-base (http://www.ietf.org/id/draft-ietf-bfd-seamless-base-01.txt) have requested early allocation of a User Port from the "Service Name and Transport Protocol Port Number Registry". This meets all of the 7120 criteria. Please invoke the expert review and make the allocation. Thanks, Adrian From nobody Mon Jul 21 13:38:05 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B489C1A0045 for ; Mon, 21 Jul 2014 13:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rla2imPluNMk for ; Mon, 21 Jul 2014 13:38:00 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA4591A0034 for ; Mon, 21 Jul 2014 13:37:59 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ho1so4713730wib.4 for ; Mon, 21 Jul 2014 13:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:content-transfer-encoding:subject:from:message-id:date :to:mime-version; bh=ANSOdG5a2bKFSnvgoeAPfsW3srqQNVieHq0/daxdT0Y=; b=yrATHpo5wnorudFHxRtPIxXSkwo7HUy1agktgE86K7ZlQ8mS3aXC9F0uPtf5vHKr/E irwrvV0wMfmmYlzhCbzBgj/F4UYuncMyYNT2+KRYMuiFlNjH5K27eA6Qm8ql9CAnmXfo juCi7VTCLHqgUsDrIQTXtmwiahTyBD3nSg+pRsfjit0Eyakho42HF0PLec9cSGazxykj gUw3QDkX2N+9pj28FERt6zzCWObFKEKDVLXqCDArApEFjw/RN4AQQdqcNQfgtQ2vM8h/ 3z5UheKvwFiO1OXLiZoWFNme2z5B+NpuwNtBQCnhnCne3BTH1q56jNjf30sMBA0gYGYn g/DQ== X-Received: by 10.194.62.140 with SMTP id y12mr27201013wjr.27.1405975078084; Mon, 21 Jul 2014 13:37:58 -0700 (PDT) Received: from [31.133.146.159] (dhcp-929f.meeting.ietf.org. [31.133.146.159]) by mx.google.com with ESMTPSA id ez1sm25117018wib.15.2014.07.21.13.37.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 13:37:56 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-531A60E7-A07D-4C82-A94F-D4157D39BBFC Content-Transfer-Encoding: 7bit Subject: BFD stability draft From: Mahesh Jethanandani Message-Id: Date: Mon, 21 Jul 2014 16:37:57 -0400 To: "rtg-bfd@ietf.org" Mime-Version: 1.0 (1.0) X-Mailer: iPad Mail (10B329) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Wn0CLo5hAdXTL76oFyzIFLJT_gI X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 20:38:03 -0000 --Apple-Mail-531A60E7-A07D-4C82-A94F-D4157D39BBFC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Following up on the chairs request to post the motivation behind the draft. While developing BFD in software, we ran into issues of trying to figure why= a particular BFD session failed. The emphasis is on a particular BFD sessio= n. Yes, there are other methods for detecting loss and delay in the network,= but packet drops in the network do not help diagnose a particular BFD sessi= on. The second emphasis is that this draft is written for BFD engine itself and t= o measure its stability. We are aware that there are other methods to measur= e LM/DMM in the network, and are happy to add in the draft that when BFD det= ects instability in the network, it can launch a LM/DMM session if there is f= urther interest in measuring network performance. Again, we welcome folks to review the draft and provide comments on this mai= ling list. http://tools.ietf.org/html/draft-ashesh-bfd-stability-00 Mahesh Jethanandani mjethanandani@gmail.com= --Apple-Mail-531A60E7-A07D-4C82-A94F-D4157D39BBFC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    Following up on the chairs request to p= ost the motivation behind the draft.

    While developi= ng BFD in software, we ran into issues of trying to figure why a particul= ar BFD session failed. The emphasis is on a particular BFD session. Yes,= there are other methods for detecting loss and delay in the network, but pa= cket drops in the network do not help diagnose a particular BFD session.

    The second emphasis is that this draft is written for B= FD engine itself and to measure its stability. We are aware that there are o= ther methods to measure LM/DMM in the network, and are happy to add in the d= raft that when BFD detects instability in the network, it can launch a LM/DM= M session if there is further interest in measuring network performance.

    Again, we welcome folks to review the draft and provid= e comments on this mailing list.

    = --Apple-Mail-531A60E7-A07D-4C82-A94F-D4157D39BBFC-- From nobody Tue Jul 22 03:03:52 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDCB1A0A96 for ; Tue, 22 Jul 2014 03:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEspK6Me8RPB for ; Tue, 22 Jul 2014 03:03:50 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FED71A032A for ; Tue, 22 Jul 2014 03:03:49 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id gf5so5539951lab.23 for ; Tue, 22 Jul 2014 03:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HClDyATs+O2iQioGa7foMOy2qF5cqVcHx1ncM9U2cSY=; b=qClVYogzjHDVh/pCwGg38dpgjBmcrcUvPwB0KpTQdr9/EZoizHFQPGOX+AGSYrIWYs LoPzrzcZwEBuhW1FRU/Dz5+9BoZ9A7ePuDGgKAap+fo6K/ldlhiU4NEjBa/eDTHjKfNo uwCHI38xy4MYMh1pxFnAIUhIXfLARf+qAc2+d86J89FluGwjR8oEAJwRgSUDjNIJ92XA KrbDQnh+oe4mkKsk0gchit/OokBDoKkPpiDAUm6hc5pbn7oOlDbN5RUBmDvM/WTpiE0q 5GyWASYQF7Mm8DSiRkSWmEgQHoZX4aXymOde2tb6TAeAVrHhq7KtZu0wEoEoMsxT+CWx JK0w== MIME-Version: 1.0 X-Received: by 10.152.2.3 with SMTP id 3mr33026691laq.8.1406023427935; Tue, 22 Jul 2014 03:03:47 -0700 (PDT) Received: by 10.114.57.196 with HTTP; Tue, 22 Jul 2014 03:03:47 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Jul 2014 15:33:47 +0530 Message-ID: Subject: Re: BFD stability draft From: Binny Jeshan To: Mahesh Jethanandani Content-Type: multipart/alternative; boundary=089e013c6662f7d26804fec5563d Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/2B7etlEyhDBJwG6axeAPga8Jy2o Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 10:03:51 -0000 --089e013c6662f7d26804fec5563d Content-Type: text/plain; charset=UTF-8 I'd be interested to follow-up closely on this Draft. By the way, how do you think TWAMP can be re-used? On 22 July 2014 02:07, Mahesh Jethanandani wrote: > Following up on the chairs request to post the motivation behind the draft. > > While developing BFD in software, we ran into issues of trying to figure > why a *particular* BFD session failed. The emphasis is on a particular > BFD session. Yes, there are other methods for detecting loss and delay in > the network, but packet drops in the network do not help diagnose a > particular BFD session. > > The second emphasis is that this draft is written for BFD engine itself > and to measure its stability. We are aware that there are other methods to > measure LM/DMM in the network, and are happy to add in the draft that when > BFD detects instability in the network, it can launch a LM/DMM session if > there is further interest in measuring network performance. > > Again, we welcome folks to review the draft and provide comments on this > mailing list. > > http://tools.ietf.org/html/draft-ashesh-bfd-stability-00 > > *Mahesh Jethanandani* > mjethanandani@gmail.com > --089e013c6662f7d26804fec5563d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    I'd be interested to follow-up closely on this Draft. = By the way, how do you think TWAMP can be re-used?


    On 22 July 2014 02:07, Mahesh Je= thanandani <mjethanandani@gmail.com> wrote:
    Following up on the c= hairs request to post the motivation behind the draft.

    =
    While developing BFD in software, we ran into issues of trying to figure wh= y a particular BFD session failed. The emphasis is on a particular B= FD session. Yes, there are other methods for detecting loss and delay in th= e network, but packet drops in the network do not help diagnose a particula= r BFD session.

    The second emphasis is that this draft is written for B= FD engine itself and to measure its stability. We are aware that there are = other methods to measure LM/DMM in the network, and are happy to add in the= draft that when BFD detects instability in the network, it can launch a LM= /DMM session if there is further interest in measuring network performance.=

    Again, we welcome folks to review the draft and provide= comments on this mailing list.


    --089e013c6662f7d26804fec5563d-- From nobody Tue Jul 22 11:57:24 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470041A016A; Tue, 22 Jul 2014 11:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDf-OXzo_n2l; Tue, 22 Jul 2014 11:57:22 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 058B31A0640; Tue, 22 Jul 2014 11:57:15 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-7b-53ce5eaab656 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 5C.30.25146.AAE5EC35; Tue, 22 Jul 2014 14:52:59 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 14:57:07 -0400 From: Gregory Mirsky To: "mpls@ietf.org" Subject: BFD Directed Path discussion Thread-Topic: BFD Directed Path discussion Thread-Index: Ac+l26e8a77RkgmdSoKSZ/ImmV7YPA== Date: Tue, 22 Jul 2014 18:57:06 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7F279F@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B7F279Feusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyuXRPoO7quHPBBsc2MlrcWrqS1eLzn22M DkweS5b8ZApgjOKySUnNySxLLdK3S+DKeL2hnaXgsU/FopdrmBsYlzl1MXJySAiYSGxsfMYE YYtJXLi3nq2LkYtDSOAoo8T8nXegnOWMEkvuHmUFqWITMJJ4sbGHHcQWEVCWODKxGyzOLKAp 0XTiM1hcWEBVYvajG1A1WhL3jzxg7GLkALL1JFbecwcJswCVNP58xwJi8wr4Suxc+xVsDCPQ Ed9PrWGCGCkucevJfKjjBCSW7DnPDGGLSrx8/I8VwlaS+Ph7PjtEfb7Eng0ToGYKSpyc+YRl AqPwLCSjZiEpm4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9i5CgtTi3LTTcy3MQI jI1jEmyOOxgXfLI8xCjAwajEw6tgdi5YiDWxrLgy9xCjNAeLkjivZvW8YCGB9MSS1OzU1ILU ovii0pzU4kOMTBycUg2MO0+6tGh7u7PLpar+MLo4WaB9d0Dc0nlTGQw/p4gbhbaJZ6w+/enr FS6ubZfWazxK6Iv/sfmhr9aiOyKZpYuvr3Vvtn7c3d5acsfzZ3ySTMpDV7UlwifyqybmJx5m bc+ofDxzZY7XnHve16dtYVOX1RSLv1Vje21T1cLwn6/0Z/LvXCqmtrlaiaU4I9FQi7moOBEA eVxIVW4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/HCUfHGKwDVotlawNtSwOik9RNeE Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:57:24 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B7F279Feusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, on behalf of the authors of this work I thank you all who participated in t= he discussions Monday (BFD WG) and today (MPLS WG). Great comments and sugg= estions - very excited by your interest in this work. I've tried to capture summary of the comments and sketch possible ways to a= ddress these: * BFD Return Path TLV suitable for RFC 5880, what about S-BFD? In order to maintain stateless character of S-BFDReflector, S-BFD control p= acket may need to carry return path information. Need to discuss with autho= rs of S-BFD Base and start work on S-BFD over MPLS LSP with IP and ACH enca= psulations; * What would happen if Return Path conveyed to the far-end BFD peer= is not available? Ingress may send another BFD Return Path in its TLV alon= g with the same BFD Discriminator; * Can BFD Echo of RFC 5880 be used in conjunction with the BFD Retu= rn Path TLV over MPLS LSP? It may be interesting as BFD Echo already allows= for a payload but work on proper handling and encapsulations of BFD Echo i= s needed. Besides, use of BFD Echo over MPLS LSP may be limited to single s= egment LSPs thus S-BFD may be more generic mechanism to have stateless far-= end BFD peer; * how this work is related to Extended BFD Discriminator TLV work? = Both may be complementary, especially as parts of controlling BFD session. = Would welcome authors of Extended BFD Discriminator TLV to discussion and r= eview draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext and draft-ietf-mpls-lsp-ping= -mpls-tp-oam-conf drafts (authors are planning to bring them over the finis= h line) Please excuse me if I've missed your question and please add it to this dis= cussion. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B7F279Feusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Dear All,

    on behalf of the authors of this work I thank you al= l who participated in the discussions Monday (BFD WG) and today (MPLS WG). = Great comments and suggestions – very excited by your interest in thi= s work.

    I’ve tried to capture summary of the comments = and sketch possible ways to address these:

    ·         BFD Return Path TLV suitable for RFC 5880, w= hat about S-BFD?

    In order to maintain stat= eless character of S-BFDReflector, S-BFD control packet may need to carry r= eturn path information. Need to discuss with authors of S-BFD Base and star= t work on S-BFD over MPLS LSP with IP and ACH encapsulations;

    ·         What would happen if Return Path conveyed to= the far-end BFD peer is not available? Ingress may send another BFD Return= Path in its TLV along with the same BFD Discriminator;

    ·         Can BFD Echo of RFC 5880 be used in conjunct= ion with the BFD Return Path TLV over MPLS LSP? It may be interesting as BF= D Echo already allows for a payload but work on proper handling and encapsu= lations of BFD Echo is needed. Besides, use of BFD Echo over MPLS LSP may be limited to single segment LSPs thus S= -BFD may be more generic mechanism to have stateless far-end BFD peer;=

    ·         how this work is related to Extended BFD Dis= criminator TLV work? Both may be complementary, especially as parts of cont= rolling BFD session. Would welcome authors of Extended BFD Discriminator TL= V to discussion and review draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext and draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf drafts (authors are planning= to bring them over the finish line)

     

    Please excuse me if I’ve missed your question = and please add it to this discussion.

     

            &nbs= p;       Regards,

            &nbs= p;            &= nbsp;          Greg=

    --_000_7347100B5761DC41A166AC17F22DF1121B7F279Feusaamb103erics_-- From nobody Thu Jul 24 03:35:11 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27FAA1A0185; Thu, 24 Jul 2014 03:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdABWMS5Cqav; Thu, 24 Jul 2014 03:35:06 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503C71A0196; Thu, 24 Jul 2014 03:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3020; q=dns/txt; s=iport; t=1406198107; x=1407407707; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ME+Fej6kWLbo4bPqPl5OK00Kc4fBL4AbJyQdpNLDXSc=; b=IiqoLPTbAfQIwxF4aREwbAb1L/81tKxJRskmQvvOpXoGysdH96EjvJBA nhMgZI//aJ+uu6sa2pcgtJmWOd3+Ba/51VPMERQXFvbVQZbnbgg6E6M4R HNll60bLSkGqOdF3wEayptPGGuGPbrjsoRYz6hITHt8bBdPrLbmLWGAe/ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAIDg0FOtJV2c/2dsb2JhbABZgw6BKQTQWAGBCxZ3hAMBAQEEeRACAQgRBAEBCx0HMhQJCAEBBAENBQiIOsATF45zJzEHgy6BGAWKL4xlmGGDSGyBAwc7 X-IronPort-AV: E=Sophos;i="5.01,723,1400025600"; d="scan'208";a="342494458" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 24 Jul 2014 10:35:06 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6OAZ5cr011801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jul 2014 10:35:05 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.202]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Thu, 24 Jul 2014 05:35:05 -0500 From: "Vengada Prasad Govindan (venggovi)" To: Gregory Mirsky , "mpls@ietf.org" Subject: RE: BFD Directed Path discussion Thread-Topic: BFD Directed Path discussion Thread-Index: Ac+l26e8a77RkgmdSoKSZ/ImmV7YPAA91X3w Date: Thu, 24 Jul 2014 10:35:05 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D34639107@xmb-rcd-x15.cisco.com> References: <7347100B5761DC41A166AC17F22DF1121B7F279F@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7F279F@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.137] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/VefjnVgUA3rLhZ3JMAElatRRIKs Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 10:35:08 -0000 Hello Greg, Thanks for your note, a couple of clarifications here: >how this work is related to Extended BFD Discriminator TLV work? Both may = be complementary, especially as parts of controlling BFD >session. Would we= lcome authors of Extended BFD Discriminator TLV to discussion and review dr= aft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext >and draft-ietf-mpls-lsp-ping-mpls-t= p-oam-conf drafts (authors are planning to bring them over the finish line) a. Are you suggesting that we add sub-TLVs to convey the instance identifie= r [1] inside the BFD configuration sub-TLV of both MPLS LSP ping [2] and th= e RSVP TE OAM [3] messages? b. Are you considering the addition of BFD reverse-path TLV [4] as well to = the LSP ping and RSVP-TE OAM messages?=20 Thanks Prasad [1] draft-vgovindan-mpls-extended-bfd-disc-tlv [2] draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-06 [3] draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-12 [4] draft-mirsky-mpls-bfd-directed-00 From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Wednesday, July 23, 2014 12:27 AM To: mpls@ietf.org Cc: rtg-bfd@ietf.org Subject: BFD Directed Path discussion Dear All, on behalf of the authors of this work I thank you all who participated in t= he discussions Monday (BFD WG) and today (MPLS WG). Great comments and sugg= estions - very excited by your interest in this work. I've tried to capture summary of the comments and sketch possible ways to a= ddress these: . BFD Return Path TLV suitable for RFC 5880, what about S-BFD? In order to maintain stateless character of S-BFDReflector, S-BFD control p= acket may need to carry return path information. Need to discuss with autho= rs of S-BFD Base and start work on S-BFD over MPLS LSP with IP and ACH enca= psulations; . What would happen if Return Path conveyed to the far-end BFD peer is not = available? Ingress may send another BFD Return Path in its TLV along with t= he same BFD Discriminator; . Can BFD Echo of RFC 5880 be used in conjunction with the BFD Return Path = TLV over MPLS LSP? It may be interesting as BFD Echo already allows for a p= ayload but work on proper handling and encapsulations of BFD Echo is needed= . Besides, use of BFD Echo over MPLS LSP may be limited to single segment L= SPs thus S-BFD may be more generic mechanism to have stateless far-end BFD = peer; . how this work is related to Extended BFD Discriminator TLV work? Both may= be complementary, especially as parts of controlling BFD session. Would we= lcome authors of Extended BFD Discriminator TLV to discussion and review dr= aft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext and draft-ietf-mpls-lsp-ping-mpls-tp= -oam-conf drafts (authors are planning to bring them over the finish line) Please excuse me if I've missed your question and please add it to this dis= cussion. =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Regards, =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 Greg From nobody Thu Jul 24 06:31:03 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB4A1A0352 for ; Thu, 24 Jul 2014 06:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wun_MroXUkcD for ; Thu, 24 Jul 2014 06:30:58 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181401A0320 for ; Thu, 24 Jul 2014 06:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1778; q=dns/txt; s=iport; t=1406208659; x=1407418259; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=ZWAbcuVc2hsLNyKiD5r+ep8shN0tQQ/OuGMVRQ8vGfE=; b=gadMWCm+kGpwuhl15vn0m2KudSaGvV2JEhalpqBG05Ff88DMQ6LvLpps esZ1vSa5m4eKkIo+Zf9xMSuWsTejSIDh/lwPrVhOZddm4RvS7uE4U4sRk KO0mZUEr2iSo8T4jwbOg13YBC4kmrd7ku5w7Zo+wr6IbkCiLL0vPvKv2E 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAMIJ0VOtJV2U/2dsb2JhbABZgmokUlcEyTOHRQGBCxZ3hAUBBDpRASoUQiYBBBsBiDkBDJklpw8XjxqDZoEYBY5IiEyYYYNIbAGBRA X-IronPort-AV: E=Sophos;i="5.01,724,1400025600"; d="scan'208";a="342522666" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP; 24 Jul 2014 13:30:58 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6ODUv3s004592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Jul 2014 13:30:57 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Thu, 24 Jul 2014 08:30:56 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: S-BFD open items, seeking comments Thread-Topic: S-BFD open items, seeking comments Thread-Index: Ac+nQ1JkI7xBGFdISdiCs4MsO7iGlA== Date: Thu, 24 Jul 2014 13:30:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/4xxnTadqVwm_nPQ3SN4OHhziMNk X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 13:31:02 -0000 Hi BFDers, In order for us to progress S-BFD Base and IP documents, we need your input= on following 2 points. Details can be found in pages 3 and 5 of: http://www.ietf.org/proceedings/90/slides/slides-90-bfd-2.pptx =3D=3D Document Structure: 1) S-BFD-Base document to describe UDP and BFD headers. a) S-BFD-IP document to describe IP and MPLS data plane headers. b) S-BFD-SR document to describe SPRING and data planes it uses. c) If S-BFD-IP-Less document is needed, it will describe ACh and clarif= y that UDP is not applicable. 2) S-BFD Base document to describe BFD header. a) S-BFD-IP document to describe UDP, IP and MPLS data plane headers. b) S-BFD-SR document to describe UDP, SPRING and data planes it uses. c) If S-BFD-IP-Less document is needed, it will describe ACh. Frankly neither are perfectly clean. Approach (1) creates a special case (I= P-less) whilst approach (2) requires UDP to be repeated in IP and SR docume= nts. Authors are ok to go with either approach from above, given WG consens= us. =3D=3D SBFDReflector state field setting in sending S-BFD packets. 1) SBFDReflector to set its local state [UP or ADMINDOWN]. 2) SBFDReflector to set [ADMINDOWN or reflect received state]. For pros/cons, please view the slide. S-BFD-Base document is currently stru= ctured with (1). Speaking with couple of folks offline, it sounds like (1) = is preferred which aligns with thoughts from most authors. We will plan to = go with (1) unless there are strong objections. =3D=3D Additionally ... Welcoming comments and discussions on pages 6 and 7. Note, these are not ga= ting the progress of S-BFD-Base/IP drafts at the moment but good topics to = discuss. Thanks! -Nobo From nobody Thu Jul 24 07:27:28 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5886D1A01FF; Thu, 24 Jul 2014 07:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ay0DNCPBvxtH; Thu, 24 Jul 2014 07:27:15 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 033821A0383; Thu, 24 Jul 2014 07:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4484; q=dns/txt; s=iport; t=1406212031; x=1407421631; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sdJrYMKLjvH2gmd/Ihl7o/bJUHbJh80or6AkHpGFfCk=; b=m/z7l01RDS8Oi5lh9HFLFzQEOo3E+V7RDbXN2e+wufsCXjKxMPSLdDMG dn/JUxh5y6UX2MbLinmyQGadnZlziHxMrgQQ5Eh44LdnFgqVYBz9kAZNz Ef1Bx5EYx9ThAFlIIUBUAZ3HVPMpmCmtGV1RDEbjIKdTa89g5YKpggHWf w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAIQX0VOtJV2Y/2dsb2JhbABZgmokgSkE0HgBgQ0Wd4QDAQEBBHkMBAIBCBEEAQELHQcyFAkIAQEEAQ0FCIg6AcBoF4l+hHUnMQcGgyiBGAEEii+EGYhMmGGDSGyBAwc7 X-IronPort-AV: E=Sophos;i="5.01,724,1400025600"; d="scan'208";a="63627820" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP; 24 Jul 2014 14:26:55 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6OEQt86009846 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jul 2014 14:26:55 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Thu, 24 Jul 2014 09:26:55 -0500 From: "Nobo Akiya (nobo)" To: "Vengada Prasad Govindan (venggovi)" , Gregory Mirsky , "mpls@ietf.org" Subject: RE: BFD Directed Path discussion Thread-Topic: BFD Directed Path discussion Thread-Index: Ac+l26e8a77RkgmdSoKSZ/ImmV7YPAA91X3wABzCcmA= Date: Thu, 24 Jul 2014 14:26:55 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7F279F@eusaamb103.ericsson.se> <315041E4211CB84E86EF7C25A2AB583D34639107@xmb-rcd-x15.cisco.com> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D34639107@xmb-rcd-x15.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/fxm8WtGXY02oP4a-mx4DP77GKxw Cc: "draft-vgovindan-mpls-extended-bfd-disc-tlv@tools.ietf.org" , "rtg-bfd@ietf.org" , "ccamp@ietf.org" , "draft-mirsky-mpls-bfd-directed@tools.ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 14:27:17 -0000 Hi Greg, Prasad, et al, Great to see this being discussed. Adding CCAMP and authors of both documen= ts. Speaking as a BFD WG co-chair ... > [1] draft-vgovindan-mpls-extended-bfd-disc-tlv > [4] draft-mirsky-mpls-bfd-directed-00 Regarding above 2 documents, details should be discussed further but the ne= eds of both look valid. However, we should not lead down the path of having= more and more BFD bootstrapping TLVs, but have/aim-for one TLV that allows= Sub-TLVs for extensions. > [2] draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-06 Above document is dead. IETF State: Dead WG Document > [3] draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-12 Above document is already LC'ed (long ago). IETF State: Submitted to IESG for Publication=20 My best guess is that we do not want to disrupt/block [3] at this point. Question to authors of [1] and [4]. Are you interested to change LSP Ping bootstrapping only? If so, then it se= ems the authors of [1] and [4] need to get together and come up with a sing= le BFD bootstrapping TLV (given that [2] is dead). Thanks! -Nobo > -----Original Message----- > From: Vengada Prasad Govindan (venggovi) > Sent: Thursday, July 24, 2014 6:35 AM > To: Gregory Mirsky; mpls@ietf.org > Cc: rtg-bfd@ietf.org; Nobo Akiya (nobo) > Subject: RE: BFD Directed Path discussion >=20 > Hello Greg, >=20 > Thanks for your note, a couple of clarifications here: > >how this work is related to Extended BFD Discriminator TLV work? Both > >may be complementary, especially as parts of controlling BFD >session. > >Would welcome authors of Extended BFD Discriminator TLV to discussion > >and review draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext >and > >draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf drafts (authors are planning > >to bring them over the finish line) > a. Are you suggesting that we add sub-TLVs to convey the instance identif= ier > [1] inside the BFD configuration sub-TLV of both MPLS LSP ping [2] and th= e > RSVP TE OAM [3] messages? > b. Are you considering the addition of BFD reverse-path TLV [4] as well t= o > the LSP ping and RSVP-TE OAM messages? >=20 > Thanks > Prasad > [1] draft-vgovindan-mpls-extended-bfd-disc-tlv > [2] draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-06 > [3] draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-12 > [4] draft-mirsky-mpls-bfd-directed-00 >=20 >=20 > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory > Mirsky > Sent: Wednesday, July 23, 2014 12:27 AM > To: mpls@ietf.org > Cc: rtg-bfd@ietf.org > Subject: BFD Directed Path discussion >=20 > Dear All, > on behalf of the authors of this work I thank you all who participated in= the > discussions Monday (BFD WG) and today (MPLS WG). Great comments and > suggestions - very excited by your interest in this work. > I've tried to capture summary of the comments and sketch possible ways to > address these: > . BFD Return Path TLV suitable for RFC 5880, what about S-BFD? > In order to maintain stateless character of S-BFDReflector, S-BFD control > packet may need to carry return path information. Need to discuss with > authors of S-BFD Base and start work on S-BFD over MPLS LSP with IP and > ACH encapsulations; . What would happen if Return Path conveyed to the > far-end BFD peer is not available? Ingress may send another BFD Return > Path in its TLV along with the same BFD Discriminator; . Can BFD Echo of = RFC > 5880 be used in conjunction with the BFD Return Path TLV over MPLS LSP? I= t > may be interesting as BFD Echo already allows for a payload but work on > proper handling and encapsulations of BFD Echo is needed. Besides, use of > BFD Echo over MPLS LSP may be limited to single segment LSPs thus S-BFD > may be more generic mechanism to have stateless far-end BFD peer; . how > this work is related to Extended BFD Discriminator TLV work? Both may be > complementary, especially as parts of controlling BFD session. Would > welcome authors of Extended BFD Discriminator TLV to discussion and > review draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext and draft-ietf-mpls-lsp- > ping-mpls-tp-oam-conf drafts (authors are planning to bring them over the > finish line) >=20 > Please excuse me if I've missed your question and please add it to this > discussion. >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Regards, > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 Greg From nobody Fri Jul 25 07:06:20 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2DD41B2993 for ; Fri, 25 Jul 2014 07:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RgndfCXr5GR for ; Fri, 25 Jul 2014 07:06:13 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48B111B295B for ; Fri, 25 Jul 2014 07:05:14 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hy4so7209729vcb.22 for ; Fri, 25 Jul 2014 07:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r2jeWLUv7hksxQtPo688xeYp8XvjeEHLzZSvWuHcZZI=; b=DVvOMooi37vk3onMta4lOR08eH9tp4uvuaFb8EPypgb3BOj0gREfYLML0U1QgyR+FW mr8fno23QH+22QhiJD6i1H/ZlxQJMOpajnZ7MQ24VBZxtpQzXY/iAIPEmx4TYHDRmuHm KtDJasDGv48Jo9Sam+Q/yAqzYcZDXbztsFgl4DrpWxnFsEZZBVlF08W7EfLwXimuX640 en07muDEdEmjynHJTGFR7ngr92hqHABe4a21O07MqwCbfWrUdKHN5Ig3+ilw9nVTPHIW 47YFNO4MFlN6yoYmfGZTPx19uww5KuFAczllE8IAeZgZkhguUAzTikM9TOf3mtUojozg EWDg== MIME-Version: 1.0 X-Received: by 10.52.163.136 with SMTP id yi8mr17896499vdb.14.1406297113240; Fri, 25 Jul 2014 07:05:13 -0700 (PDT) Received: by 10.52.100.129 with HTTP; Fri, 25 Jul 2014 07:05:13 -0700 (PDT) In-Reply-To: References: Date: Fri, 25 Jul 2014 10:05:13 -0400 Message-ID: Subject: Re: S-BFD open items, seeking comments From: Pablo Frank To: "Nobo Akiya (nobo)" Content-Type: multipart/alternative; boundary=001a11c2238ee22a1204ff050f54 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Co1i8D1Ra8rHNFHU807VCL9XGKc Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 14:06:15 -0000 --001a11c2238ee22a1204ff050f54 Content-Type: text/plain; charset=UTF-8 Hi Nobo, et al, Regarding the document structure: I think I prefer the option where the base S-BFD draft does not specify UDP headers. UDP is not intrinsic to BFD although it is commonly used in several encapsulations. We already have examples where the UDP port usage had to be modified anyway (e.g. BFD-LAG, and of course S-BFD). Wrt/ concerns over having to repeatedly specify the UDP behaviour across multiple documents, I think we can mostly avoid that by primarily specifying the UDP header usage in the S-BFD-IP document. S-BFD-SR (or any other documents that need it) can simply reference the S-BFD-IP document for UDP header usage, and the S-BFD-BASE for BFD header usage. Regarding the state field in the S-BFD packets: I think I strongly prefer option 1. By giving the reflector an independent state, it leaves open the possibility of extending the state machine in the future (I do have an ulterior motive here that I'd like to discuss soon). Option 2 is very rigid and leaves little room for extension. I also think it's misleading to suggest that option 2 allows the initiator to re-use the RFC 5880 state machine. Because of the differences in procedure introduced by S-BFD, the state-machine is only superficially similar. It may have the same set of states but the details of the transitions are quite different. Therefore, I see little value in option 2. My 2 cents, regards, Pablo On Thu, Jul 24, 2014 at 9:30 AM, Nobo Akiya (nobo) wrote: > Hi BFDers, > > In order for us to progress S-BFD Base and IP documents, we need your > input on following 2 points. > > Details can be found in pages 3 and 5 of: > http://www.ietf.org/proceedings/90/slides/slides-90-bfd-2.pptx > > > == Document Structure: > > 1) S-BFD-Base document to describe UDP and BFD headers. > a) S-BFD-IP document to describe IP and MPLS data plane headers. > b) S-BFD-SR document to describe SPRING and data planes it uses. > c) If S-BFD-IP-Less document is needed, it will describe ACh and > clarify that UDP is not applicable. > > 2) S-BFD Base document to describe BFD header. > a) S-BFD-IP document to describe UDP, IP and MPLS data plane headers. > b) S-BFD-SR document to describe UDP, SPRING and data planes it uses. > c) If S-BFD-IP-Less document is needed, it will describe ACh. > > Frankly neither are perfectly clean. Approach (1) creates a special case > (IP-less) whilst approach (2) requires UDP to be repeated in IP and SR > documents. Authors are ok to go with either approach from above, given WG > consensus. > > > == SBFDReflector state field setting in sending S-BFD packets. > > 1) SBFDReflector to set its local state [UP or ADMINDOWN]. > > 2) SBFDReflector to set [ADMINDOWN or reflect received state]. > > For pros/cons, please view the slide. S-BFD-Base document is currently > structured with (1). Speaking with couple of folks offline, it sounds like > (1) is preferred which aligns with thoughts from most authors. We will plan > to go with (1) unless there are strong objections. > > > == Additionally ... > > Welcoming comments and discussions on pages 6 and 7. Note, these are not > gating the progress of S-BFD-Base/IP drafts at the moment but good topics > to discuss. > > > Thanks! > > -Nobo > > --001a11c2238ee22a1204ff050f54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi Nobo, et al,

    Regarding the document = structure:

    I think I prefer the option where the b= ase S-BFD draft does not specify UDP headers. =C2=A0UDP is not intrinsic to= BFD although it is commonly used in several encapsulations. =C2=A0We alrea= dy have examples where the UDP port usage had to be modified anyway (e.g. B= FD-LAG, and of course S-BFD). =C2=A0Wrt/ concerns over having to repeatedly= specify the UDP behaviour across multiple documents, I think we can mostly= avoid that by primarily specifying the UDP header usage in the S-BFD-IP do= cument. =C2=A0S-BFD-SR (or any other documents that need it) can simply ref= erence the S-BFD-IP document for UDP header usage, and the S-BFD-BASE for B= FD header usage.

    Regarding the state field in the S-BFD packets:

    I think I strongly prefer option 1. =C2=A0By giving the r= eflector an independent state, it leaves open the possibility of extending = the state machine in the future (I do have an ulterior motive here that I&#= 39;d like to discuss soon). =C2=A0Option 2 is very rigid and leaves little = room for extension. =C2=A0I also think it's misleading to suggest that = option 2 allows the initiator to re-use the RFC 5880 state machine. =C2=A0B= ecause of the differences in procedure introduced by S-BFD, the state-machi= ne is only superficially similar. =C2=A0It may have the same set of states = but the details of the transitions are quite different. =C2=A0Therefore, I = see little value in option 2.

    My 2 cents,

    regards,
    Pablo


    On Thu, Jul 24, 2014 at 9:30 AM, Nobo Akiya (nobo) &= lt;nobo@cisco.com&g= t; wrote:
    Hi BFDers,

    In order for us to progress S-BFD Base and IP documents, we need your input= on following 2 points.

    Details can be found in pages 3 and 5 of:
    http://www.ietf.org/proceedings/90/slides/slides-90-bfd-2= .pptx


    =3D=3D Document Structure:

    1) S-BFD-Base document to describe UDP and BFD headers.
    =C2=A0 =C2=A0 a) S-BFD-IP document to describe IP and MPLS data plane heade= rs.
    =C2=A0 =C2=A0 b) S-BFD-SR document to describe SPRING and data planes it us= es.
    =C2=A0 =C2=A0 c) If S-BFD-IP-Less document is needed, it will describe ACh = and clarify that UDP is not applicable.

    2) S-BFD Base document to describe BFD header.
    =C2=A0 =C2=A0 a) S-BFD-IP document to describe UDP, IP and MPLS data plane = headers.
    =C2=A0 =C2=A0 b) S-BFD-SR document to describe UDP, SPRING and data planes = it uses.
    =C2=A0 =C2=A0 c) If S-BFD-IP-Less document is needed, it will describe ACh.=

    Frankly neither are perfectly clean. Approach (1) creates a special case (I= P-less) whilst approach (2) requires UDP to be repeated in IP and SR docume= nts. Authors are ok to go with either approach from above, given WG consens= us.


    =3D=3D SBFDReflector state field setting in sending S-BFD packets.

    1) SBFDReflector to set its local state [UP or ADMINDOWN].

    2) SBFDReflector to set [ADMINDOWN or reflect received state].

    For pros/cons, please view the slide. S-BFD-Base document is currently stru= ctured with (1). Speaking with couple of folks offline, it sounds like (1) = is preferred which aligns with thoughts from most authors. We will plan to = go with (1) unless there are strong objections.


    =3D=3D Additionally ...

    Welcoming comments and discussions on pages 6 and 7. Note, these are not ga= ting the progress of S-BFD-Base/IP drafts at the moment but good topics to = discuss.


    Thanks!

    -Nobo


    --001a11c2238ee22a1204ff050f54-- From nobody Sun Jul 27 10:49:07 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0231A0AE5 for ; Sun, 27 Jul 2014 10:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBYSoyEYOiAe for ; Sun, 27 Jul 2014 10:49:03 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C091A0AD7 for ; Sun, 27 Jul 2014 10:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=364; q=dns/txt; s=iport; t=1406483343; x=1407692943; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=sHCt8JKR1ZPiDQl0TNkDsGbRuyXYwQDvxpNACm8QGcE=; b=EBVZwJItd9OM9dWlh3jvqLISWhHehxDEPvOl4vAje/HuZeqj4MzB0Dd7 2QmqO01jbxE/KLDOz5B4Afezzd0DB+/jbcqJw7EN+ziosTXwPRp5cAijy 3LHVV1EmKfelmZnu5jFIKLQg8pBMAAjYK8UCdmvRPaghon1odA1NIqKG5 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsJAOY61VOtJV2Q/2dsb2JhbABYgmokUlgDy12HRQGBChZ3hAUBBDpRASoUQiYBBBsBiDkBDJZZpXoXjmoRAR+DZ4EbBY5XoUGDSYF4OQ X-IronPort-AV: E=Sophos;i="5.01,743,1400025600"; d="scan'208";a="64413343" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP; 27 Jul 2014 17:49:02 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6RHn2o1008654 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 27 Jul 2014 17:49:02 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Sun, 27 Jul 2014 12:49:02 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: IETF 90 BFD WG Meeting Minutes Thread-Topic: IETF 90 BFD WG Meeting Minutes Thread-Index: Ac+pwt786krFNEIrRxOALV6KydJXOw== Date: Sun, 27 Jul 2014 17:49:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/7FiKIgjqnDYbDkFZyiD1USNOI1Q X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 17:49:04 -0000 Hi BFDers, The minutes from the BFD WG @ IETF90 has been posted, please take a moment = to review the contents. http://www.ietf.org/proceedings/90/minutes/minutes-90-bfd If changes should be made, please email Jeff and myself. Many thanks to Acee Lindem for taking the minutes and Jared Mauch for cover= ing the jabber. Thanks! -Nobo and Jeff From nobody Sun Jul 27 11:21:59 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F30C1A0AE5 for ; Sun, 27 Jul 2014 11:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hd_QLVmv67Jq for ; Sun, 27 Jul 2014 11:21:55 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 170B71A0350 for ; Sun, 27 Jul 2014 11:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6360; q=dns/txt; s=iport; t=1406485315; x=1407694915; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1UfabdtCifcIVmDptKOvI81EN+y5QTdYgBSJ7emMAE0=; b=mgbV9HVyIcqgsoHDo5xiuHdbYjJrVIlO5e+j4rXbeCvaI7XPtGmUEN4V hVApYwVNeKgLCmXqEHdp8C6/m+LcaL4ixPK119O78sFI+n2ih0e5awm76 8lxmf7bK1k+Bbo+hRM0F+hfmwAZl2gXheKRsZwXG715jUzhJ5RhrP2sqo k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAC1C1VOtJA2E/2dsb2JhbABYgmokUlcEgnTIaYdFARlyFneEAwEBAQMBIxFFBQcEAgEIEQQBAQECAgYdAwICAh8RFAEICAEBBA4FCAGIJQMJCAEMpWePNg2HEReBLItzgXwWGwcGgnM2gRsFjleIU4IdkC6GI4NJbAGBRA X-IronPort-AV: E=Sophos;i="5.01,743,1400025600"; d="scan'208";a="343153662" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP; 27 Jul 2014 18:21:54 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6RILsaO008229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 27 Jul 2014 18:21:54 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Sun, 27 Jul 2014 13:21:54 -0500 From: "Nobo Akiya (nobo)" To: Pablo Frank Subject: RE: S-BFD open items, seeking comments Thread-Topic: S-BFD open items, seeking comments Thread-Index: Ac+nQ1JkI7xBGFdISdiCs4MsO7iGlAA+ApiAAGJabBA= Date: Sun, 27 Jul 2014 18:21:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.51] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/6AowKsv5NigHxNtIeIoDKNi--2U Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 18:21:57 -0000 SGkgUGFibG8sDQoNClRydWx5IGFwcHJlY2lhdGUgeW91ciBjb21tZW50cy4NCg0KUGxlYXNlIHNl ZS1pbmxpbmUuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGFibG8g RnJhbmsgW21haWx0bzpwYWJsb2lzbm90QGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBKdWx5 IDI1LCAyMDE0IDEwOjA1IEFNDQo+IFRvOiBOb2JvIEFraXlhIChub2JvKQ0KPiBDYzogcnRnLWJm ZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogUy1CRkQgb3BlbiBpdGVtcywgc2Vla2luZyBjb21t ZW50cw0KPiANCj4gSGkgTm9ibywgZXQgYWwsDQo+IA0KPiBSZWdhcmRpbmcgdGhlIGRvY3VtZW50 IHN0cnVjdHVyZToNCj4gDQo+IEkgdGhpbmsgSSBwcmVmZXIgdGhlIG9wdGlvbiB3aGVyZSB0aGUg YmFzZSBTLUJGRCBkcmFmdCBkb2VzIG5vdCBzcGVjaWZ5IFVEUA0KPiBoZWFkZXJzLiDCoFVEUCBp cyBub3QgaW50cmluc2ljIHRvIEJGRCBhbHRob3VnaCBpdCBpcyBjb21tb25seSB1c2VkIGluIHNl dmVyYWwNCj4gZW5jYXBzdWxhdGlvbnMuIMKgV2UgYWxyZWFkeSBoYXZlIGV4YW1wbGVzIHdoZXJl IHRoZSBVRFAgcG9ydCB1c2FnZSBoYWQNCj4gdG8gYmUgbW9kaWZpZWQgYW55d2F5IChlLmcuIEJG RC1MQUcsIGFuZCBvZiBjb3Vyc2UgUy1CRkQpLiDCoFdydC8gY29uY2VybnMNCj4gb3ZlciBoYXZp bmcgdG8gcmVwZWF0ZWRseSBzcGVjaWZ5IHRoZSBVRFAgYmVoYXZpb3VyIGFjcm9zcyBtdWx0aXBs ZQ0KPiBkb2N1bWVudHMsIEkgdGhpbmsgd2UgY2FuIG1vc3RseSBhdm9pZCB0aGF0IGJ5IHByaW1h cmlseSBzcGVjaWZ5aW5nIHRoZSBVRFANCj4gaGVhZGVyIHVzYWdlIGluIHRoZSBTLUJGRC1JUCBk b2N1bWVudC4gwqBTLUJGRC1TUiAob3IgYW55IG90aGVyIGRvY3VtZW50cw0KPiB0aGF0IG5lZWQg aXQpIGNhbiBzaW1wbHkgcmVmZXJlbmNlIHRoZSBTLUJGRC1JUCBkb2N1bWVudCBmb3IgVURQIGhl YWRlcg0KPiB1c2FnZSwgYW5kIHRoZSBTLUJGRC1CQVNFIGZvciBCRkQgaGVhZGVyIHVzYWdlLg0K DQpZb3UgYXJlIHRoZSB0aGlyZCBwZXJzb24gd2hvIHZvaWNlZCB0aGUgcHJlZmVyZW5jZSBmb3Ig dGhpcyBkb2N1bWVudCBzdHJ1Y3R1cmUgb24gdGhlIGxpc3QsIGFzIG9wcG9zZWQgdG8gemVybygw KSBwcmVmZXJyaW5nIHRoZSBjdXJyZW50IGRvY3VtZW50IHN0cnVjdHVyZS4gTnVtYmVyIG9mIHZv dGVzIGFyZSBzbWFsbCwgYnV0IGl0J3MgcHJvYmFibHkgcmVhc29uYWJsZSB0byBjb25jbHVkZSB0 aGF0IHdlIHNob3VsZCBnbyB3aXRoOg0KDQo+IDIpIFMtQkZEIEJhc2UgZG9jdW1lbnQgdG8gZGVz Y3JpYmUgQkZEIGhlYWRlci4NCj4gICAgIGEpIFMtQkZELUlQIGRvY3VtZW50IHRvIGRlc2NyaWJl IFVEUCwgSVAgYW5kIE1QTFMgZGF0YSBwbGFuZSBoZWFkZXJzLg0KPiAgICAgYikgUy1CRkQtU1Ig ZG9jdW1lbnQgdG8gZGVzY3JpYmUgVURQLCBTUFJJTkcgYW5kIGRhdGEgcGxhbmVzIGl0IHVzZXMu DQo+ICAgICBjKSBJZiBTLUJGRC1JUC1MZXNzIGRvY3VtZW50IGlzIG5lZWRlZCwgaXQgd2lsbCBk ZXNjcmliZSBBQ2guDQoNCkkgd2lsbCB0YWtlIGEgY3JhY2sgYXQgcmVzdHJ1Y3R1cmluZyB0aGUg Uy1CRkQgZG9jdW1lbnRzIHNvb24uDQoNCj4gDQo+IFJlZ2FyZGluZyB0aGUgc3RhdGUgZmllbGQg aW4gdGhlIFMtQkZEIHBhY2tldHM6DQo+IA0KPiBJIHRoaW5rIEkgc3Ryb25nbHkgcHJlZmVyIG9w dGlvbiAxLiDCoEJ5IGdpdmluZyB0aGUgcmVmbGVjdG9yIGFuIGluZGVwZW5kZW50DQo+IHN0YXRl LCBpdCBsZWF2ZXMgb3BlbiB0aGUgcG9zc2liaWxpdHkgb2YgZXh0ZW5kaW5nIHRoZSBzdGF0ZSBt YWNoaW5lIGluIHRoZQ0KPiBmdXR1cmUgKEkgZG8gaGF2ZSBhbiB1bHRlcmlvciBtb3RpdmUgaGVy ZSB0aGF0IEknZCBsaWtlIHRvIGRpc2N1c3MNCj4gc29vbikuIMKgT3B0aW9uIDIgaXMgdmVyeSBy aWdpZCBhbmQgbGVhdmVzIGxpdHRsZSByb29tIGZvciBleHRlbnNpb24uIMKgSSBhbHNvDQo+IHRo aW5rIGl0J3MgbWlzbGVhZGluZyB0byBzdWdnZXN0IHRoYXQgb3B0aW9uIDIgYWxsb3dzIHRoZSBp bml0aWF0b3IgdG8gcmUtdXNlDQo+IHRoZSBSRkMgNTg4MCBzdGF0ZSBtYWNoaW5lLiDCoEJlY2F1 c2Ugb2YgdGhlIGRpZmZlcmVuY2VzIGluIHByb2NlZHVyZQ0KPiBpbnRyb2R1Y2VkIGJ5IFMtQkZE LCB0aGUgc3RhdGUtbWFjaGluZSBpcyBvbmx5IHN1cGVyZmljaWFsbHkgc2ltaWxhci4gwqBJdCBt YXkNCj4gaGF2ZSB0aGUgc2FtZSBzZXQgb2Ygc3RhdGVzIGJ1dCB0aGUgZGV0YWlscyBvZiB0aGUg dHJhbnNpdGlvbnMgYXJlIHF1aXRlDQo+IGRpZmZlcmVudC4gwqBUaGVyZWZvcmUsIEkgc2VlIGxp dHRsZSB2YWx1ZSBpbiBvcHRpb24gMi4NCg0KR29vZCBwb2ludHMuIExvb2tzIGxpa2UgY29uc2Vu c3VzIGlzIHBvaW50aW5nIHRvIG9wdGlvbiAxLCB0aGUgd2F5IGl0IGlzIGN1cnJlbnRseSBkZXNj cmliZWQgaW4gdGhlIFMtQkZELUJhc2UgZG9jdW1lbnQuIEkgd2lsbCBwbGFuIHRvIHByb2NlZWQg YXMgaXMuDQoNCkFuZCBsb29raW5nIGZvcndhcmQgdG8gaGVhcmluZyB5b3VyIHVsdGVyaW9yIG1v dGl2ZSBzb29uIDopDQoNCj4gDQo+IE15IDIgY2VudHMsDQoNCllvdXIgY29tbWVudHMgd2VyZS9h cmUgd29ydGggd2F5IG1vcmUgdGhhbiAyIGNlbnRzLCB0aGFua3MhDQoNCi1Ob2JvDQoNCj4gDQo+ IHJlZ2FyZHMsDQo+IFBhYmxvDQo+IA0KPiBPbiBUaHUsIEp1bCAyNCwgMjAxNCBhdCA5OjMwIEFN LCBOb2JvIEFraXlhIChub2JvKSA8bm9ib0BjaXNjby5jb20+DQo+IHdyb3RlOg0KPiBIaSBCRkRl cnMsDQo+IA0KPiBJbiBvcmRlciBmb3IgdXMgdG8gcHJvZ3Jlc3MgUy1CRkQgQmFzZSBhbmQgSVAg ZG9jdW1lbnRzLCB3ZSBuZWVkIHlvdXINCj4gaW5wdXQgb24gZm9sbG93aW5nIDIgcG9pbnRzLg0K PiANCj4gRGV0YWlscyBjYW4gYmUgZm91bmQgaW4gcGFnZXMgMyBhbmQgNSBvZjoNCj4gaHR0cDov L3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85MC9zbGlkZXMvc2xpZGVzLTkwLWJmZC0yLnBwdHgN Cj4gDQo+IA0KPiA9PSBEb2N1bWVudCBTdHJ1Y3R1cmU6DQo+IA0KPiAxKSBTLUJGRC1CYXNlIGRv Y3VtZW50IHRvIGRlc2NyaWJlIFVEUCBhbmQgQkZEIGhlYWRlcnMuDQo+IMKgIMKgIGEpIFMtQkZE LUlQIGRvY3VtZW50IHRvIGRlc2NyaWJlIElQIGFuZCBNUExTIGRhdGEgcGxhbmUgaGVhZGVycy4N Cj4gwqAgwqAgYikgUy1CRkQtU1IgZG9jdW1lbnQgdG8gZGVzY3JpYmUgU1BSSU5HIGFuZCBkYXRh IHBsYW5lcyBpdCB1c2VzLg0KPiDCoCDCoCBjKSBJZiBTLUJGRC1JUC1MZXNzIGRvY3VtZW50IGlz IG5lZWRlZCwgaXQgd2lsbCBkZXNjcmliZSBBQ2ggYW5kIGNsYXJpZnkNCj4gdGhhdCBVRFAgaXMg bm90IGFwcGxpY2FibGUuDQo+IA0KPiAyKSBTLUJGRCBCYXNlIGRvY3VtZW50IHRvIGRlc2NyaWJl IEJGRCBoZWFkZXIuDQo+IMKgIMKgIGEpIFMtQkZELUlQIGRvY3VtZW50IHRvIGRlc2NyaWJlIFVE UCwgSVAgYW5kIE1QTFMgZGF0YSBwbGFuZSBoZWFkZXJzLg0KPiDCoCDCoCBiKSBTLUJGRC1TUiBk b2N1bWVudCB0byBkZXNjcmliZSBVRFAsIFNQUklORyBhbmQgZGF0YSBwbGFuZXMgaXQgdXNlcy4N Cj4gwqAgwqAgYykgSWYgUy1CRkQtSVAtTGVzcyBkb2N1bWVudCBpcyBuZWVkZWQsIGl0IHdpbGwg ZGVzY3JpYmUgQUNoLg0KPiANCj4gRnJhbmtseSBuZWl0aGVyIGFyZSBwZXJmZWN0bHkgY2xlYW4u IEFwcHJvYWNoICgxKSBjcmVhdGVzIGEgc3BlY2lhbCBjYXNlIChJUC0NCj4gbGVzcykgd2hpbHN0 IGFwcHJvYWNoICgyKSByZXF1aXJlcyBVRFAgdG8gYmUgcmVwZWF0ZWQgaW4gSVAgYW5kIFNSDQo+ IGRvY3VtZW50cy4gQXV0aG9ycyBhcmUgb2sgdG8gZ28gd2l0aCBlaXRoZXIgYXBwcm9hY2ggZnJv bSBhYm92ZSwgZ2l2ZW4NCj4gV0cgY29uc2Vuc3VzLg0KPiANCj4gDQo+ID09IFNCRkRSZWZsZWN0 b3Igc3RhdGUgZmllbGQgc2V0dGluZyBpbiBzZW5kaW5nIFMtQkZEIHBhY2tldHMuDQo+IA0KPiAx KSBTQkZEUmVmbGVjdG9yIHRvIHNldCBpdHMgbG9jYWwgc3RhdGUgW1VQIG9yIEFETUlORE9XTl0u DQo+IA0KPiAyKSBTQkZEUmVmbGVjdG9yIHRvIHNldCBbQURNSU5ET1dOIG9yIHJlZmxlY3QgcmVj ZWl2ZWQgc3RhdGVdLg0KPiANCj4gRm9yIHByb3MvY29ucywgcGxlYXNlIHZpZXcgdGhlIHNsaWRl LiBTLUJGRC1CYXNlIGRvY3VtZW50IGlzIGN1cnJlbnRseQ0KPiBzdHJ1Y3R1cmVkIHdpdGggKDEp LiBTcGVha2luZyB3aXRoIGNvdXBsZSBvZiBmb2xrcyBvZmZsaW5lLCBpdCBzb3VuZHMgbGlrZSAo MSkgaXMNCj4gcHJlZmVycmVkIHdoaWNoIGFsaWducyB3aXRoIHRob3VnaHRzIGZyb20gbW9zdCBh dXRob3JzLiBXZSB3aWxsIHBsYW4gdG8gZ28NCj4gd2l0aCAoMSkgdW5sZXNzIHRoZXJlIGFyZSBz dHJvbmcgb2JqZWN0aW9ucy4NCj4gDQo+IA0KPiA9PSBBZGRpdGlvbmFsbHkgLi4uDQo+IA0KPiBX ZWxjb21pbmcgY29tbWVudHMgYW5kIGRpc2N1c3Npb25zIG9uIHBhZ2VzIDYgYW5kIDcuIE5vdGUs IHRoZXNlIGFyZSBub3QNCj4gZ2F0aW5nIHRoZSBwcm9ncmVzcyBvZiBTLUJGRC1CYXNlL0lQIGRy YWZ0cyBhdCB0aGUgbW9tZW50IGJ1dCBnb29kIHRvcGljcw0KPiB0byBkaXNjdXNzLg0KPiANCj4g DQo+IFRoYW5rcyENCj4gDQo+IC1Ob2JvDQoNCg== From nobody Sun Jul 27 12:56:34 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D571A01E1; Sun, 27 Jul 2014 12:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-z0xIziygvF; Sun, 27 Jul 2014 12:56:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9BB1A020B; Sun, 27 Jul 2014 12:56:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-intervals-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140727195629.17580.74582.idtracker@ietfa.amsl.com> Date: Sun, 27 Jul 2014 12:56:29 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/u_jq50topuimOvR8VpX55-a1ZTI Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 19:56:31 -0000 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 : Common Interval Support in BFD Authors : Nobo Akiya Marc Binderberger Greg Mirsky Filename : draft-ietf-bfd-intervals-02.txt Pages : 8 Date : 2014-07-27 Abstract: Some BFD implementations may be restricted to only support several interval values. When such BFD implementations speak to each other, there is a possibility of two sides not being able to find a common interval value to run BFD sessions. This document defines a small set of interval values for BFD that we call "Common intervals", and recommends implementations to support the defined intervals. This solves the problem of finding an interval value that both BFD speakers can support while allowing a simplified implementation as seen for hardware-based BFD. It does not restrict an implementation from supporting more intervals in addition to the Common intervals. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-intervals/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-intervals-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-intervals-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 27 13:00:59 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428B21A0267 for ; Sun, 27 Jul 2014 13:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNGGGaPBkV83 for ; Sun, 27 Jul 2014 13:00:55 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9181A02C1 for ; Sun, 27 Jul 2014 13:00:43 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 9BC0F2AA0F; Sun, 27 Jul 2014 20:00:41 +0000 (GMT) Date: Sun, 27 Jul 2014 13:01:46 -0700 From: Marc Binderberger To: Jeffrey Haas Message-ID: <20140727130146281044.87376e48@sniff.de> In-Reply-To: <20140716180444.GL25188@pfrc> References: <20140630163846.GA11842@pfrc> <20140716180444.GL25188@pfrc> Subject: Re: WGLC concluded for draft-ietf-bfd-intervals MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/dk4YByGzGzsk1U8xvCxYfK7Os_M Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 20:00:57 -0000 Hello Jeff & BFD experts, > Marc had one additional clarification regarding the 3.3ms value to be added > to the document. Once an I-D has been published containing this > information, the document will be submitted to the IESG. version -02 uploaded: The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-intervals/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-intervals-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-intervals-02 Thanks & Regards, Marc On Wed, 16 Jul 2014 14:04:44 -0400, Jeffrey Haas wrote: > On Mon, Jun 30, 2014 at 12:38:46PM -0400, Jeffrey Haas wrote: >> We would like to initiate the start of Working Group Last Call for >> Common Interval Support in BFD: >> >> http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 >> >> Note that the intended status of this document is INFORMATIONAL. >> >> Please send your comments, including whether you think the draft is ready >> for publication or not, to the list no later than July 15. > > WGLC has concluded. My judgment is that while support from non-authors is > somewhat weak, there has been no objection to the draft. > > Given that the author set also represents multiple vendors and that the > status of this Informational draft is to assist in the creation of BFD > stacks that are cross-vendor interoperable, I believe this document has > sufficient consensus to continue. > > Marc had one additional clarification regarding the 3.3ms value to be added > to the document. Once an I-D has been published containing this > information, the document will be submitted to the IESG. > > -- Jeff > From nobody Sun Jul 27 13:38:30 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D141A031A for ; Sun, 27 Jul 2014 13:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCl95Hm8H-EF for ; Sun, 27 Jul 2014 13:38:27 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 954141A02DF for ; Sun, 27 Jul 2014 13:38:27 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-90-53d50da04fa6 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 4B.CB.25146.0AD05D35; Sun, 27 Jul 2014 16:33:04 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Sun, 27 Jul 2014 16:38:19 -0400 From: Gregory Mirsky To: Marc Binderberger , Jeffrey Haas Subject: RE: WGLC concluded for draft-ietf-bfd-intervals Thread-Topic: WGLC concluded for draft-ietf-bfd-intervals Thread-Index: AQHPoSB3cGrr1/hydkCWRu+kKEkmbJu0q/0A///G7dA= Date: Sun, 27 Jul 2014 20:38:19 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7F55FB@eusaamb103.ericsson.se> References: <20140630163846.GA11842@pfrc> <20140716180444.GL25188@pfrc> <20140727130146281044.87376e48@sniff.de> In-Reply-To: <20140727130146281044.87376e48@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyuXRPrO4C3qvBBgsXa1jsP/iW1WL2lf/M Fp//bGN0YPZYsuQnk8fl3q2sHq2ru1kCmKO4bFJSczLLUov07RK4Mg5tdS24JlCxbcdG1gbG c7xdjJwcEgImEs9PLGOGsMUkLtxbz9bFyMUhJHCUUWLZkivsIAkhgeWMEs+6rUBsNgEjiRcb e8DiIgIuEoe+bGYCsZkFNCWaTnwGiwsLWEocX3OPDaLGSuLXv3dMMPaNk5tZuhg5OFgEVCV+ tXmBhHkFfCU+3lzFBBIWEiiS2DAlHiTMKWAq0TnrGiuIzQh02vdTa6A2iUvcejKfCeJkAYkl e85DnS8q8fLxP1YIW0lizutrzBD1OhILdn9ig7C1JZYtfM0MsVZQ4uTMJywTGMVmIRk7C0nL LCQts5C0LGBkWcXIUVqcWpabbmS4iREYM8ck2Bx3MC74ZHmIUYCDUYmH9wHr1WAh1sSy4src Q4zSHCxK4rya1fOChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTD215iun3iLuy7ipGv+w6ZL F3UfFq2JX/JC+4dNHmf1gSCek4uFIroW8z5UNs6VZtj9ud43a3HkgbtpCd+TZxr5mfd3vlnu mPKTJ17wXgJ7bfJKybV8Gz/JvnKa6DKj+pOe8JzdG5UmabiaXLKSfcDGOv/R1c8qe5m3+elG Gsx5Ur8i/mfnFC8lluKMREMt5qLiRABsp6j5egIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/b_weQIqIkZD1oVwbz2c4JCi1H_w Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 20:38:29 -0000 Many thanks, Marc!=20 Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc Binderber= ger Sent: Sunday, July 27, 2014 1:02 PM To: Jeffrey Haas Cc: rtg-bfd@ietf.org Subject: Re: WGLC concluded for draft-ietf-bfd-intervals=20 Hello Jeff & BFD experts, > Marc had one additional clarification regarding the 3.3ms value to be=20 > added to the document. Once an I-D has been published containing this=20 > information, the document will be submitted to the IESG. version -02 uploaded: The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-intervals/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-intervals-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-intervals-02 Thanks & Regards, Marc On Wed, 16 Jul 2014 14:04:44 -0400, Jeffrey Haas wrote: > On Mon, Jun 30, 2014 at 12:38:46PM -0400, Jeffrey Haas wrote: >> We would like to initiate the start of Working Group Last Call for=20 >> Common Interval Support in BFD: >>=20 >> http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 >>=20 >> Note that the intended status of this document is INFORMATIONAL. >>=20 >> Please send your comments, including whether you think the draft is=20 >> ready for publication or not, to the list no later than July 15. >=20 > WGLC has concluded. My judgment is that while support from=20 > non-authors is somewhat weak, there has been no objection to the draft. >=20 > Given that the author set also represents multiple vendors and that=20 > the status of this Informational draft is to assist in the creation of=20 > BFD stacks that are cross-vendor interoperable, I believe this=20 > document has sufficient consensus to continue. >=20 > Marc had one additional clarification regarding the 3.3ms value to be=20 > added to the document. Once an I-D has been published containing this=20 > information, the document will be submitted to the IESG. >=20 > -- Jeff >=20 From nobody Mon Jul 28 09:28:27 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CE81A0323 for ; Mon, 28 Jul 2014 09:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGtu2sE0RiP5 for ; Mon, 28 Jul 2014 09:28:22 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 396691A0342 for ; Mon, 28 Jul 2014 09:28:22 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 0270EC3DF; Mon, 28 Jul 2014 12:28:21 -0400 (EDT) Date: Mon, 28 Jul 2014 12:28:21 -0400 From: Jeffrey Haas To: Marc Binderberger Subject: Re: WGLC concluded for draft-ietf-bfd-intervals Message-ID: <20140728162821.GI22665@pfrc> References: <20140630163846.GA11842@pfrc> <20140716180444.GL25188@pfrc> <20140727130146281044.87376e48@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140727130146281044.87376e48@sniff.de> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/9y3S-SnG5kfOukXrWHhVuEXDcWY Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 16:28:25 -0000 On Sun, Jul 27, 2014 at 01:01:46PM -0700, Marc Binderberger wrote: > Hello Jeff & BFD experts, > > > Marc had one additional clarification regarding the 3.3ms value to be added > > to the document. Once an I-D has been published containing this > > information, the document will be submitted to the IESG. > > version -02 uploaded: > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-bfd-intervals/ The change covers the lingering discussion item. I've done the shepherd writeup and have submited the document to the IESG for publication. -- Jeff From nobody Mon Jul 28 23:03:56 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51A01A055D for ; Mon, 28 Jul 2014 23:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhJmWJFRg9sn for ; Mon, 28 Jul 2014 23:03:54 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 985881A01FF for ; Mon, 28 Jul 2014 23:03:53 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id D68592AA0F; Tue, 29 Jul 2014 06:03:47 +0000 (GMT) Date: Mon, 28 Jul 2014 23:03:49 -0700 From: Marc Binderberger To: Nobo Akiya (nobo) , Pablo Frank Message-ID: <20140728230349548813.048d9b16@sniff.de> In-Reply-To: References: Subject: RE: S-BFD open items, seeking comments MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/aYUk-qrTp08HwqAeXR1pYh7HRrA Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 06:03:55 -0000 Hello Nobo and Pablo, >> Regarding the document structure: >>=20 >> I think I prefer the option where the base S-BFD draft does not specify = UDP >> headers. UDP is not intrinsic to BFD although it is commonly used in=20 >> several >> =09[...] >=20 > You are the third person who voiced the preference for this document=20 > structure on the list, as opposed to zero(0) preferring the current=20 > document structure. Number of votes are small, but it's probably reasonab= le=20 > to conclude that we should go with: >=20 >> 2) S-BFD Base document to describe BFD header. >> a) S-BFD-IP document to describe UDP, IP and MPLS data plane headers= . >> b) S-BFD-SR document to describe UDP, SPRING and data planes it uses= . >> c) If S-BFD-IP-Less document is needed, it will describe ACh. >=20 > I will take a crack at restructuring the S-BFD documents soon. You won't be surprised I prefer (2) as well if I have the choice ;-) >> Regarding the state field in the S-BFD packets: >>=20 >> I think I strongly prefer option 1. By giving the reflector an independ= ent >> state, it leaves open the possibility of extending the state machine in = the >> future (I do have an ulterior motive here that I'd like to discuss ?!? ... how can option 1 be extended? Well, of course you can always modify= a=20 definition but S-BFD base defines the state of the reflector as Up unless= =20 it's AdminDown for administrative reasons. How is this an independent state= ? Not to mention: an independent state on the reflector - wasn't the reflecto= r=20 supposed to be "stateless" ? (i.e. not having many state variables to=20 remember) >> Option 2 is very rigid and leaves little room for extension. I'm almost wondering if we talk about different things? Option 2 means the= =20 reflector just reflects the incoming state field. Unless it's set to=20 AdminDown for administrative reasons. In which sense is this rigid? =46rom what you write I would guess you want to have a state on the reflect= or=20 per session or group of sessions, in any case a larger number of states? >> think it's misleading to suggest that option 2 allows the initiator to= =20 >> re-use >> the RFC 5880 state machine. Because of the differences in procedure >> introduced by S-BFD, the state-machine is only superficially similar. I= t=20 >> may >> have the same set of states but the details of the transitions are quite >> different. Can you elaborate on this? Not that I promote the re-use of RFC5880 state= =20 machine but you can actually run it against a state reflector and it works= =20 (talking about todays RFC5880 BFD, of course). In which sense are the detai= ls=20 of the transition quite different for S-BFD? Nobo, there was the other discussion about the discriminator pool. What is= =20 the status? Do we introduce a new UDP port for reflector->Initiator=20 sessions? Or do you propose setting the source port to the S-BFD port? Or= =20 something else? Thanks & Regards, Marc From nobody Tue Jul 29 05:39:25 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0301B2848 for ; Tue, 29 Jul 2014 05:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6JIow_ZDA7R for ; Tue, 29 Jul 2014 05:39:21 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF1721B283E for ; Tue, 29 Jul 2014 05:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4584; q=dns/txt; s=iport; t=1406637561; x=1407847161; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hL4YGlQ8r+pjDFklQx9Nkg4+A+OxpLKYhDZEJIr06No=; b=WKqbq93A1IhqOcMCEBcod4rjsnhZiMFhbPQGo7tk9O3Gz+xXBnzbMsjd d4Umf7Ku1tWClbOZw49RuV8yKDteaR59oWew6CjtRBeMZwNBwRxgAmWvi kMyMKy8CIJTdCazeTL5hJzN7u1R+a3cExGpIo72XTPkqmXxmzMfdd0EGe w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAD6V11OtJA2D/2dsb2JhbABZgmokgSkE0zUBgQ0Wd4QDAQEBAwEnEz8MBAIBCBEEAQELFAkHMhQJCAEBBAENBQiIMggBvwsXjxsxBwaDKYEbAQSOV6FDg0lsgUU X-IronPort-AV: E=Sophos;i="5.01,757,1400025600"; d="scan'208";a="343539575" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-2.cisco.com with ESMTP; 29 Jul 2014 12:39:20 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6TCdKio028669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jul 2014 12:39:20 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Tue, 29 Jul 2014 07:39:19 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger , Pablo Frank Subject: RE: S-BFD open items, seeking comments Thread-Topic: S-BFD open items, seeking comments Thread-Index: Ac+nQ1JkI7xBGFdISdiCs4MsO7iGlAA+ApiAAGJabBAAVf/wgAAC0Urw Date: Tue, 29 Jul 2014 12:39:19 +0000 Message-ID: References: <20140728230349548813.048d9b16@sniff.de> In-Reply-To: <20140728230349548813.048d9b16@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ArE-pSSkqC0NMNXy9ChCbivfrGE Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 12:39:22 -0000 Hi Marc, > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Tuesday, July 29, 2014 2:04 AM > To: Nobo Akiya (nobo); Pablo Frank > Cc: rtg-bfd@ietf.org > Subject: RE: S-BFD open items, seeking comments >=20 > Hello Nobo and Pablo, >=20 > >> Regarding the document structure: > >> > >> I think I prefer the option where the base S-BFD draft does not > >> specify UDP headers. UDP is not intrinsic to BFD although it is > >> commonly used in several > >> [...] > > > > You are the third person who voiced the preference for this document > > structure on the list, as opposed to zero(0) preferring the current > > document structure. Number of votes are small, but it's probably > > reasonable to conclude that we should go with: > > > >> 2) S-BFD Base document to describe BFD header. > >> a) S-BFD-IP document to describe UDP, IP and MPLS data plane heade= rs. > >> b) S-BFD-SR document to describe UDP, SPRING and data planes it us= es. > >> c) If S-BFD-IP-Less document is needed, it will describe ACh. > > > > I will take a crack at restructuring the S-BFD documents soon. >=20 > You won't be surprised I prefer (2) as well if I have the choice ;-) Yup, this is indeed the consensus. I have spent some time last night re-structuring the documents, as well as = incorporating comments from you and Greg. We should be able to roll out new revisions of -base and -ip documents soon= . >=20 >=20 >=20 > >> Regarding the state field in the S-BFD packets: > >> > >> I think I strongly prefer option 1. By giving the reflector an > >> independent state, it leaves open the possibility of extending the > >> state machine in the future (I do have an ulterior motive here that > >> I'd like to discuss >=20 > ?!? ... how can option 1 be extended? Well, of course you can always modi= fy > a definition but S-BFD base defines the state of the reflector as Up unle= ss > it's AdminDown for administrative reasons. How is this an independent > state? >=20 > Not to mention: an independent state on the reflector - wasn't the reflec= tor > supposed to be "stateless" ? (i.e. not having many state variables to > remember) >=20 >=20 > >> Option 2 is very rigid and leaves little room for extension. >=20 > I'm almost wondering if we talk about different things? Option 2 means th= e > reflector just reflects the incoming state field. Unless it's set to Admi= nDown > for administrative reasons. In which sense is this rigid? >=20 >=20 > From what you write I would guess you want to have a state on the reflect= or > per session or group of sessions, in any case a larger number of states? >=20 >=20 > >> think it's misleading to suggest that option 2 allows the initiator to > >> re-use > >> the RFC 5880 state machine. Because of the differences in procedure > >> introduced by S-BFD, the state-machine is only superficially similar. = It > >> may > >> have the same set of states but the details of the transitions are qui= te > >> different. >=20 > Can you elaborate on this? Not that I promote the re-use of RFC5880 state > machine but you can actually run it against a state reflector and it work= s > (talking about todays RFC5880 BFD, of course). In which sense are the det= ails > of the transition quite different for S-BFD? I'll leave above between you and Pablo, but the rough consensus (at least i= n my eyes as an individual contributor) is pointing to option 1. This is ba= sed on few folks chimed in on the list in last few weeks as well as speakin= g to few folks in Toronto last week. At the end, things will work either wa= y but we need to choose one to allow implementations to move forward (I kno= w of one implementation that is being worked on). As the lead contributor o= f this document, I'm making the call to proceed with option 1. Sorry Marc, = but I appreciate that you have raised this point and made it aware by every= one! >=20 >=20 >=20 > Nobo, there was the other discussion about the discriminator pool. What i= s > the status? Do we introduce a new UDP port for reflector->Initiator > sessions? Or do you propose setting the source port to the S-BFD port? = Or > something else? We've closed on this one already, and some clarification texts will be adde= d in the -base as result. Hopefully we can roll out the revision this weeke= nd. Once it's out, can you take a look and see if you have any further conc= erns? Thanks! -Nobo >=20 >=20 > Thanks & Regards, > Marc From nobody Tue Jul 29 13:19:08 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BFE1A00B2 for ; Tue, 29 Jul 2014 13:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoslcQIScbwc for ; Tue, 29 Jul 2014 13:19:02 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 68D671B2A2D for ; Tue, 29 Jul 2014 13:17:29 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1AFBFC3DC; Tue, 29 Jul 2014 16:17:29 -0400 (EDT) Date: Tue, 29 Jul 2014 16:17:29 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: BFD status on IETF wiki Message-ID: <20140729201729.GB24324@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/4nr6LpoK02CWQpT_rMe4-yQvqtU X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 20:19:03 -0000 Working Group, In order to help keep better track of where document work is for the WG, Nobo and I have put together a wiki entry covering existing work along with recently presented work. http://wiki.tools.ietf.org/wg/bfd/trac/wiki If you recently presented a draft to the most recent IETF session in Toronto, please check the status in this document. Nobo and I probably already sent you email about our perceived status for your draft. -- Jeff From nobody Thu Jul 31 05:06:28 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEFD1A0B14; Thu, 31 Jul 2014 05:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAplh5bunbjh; Thu, 31 Jul 2014 05:06:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A511F1A0AFF; Thu, 31 Jul 2014 05:06:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-hmac-sha-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140731120608.12963.34029.idtracker@ietfa.amsl.com> Date: Thu, 31 Jul 2014 05:06:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/U9CHOkzVJr2HFcAfNApT_o7JtaA Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 12:06:13 -0000 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 : Authenticating BFD using HMAC-SHA-2 procedures Authors : Dacheng Zhang Manav Bhatia Vishwas Manral Mahesh Jethanandani Filename : draft-ietf-bfd-hmac-sha-05.txt Pages : 8 Date : 2014-05-24 Abstract: This document describes the mechanism to authenticate Bidirectional Forwarding Detection (BFD) protocol packets using Hashed Message Authentication Mode (HMAC) with the SHA-256, SHA-384, and SHA-512 algorithms. The described mechanism uses the Generic Cryptographic Authentication and Generic Meticulous Cryptographic Authentication sections to carry the authentication data. This document updates, but does not supersede, the cryptographic authentication mechanism specified in RFC 5880. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-hmac-sha/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-hmac-sha-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-hmac-sha-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 31 09:12:24 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421C11A00D5 for ; Thu, 31 Jul 2014 09:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48hvU433RR9b for ; Thu, 31 Jul 2014 09:12:20 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 764321A01F3 for ; Thu, 31 Jul 2014 09:12:20 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id ik5so4530731vcb.20 for ; Thu, 31 Jul 2014 09:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V/y4MpEDW79uQdwcU6XjVuQn9nbz3S95in+pioawu1c=; b=IYOW6nZeVOC20K0mq5QVuA6rjLZmpL1jMmNo/8PAYLtz3/BEuQhojREFUQncRwWS8U 0yRpyh7Q2rTvJOsHkA0JBwbtaxEOMnn1Xn0q6cQwjjZG7nb6X/3YfMOvEdgxLUW1TZHn 1EhAwKN/ynJzpA5kBepLy640AQuCxGaqivp0/n66HmmrdDH6XaFIRor6PNr4CEQNxeZz RFGVi5/vkMHQ3uAIvwDQa3ihye1NWSWLIOh/zuNzi4s0GTqjUKCcHVW2w7Xu6EEhNTOK qo0aX2Q6RkDOb2555gFUpgnHJuU5HD3dlID1P0N/O1i3Db6MXfik2HY0nX15P3Xi1/Dk StAA== MIME-Version: 1.0 X-Received: by 10.52.147.15 with SMTP id tg15mr16216307vdb.53.1406823139067; Thu, 31 Jul 2014 09:12:19 -0700 (PDT) Received: by 10.52.144.42 with HTTP; Thu, 31 Jul 2014 09:12:19 -0700 (PDT) In-Reply-To: <20140728230349548813.048d9b16@sniff.de> References: <20140728230349548813.048d9b16@sniff.de> Date: Thu, 31 Jul 2014 12:12:19 -0400 Message-ID: Subject: Re: S-BFD open items, seeking comments From: Pablo Frank To: Marc Binderberger Content-Type: multipart/alternative; boundary=bcaec51ba2a377511304ff7f8920 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Ctkzvr9L9davsDRMvggO0nxCGFw Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 16:12:23 -0000 --bcaec51ba2a377511304ff7f8920 Content-Type: text/plain; charset=UTF-8 Hi Marc, See PF>> below... On Tue, Jul 29, 2014 at 2:03 AM, Marc Binderberger wrote: > > >> Regarding the state field in the S-BFD packets: > >> > >> I think I strongly prefer option 1. By giving the reflector an > independent > >> state, it leaves open the possibility of extending the state machine in > the > >> future (I do have an ulterior motive here that I'd like to discuss > > ?!? ... how can option 1 be extended? Well, of course you can always > modify a > definition but S-BFD base defines the state of the reflector as Up unless > it's AdminDown for administrative reasons. How is this an independent > state? > > Not to mention: an independent state on the reflector - wasn't the > reflector > supposed to be "stateless" ? (i.e. not having many state variables to > remember) Well, it's not completely stateless. It's either "up" or "admin-down" in option 1. I suppose you could argue that it's either "admin-down" or "reflecting" in option 2. I guess what I don't like about option 2 is that if the device is in "reflecting" state, then the state that it emits is not its own state. That's what I meant with the word "independent". Consider the case where the initiator is running the 5880 state machine and enters admin-down. Per the spec, it will send some number of admin-down packets that will get happily reflected by the option 2 reflector. The state from the reflector is now ambiguous. Is it admin-down because the reflector is admin-down or is it admin-down because the initiator is admin-down? That seems a bit fishy. By the way, my reading of the current (option 1) draft is that the reflector would respond to an admin-down packet with an UP state. I'm not sure if that was authors' intent...? Could use some clarifying text. > > >> Option 2 is very rigid and leaves little room for extension. > > I'm almost wondering if we talk about different things? Option 2 means the > reflector just reflects the incoming state field. Unless it's set to > AdminDown for administrative reasons. In which sense is this rigid? > > > From what you write I would guess you want to have a state on the reflector > per session or group of sessions, in any case a larger number of states? > PF>> I've got a half-baked idea about reflector sessions that are associated with point-to-point links (e.g. a bi-directional LSP) could transition into an initiator themselves. The idea is that an S-BFD session (under specific circumstances) could basically morph into a regular BFD session (the main use-case is fast bring-up of protected LSPs). I'm still sketching the idea out on paper though. I haven't convinced myself it works yet... :-) > > >> think it's misleading to suggest that option 2 allows the initiator to > >> re-use > >> the RFC 5880 state machine. Because of the differences in procedure > >> introduced by S-BFD, the state-machine is only superficially similar. > It > >> may > >> have the same set of states but the details of the transitions are quite > >> different. > > Can you elaborate on this? Not that I promote the re-use of RFC5880 state > machine but you can actually run it against a state reflector and it works > (talking about todays RFC5880 BFD, of course). In which sense are the > details > of the transition quite different for S-BFD? > PF>> Mostly the timer usage I think. An RFC 5880 BFD session would start with a slow exchange of packets running at 1 packet per second. S-BFD is explicitly trying to eliminate this slow / sedate bring-up of the session. regards, Pablo --bcaec51ba2a377511304ff7f8920 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi Marc,=C2=A0

    See PF>> below...<= br>

    On Tue, Jul 29= , 2014 at 2:03 AM, Marc Binderberger <marc@sniff.de> wrote:

    >> Regarding the state field in the S-BFD packets:
    >>
    >> I think I strongly prefer option 1. =C2=A0By giving the reflector = an independent
    >> state, it leaves open the possibility of extending the state machi= ne in the
    >> future (I do have an ulterior motive here that I'd like to dis= cuss

    ?!? ... how can option 1 be extended? Well, of course you can always = modify a
    definition but S-BFD base defines the state of the reflector as Up unless it's AdminDown for administrative reasons. How is this an independent s= tate?

    Not to mention: an independent state on the reflector - wasn't the refl= ector
    supposed to be "stateless" ? (i.e. not having many state variable= s to
    remember)

    Well, it's not completely sta= teless. =C2=A0It's either "up" or "admin-down" in o= ption 1. =C2=A0I suppose you could argue that it's either "admin-d= own" or "reflecting" in option 2. =C2=A0I guess what I don&#= 39;t like about option 2 is that if the device is in "reflecting"= state, then the state that it emits is not its own state. =C2=A0That's= what I meant with the word "independent". =C2=A0Consider the cas= e where the initiator is running the 5880 state machine and enters admin-do= wn. =C2=A0Per the spec, it will send some number of admin-down packets that= will get happily reflected by the option 2 reflector. =C2=A0The state from= the reflector is now ambiguous. =C2=A0Is it admin-down because the reflect= or is admin-down or is it admin-down because the initiator is admin-down? = =C2=A0That seems a bit fishy.

    By the way, my reading of the current (option 1) draft is that the= reflector would respond to an admin-down packet with an UP state. =C2=A0I&= #39;m not sure if that was authors' intent...? =C2=A0Could use some cla= rifying text.
    =C2=A0

    >> Option 2 is very rigid and leaves little room for extension.

    I'm almost wondering if we talk about different things? Option 2 = means the
    reflector just reflects the incoming state field. Unless it's set to AdminDown for administrative reasons. In which sense is this rigid?


    >From what you write I would guess you want to have a state on the reflector=
    per session or group of sessions, in any case a larger number of states?

    PF>> =C2=A0I've got a half-bake= d idea about reflector sessions that are associated with point-to-point lin= ks (e.g. a bi-directional LSP) could transition into an initiator themselve= s. =C2=A0The idea is that an S-BFD session (under specific circumstances) c= ould basically morph into a regular BFD session (the main use-case is fast = bring-up of protected LSPs). =C2=A0I'm still sketching the idea out on = paper though. =C2=A0I haven't convinced myself it works yet... :-)

    >> think it's misleading to suggest that option 2 allows the init= iator to
    >> re-use
    >> the RFC 5880 state machine. =C2=A0Because of the differences in pr= ocedure
    >> introduced by S-BFD, the state-machine is only superficially simil= ar. =C2=A0It
    >> may
    >> have the same set of states but the details of the transitions are= quite
    >> different.

    Can you elaborate on this? Not that I promote the re-use of RFC5880 s= tate
    machine but you can actually run it against a state reflector and it works<= br> (talking about todays RFC5880 BFD, of course). In which sense are the detai= ls
    of the transition quite different for S-BFD?

    PF>> Mostly the timer usage I think. =C2=A0An RFC 5880 BFD sess= ion would start with a slow exchange of packets running at 1 packet per sec= ond. =C2=A0S-BFD is explicitly trying to eliminate this slow / sedate bring= -up of the session.

    regards,
    Pablo


    =
    --bcaec51ba2a377511304ff7f8920-- From nobody Thu Jul 31 11:19:00 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3261A011D for ; Thu, 31 Jul 2014 11:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvWIUUksEboQ for ; Thu, 31 Jul 2014 11:18:57 -0700 (PDT) Received: from BAY004-OMC4S12.hotmail.com (bay004-omc4s12.hotmail.com [65.54.190.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8FE51A014F for ; Thu, 31 Jul 2014 11:18:57 -0700 (PDT) Received: from BAY176-W6 ([65.54.190.200]) by BAY004-OMC4S12.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Thu, 31 Jul 2014 11:18:57 -0700 X-TMN: [FiwfqlNK0/ETjQNKZFQbXQPVujdOnEXB] X-Originating-Email: [mishra.ashesh@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_be0e2011-37ee-42c3-b3d7-0a810ff5f73d_" From: Ashesh Mishra To: "rtg-bfd@ietf.org" Subject: Comments on draft-ietf-bfd-hmac-sha-05 Date: Thu, 31 Jul 2014 11:18:57 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 31 Jul 2014 18:18:57.0492 (UTC) FILETIME=[E4EAD140:01CFACEB] Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/YswyV47TtRtiVQ79uOgsQbcV_GI X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 18:18:59 -0000 --_be0e2011-37ee-42c3-b3d7-0a810ff5f73d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Authors=2C While the need for good security within network protocols is paramount=2C h= as there been an analysis on the vulnerability of MD5 and SHA1 (specificall= y in BFD) to cryptanalysis?=20 If the intention is to move towards stronger encryption algorithms for BFD = (especially ones that use larger digests)=2C the increased complexity and c= ost of hardware implementations (and also software implementations=2C but t= o a lesser degree) must be justifiable.=20 Thanks=2C Ashesh Mishra = --_be0e2011-37ee-42c3-b3d7-0a810ff5f73d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Authors=2C

    While the need= for good security within network protocols is paramount=2C has there been = an analysis on the vulnerability of MD5 and SHA1 (specifically in BFD) to c= ryptanalysis?

    If the intention is to move towards stronger encrypti= on algorithms for BFD (especially ones that use larger digests)=2C the incr= eased complexity and cost of hardware implementations (and also software im= plementations=2C but to a lesser degree) must be justifiable.


    T= hanks=2C
    Ashesh Mishra

    = --_be0e2011-37ee-42c3-b3d7-0a810ff5f73d_--