I was just wondering why you would want to write the same information = multiple times instead of just refering to information that is already pres= ent, I guess it will save a lot of time for the WG as well as the authors.<= /div>

=A0

I guess it would apply to both the drafts you state as well as any fut= ure ones.

=A0

I am stating this because I am seeing the discussion on things that ha= ve already been discussed multiple times.

=A0

Thanks,

Vishwas

On Tue, Apr 12, 2011 at 5:40 PM, Bhatia, Manav (= Manav) <manav.bhatia@alcatel-lucent.com> wrote:

Hi Vishwas,

Yes, its very= similar to rfc 6039 but there are a few additional things like key rollove= r, limited intra-session replay and no inter-session replay protection, etc= that have been discussed in this draft. Any document that does gap analysi= s of any routing protocol will have an overlap with rfc 6039, so i dont thi= nk there is anything new here. You will also find substantial overlap in dr= aft-ietf-karp-ospf-analysis and rfc 6039, which is again not surprising bec= ause rfc 6039 talks about the vulnerabilities that exist despite using cryp= tographic authentication.

Cheers, Manav

________________________________=

=A0 =A0 =A0 =A0From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
=A0 =A0 =A0 =A0Sent= : Wednesday, April 13, 2011 5.34 AM

=A0 =A0 =A0 =A0To: Bhatia, Manav (Manav)
=A0 =A0 =A0 = =A0Cc: Alexander Vainshtein; rtg-bfd@ie= tf.org
=A0 =A0 =A0 =A0Subject: Re: BFD Security Gap Analysis

=
=A0 =A0 =A0 =A0Hi Manav,

=A0 =A0 =A0 =A0I was talking about the following (which is about gap an= alysis of BFD):
=A0 =A0 =A0 =A0http://tools.ietf.org/html/rfc6039#page-15<= /a>

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Vishwas

=A0 =A0 =A0 =A0On Tue, Apr 12, 2011 at 1:49 P= M, Bhatia, Manav (Manav) <manav.bhatia@alcatel-lucent.com> wrote:

=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0Hi Vishwas,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0This draft, as the name suggests, just d= oes a gap analysis of BFD security mechanism for KARP WG as it stands today= . It does not fix them and it in fact refers to draft-bhatia-bfd-crypto-aut= h-03.txt for fixing the issues. However, as a result of this gap analysis w= e know that there are a couple of more things that we need to address in dr= aft-bhatia-bfd-crypto-auth document.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Cheers, Manav

=A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0________________________________

=A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
=A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 Sent: Tuesday, April 12, 2011 10.11 PM
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 To: Bhatia, Manav (Manav)
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cc: Alexander Vainshtein; rtg-bfd@ietf.org
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 Subject: Re: BFD Security Gap Analysis

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hi Manav,

= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I havent read the draft, but ju= st seeing the discussion, it seems we have had the discussions on the BFD l= ist as well as in the draft on security issues with protocols (which is now= an RFC).

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 What additional work is bei= ng done here in KARP for the same?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Vishwas<= br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On Tue, Apr 12, 2011 at = 4:01 AM, Bhatia, Manav (Manav) <manav.bhatia@alcatel-lucent.com> wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sasha,<= br>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >= Please note also that in order to be accepted, a replayed BFD
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > packet must fit in= to a relatively short window (3 times that
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > of the =A0= detect interval of the session). Millisecond Tx
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > interval is commonly used for shor= t detection intervals, and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 > this means that in order for the packet to pass throug= h the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > authentica= tion mechanism, replay must be timed with
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > resolution of ~ 10 milliseconds.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Given tha= t the sequence space can wrap around in 7 weeks cant I reply the packet aft= er that? Once I replay a packet with the higher sequence number the receive= r will not process any further packets coming from the source till its sequ= ence space reaches that of the replayed packet. This will cause BFD to go d= own since all legitimate packets will get rejected.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cheers, Man= av

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &= gt;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > Thi= s does not say that BFD cannot be used in such a way as to
=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > be a security breach.<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > But =A0I t= hink that if used reasonably, it makes some of the
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > DoS attacks described in the d= raft somewhat problematic.
=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 > My 2c,
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0Sasha
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >= ;

--00504502b67c66a4aa04a0c35a0e-- From Alexander.Vainshtein@ecitele.com Tue Apr 12 22:15:14 2011 Return-Path: X-Original-To: rtg-bfd@ietfc.amsl.com Delivered-To: rtg-bfd@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8C790E06A3 for ; Tue, 12 Apr 2011 22:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdf4e4iojan5 for ; Tue, 12 Apr 2011 22:15:13 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfc.amsl.com (Postfix) with ESMTP id 084D7E0687 for ; Tue, 12 Apr 2011 22:15:12 -0700 (PDT) X-AuditID: 93eaf2e8-b7c91ae000000a83-a9-4da530fa16c7 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id E6.DB.02691.AF035AD4; Wed, 13 Apr 2011 08:13:30 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Wed, 13 Apr 2011 08:15:09 +0300 From: Alexander Vainshtein To: "Bhatia, Manav (Manav)" Date: Wed, 13 Apr 2011 08:15:09 +0300 Subject: RE: BFD Security Gap Analysis Thread-Topic: BFD Security Gap Analysis Thread-Index: Acv4+oILfEeuQaBtTK2B2k1+obeqCQAADMxQAADHqdAAAJ9QYAAl3M6t Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CFD037C86@INBANSXCHMBSA1.in.alcatel-lucent.com> , <7C362EEF9C7896468B36C9B79200D8350CFD037CBA@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFD037CBA@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUy+dWnL7q/DJb6Gmw9ZGwx5949VovPf7Yx OjB5tD7by+qxZMlPpgCmqAZGm8S8vPySxJJUhZTU4mRbpYCizLLE5EolhcwUWyVDJYWCnMTk 1NzUvBJbpcSCgtS8FCU7LgUMYANUlpmnkJqXnJ+SmZduq+QZ7K9rYWFqqWuoZKembGhszRWS kVmskKqbm5iZo5CbWlycmJ6qABRJ2MKcMfdGP2vBGsGKO6+/sjcwXuLtYuTkkBAwkfh+ehYj hC0mceHeerYuRi4OIYGdjBIzHqxnh3CmMEr8nXWHCaSKTcBWYtPqu2wgtgiQ/XzzLhYQm1lA U6LpxGd2EJtFQFVi/dN9YHFhATWJ7tnLWCHq1SVaLrSxQ9huEuvXHAObwyvgL7HhwFtGiGVf GSV6F/eCJTgF4iTeNKwFsxmBzvt+ag0TxDJxiVtP5jNBnC0gsWTPeWYIW1Ti5eN/rBD1ohJ3 2tczQtTrSCzY/YkNwtaWWLbwNTPEYkGJkzOfsED0SkocXHGDZQKj+CwkK2YhaZ+FpH0WkvYF jCyrGEUzcwpKknLTDYz0UpMzS1JzUvWS83M3MUJSyYsdjLfPaB5itAAGzkRmKe7kfGAqyiuJ NzYwQOEoifO+S1jiKySQDkws2ampBalF8UWlOanFhxiZODilGhidXPd2l12stfh+nvfFTe6f gY47Nz6QKX0qZK5VazJNeXH4jG1O5vXOQq4XnYu38odOZ5HbWXfjv4drX1EeZ9/dkvePXXat vznhGW8Us1rDv8Pvv1jO/fhi28EjQc7Lmsu6Yq3L/ZdsmuvFtSXm1BzPYwLiE/60aAjl2328 cSlpbTjzYkcpi9tKLMUZiYZazEXFiQA2vVNAEAMAAA== Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 05:15:14 -0000 Manav, Lots of thanks for a prompt response. Please see inline below. Regards, Sasha ________________________________________ From: Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] Sent: Tuesday, April 12, 2011 2:01 PM To: Alexander Vainshtein Cc: rtg-bfd@ietf.org Subject: RE: BFD Security Gap Analysis > Sasha, > > Please note also that in order to be accepted, a replayed BFD > > packet must fit into a relatively short window (3 times that > > of the detect interval of the session). Millisecond Tx > > interval is commonly used for short detection intervals, and > > this means that in order for the packet to pass through the > > authentication mechanism, replay must be timed with > > resolution of ~ 10 milliseconds. > Given that the sequence space can wrap around in 7 weeks cant I reply the= packet after that? Once I replay > a packet with the higher sequence number= the receiver will not process any further packets coming from the > source= till its sequence space reaches that of the replayed packet. This will caus= e BFD to go down since all > legitimate packets will get rejected. Not exactly. Please consider the following example: Tx interval =3D 1 ms, De= tect multiply =3D 3, meticulously keyed MDA5 or SHA1 authentication in use. Once you've captured a valid packet, you will have to wait for 7+ weeks, the= n to shoot the spoofed packet in such a way that it would reach the destinat= ion within a 9 ms window preceding reception of the legitimate packet with t= he same sequence number (otherwise the spoofed packet will not be accepted).= If you succeed (requires some pretty accurate timing), you can make the ses= sion to advance the last received sequence number by at most 8. As a consequ= ence, between 1 to 8 legitimate packets would be rejected with a 75% chance= to bring the session down, but not ALL legitimate packets... > Cheers, Manav > > > > This does not say that BFD cannot be used in such a way as to > > be a security breach. > > But I think that if used reasonably, it makes some of the > > DoS attacks described in the draft somewhat problematic. > > > > My 2c, > > Sasha > > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From toms.sanders@gmail.com Wed Apr 13 09:04:58 2011 Return-Path: X-Original-To: rtg-bfd@ietfc.amsl.com Delivered-To: rtg-bfd@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E3BE3E07CE for ; Wed, 13 Apr 2011 09:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpsiUIFz-sFI for ; Wed, 13 Apr 2011 09:04:58 -0700 (PDT) Received: from mail-fx0-f66.google.com (mail-fx0-f66.google.com [209.85.161.66]) by ietfc.amsl.com (Postfix) with ESMTP id 035F4E07EC for ; Wed, 13 Apr 2011 09:04:57 -0700 (PDT) Received: by fxm1 with SMTP id 1so163915fxm.1 for ; Wed, 13 Apr 2011 09:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7WoCfTC/sBZA1sWMzZ1IG6mQ6ZUB1p7YAGBljDauh1o=; b=iYDyOI7UdwvRt2HiqqvdhPb5luFzEpALoGX9Ho8dKA3dWVrqqa0DMMPOFFdHRMZS8t p5/tBUJ6tX1uhsbMrnlu96i/QghHCuBxz78DOcesVNU6pp77OBg5FVYAthgx3Y/cqJcM RyKZmOAB47cstuVPc0AGWkEBNTa0Tp3hkRZGk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Po8E2EWF9AIZpFOcBYx/nHNcWBkrFpVZCkfC2on30fmisLNL/synxwtvoTN+ZDVhYk g6CTKxy9zFA3tFIqyih9F6Ge/ND0BopAAjOOtdD/X55Ry/tnwIMJDIpy619bkU4wqeyF 9P31788EYOg/LceOK2a2U2gELbNFNlD15pDHU= MIME-Version: 1.0 Received: by 10.223.28.19 with SMTP id k19mr135993fac.139.1302710539615; Wed, 13 Apr 2011 09:02:19 -0700 (PDT) Received: by 10.223.112.11 with HTTP; Wed, 13 Apr 2011 09:02:19 -0700 (PDT) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350CFD037C86@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CFD037CBA@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Wed, 13 Apr 2011 21:32:19 +0530 Message-ID: Subject: Re: BFD Security Gap Analysis From: Tom Sanders To: Alexander Vainshtein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 16:04:59 -0000 Sasha and Manav, I think the replay attack that the gap analysis draft describes is primarily for the non-meticulous authentication schemes, which i wager would be far more widely deployed because of some optimizations that can be done in the HW (keep sending the same BFD packet if nothing really changes). Given this it still makes sense to include this, however a note clarifying this is patently warranted. Toms On 13 April 2011 10:45, Alexander Vainshtein wrote: > Manav, > Lots of thanks for a prompt response. > > Please see inline below. > > Regards, > =C2=A0 =C2=A0 Sasha > > ________________________________________ > From: Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > Sent: Tuesday, April 12, 2011 2:01 PM > To: Alexander Vainshtein > Cc: rtg-bfd@ietf.org > Subject: RE: BFD Security Gap Analysis > >> Sasha, > >> > Please note also that in order to be accepted, a replayed BFD >> > packet must fit into a relatively short window (3 times that >> > of the =C2=A0detect interval of the session). Millisecond Tx >> > interval is commonly used for short detection intervals, and >> > this means that in order for the packet to pass through the >> > authentication mechanism, replay must be timed with >> > resolution of ~ 10 milliseconds. > >> Given that the sequence space can wrap around in 7 weeks cant I reply th= e packet after that? Once I replay > a packet with the higher sequence numb= er the receiver will not process any further packets coming from the > sour= ce till its sequence space reaches that of the replayed packet. This will c= ause BFD to go down since all > legitimate packets will get rejected. > > Not exactly. Please consider the following example: Tx interval =3D 1 ms,= Detect multiply =3D 3, meticulously keyed MDA5 or SHA1 authentication in u= se. > > Once you've captured a valid packet, you will have to wait for 7+ weeks, = then to shoot the spoofed packet in such a way that it would reach the dest= ination within a 9 ms window preceding reception of the legitimate packet w= ith the same sequence number (otherwise the spoofed packet will not be acce= pted). If you succeed (requires some pretty accurate timing), you can make = the session to advance the last received sequence number by at most 8. As a= consequence, between 1 to 8 legitimate packets would be rejected with a 75= % chance to bring the session down, but not ALL legitimate packets... > > > > >> Cheers, Manav > >> > >> > This does not say that BFD cannot be used in such a way as to >> > be a security breach. >> > But =C2=A0I think that if used reasonably, it makes some of the >> > DoS attacks described in the draft somewhat problematic. >> > >> > My 2c, >> > =C2=A0 =C2=A0 =C2=A0Sasha >> > > > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. > > --=20 Toms. From loa@pi.nu Thu Apr 14 04:08:56 2011 Return-Path: X-Original-To: rtg-bfd@ietfc.amsl.com Delivered-To: rtg-bfd@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E6D84E070A for ; Thu, 14 Apr 2011 04:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXlGKFR4gE0M for ; Thu, 14 Apr 2011 04:08:56 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfc.amsl.com (Postfix) with ESMTP id 3F642E06F4 for ; Thu, 14 Apr 2011 04:08:53 -0700 (PDT) Received: from [192.168.1.68] (unknown [58.69.139.171]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id B8B062A8001; Thu, 14 Apr 2011 13:08:49 +0200 (CEST) Message-ID: <4DA6D5BB.80209@pi.nu> Date: Thu, 14 Apr 2011 19:08:43 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Rtg-bfd@ietf.org, Ross Callon , George Swallow , David Ward , Jeff Haas Subject: Re: [RTG-DIR] bfd working group last call on draft-ietf-mpls-tp-cc-cv-rdi-03 References: <4D93457F.4080500@pi.nu> <4D9346E4.2080606@pi.nu> In-Reply-To: <4D9346E4.2080606@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2011 11:08:57 -0000 All, this working group last call has ended! I've not seen any comments! /Loa On 2011-03-30 23:06, Loa Andersson wrote: > All, > > someone = possibly me - mixed the mail addresses up. This was intended > for the bfd working group! Though comments from the routing directorate > would be welcome! > > /Loa > > On 2011-03-30 17:00, Loa Andersson wrote: >> BFD working group, >> >> This is to start a 19 days BFD working group last on an mpls wg draft; >> >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi-03.txt >> >> the draft was recently wg last called in the mpls wg, but the wg chairs >> of both groups has agreed that this draft should also be last called in >> the bfd working group. >> >> The document is part of the ongoing mpls-tp project. >> >> Please send your comments to the mpls@ietf.org mailing list. >> >> If your are not subscribed to the mpls wg list, please send to the >> bfd wg mailing list (rtg-bfd@ietf.org) >> >> This working group last call ends April 11. >> >> >> Loa George Ross Jeff and Dave >> >> mpls and bfd working group chairs >> > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From jhaas@slice.pfrc.org Mon Apr 18 18:18:31 2011 Return-Path: X-Original-To: rtg-bfd@ietfc.amsl.com Delivered-To: rtg-bfd@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BE7DBE0692 for ; Mon, 18 Apr 2011 18:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.163 X-Spam-Level: X-Spam-Status: No, score=-102.163 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75A+XKxeMHGy for ; Mon, 18 Apr 2011 18:18:30 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfc.amsl.com (Postfix) with ESMTP id CB344E0687 for ; Mon, 18 Apr 2011 18:18:27 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 59037134001; Tue, 19 Apr 2011 01:18:27 +0000 (UTC) Date: Tue, 19 Apr 2011 01:18:27 +0000 From: Jeffrey Haas To: Loa Andersson Subject: Re: [RTG-DIR] bfd working group last call on draft-ietf-mpls-tp-cc-cv-rdi-03 Message-ID: <20110419011827.GK7824@slice> References: <4D93457F.4080500@pi.nu> <4D9346E4.2080606@pi.nu> <4DA6D5BB.80209@pi.nu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DA6D5BB.80209@pi.nu> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Ross Callon , Rtg-bfd@ietf.org, Jeff Haas , David Ward X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 01:18:31 -0000 As was discussed with Loa off-list, I didn't prioritize my reply high enough since I was counting 19 days from mail list publication and had ignored the embedded date. Here are my comments upon reviewing draft-ietf-mpls-tp-cc-cv-rdi-03: : 3.5. BFD Profile for MPLS-TP : : : BFD MUST operate in asynchronous mode. In this mode, the BFD Control : packets are periodically sent at configurable time rate. This rate is : typically a fixed value for the lifetime of the session. In the rare : circumstance where an operator has a reason to change session : parameters, the session MUST be moved to the ADMIN DOWN state. : Poll/final discipline can only used for VCCV and UDP/IP encapsulated : BFD. As was discussed at IETF 80 with the authors, the lack of a poll sequence is the single biggest obstacle to interoperability with standard BFD version 1. As was explained to me, the motivation to avoid poll sequences included several factors, but the primary one was the desire to avoid having to deal with the full gamut of possible timers that may be offered. The suggested behavior that addresses the concern of supporting only specific well accepted timers is the observation that in response to a poll sequence containing unacceptable timer values, it is acceptable for the receiver of the poll sequence to simply take the session into the Down state. With the addition of the "configuration error" code point, this will hopefully be an acceptable solution. : The base spec is unclear on aspects of how a MEP with a BFD transmit : rate set to zero behaves. One interpretation is that no periodic : messages on the reverse component of the bi-directional LSP originate : with that MEP, it will only originate messages on a state change. This particular spect of BFD is unclear since the expected case where transmit behavior is totally suppressed while in the Up state is done via Demand mode. I would suggest that Demand mode be used for the sink MEP. : 3.5.1. Session initiation : : : In all scenarios a BFD session starts with both ends in the DOWN : state. DOWN state messages exchanged include the desired Tx and Rx : rates for the session. If a node cannot support the Min Tx rate : desired by a peer MEP it does not transition from down to the INIT : state and sends a diagnostic code of configuration error (to be : assigned by IANA) indicating that the requested Tx rate cannot be : supported. As discussed above, a poll sequence should be used to adjust the timers. The primay impact on this section is that it's deleted and normal BFD behavior of session initialization with 1 second timers is used. : 3.5.4.2. Exit from a session mis-configuration defect : : : Exit from a misconfiguration defect occurs when two consecutive CC or : CV frames have been received with the expected M bit setting. It may not have been the intention of this section, but this seems to suggest the M-bit is being used for misconfiguration signaling. If the authors take the suggestion of keeping the polling sequence but permitting the use of forcing a session Down with the configuration error Diag code, this section may require some rework. : 3.5.5. State machines This section has the items of most concern to me. I believe other points have been raised off-list about this section but I don't have the relevant messages. Here are my observations: The coordinated session state machine is effectively the base BFD state machine with additional inputs that can force transition into the Down state. These are all fine and do not impact BFD version 1 compatibility. The source MEP state machine does not transition out of the Up state without receiving an Admin Down event. If the suggestion of Demand mode above is taken, the behavior is effectively the same as if the replies from the sink MEP have been lost. In other words, the source MEP continues to hammer BFD control messages on the wire at the negotiated Tx rate. As long as the Tx rate is negotiated via a poll sequence, it should never be faced with a BFD peer that wasn't capable of absorbing that level of traffic. Thus, in my opinion, while this is a violation of the BFD v1 state machine, it's not a critical fault. : The sink MEP state machine (for which the transmit interval has been : set to zero) is modified to: : : 1) Permit direct transition from DOWN to UP once the session has been : initialized. With the exception of via the ADMIN DOWN state, the : source MEP will never transition from the UP state, hence in normal : unidirectional fault scenarios will never transition to the INIT : state. Again, I'd suggest that demand mode be used here. The state machine change is also incompatible with the base BFD v1 state machine. Unlike the source MEP state machine which can be observed to be behaving "correctly" if one pretends that messages are being lost in demand mode, a BFD v1 state machine can't successfully interoperate with a sink MEP state machine after the first fault without an intervening AdminDown event. I would suggest some strong caveat in the text about how independent session state machines MUST NOT face a BFD v1 compliant state machine. -- Jeff On Thu, Apr 14, 2011 at 07:08:43PM +0800, Loa Andersson wrote: > All, > > this working group last call has ended! > > I've not seen any comments! > > /Loa > > On 2011-03-30 23:06, Loa Andersson wrote: >> All, >> >> someone = possibly me - mixed the mail addresses up. This was intended >> for the bfd working group! Though comments from the routing directorate >> would be welcome! >> >> /Loa >> >> On 2011-03-30 17:00, Loa Andersson wrote: >>> BFD working group, >>> >>> This is to start a 19 days BFD working group last on an mpls wg draft; >>> >>> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi-03.txt >>> >>> the draft was recently wg last called in the mpls wg, but the wg chairs >>> of both groups has agreed that this draft should also be last called in >>> the bfd working group. >>> >>> The document is part of the ongoing mpls-tp project. >>> >>> Please send your comments to the mpls@ietf.org mailing list. >>> >>> If your are not subscribed to the mpls wg list, please send to the >>> bfd wg mailing list (rtg-bfd@ietf.org) >>> >>> This working group last call ends April 11. >>> >>> >>> Loa George Ross Jeff and Dave >>> >>> mpls and bfd working group chairs >>> >> > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 From gregimirsky@gmail.com Tue Apr 19 12:20:05 2011 Return-Path: X-Original-To: rtg-bfd@ietfc.amsl.com Delivered-To: rtg-bfd@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 86B76E0689 for ; Tue, 19 Apr 2011 12:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[AWL=0.726, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Luvt8sHAmwQ9 for ; Tue, 19 Apr 2011 12:20:03 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 872B4E0675 for ; Tue, 19 Apr 2011 12:20:00 -0700 (PDT) Received: by vws12 with SMTP id 12so15720vws.31 for ; Tue, 19 Apr 2011 12:20:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+y1mgykuQRvqeidjm5EU3lNnMmweFHnM8WediUb7ufw=; b=hu05yob5UHTEJ2qnm0XQQVfYk3WacLfQs04vY+PgTaRaG6zd91OHBIkc/ULTcpnQJU 31K7txgXtDF9vI3IX8bn+IDZ36EEP4nvkMflxh2rdx1QLWGffeybbG1yRNh4ypto2nP9 v/KWVRjKyOwo475zXpZk7rvoCNFWjFw1HtLP0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xpaZhYMTPvCi0QeGMt+hRPMczML99AcCJm1054Iu0MBmCxbjjGgR9IoAXRoTdLPo48 rKyxm4QPeTshugFC52NRpxaeseaxr9MT1fNlYWP4+Z0mue/3hIyx5TYpo3py0z/MvN0F eeUrFfebnGY/vmGY712Of3Ldk9jBtRsNQiD/w= MIME-Version: 1.0 Received: by 10.52.90.116 with SMTP id bv20mr462926vdb.108.1303240799948; Tue, 19 Apr 2011 12:19:59 -0700 (PDT) Received: by 10.52.159.38 with HTTP; Tue, 19 Apr 2011 12:19:59 -0700 (PDT) In-Reply-To: <20110419011827.GK7824@slice> References: <4D93457F.4080500@pi.nu> <4D9346E4.2080606@pi.nu> <4DA6D5BB.80209@pi.nu> <20110419011827.GK7824@slice> Date: Tue, 19 Apr 2011 12:19:59 -0700 Message-ID: Subject: Re: [RTG-DIR] bfd working group last call on draft-ietf-mpls-tp-cc-cv-rdi-03 From: Greg Mirsky To: Jeffrey Haas Content-Type: multipart/alternative; boundary=20cf307f38d4f00e0304a14a6416 Cc: Ross Callon , Jeff Haas , Rtg-bfd@ietf.org, David Ward X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 19:20:05 -0000 --20cf307f38d4f00e0304a14a6416 Content-Type: text/plain; charset=ISO-8859-1 Dear Jeff, I've got very interested by your suggestion to use Demand mode in Independent mode of operating MPLS-TP CC/CV. If I understand correctly, it would be the Source that is in Demand mode and sets its D bit up after the session reaches the Up state. The Sink, remote system, would not enter Demand mode but will have to not to send periodic control messages to Source according to Section 6.6 RFC 5880. That is the same effect as Source setting MinRxInterval to zero as described in the draft-ietf-mpls-tp-cc-cv-rdi-03 now. The behavior of the system with assymetric use of the Demand mode is not defined by RFC 5880: " Resolving the issue of one system requesting Demand mode while the other requires continuous bidirectional connectivity verification is outside the scope of this specification." Is the purpose of the Demand mode in Independent mode of monitoring bi-directional associated MPLS-TP LSP to suppress periodic control messages from Sink to improve compatibility with RFC 5880? But RFC is vague on how such asymmetric mode operates thus interoperability might be an issue here too. Regards, Greg On Mon, Apr 18, 2011 at 6:18 PM, Jeffrey Haas wrote: > As was discussed with Loa off-list, I didn't prioritize my reply high > enough > since I was counting 19 days from mail list publication and had ignored the > embedded date. Here are my comments upon reviewing > draft-ietf-mpls-tp-cc-cv-rdi-03: > > : 3.5. BFD Profile for MPLS-TP > : > : > : BFD MUST operate in asynchronous mode. In this mode, the BFD Control > : packets are periodically sent at configurable time rate. This rate is > : typically a fixed value for the lifetime of the session. In the rare > : circumstance where an operator has a reason to change session > : parameters, the session MUST be moved to the ADMIN DOWN state. > : Poll/final discipline can only used for VCCV and UDP/IP encapsulated > : BFD. > > As was discussed at IETF 80 with the authors, the lack of a poll sequence > is > the single biggest obstacle to interoperability with standard BFD version > 1. > As was explained to me, the motivation to avoid poll sequences included > several factors, but the primary one was the desire to avoid having to deal > with the full gamut of possible timers that may be offered. > > The suggested behavior that addresses the concern of supporting only > specific well accepted timers is the observation that in response to a poll > sequence containing unacceptable timer values, it is acceptable for the > receiver of the poll sequence to simply take the session into the Down > state. With the addition of the "configuration error" code point, this > will hopefully be an acceptable solution. > > : The base spec is unclear on aspects of how a MEP with a BFD transmit > : rate set to zero behaves. One interpretation is that no periodic > : messages on the reverse component of the bi-directional LSP originate > : with that MEP, it will only originate messages on a state change. > > This particular spect of BFD is unclear since the expected case where > transmit behavior is totally suppressed while in the Up state is done via > Demand mode. I would suggest that Demand mode be used for the sink MEP. > > : 3.5.1. Session initiation > : > : > : In all scenarios a BFD session starts with both ends in the DOWN > : state. DOWN state messages exchanged include the desired Tx and Rx > : rates for the session. If a node cannot support the Min Tx rate > : desired by a peer MEP it does not transition from down to the INIT > : state and sends a diagnostic code of configuration error (to be > : assigned by IANA) indicating that the requested Tx rate cannot be > : supported. > > As discussed above, a poll sequence should be used to adjust the timers. > The primay impact on this section is that it's deleted and normal BFD > behavior of session initialization with 1 second timers is used. > > : 3.5.4.2. Exit from a session mis-configuration defect > : > : > : Exit from a misconfiguration defect occurs when two consecutive CC or > : CV frames have been received with the expected M bit setting. > > It may not have been the intention of this section, but this seems to > suggest the M-bit is being used for misconfiguration signaling. If the > authors take the suggestion of keeping the polling sequence but permitting > the use of forcing a session Down with the configuration error Diag code, > this section may require some rework. > > : 3.5.5. State machines > > This section has the items of most concern to me. I believe other points > have been raised off-list about this section but I don't have the relevant > messages. Here are my observations: > > The coordinated session state machine is effectively the base BFD state > machine with additional inputs that can force transition into the Down > state. These are all fine and do not impact BFD version 1 compatibility. > > The source MEP state machine does not transition out of the Up state > without > receiving an Admin Down event. If the suggestion of Demand mode above is > taken, the behavior is effectively the same as if the replies from the sink > MEP have been lost. In other words, the source MEP continues to hammer BFD > control messages on the wire at the negotiated Tx rate. As long as the Tx > rate is negotiated via a poll sequence, it should never be faced with a BFD > peer that wasn't capable of absorbing that level of traffic. Thus, in my > opinion, while this is a violation of the BFD v1 state machine, it's not a > critical fault. > > : The sink MEP state machine (for which the transmit interval has been > : set to zero) is modified to: > : > : 1) Permit direct transition from DOWN to UP once the session has been > : initialized. With the exception of via the ADMIN DOWN state, the > : source MEP will never transition from the UP state, hence in normal > : unidirectional fault scenarios will never transition to the INIT > : state. > > Again, I'd suggest that demand mode be used here. > > The state machine change is also incompatible with the base BFD v1 state > machine. Unlike the source MEP state machine which can be observed to be > behaving "correctly" if one pretends that messages are being lost in demand > mode, a BFD v1 state machine can't successfully interoperate with a sink > MEP > state machine after the first fault without an intervening AdminDown event. > > I would suggest some strong caveat in the text about how independent > session state machines MUST NOT face a BFD v1 compliant state machine. > > -- Jeff > > > > On Thu, Apr 14, 2011 at 07:08:43PM +0800, Loa Andersson wrote: > > All, > > > > this working group last call has ended! > > > > I've not seen any comments! > > > > /Loa > > > > On 2011-03-30 23:06, Loa Andersson wrote: > >> All, > >> > >> someone = possibly me - mixed the mail addresses up. This was intended > >> for the bfd working group! Though comments from the routing directorate > >> would be welcome! > >> > >> /Loa > >> > >> On 2011-03-30 17:00, Loa Andersson wrote: > >>> BFD working group, > >>> > >>> This is to start a 19 days BFD working group last on an mpls wg draft; > >>> > >>> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi-03.txt > >>> > >>> the draft was recently wg last called in the mpls wg, but the wg chairs > >>> of both groups has agreed that this draft should also be last called in > >>> the bfd working group. > >>> > >>> The document is part of the ongoing mpls-tp project. > >>> > >>> Please send your comments to the mpls@ietf.org mailing list. > >>> > >>> If your are not subscribed to the mpls wg list, please send to the > >>> bfd wg mailing list (rtg-bfd@ietf.org) > >>> > >>> This working group last call ends April 11. > >>> > >>> > >>> Loa George Ross Jeff and Dave > >>> > >>> mpls and bfd working group chairs > >>> > >> > > > > -- > > > > > > Loa Andersson email: loa.andersson@ericsson.com > > Sr Strategy and Standards Manager loa@pi.nu > > Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 > --20cf307f38d4f00e0304a14a6416 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Jeff,
I've got very interested by your suggestion to use Demand= mode in Independent mode of operating MPLS-TP CC/CV.
If I understand c= orrectly, it would be the Source that is in Demand mode and sets its D bit = up after the session reaches the Up state. The Sink, remote system, would n= ot enter Demand mode but will have to not to send periodic control messages= to Source according to Section 6.6 RFC 5880. That is the same effect as So= urce setting MinRxInterval to zero as described in the draft-ietf-mpls-tp-c= c-cv-rdi-03 now. The behavior of the system with assymetric use of the Dema= nd mode is not defined by RFC 5880:
" Resolving the issue of one system requesting Demand mode while the o= ther requires continuous bidirectional connectivity verification is outsi= de the scope of this specification."
Is the purpose of the Demand m= ode in Independent mode of monitoring bi-directional associated MPLS-TP LSP= to suppress periodic control messages from Sink to improve compatibility w= ith RFC 5880? But RFC is vague on how such asymmetric mode operates thus in= teroperability might be an issue here too.

Regards,
Greg

On Mon, Apr 18, 2011= at 6:18 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
As was discussed with Loa off-list, I didn't prioritize my reply high e= nough
since I was counting 19 days from mail list publication and had ignored the=
embedded date. =A0Here are my comments upon reviewing
draft-ietf-mpls-tp-cc-cv-rdi-03:

: 3.5. BFD Profile for MPLS-TP
:
:
: =A0 =A0BFD MUST operate in asynchronous mode. In this mode, the BFD Contr= ol
: =A0 =A0packets are periodically sent at configurable time rate. This rate= is
: =A0 =A0typically a fixed value for the lifetime of the session. In the ra= re
: =A0 =A0circumstance where an operator has a reason to change session
: =A0 =A0parameters, the session MUST be moved to the ADMIN DOWN state.
: =A0 =A0Poll/final discipline can only used for VCCV and UDP/IP encapsulat= ed
: =A0 =A0BFD.

As was discussed at IETF 80 with the authors, the lack of a poll sequence i= s
the single biggest obstacle to interoperability with standard BFD version 1= .
As was explained to me, the motivation to avoid poll sequences included
several factors, but the primary one was the desire to avoid having to deal=
with the full gamut of possible timers that may be offered.

The suggested behavior that addresses the concern of supporting only
specific well accepted timers is the observation that in response to a poll=
sequence containing unacceptable timer values, it is acceptable for the
receiver of the poll sequence to simply take the session into the Down
state. =A0With the addition of the "configuration error" code poi= nt, this
will hopefully be an acceptable solution.

: =A0 =A0The base spec is unclear on aspects of how a MEP with a BFD transm= it
: =A0 =A0rate set to zero behaves. One interpretation is that no periodic : =A0 =A0messages on the reverse component of the bi-directional LSP origin= ate
: =A0 =A0with that MEP, it will only originate messages on a state change.<= br>
This particular spect of BFD is unclear since the expected case where
transmit behavior is totally suppressed while in the Up state is done via Demand mode. =A0I would suggest that Demand mode be used for the sink MEP.<= br>
: 3.5.1. Session initiation
:
:
: =A0 =A0In all scenarios a BFD session starts with both ends in the DOWN : =A0 =A0state. DOWN state messages exchanged include the desired Tx and Rx=
: =A0 =A0rates for the session. If a node cannot support the Min Tx rate : =A0 =A0desired by a peer MEP it does not transition from down to the INIT=
: =A0 =A0state and sends a diagnostic code of configuration error (to be : =A0 =A0assigned by IANA) indicating that the requested Tx rate cannot be<= br> : =A0 =A0supported.

As discussed above, a poll sequence should be used to adjust the timers. The primay impact on this section is that it's deleted and normal BFD behavior of session initialization with 1 second timers is used.

: 3.5.4.2. Exit from a session mis-configuration defect
:
:
: =A0 =A0Exit from a misconfiguration defect occurs when two consecutive CC= or
: =A0 =A0CV frames have been received with the expected M bit setting.

It may not have been the intention of this section, but this seems to
suggest the M-bit is being used for misconfiguration signaling. =A0If the authors take the suggestion of keeping the polling sequence but permitting<= br> the use of forcing a session Down with the configuration error Diag code, this section may require some rework.

: 3.5.5. State machines

This section has the items of most concern to me. =A0I believe other points=
have been raised off-list about this section but I don't have the relev= ant
messages. =A0Here are my observations:

The coordinated session state machine is effectively the base BFD state
machine with additional inputs that can force transition into the Down
state. =A0These are all fine and do not impact BFD version 1 compatibility.=

The source MEP state machine does not transition out of the Up state withou= t
receiving an Admin Down event. =A0If the suggestion of Demand mode above is=
taken, the behavior is effectively the same as if the replies from the sink=
MEP have been lost. =A0In other words, the source MEP continues to hammer B= FD
control messages on the wire at the negotiated Tx rate. =A0As long as the T= x
rate is negotiated via a poll sequence, it should never be faced with a BFD=
peer that wasn't capable of absorbing that level of traffic. =A0Thus, i= n my
opinion, while this is a violation of the BFD v1 state machine, it's no= t a
critical fault.

: =A0 =A0The sink MEP state machine (for which the transmit interval has be= en
: =A0 =A0set to zero) is modified to:
:
: =A0 =A01) Permit direct transition from DOWN to UP once the session has b= een
: =A0 =A0initialized. With the exception of via the ADMIN DOWN state, the : =A0 =A0source MEP will never transition from the UP state, hence in norma= l
: =A0 =A0unidirectional fault scenarios will never transition to the INIT : =A0 =A0state.

Again, I'd suggest that demand mode be used here.

The state machine change is also incompatible with the base BFD v1 state machine. =A0Unlike the source MEP state machine which can be observed to be=
behaving "correctly" if one pretends that messages are being lost= in demand
mode, a BFD v1 state machine can't successfully interoperate with a sin= k MEP
state machine after the first fault without an intervening AdminDown event.=

I would suggest some strong caveat in the text about how independent
session state machines MUST NOT face a BFD v1 compliant state machine.

-- Jeff

On Thu, Apr 14, 2011 at 07:08:43PM +0800, Loa Andersson wrote:
> All,
>
> this working group last call has ended!
>
> I've not seen any comments!
>
> /Loa
>
> On 2011-03-30 23:06, Loa Andersson wrote:
>> All,
>>
>> someone =3D possibly me - mixed the mail addresses up. This was in= tended
>> for the bfd working group! Though comments from the routing direct= orate
>> would be welcome!
>>
>> /Loa
>>
>> On 2011-03-30 17:00, Loa Andersson wrote:
>>> BFD working group,
>>>
>>> This is to start a 19 days BFD working group last on an mpls w= g draft;
>>>
>>> http://datatracker.ietf.org/doc/draft-i= etf-mpls-tp-cc-cv-rdi-03.txt
>>>
>>> the draft was recently wg last called in the mpls wg, but the = wg chairs
>>> of both groups has agreed that this draft should also be last = called in
>>> the bfd working group.
>>>
>>> The document is part of the ongoing mpls-tp project.
>>>
>>> Please send your comments to the mpls@ietf.org mailing list.
>>>
>>> If your are not subscribed to the mpls wg list, please send to= the
>>> bfd wg mailing list (rtg-bfd@ietf.org)
>>>
>>> This working group last call ends April 11.
>>>
>>>
>>> Loa George Ross Jeff and Dave
>>>
>>> mpls and bfd working group chairs
>>>
>>
>
> --
>
>
> Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: <= a href=3D"mailto:loa.andersson@ericsson.com" target=3D"_blank">loa.andersso= n@ericsson.com
> Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
> Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone:= +46 10 717 52 13
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0+46 767 72 92 13

--20cf307f38d4f00e0304a14a6416-- From jhaas@slice.pfrc.org Tue Apr 19 12:54:33 2011 Return-Path: X-Original-To: rtg-bfd@ietfc.amsl.com Delivered-To: rtg-bfd@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F1032E07AD for ; Tue, 19 Apr 2011 12:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.17 X-Spam-Level: X-Spam-Status: No, score=-102.17 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceLtY08zS5vY for ; Tue, 19 Apr 2011 12:54:33 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfc.amsl.com (Postfix) with ESMTP id 2A71EE0670 for ; Tue, 19 Apr 2011 12:54:33 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C3AE5224110; Tue, 19 Apr 2011 19:54:32 +0000 (UTC) Date: Tue, 19 Apr 2011 19:54:32 +0000 From: Jeffrey Haas To: Greg Mirsky Subject: Re: [RTG-DIR] bfd working group last call on draft-ietf-mpls-tp-cc-cv-rdi-03 Message-ID: <20110419195432.GA19083@slice> References: <4D93457F.4080500@pi.nu> <4D9346E4.2080606@pi.nu> <4DA6D5BB.80209@pi.nu> <20110419011827.GK7824@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Jeff Haas , David Ward , Ross Callon , Rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 19:54:34 -0000 Greg, On Tue, Apr 19, 2011 at 12:19:59PM -0700, Greg Mirsky wrote: > If I understand correctly, it would be the Source that is in Demand mode and > sets its D bit up after the session reaches the Up state. The Sink, remote > system, would not enter Demand mode but will have to not to send periodic > control messages to Source according to Section 6.6 RFC 5880. That is the > same effect as Source setting MinRxInterval to zero as described in the > draft-ietf-mpls-tp-cc-cv-rdi-03 now. Right. This places the desired behavior more into the general expected design of the protocol rather than requiring more special cases. > The behavior of the system with > assymetric use of the Demand mode is not defined by RFC 5880: > " Resolving the issue of one system requesting Demand mode while the other > requires continuous bidirectional connectivity verification is outside the > scope of this specification." In the context of the typical BFD behavior, Demand mode is expected when bi-directional connectivity is being verified by some means outside of the BFD async mechanism. One would normally expect such a mechanism to be symmetrical. MPLS-TP CC-CV is a case where that's not true. > Is the purpose of the Demand mode in Independent mode of monitoring > bi-directional associated MPLS-TP LSP to suppress periodic control messages > from Sink to improve compatibility with RFC 5880? But RFC is vague on how > such asymmetric mode operates thus interoperability might be an issue here > too. I think it's less vague than "this isn't what the protocol was typically designed for". The non-independent mode of BFD functions as a normal BFD speaker would be expected to function. Independent mode instead uses two pairs of BFD state machines to measure each side of a unidirectional LSP's connectivity. (Presuming I got the use case correct.) The purpose of my suggestions is primarily to look for ways supported within the base BFD protocol specification to implement MPLS-TP CC-CV desired behaviors with minimal changes. I think with demand mode and supporting poll sequences that this gets us most of the way there. > Greg -- Jeff From steve.baillargeon@ericsson.com Wed Apr 20 12:49:29 2011 Return-Path: X-Original-To: rtg-bfd@ietfc.amsl.com Delivered-To: rtg-bfd@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C0651E073B for ; Wed, 20 Apr 2011 12:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5x7BQljm51O for ; Wed, 20 Apr 2011 12:49:28 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfc.amsl.com (Postfix) with ESMTP id A046CE0669 for ; Wed, 20 Apr 2011 12:49:28 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3KJnCK8012480 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 20 Apr 2011 14:49:27 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 20 Apr 2011 15:49:20 -0400 From: Steve Baillargeon To: "rtg-bfd@ietf.org" Date: Wed, 20 Apr 2011 15:49:19 -0400 Subject: Re: New Draft- BFD Express Path Thread-Topic: Re: New Draft- BFD Express Path Thread-Index: Acv/lAnxasBiOyHbTgCSlLK+YTRZJg== Message-ID: <4383945B8C24AA4FBC33555BB7B829EF0DEC48C91A@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4383945B8C24AA4FBC33555BB7B829EF0DEC48C91AEUSAACMS0701e_" MIME-Version: 1.0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 19:49:29 -0000 --_000_4383945B8C24AA4FBC33555BB7B829EF0DEC48C91AEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am sorry for being very late to this discussion. I am not sure what is the status of the BFD express path draft. It looks some of the ideas from the BFD express path draft are being introd= uced/complimented in a new OSPF draft called OSPF TE express path by the sa= me author and more. The OSPF TE express path does not make any references to the mechanism for = measuring the network performance across a link. Does the author assume it= is the mechanism proposed in the BFD express path draft? I hope not. In general, I agree that IPPM is a much better fit for monitoring network p= erformance. TWAMP for instance can monitor/estimate all aspects of an IP link or path p= erformance including forward, reverse and round-trip metrics. Regards Steve B ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= --------------------------------------------------------------------------- To: Mach Chen Subject: Re: New Draft- BFD Express Path From: Vishwas Manral Date: Wed, 24 Nov 2010 10:18:33 -0800 Cc: rtg-bfd at ietf.org ---------------------------------------------------------------------------= ----- Hi Mach, I agree to the charters of IPPM and MPLS-TP, however looking at the draft I see they are passing a lot more details than just originator and receiver timestamps. My comment was that it could be looked at in greater detail. Thanks, Vishwas --_000_4383945B8C24AA4FBC33555BB7B829EF0DEC48C91AEUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am sorry for being very late to this discussion.

I am not sure what is the status of the BFD express path draft.

It looks some of the ideas from the BFD express path draft are being i= ntroduced/complimented in a new OSPF draft called OSPF TE express path by t= he same author and more.

The OSPF TE express path does not make any references to the mechanism= for measuring the network performance across a link. Does the author= assume it is the mechanism proposed in the BFD express path draft?

I hope not.

In general, I agree that IPPM is a much better fit for monitoring netw= ork performance.

TWAMP for instance can monitor/estimate all aspects of an IP link or p= ath performance including forward, reverse and round-trip metrics.

Regards

Steve B

----------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= -----

To: Mach Chen &l= t;mach at huawei.com>

Subject: Re: New= Draft- BFD Express Path

From: Vishwas Ma= nral <vishwas.ietf at gmail.com>

Date: Wed, 24 No= v 2010 10:18:33 -0800

Cc: rtg-bfd at i= etf.org

----------------= ----------------------------------------------------------------=

Hi Mach,

I agree to the c= harters of IPPM and MPLS-TP, however looking at the

draft I see they= are passing a lot more details than just originator

and receiver tim= estamps.

My comment was t= hat it could be looked at in greater detail.

Thanks,

Vishwas

--_000_4383945B8C24AA4FBC33555BB7B829EF0DEC48C91AEUSAACMS0701e_-- From vishwas.ietf@gmail.com Wed Apr 20 13:22:59 2011 Return-Path: X-Original-To: rtg-bfd@ietfc.amsl.com Delivered-To: rtg-bfd@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D2633E06C4 for ; Wed, 20 Apr 2011 13:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.329 X-Spam-Level: X-Spam-Status: No, score=-3.329 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTiyec8I6vE4 for ; Wed, 20 Apr 2011 13:22:59 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id E21A8E0669 for ; Wed, 20 Apr 2011 13:22:58 -0700 (PDT) Received: by vws12 with SMTP id 12so1067577vws.31 for ; Wed, 20 Apr 2011 13:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4fZEIdzH4R6rm2TKJEb5XtDP92/HfyvsumHlCK+etmU=; b=CCJQEdkEFo1c6N61nnMqN8ppGK+3LzEKmx2mjMl/7b2sfh6JrMAjcp+6f+NpDvnjNk RIq7r3e6iGeEdOJf6/FRXTXH7+85nJlk4RWRAwZcJ8zg7F5r7hi+WkXmb518CocTbxwE J03Hi1t049ct/P3jwwqbfwoTK+jLkjDkOa2X8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PsiPyPVqQeYM60+Ah4H3trml9FDQ6T0Batjw5Ndg0j83zXvAiGc3sov7bRPqKwh5A0 p2N9XYr1/rEoUbrN1JSWUYS2kOUu1OCznsoXDwZYaxmiPZiYoxBntWgfwLy0KJhvskgM XlcWvP1njFClasvEHzlC9Mq0vPnJ9Rd+hDvUY= MIME-Version: 1.0 Received: by 10.52.179.69 with SMTP id de5mr3294684vdc.304.1303330978169; Wed, 20 Apr 2011 13:22:58 -0700 (PDT) Received: by 10.52.115.7 with HTTP; Wed, 20 Apr 2011 13:22:58 -0700 (PDT) In-Reply-To: <4383945B8C24AA4FBC33555BB7B829EF0DEC48C91A@EUSAACMS0701.eamcs.ericsson.se> References: <4383945B8C24AA4FBC33555BB7B829EF0DEC48C91A@EUSAACMS0701.eamcs.ericsson.se> Date: Wed, 20 Apr 2011 13:22:58 -0700 Message-ID: Subject: Re: New Draft- BFD Express Path From: Vishwas Manral To: Steve Baillargeon Content-Type: multipart/alternative; boundary=bcaec5014a37fa827704a15f63ef Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 20:23:00 -0000 --bcaec5014a37fa827704a15f63ef Content-Type: text/plain; charset=ISO-8859-1 Hi Steve, We have come across a few hurdles in the measurements of loss and delay and their usage in the Express forwarding. A lot of the variance in delays can happen due to congestion in devices. We are trying to model and see how things can be done. You should hear some proposal on this soon. Thanks, Vishwas On Wed, Apr 20, 2011 at 12:49 PM, Steve Baillargeon < steve.baillargeon@ericsson.com> wrote: > I am sorry for being very late to this discussion. > I am not sure what is the status of the BFD express path draft. > > It looks some of the ideas from the BFD express path draft are being > introduced/complimented in a new OSPF draft called OSPF TE express path by > the same author and more. > > The OSPF TE express path does not make any references to the mechanism for > measuring the network performance across a link. Does the author assume it > is the mechanism proposed in the BFD express path draft? > > I hope not. > In general, I agree that IPPM is a much better fit for monitoring network > performance. > TWAMP for instance can monitor/estimate all aspects of an IP link or path > performance including forward, reverse and round-trip metrics. > > Regards > Steve B > > > > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > *To: Mach Chen * > *Subject: Re: New Draft- BFD Express Path * > *From: Vishwas Manral * > *Date: Wed, 24 Nov 2010 10:18:33 -0800 * > *Cc: rtg-bfd at ietf.org * > * > -------------------------------------------------------------------------------- > * > > *Hi Mach,* > > *I agree to the charters of IPPM and MPLS-TP, however looking at the* > *draft I see they are passing a lot more details than just originator* > *and receiver timestamps.* > > *My comment was that it could be looked at in greater detail.* > > *Thanks,* > *Vishwas* > > > > > > --bcaec5014a37fa827704a15f63ef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Steve,

=A0

We have come across a few hurdles in the measurements of loss and dela= y and their usage in the Express forwarding. A lot of the variance in=A0del= ays can happen due to congestion in devices. We are trying to model and see= how things can be done.

=A0

You should hear some proposal on this soon.

=A0

Thanks,

Vishwas

On Wed, Apr 20, 2011 at 12:49 PM, Steve Baillarg= eon <steve.baillargeon@ericsson.com> wrote:

I am sorry for being very late to this discussion.

I am not sure what is the status of the BFD express path draft.

=A0

It looks some of the ideas from the BFD express path draft are being i= ntroduced/complimented in a new OSPF draft called OSPF TE express path by t= he same author and more.

=A0

The OSPF TE express path does not make any references to the mechanism= for measuring the network performance across a link.=A0 Does the author as= sume it is the mechanism proposed in the BFD express path draft?

=A0

I hope not.

In general, I agree that IPPM is a much better fit for monitoring netw= ork performance.

TWAMP for instance can monitor/estimate all aspects of an IP link or p= ath performance including forward, reverse and round-trip metrics.

=A0

Regards

Steve B

=A0

=A0

----------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= -----

To: Mach Chen &l= t;mach at huawei.com&g= t;

Subject: Re: New= Draft- BFD Express Path

From: Vishwas Ma= nral <vishwas.ietf at gm= ail.com>

Date: Wed, 24 No= v 2010 10:18:33 -0800

Cc: rtg-bfd at <= a href=3D"http://ietf.org/" target=3D"_blank">ietf.org
----------------= ----------------------------------------------------------------=

=A0

Hi Mach,

=A0

I agree to the c= harters of IPPM and MPLS-TP, however looking at the

draft I see they= are passing a lot more details than just originator

and receiver tim= estamps.

=A0

My comment was t= hat it could be looked at in greater detail.

=A0

Thanks,

Vishwas

=A0

=A0

=A0

=A0

--bcaec5014a37fa827704a15f63ef-- From swallow@cisco.com Wed Apr 20 13:23:49 2011 Return-Path: X-Original-To: rtg-bfd@ietfc.amsl.com Delivered-To: rtg-bfd@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 961B6E0753 for ; Wed, 20 Apr 2011 13:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1so5f26VArX for ; Wed, 20 Apr 2011 13:23:48 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id 8CF2FE0751 for ; Wed, 20 Apr 2011 13:23:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=2392; q=dns/txt; s=iport; t=1303331028; x=1304540628; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=OCZcDN3Ko4REBDUq2R1Hi4T+wRAlYk+rsUD/ajRrLSc=; b=Mz8rIyxcKGhaEQI8pV0e5Xf8/VBBtncxz/Ua9mGPItMLNsYrkegkadRo TxUz+o3QviOb33WlUOsXLowWvCEbwYsQnfarF3W9ySWgoTOcvxzCokZz+ E4ugtu8V/Vo89yHbj6y5PDxD6ejVq9l2AkmApKrXEeVPRXOafp0rx1arv 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKw/r02tJXG//2dsb2JhbAClQneIb6E+nHWFcQSOIoQG X-IronPort-AV: E=Sophos;i="4.64,247,1301875200"; d="scan'208";a="298738373" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-3.cisco.com with ESMTP; 20 Apr 2011 20:23:47 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3KKNklk021683; Wed, 20 Apr 2011 20:23:46 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Apr 2011 15:23:46 -0500 Received: from 10.98.32.163 ([10.98.32.163]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Wed, 20 Apr 2011 20:23:46 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 20 Apr 2011 16:23:45 -0400 Subject: Re: [RTG-DIR] bfd working group last call on draft-ietf-mpls-tp-cc-cv-rdi-03 From: George Swallow To: Jeffrey Haas , Greg Mirsky , David Allan , John E Drake Message-ID: Thread-Topic: [RTG-DIR] bfd working group last call on draft-ietf-mpls-tp-cc-cv-rdi-03 Thread-Index: Acv/mNjx+v7UrxJMWkOmoaWxYdTVoA== In-Reply-To: <20110419195432.GA19083@slice> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Apr 2011 20:23:46.0563 (UTC) FILETIME=[D9DFDD30:01CBFF98] Cc: Jeff Haas , Ross Callon , Rtg-bfd@ietf.org, David Ward X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 20:23:49 -0000 Adding Dave Allen and John Drake to the thread. ...George On 4/19/11 3:54 PM, "Jeffrey Haas" wrote: > Greg, > > On Tue, Apr 19, 2011 at 12:19:59PM -0700, Greg Mirsky wrote: >> If I understand correctly, it would be the Source that is in Demand mode and >> sets its D bit up after the session reaches the Up state. The Sink, remote >> system, would not enter Demand mode but will have to not to send periodic >> control messages to Source according to Section 6.6 RFC 5880. That is the >> same effect as Source setting MinRxInterval to zero as described in the >> draft-ietf-mpls-tp-cc-cv-rdi-03 now. > > Right. This places the desired behavior more into the general expected > design of the protocol rather than requiring more special cases. > >> The behavior of the system with >> assymetric use of the Demand mode is not defined by RFC 5880: >> " Resolving the issue of one system requesting Demand mode while the other >> requires continuous bidirectional connectivity verification is outside the >> scope of this specification." > > In the context of the typical BFD behavior, Demand mode is expected when > bi-directional connectivity is being verified by some means outside of the > BFD async mechanism. One would normally expect such a mechanism to be > symmetrical. MPLS-TP CC-CV is a case where that's not true. > >> Is the purpose of the Demand mode in Independent mode of monitoring >> bi-directional associated MPLS-TP LSP to suppress periodic control messages >> from Sink to improve compatibility with RFC 5880? But RFC is vague on how >> such asymmetric mode operates thus interoperability might be an issue here >> too. > > I think it's less vague than "this isn't what the protocol was typically > designed for". The non-independent mode of BFD functions as a normal BFD > speaker would be expected to function. Independent mode instead uses two > pairs of BFD state machines to measure each side of a unidirectional LSP's > connectivity. (Presuming I got the use case correct.) > > The purpose of my suggestions is primarily to look for ways supported within > the base BFD protocol specification to implement MPLS-TP CC-CV desired > behaviors with minimal changes. I think with demand mode and supporting > poll sequences that this gets us most of the way there. > >> Greg > > -- Jeff From jdrake@juniper.net Wed Apr 20 14:08:55 2011 Return-Path: X-Original-To: rtg-bfd@ietfc.amsl.com Delivered-To: rtg-bfd@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 87746E0725 for ; Wed, 20 Apr 2011 14:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.761 X-Spam-Level: X-Spam-Status: No, score=-5.761 tagged_above=-999 required=5 tests=[AWL=0.838, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppcvvAz5hq0F for ; Wed, 20 Apr 2011 14:08:54 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfc.amsl.com (Postfix) with ESMTP id 78771E06A2 for ; Wed, 20 Apr 2011 14:08:54 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTa9LYbFbk/rVOEHFkqrCs9EY0oeb7wjL@postini.com; Wed, 20 Apr 2011 14:08:54 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 20 Apr 2011 14:05:40 -0700 From: John E Drake To: George Swallow , Jeffrey Haas , Greg Mirsky , David Allan Date: Wed, 20 Apr 2011 14:07:46 -0700 Subject: RE: [RTG-DIR] bfd working group last call on draft-ietf-mpls-tp-cc-cv-rdi-03 Thread-Topic: [RTG-DIR] bfd working group last call on draft-ietf-mpls-tp-cc-cv-rdi-03 Thread-Index: Acv/mNjx+v7UrxJMWkOmoaWxYdTVoAABZdfQ Message-ID: <5E893DB832F57341992548CDBB333163A0971198BB@EMBX01-HQ.jnpr.net> References: <20110419195432.GA19083@slice> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jeff Haas , Ross Callon , "Rtg-bfd@ietf.org" , David Ward X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 21:08:55 -0000 Hi, I had sent an email to Jeff asking about his suggestion to use Demand to su= pport Independent Mode and telling him about our new proposal for supportin= g P/F. Thanks, John Sent from my iPhone > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Wednesday, April 20, 2011 1:24 PM > To: Jeffrey Haas; Greg Mirsky; David Allan; John E Drake > Cc: Jeff Haas; David Ward; Ross Callon; Rtg-bfd@ietf.org > Subject: Re: [RTG-DIR] bfd working group last call on draft-ietf-mpls- > tp-cc-cv-rdi-03 >=20 > Adding Dave Allen and John Drake to the thread. >=20 > ...George >=20 >=20 > On 4/19/11 3:54 PM, "Jeffrey Haas" wrote: >=20 > > Greg, > > > > On Tue, Apr 19, 2011 at 12:19:59PM -0700, Greg Mirsky wrote: > >> If I understand correctly, it would be the Source that is in Demand > mode and > >> sets its D bit up after the session reaches the Up state. The Sink, > remote > >> system, would not enter Demand mode but will have to not to send > periodic > >> control messages to Source according to Section 6.6 RFC 5880. That > is the > >> same effect as Source setting MinRxInterval to zero as described in > the > >> draft-ietf-mpls-tp-cc-cv-rdi-03 now. > > > > Right. This places the desired behavior more into the general > expected > > design of the protocol rather than requiring more special cases. > > > >> The behavior of the system with > >> assymetric use of the Demand mode is not defined by RFC 5880: > >> " Resolving the issue of one system requesting Demand mode while the > other > >> requires continuous bidirectional connectivity verification is > outside the > >> scope of this specification." > > > > In the context of the typical BFD behavior, Demand mode is expected > when > > bi-directional connectivity is being verified by some means outside > of the > > BFD async mechanism. One would normally expect such a mechanism to > be > > symmetrical. MPLS-TP CC-CV is a case where that's not true. > > > >> Is the purpose of the Demand mode in Independent mode of monitoring > >> bi-directional associated MPLS-TP LSP to suppress periodic control > messages > >> from Sink to improve compatibility with RFC 5880? But RFC is vague > on how > >> such asymmetric mode operates thus interoperability might be an > issue here > >> too. > > > > I think it's less vague than "this isn't what the protocol was > typically > > designed for". The non-independent mode of BFD functions as a normal > BFD > > speaker would be expected to function. Independent mode instead uses > two > > pairs of BFD state machines to measure each side of a unidirectional > LSP's > > connectivity. (Presuming I got the use case correct.) > > > > The purpose of my suggestions is primarily to look for ways supported > within > > the base BFD protocol specification to implement MPLS-TP CC-CV > desired > > behaviors with minimal changes. I think with demand mode and > supporting > > poll sequences that this gets us most of the way there. > > > >> Greg > > > > -- Jeff From steve.baillargeon@ericsson.com Thu Apr 21 04:41:38 2011 Return-Path: X-Original-To: rtg-bfd@ietfc.amsl.com Delivered-To: rtg-bfd@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D14E5E06DA for ; Thu, 21 Apr 2011 04:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJnHsLvlNo38 for ; Thu, 21 Apr 2011 04:41:37 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id AD665E0689 for ; Thu, 21 Apr 2011 04:41:37 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3LBfXH5016374; Thu, 21 Apr 2011 06:41:35 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 21 Apr 2011 07:41:33 -0400 From: Steve Baillargeon To: Vishwas Manral Date: Thu, 21 Apr 2011 07:41:31 -0400 Subject: RE: New Draft- BFD Express Path Thread-Topic: New Draft- BFD Express Path Thread-Index: Acv/mMIWdX6M2Q5aQf29Rrn+3NS9IAAfvrjQ Message-ID: <4383945B8C24AA4FBC33555BB7B829EF0DEC48CAAA@EUSAACMS0701.eamcs.ericsson.se> References: <4383945B8C24AA4FBC33555BB7B829EF0DEC48C91A@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4383945B8C24AA4FBC33555BB7B829EF0DEC48CAAAEUSAACMS0701e_" MIME-Version: 1.0 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 11:41:39 -0000 --_000_4383945B8C24AA4FBC33555BB7B829EF0DEC48CAAAEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vishwas Most or all of these delay measurement issues and challenges have been reso= lved in IPPM. I think active measurement is somehow required to measure the one-way delay= s across a link and TWAMP is best equipped for it. For instance, the implementer may decide to run the BFD session and the TWA= MP session using different DSCP codepoints. This separation is desirable. Furthermore, TWAMP allows multiple test sessi= ons to run concurrently between two peers using different DSCP codepoints. This performance data can be used to measure the average link delay for ins= tance. -Steve ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: April-20-11 4:23 PM To: Steve Baillargeon Cc: rtg-bfd@ietf.org Subject: Re: New Draft- BFD Express Path Hi Steve, We have come across a few hurdles in the measurements of loss and delay and= their usage in the Express forwarding. A lot of the variance in delays can= happen due to congestion in devices. We are trying to model and see how th= ings can be done. You should hear some proposal on this soon. Thanks, Vishwas On Wed, Apr 20, 2011 at 12:49 PM, Steve Baillargeon > wrote: I am sorry for being very late to this discussion. I am not sure what is the status of the BFD express path draft. It looks some of the ideas from the BFD express path draft are being introd= uced/complimented in a new OSPF draft called OSPF TE express path by the sa= me author and more. The OSPF TE express path does not make any references to the mechanism for = measuring the network performance across a link. Does the author assume it= is the mechanism proposed in the BFD express path draft? I hope not. In general, I agree that IPPM is a much better fit for monitoring network p= erformance. TWAMP for instance can monitor/estimate all aspects of an IP link or path p= erformance including forward, reverse and round-trip metrics. Regards Steve B ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= --------------------------------------------------------------------------- To: Mach Chen > Subject: Re: New Draft- BFD Express Path From: Vishwas Manral > Date: Wed, 24 Nov 2010 10:18:33 -0800 Cc: rtg-bfd at ietf.org ---------------------------------------------------------------------------= ----- Hi Mach, I agree to the charters of IPPM and MPLS-TP, however looking at the draft I see they are passing a lot more details than just originator and receiver timestamps. My comment was that it could be looked at in greater detail. Thanks, Vishwas --_000_4383945B8C24AA4FBC33555BB7B829EF0DEC48CAAAEUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Vishwas
Most or all of these delay measurement issues= and=20 challenges have been resolved in IPPM.

I think active measurement is somehow required to measure t= he=20 one-way delays across a link and TWAMP is best equipped for=20 it.

For instance, the implementer may decide to run the BFD ses= sion=20 and the TWAMP session using different DSCP codepoints.

This separation is desirable. Furthermore, = TWAMP=20 allows multiple test sessions to run concurrently between two peers using=20 different DSCP codepoints.

This performance data can be used to measure the average li= nk=20 delay for instance.

-Steve

From: Vishwas Manral=20 [mailto:vishwas.ietf@gmail.com]
Sent: April-20-11 4:23=20 PM
To: Steve Baillargeon
Cc:=20 rtg-bfd@ietf.org
Subject: Re: New Draft- BFD Express=20 Path

Hi Steve,

We have come across a few hurdles in the measurements of loss and dela= y and=20 their usage in the Express forwarding. A lot of the variance in delays= can=20 happen due to congestion in devices. We are trying to model and see how thi= ngs=20 can be done.

You should hear some proposal on this soon.

Thanks,

Vishwas

On Wed, Apr 20, 2011 at 12:49 PM, Steve Baillargeo= n <steve.baillargeon@ericsson.c= om>=20 wrote:

I am sorry for being very late to this discussion.

I am not sure what is the status of the BFD express path draft.

It looks some of the ideas from the BFD express path draft are being= =20 introduced/complimented in a new OSPF draft called OSPF TE express path b= y the=20 same author and more.

The OSPF TE express path does not make any references to the mechani= sm=20 for measuring the network performance across a link. Does the autho= r=20 assume it is the mechanism proposed in the BFD express path draft?

I hope not.

In general, I agree that IPPM is a much better fit for monitoring ne= twork=20 performance.

TWAMP for instance can monitor/estimate all aspects of an IP link or= path=20 performance including forward, reverse and round-trip metrics.

Regards

Steve B

--------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= -------

To: Mach Chen &l= t;mach at=20 huawei.com>=20

Subject: Re: New= Draft-=20 BFD Express Path

From: Vishwas Ma= nral=20 <vishwas.ietf at gmail.com>

Date: Wed, 24 No= v 2010=20 10:18:33 -0800

Cc: rtg-bfd at <= A=20 href=3D"http://ietf.org/" target=3D_blank>ietf.org

------------------------------------------------------= --------------------------

Hi Mach,

I agree to the c= harters=20 of IPPM and MPLS-TP, however looking at the

draft I see they= are=20 passing a lot more details than just originator

and receiver=20 timestamps.

My comment was t= hat it=20 could be looked at in greater detail.

Thanks,

Vishwas

--_000_4383945B8C24AA4FBC33555BB7B829EF0DEC48CAAAEUSAACMS0701e_-- From tnadeau@lucidvision.com Thu Apr 21 05:07:14 2011 Return-Path: X-Original-To: rtg-bfd@ietfc.amsl.com Delivered-To: rtg-bfd@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ADEF5E06DA for ; Thu, 21 Apr 2011 05:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMjtpLV7Dqmk for ; Thu, 21 Apr 2011 05:07:13 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfc.amsl.com (Postfix) with ESMTP id 695F7E0698 for ; Thu, 21 Apr 2011 05:07:13 -0700 (PDT) Received: from [192.168.1.126] (70-91-139-77-ma-ne.hfc.comcastbusiness.net [70.91.139.77]) by lucidvision.com (Postfix) with ESMTP id 76D901B08AE8; Thu, 21 Apr 2011 08:07:12 -0400 (EDT) Subject: Re: New Draft- BFD Express Path Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-7-810401674 From: Thomas Nadeau In-Reply-To: <4383945B8C24AA4FBC33555BB7B829EF0DEC48CAAA@EUSAACMS0701.eamcs.ericsson.se> Date: Thu, 21 Apr 2011 08:07:12 -0400 Message-Id: <19A10BF2-D144-48A7-976B-D4AEEE1B9FD3@lucidvision.com> References: <4383945B8C24AA4FBC33555BB7B829EF0DEC48C91A@EUSAACMS0701.eamcs.ericsson.se> <4383945B8C24AA4FBC33555BB7B829EF0DEC48CAAA@EUSAACMS0701.eamcs.ericsson.se> To: Steve Baillargeon X-Mailer: Apple Mail (2.1084) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 12:07:14 -0000 --Apple-Mail-7-810401674 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Steve, this is a good point. I raised the possibility of using = BFD for this purpose when it was just on the drawing board several years = ago, but the idea was nixed by Dave^2 in order to keep the protocol = simple. To my knowledge, this design decision still stands. --Tom > Hi Vishwas > Most or all of these delay measurement issues and challenges have been = resolved in IPPM. > =20 > I think active measurement is somehow required to measure the one-way = delays across a link and TWAMP is best equipped for it. > =20 > For instance, the implementer may decide to run the BFD session and = the TWAMP session using different DSCP codepoints. > This separation is desirable. Furthermore, TWAMP allows multiple test = sessions to run concurrently between two peers using different DSCP = codepoints. > This performance data can be used to measure the average link delay = for instance. > =20 > -Steve > =20 >=20 > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=20 > Sent: April-20-11 4:23 PM > To: Steve Baillargeon > Cc: rtg-bfd@ietf.org > Subject: Re: New Draft- BFD Express Path >=20 > Hi Steve, > =20 > We have come across a few hurdles in the measurements of loss and = delay and their usage in the Express forwarding. A lot of the variance = in delays can happen due to congestion in devices. We are trying to = model and see how things can be done. > =20 > You should hear some proposal on this soon. > =20 > Thanks, > Vishwas > On Wed, Apr 20, 2011 at 12:49 PM, Steve Baillargeon = wrote: > I am sorry for being very late to this discussion. > I am not sure what is the status of the BFD express path draft. > =20 > It looks some of the ideas from the BFD express path draft are being = introduced/complimented in a new OSPF draft called OSPF TE express path = by the same author and more. > =20 > The OSPF TE express path does not make any references to the mechanism = for measuring the network performance across a link. Does the author = assume it is the mechanism proposed in the BFD express path draft? > =20 > I hope not. > In general, I agree that IPPM is a much better fit for monitoring = network performance. > TWAMP for instance can monitor/estimate all aspects of an IP link or = path performance including forward, reverse and round-trip metrics. > =20 > Regards > Steve B > =20 > =20 > = --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --- > To: Mach Chen > Subject: Re: New Draft- BFD Express Path > From: Vishwas Manral > Date: Wed, 24 Nov 2010 10:18:33 -0800 > Cc: rtg-bfd at ietf.org > = --------------------------------------------------------------------------= ------ > =20 > Hi Mach, > =20 > I agree to the charters of IPPM and MPLS-TP, however looking at the > draft I see they are passing a lot more details than just originator > and receiver timestamps. > =20 > My comment was that it could be looked at in greater detail. > =20 > Thanks, > Vishwas > =20 >=20 > =20 > =20 > =20 >=20 --Apple-Mail-7-810401674 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

Steve, this is a good point. I raised the possibility of using BFD for this purpose when it was just on the drawing board several years ago, but the idea was nixed by Dave^2 in order to keep the protocol simple. To my knowledge, this design decision still stands.

--Tom

Hi Vishwas
Most or all of these delay measurement issues and challenges have been resolved in IPPM.

I think active measurement is somehow required to measure the one-way delays across a link and TWAMP is best equipped for it.

For instance, the implementer may decide to run the BFD session and the TWAMP session using different DSCP codepoints.

This separation is desirable. Furthermore, TWAMP allows multiple test sessions to run concurrently between two peers using different DSCP codepoints.

This performance data can be used to measure the average link delay for instance.

-Steve

From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: April-20-11 4:23 PM
To: Steve Baillargeon
Cc: rtg-bfd@ietf.org
Subject: Re: New Draft- BFD Express Path

Hi Steve,

We have come across a few hurdles in the measurements of loss and delay and their usage in the Express forwarding. A lot of the variance in delays can happen due to congestion in devices. We are trying to model and see how things can be done.

You should hear some proposal on this soon.

Thanks,

Vishwas

On Wed, Apr 20, 2011 at 12:49 PM, Steve Baillargeon <steve.baillargeon@ericsson.com> wrote:

I am sorry for being very late to this discussion.

I am not sure what is the status of the BFD express path draft.

It looks some of the ideas from the BFD express path draft are being introduced/complimented in a new OSPF draft called OSPF TE express path by the same author and more.

The OSPF TE express path does not make any references to the mechanism for measuring the network performance across a link. Does the author assume it is the mechanism proposed in the BFD express path draft?

I hope not.

In general, I agree that IPPM is a much better fit for monitoring network performance.

TWAMP for instance can monitor/estimate all aspects of an IP link or path performance including forward, reverse and round-trip metrics.

Regards

Steve B

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

To: Mach Chen <mach at huawei.com>

Subject: Re: New Draft- BFD Express Path

From: Vishwas Manral <vishwas.ietf at gmail.com>

Date: Wed, 24 Nov 2010 10:18:33 -0800

Cc: rtg-bfd at ietf.org

--------------------------------------------------------------------------------

Hi Mach,

I agree to the charters of IPPM and MPLS-TP, however looking at the

draft I see they are passing a lot more details than just originator

and receiver timestamps.

My comment was that it could be looked at in greater detail.

Thanks,

Vishwas

--Apple-Mail-7-810401674-- From vishwas.ietf@gmail.com Thu Apr 21 09:34:52 2011 Return-Path: X-Original-To: rtg-bfd@ietfc.amsl.com Delivered-To: rtg-bfd@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6C7E3E0655 for ; Thu, 21 Apr 2011 09:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bX7xqkvlp8z3 for ; Thu, 21 Apr 2011 09:34:51 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 32F23E0663 for ; Thu, 21 Apr 2011 09:34:51 -0700 (PDT) Received: by vws12 with SMTP id 12so1771808vws.31 for ; Thu, 21 Apr 2011 09:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GcqEvtg33o1vkZ6q9bx8UqgIfpkOe8ikx4Ikt9DMxiE=; b=jNrm8JhZKyNHqn3wPWCQslIeH3IWbucjEjvSUSpDPhAaWshgFZQCjveOjcPCnqxLZj KyVirDgMrJA81k5aYZXyLlIrz6iYB53fLdPn2W1z48EsA+z5OdjR25R3veZ4fmcjOyrs NGiRZyP/rdB591K4Y0Ykwl3PBNx3GeNNm9RbI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=S4D9XU80kJa3DWIWYfVR6Z7bAQpk41ehSzx+AhpRdbao+NQDwk8JJUqZ9IITaVk032 GATL2Do3VukdLr4KNU8zvVCohoxmfXwcIsHxja3tb410OXaTTTmidVr1e1Uh0q6PCZsl +cj0bzbKW/LNqeSUSvmEF5PQ3hMgs4fadN82Y= MIME-Version: 1.0 Received: by 10.52.179.69 with SMTP id de5mr180218vdc.304.1303403690635; Thu, 21 Apr 2011 09:34:50 -0700 (PDT) Received: by 10.52.114.100 with HTTP; Thu, 21 Apr 2011 09:34:50 -0700 (PDT) In-Reply-To: <4383945B8C24AA4FBC33555BB7B829EF0DEC48CAAA@EUSAACMS0701.eamcs.ericsson.se> References: <4383945B8C24AA4FBC33555BB7B829EF0DEC48C91A@EUSAACMS0701.eamcs.ericsson.se> <4383945B8C24AA4FBC33555BB7B829EF0DEC48CAAA@EUSAACMS0701.eamcs.ericsson.se> Date: Thu, 21 Apr 2011 09:34:50 -0700 Message-ID: Subject: Re: New Draft- BFD Express Path From: Vishwas Manral To: Steve Baillargeon Content-Type: multipart/alternative; boundary=bcaec5014a37fab1a704a17051fc Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 16:34:52 -0000 --bcaec5014a37fab1a704a17051fc Content-Type: text/plain; charset=ISO-8859-1 Hi Steve, The work is mainly targeted at the finance industry networks. We are talking about microsecond granularity and we want to take into consideration link and node delays seperately. I do not think IPPM is anywhere close to measuring device delays. If it has been done, can you please point me to how you would model delay on a device? The actual packet format to use for measurement sis a considerably smaller thing. Thanks, Vishwas On Thu, Apr 21, 2011 at 4:41 AM, Steve Baillargeon < steve.baillargeon@ericsson.com> wrote: > Hi Vishwas > Most or all of these delay measurement issues and challenges have been > resolved in IPPM. > > I think active measurement is somehow required to measure the one-way > delays across a link and TWAMP is best equipped for it. > > For instance, the implementer may decide to run the BFD session and the > TWAMP session using different DSCP codepoints. > This separation is desirable. Furthermore, TWAMP allows multiple test > sessions to run concurrently between two peers using different DSCP > codepoints. > This performance data can be used to measure the average link delay for > instance. > > -Steve > > > ------------------------------ > *From:* Vishwas Manral [mailto:vishwas.ietf@gmail.com] > *Sent:* April-20-11 4:23 PM > *To:* Steve Baillargeon > *Cc:* rtg-bfd@ietf.org > > *Subject:* Re: New Draft- BFD Express Path > > Hi Steve, > > We have come across a few hurdles in the measurements of loss and delay and > their usage in the Express forwarding. A lot of the variance in delays can > happen due to congestion in devices. We are trying to model and see how > things can be done. > > You should hear some proposal on this soon. > > Thanks, > Vishwas > On Wed, Apr 20, 2011 at 12:49 PM, Steve Baillargeon < > steve.baillargeon@ericsson.com> wrote: > >> I am sorry for being very late to this discussion. >> I am not sure what is the status of the BFD express path draft. >> >> It looks some of the ideas from the BFD express path draft are being >> introduced/complimented in a new OSPF draft called OSPF TE express path by >> the same author and more. >> >> The OSPF TE express path does not make any references to the mechanism for >> measuring the network performance across a link. Does the author assume it >> is the mechanism proposed in the BFD express path draft? >> >> I hope not. >> In general, I agree that IPPM is a much better fit for monitoring network >> performance. >> TWAMP for instance can monitor/estimate all aspects of an IP link or path >> performance including forward, reverse and round-trip metrics. >> >> Regards >> Steve B >> >> >> >> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> *To: Mach Chen * >> *Subject: Re: New Draft- BFD Express Path * >> *From: Vishwas Manral * >> *Date: Wed, 24 Nov 2010 10:18:33 -0800 * >> *Cc: rtg-bfd at ietf.org * >> * >> -------------------------------------------------------------------------------- >> * >> >> *Hi Mach,* >> >> *I agree to the charters of IPPM and MPLS-TP, however looking at the* >> *draft I see they are passing a lot more details than just originator* >> *and receiver timestamps.* >> >> *My comment was that it could be looked at in greater detail.* >> >> *Thanks,* >> *Vishwas* >> >> >> >> >> >> > > --bcaec5014a37fab1a704a17051fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Steve,

=A0

The work is mainly targeted at the finance industry networks. We are t= alking about microsecond granularity and we want to take into consideration= link and node delays seperately. I do not think IPPM is anywhere close to = measuring device delays.

=A0

If it has been done, can you please=A0point me to how you would model = delay on a device?=A0The actual packet format to use for measurement sis a = considerably smaller thing.=A0

=A0

Thanks,

Vishwas

On Thu, Apr 21, 2011 at 4:41 AM, Steve Baillarge= on <= steve.baillargeon@ericsson.com> wrote:

Hi Vishwas
Most or all of these delay measurement issues and challenge= s have been resolved in IPPM.

=A0

I think active measurement is somehow required to measure the one-way del= ays across a link and TWAMP is best equipped for it.

=A0

For instance, the implementer may decide to run the BFD session and the T= WAMP session using different DSCP codepoints.

This separation is desirable. Furthermore, TWAMP allows multiple test sessions to run con= currently between two peers using different DSCP codepoints.<= /div>
This performance data can be used to measure the average link delay for i= nstance.

=A0

-Steve

=A0

From: Vishwas Manral [mailto:vishwas.ietf@gmail.co= m]
Sent: April-20-11 4:23 PM
To: Steve Baillargeon=
Cc: rtg-bfd@ie= tf.org=20

Subject: Re: New Draft- BFD Express Path

Hi Steve,

=A0

We have come across a few hurdles in the measurements of loss and dela= y and their usage in the Express forwarding. A lot of the variance in=A0del= ays can happen due to congestion in devices. We are trying to model and see= how things can be done.

=A0

You should hear some proposal on this soon.

=A0

Thanks,

Vishwas

On Wed, Apr 20, 2011 at 12:49 PM, Steve Baillarg= eon <steve.baillargeon@ericsson.com> wrote:

I am sorry for being very late to this discussion.

I am not sure what is the status of the BFD express path draft.

=A0

It looks some of the ideas from the BFD express path draft are being i= ntroduced/complimented in a new OSPF draft called OSPF TE express path by t= he same author and more.

=A0

The OSPF TE express path does not make any references to the mechanism= for measuring the network performance across a link.=A0 Does the author as= sume it is the mechanism proposed in the BFD express path draft?

=A0

I hope not.

In general, I agree that IPPM is a much better fit for monitoring netw= ork performance.

TWAMP for instance can monitor/estimate all aspects of an IP link or p= ath performance including forward, reverse and round-trip metrics.

=A0

Regards

Steve B

=A0

=A0

----------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= -----

To: Mach Chen &l= t;mach at huawei.com&g= t;

Subject: Re: New= Draft- BFD Express Path

From: Vishwas Ma= nral <vishwas.ietf at gm= ail.com>

Date: Wed, 24 No= v 2010 10:18:33 -0800

Cc: rtg-bfd at <= a href=3D"http://ietf.org/" target=3D"_blank">ietf.org
----------------= ----------------------------------------------------------------=

=A0

Hi Mach,

=A0

I agree to the c= harters of IPPM and MPLS-TP, however looking at the

draft I see they= are passing a lot more details than just originator

and receiver tim= estamps.

=A0

My comment was t= hat it could be looked at in greater detail.

=A0

Thanks,

Vishwas

=A0

=A0

=A0

=A0

--bcaec5014a37fab1a704a17051fc-- From rcallon@juniper.net Fri Apr 22 10:32:24 2011 Return-Path: X-Original-To: rtg-bfd@ietfc.amsl.com Delivered-To: rtg-bfd@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 726F8E0808; Fri, 22 Apr 2011 10:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.695 X-Spam-Level: X-Spam-Status: No, score=-106.695 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbYTgY-HXcy8; Fri, 22 Apr 2011 10:32:20 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfc.amsl.com (Postfix) with ESMTP id 00A0DE07FE; Fri, 22 Apr 2011 10:32:19 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTbG7o6+6Bu7x5kaH3/OTjurk2vKi4KLz@postini.com; Fri, 22 Apr 2011 10:32:20 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 22 Apr 2011 10:29:34 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 22 Apr 2011 13:29:34 -0400 From: Ross Callon To: "rtg-bfd@ietf.org" Date: Fri, 22 Apr 2011 13:29:34 -0400 Subject: FW: Poll / Final in draft-cc-cv-rdi Thread-Topic: Poll / Final in draft-cc-cv-rdi Thread-Index: Acv+tvS4BEK+rt17R96WWlGBJIq3WgAuHfsAAGi3yiA= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 26 Apr 2011 09:43:10 -0700 Cc: "mpls@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 22 Apr 2011 17:32:24 -0000 FYI. This discussion on the MPLS WG email list may be of interest to some B= FD folks.=20 Ross -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com]=20 Sent: Wednesday, April 20, 2011 11:30 AM To: mpls@ietf.org Cc: Loa Andersson; Ross Callon; George Swallow; John E Drake Subject: FW: Poll / Final in draft-cc-cv-rdi Hi Folks: =20 We've received a number of comments both formally and informally that the current draft has deviated too far from the base BFD spec and thus loses backward compatibility with existing code bases. Further, discussions with the BFD WG have indicated we have a potential race condition in the current startup procedures described in draft-cc-cv-rdi. =20 The issue is the transition to UP state requires confirmation by the peer MEP prior to changing the detection time to the rx-interval x detect mult i= n order to avoid potential flapping. This can result in an implementation effectively needing two UP states (UP forward, UP reverse direction). Otherwise the MEP may time out the reverse direction before seeing an UP state from the peer MEP. =20 So we can make this implicit in the specification and require BFD changes o= r we can use poll/final discipline on startup as defined in the base specification and make the transition to fully UP and the desired rate both explicit and exposed in the protocol exchange. This would reduce the deltas between the base spec (RFC 5880) and draft CC-CV-RDI. =20 We would also observe that it is permissable in the specification to respon= d to a poll with a final reply with the session parameters unchanged. So once a session is up a compliant implementation does not actually have to implement on the fly changes to session paramters. The processing of the poll bit can simply be reduced to setting the final bit in the next message= . This would permit implementations to optimize the UP processing loop. =20 This is a change of direction from what has been in the draft to date, henc= e we'd look to the WG for comment on this change... =20 the editors Dave, John and George... From loa@pi.nu Tue Apr 26 10:38:30 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7611E0769 for ; Tue, 26 Apr 2011 10:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqcLCTLRfhJI for ; Tue, 26 Apr 2011 10:38:30 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD31E0710 for ; Tue, 26 Apr 2011 10:38:29 -0700 (PDT) Received: from pi.nu (localhost [127.0.0.1]) by mail.pi.nu (Postfix) with ESMTP id 620C42A8001 for ; Tue, 26 Apr 2011 19:38:27 +0200 (CEST) Received: from 129.192.170.250 (SquirrelMail authenticated user loa@pi.nu) by pi.nu with HTTP; Tue, 26 Apr 2011 19:38:27 +0200 Message-ID: <1d5bdfd90be0798adb4a9ef663b44b9e.squirrel@pi.nu> Date: Tue, 26 Apr 2011 19:38:27 +0200 Subject: [Fwd: FW: Poll / Final in draft-cc-cv-rdi] From: loa@pi.nu To: rtg-bfd@ietf.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20110426193827_61219" X-Priority: 3 (Normal) Importance: Normal X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 17:38:31 -0000 ------=_20110426193827_61219 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit BFD Working Group, this is a discussion just starting on the mpls working group mailing list, that might be of interest for you. /Loa ---------------------------- Original Message ---------------------------- Subject: FW: Poll / Final in draft-cc-cv-rdi From: "David Allan I" Date: Wed, April 20, 2011 5:29 pm To: "mpls@ietf.org" Cc: "Loa Andersson" "Ross Callon" "George Swallow" "John E Drake" -------------------------------------------------------------------------- Hi Folks: We've received a number of comments both formally and informally that the current draft has deviated too far from the base BFD spec and thus loses backward compatibility with existing code bases. Further, discussions with the BFD WG have indicated we have a potential race condition in the current startup procedures described in draft-cc-cv-rdi. The issue is the transition to UP state requires confirmation by the peer MEP prior to changing the detection time to the rx-interval x detect mult in order to avoid potential flapping. This can result in an implementation effectively needing two UP states (UP forward, UP reverse direction). Otherwise the MEP may time out the reverse direction before seeing an UP state from the peer MEP. So we can make this implicit in the specification and require BFD changes or we can use poll/final discipline on startup as defined in the base specification and make the transition to fully UP and the desired rate both explicit and exposed in the protocol exchange. This would reduce the deltas between the base spec (RFC 5880) and draft CC-CV-RDI. We would also observe that it is permissable in the specification to respond to a poll with a final reply with the session parameters unchanged. So once a session is up a compliant implementation does not actually have to implement on the fly changes to session paramters. The processing of the poll bit can simply be reduced to setting the final bit in the next message. This would permit implementations to optimize the UP processing loop. This is a change of direction from what has been in the draft to date, hence we'd look to the WG for comment on this change... the editors Dave, John and George... ------=_20110426193827_61219 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQUTCCA2Ew ggJJoAMCAQICEAoBAQEAAAJ8AAAACgAAAAIwDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDEwMjIyMjAz OTIzWhcNMjYwMjIyMjAzOTIzWjA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQL ExRSU0EgU2VjdXJpdHkgMjA0OCBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALeP VXHSgN17aXmn8BhQMjxiZ/YKlQfd5hvzntnSQVRrrZ98vhnN+0arQWgeGOpVyC+ReIko+ycpYP/f j4w7yUmbtaSUzgHqPrVje38m/RndwCG9hNEtT0bDTtzYNzk7KK/LnRrqK68hpcEjIri4G1oTh1eD 0fAg5+hPI0KwAKV9ienpYXOUmHEmvC1q4PdN8PG2KjgxgQ0p4QDBUQ9MUvgEWqp9ctO4hyq7YxAD KrOhTw1aXka3PQ71dOyZn/k9JIGIpt1gVOiVNj3GCZOaoxKAAFWZGUe90KV8w7r7H/f1D/isubX0 N5gTGN6FW7cMgjuHb5U5WDDabgFoFyLMwAsCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFAfD UTCkqulFrjUk+v8kLDPQsZ2MMA0GCSqGSIb3DQEBBQUAA4IBAQBfPoZ2brg1PE42HB55mL/91RIR eVIO7jGJvN1/+dHGFSHoigFUDTr7VLnWY9SxqpZNokJN1FMfixDef2W+YBMncYikc+OEY9GkVeFQ k+YbDnnQZ7xGyL8/Fw2V5saQad7ntC/elX3QEj89Pn9NPxRo9RFQ1cH0kKUIHTFg/2CMI1QKr/6h bsXReipoeM8eggogtB+t5YWyamh1Tq0lN5SFvr2h1Oq3DEs8negSAPBfrA3hrHBjc/d/eZ8yJUJ0 BYAov73BJJZYFbEXIemJS9sHiGf0Fa1wPi9NhTvCt9v+mGgjieF0D970xYRjKRvMywfJAKSp18Ii T2fXd+wgBWHeMIIELjCCAxagAwIBAgIRALblbh/SK1c9Ljnzou72C4UwDQYJKoZIhvcNAQEFBQAw OTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0Ew MTAeFw0wOTEwMjgxMzAwMzVaFw0xMjEwMjgxMzAwMzJaMGYxETAPBgNVBAoMCEVyaWNzc29uMRQw EgYDVQQDDAtEYXZpZCBBbGxhbjEQMA4GA1UEBRMHZWFsbGRhdjEpMCcGCSqGSIb3DQEJARYaZGF2 aWQuaS5hbGxhbkBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALcxmDlr O4lawMYgUOZdbfo3ZCBNOKIDfrOeZg5dmU0kgGrSkFPw5BK5I4bR13PMlTy5yEMSKlSeR8Q1E6nc mYJRQEHYQlrNzItpoTC73kANBEYoI3oAqkcJxj1CZJv+9jvWAaEpajxg9l8WuSe/XAfjS79BI/Y6 DXtgOsZKdwTxAgMBAAGjggGGMIIBgjCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3Js LnRydXN0LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRh cC50cnVzdC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89 RXJpY3Nzb24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAlBgNVHREEHjAc gRpkYXZpZC5pLmFsbGFuQGVyaWNzc29uLmNvbTBGBgNVHSAEPzA9MDsGBiqFcGsBATAxMC8GCCsG AQUFBwIBFiNodHRwOi8vd3d3LmVyaWNzc29uLmNvbS9sZWdhbC5zaHRtbDAdBgNVHQ4EFgQUayrt IThpu38nwwrhT4GDR/+dIWAwHwYDVR0jBBgwFoAUlifDuN6lX11EPjlS5UWxdl9jMJswDgYDVR0P AQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4IBAQBzF4/vMotGcoPjCyuIUptzrYoQ8VhJe5/ufZNv 78ulVpc0LBaBjDx4r7xnPiM8wKKSY+GAzeWneeh6fK5epbDih7uB78kcziHeZGar6g8PHk/NZAKb A/MHOpHQZc72zzQC/eQJl3sFtctDVX5dLnrTwL/2nHp1genPDl7Ff0yvUkobDD/3oIWKIrGV0ayw jMrpCkpn+F5/3UxymJQ/8961F4GWivcUuYgbNmIBZMdaR+LoDZHD7p2268LwuYPFj6LHsHE/dIVY ZYzVRKP3+jbzMuipOv3wB0zIG5Vr9diGCKzUmyVK6HA2f0HAmWOGV3oHg1BdIWulvx1+MmetnK/L MIIERTCCAy2gAwIBAgIQE8nq/94mrancpMojgYNH4zANBgkqhkiG9w0BAQUFADBEMRowGAYDVQQK DBFUZWxpYVNvbmVyYSBHcm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0Eg djEwHhcNMDYxMDA2MTAwMDUzWhcNMTYxMDAyMDUwNDE3WjA5MREwDwYDVQQKDAhFcmljc3NvbjEk MCIGA1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQTAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAthB35DUe64fEPI0YWUQ/MLG488U7lbbHKv6eoJWc0nhBgV7UcAKpq+o0vBQY iogTIe/Wsud+5v0sFzt1ClEeOX92CCKfQ404UnfqdsYRt8eMsnPYHM5a/CXzhJz4XHT0isNT9JlJ YVJ+GpO7dNPf2Hv1usd1GR08FSAFiCyIUquIcjROM/kbzrbwfbsEPOpSnMYtJhaC3r+2nC44fmVx 818dYxwJhdGWhu/QqW7yXEblqZaoCeqsfoQI7JglNFsdOxpMhk4fL1DD/R5c+6MpPu1TnHFIjZJ1 x4mrNRsDPagVFDo/Hv8bJ2kz9GX6pigY9xq4dQvVpJ5UlmoMWpwgXQIDAQABo4IBPDCCATgwEgYD VR0TAQH/BAgwBgEB/wIBADBGBgNVHSAEPzA9MDsGByqFcCMCAQEwMDAuBggrBgEFBQcCARYiaHR0 cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTCBiQYDVR0fBIGBMH8wfaB7oHmGd2xkYXA6 Ly9sZGFwLnRydXN0LnRlbGlhLmNvbS9jbj1UZWxpYVNvbmVyYSUyMFB1YmxpYyUyMFJvb3QlMjBD QSUyMHYxLG89VGVsaWFTb25lcmElMjBHcm91cD9hdXRob3JpdHlyZXZvY2F0aW9ubGlzdD9iYXNl MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUlifDuN6lX11EPjlS5UWxdl9jMJswHwYDVR0jBBgw FoAURdvwj7gaYqGoIxtjiDij2+AaYvEwDQYJKoZIhvcNAQEFBQADggEBAHYASipDP4zdFr1qWSmf 9ifCFci/q0+OFS9K42zTQ2F3RP1eGUhTdrrkJoH9QpKqdrITS3tDRCrev7H8YreKf+aKTyL88rb+ rwe63NgVLPPo2nO2mjYkbsAQo4k9Vp55uOeDjmbq80LtEh/NT2wbYsFH+F7BLyzp0UWfvTDv3nFT AkFZnrs7MgpeshVW8dM5iltYD4wRIoBfAWGdU42s5NaVXCsxSLgduI9ak6T7FBuB6EISLua7dxex pTVereQxe6I24LtUqihvyYU72j1FP52WKsPa5FfA2m8K7du63orKG7T6e/LaJcYqN2XGVZOx0PK6 VdjP45gIxn2UVZHMwg8wggRtMIIDVaADAgECAhEAnLCMBJrLlyJ4Y2K2G4ZaPTANBgkqhkiG9w0B AQUFADA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQLExRSU0EgU2VjdXJpdHkg MjA0OCBWMzAeFw0wNjEwMzEyMDQyMjdaFw0xNjExMDExNTQyMjVaMEQxGjAYBgNVBAoMEVRlbGlh U29uZXJhIEdyb3VwMSYwJAYDVQQDDB1UZWxpYVNvbmVyYSBQdWJsaWMgUm9vdCBDQSB2MTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMpPEANqkICreamVfhHiA235Zl7lAoadpURBLJju UgIoXkO5V1Y8wscOPOHDkjMN3zrRlnH/RWuEYHcOY/hIMhYIqjY/G9jk1yR0FY9an9Pa5pB04DCC oek3Sl7Vfv+N6Xn1axZhcoaD/zVa2Hvdkr+B4TsbP0++PUtTo3hiEsyCijEqcJL5mMHmJxYCD5B3 VClCEXjofWJunouwFYOnnow+mDwXlfrLswZVwpgt2cs4+zzi7FFb2qzWQGinNAGPqzlLJWHwD6Pm WIMGOCFdinD/6loYR2oc95IVjFkp4lq2aMQotiXFxlZEp/jfoq9AD2MGEwSbK0w1saJxHWZEfq0C AwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFAfDUTCkqulFrjUk+v8kLDPQsZ2MMB0GA1UdDgQWBBRF 2/CPuBpioagjG2OIOKPb4Bpi8TASBgNVHRMBAf8ECDAGAQH/AgEEMIGFBgNVHSAEfjB8MD0GCSqG SIb3DQUGATAwMC4GCCsGAQUFBwIBFiJodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWEuY29t MDsGByqFcCMCAQEwMDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh LmNvbTBwBgNVHR8EaTBnMGWgY6Bhhl9odHRwOi8vd3d3LnJzYXNlY3VyaXR5LmNvbS9wcm9kdWN0 cy9rZW9uL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVfc3RhdHVzL1JTQV9TZWN1cml0eV8yMDQ4X3Yz LkNSTDAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAARemizYKcibv/zvbK1KsQdZ mC+E5QSRSbbk9Z/9eRaSjjVNov28hLVLoB1YKE2paadiJLsZ9oiIMz2zUPoruGJ1YEM6bjps10zd nCEzIMJ+QMlKB4nTD7tiaO8KG7uBaoNkKxu1nmADWLEJN0Oe5kHrskZI8ZbqvvdyitoM/x2I6mJC i4y8zpsq5M8Ef/WmgtxyxTGwqCtDbckL0tYJFvxxgeRmNcUfUrjhOwiXkud7ahPQkjenB0Da/qM7 in84see0/6emPA9t50w9RmQNgKR3ctLGPxzclPG0DxKU8K0gcTWGHrnGKGDUlEiWJKmGuqv2Rt/A d15XE904jka0Ng8xggJ+MIICegIBATBOMDkxETAPBgNVBAoMCEVyaWNzc29uMSQwIgYDVQQDDBtF cmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEQC25W4f0itXPS4586Lu9guFMAkGBSsOAwIaBQCg ggGGMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQyMDE1Mjk1 MFowIwYJKoZIhvcNAQkEMRYEFHg9RIvwRV/BXULbYOvoPmqRuK34MF0GCSsGAQQBgjcQBDFQME4w OTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0Ew MQIRALblbh/SK1c9Ljnzou72C4UwXwYLKoZIhvcNAQkQAgsxUKBOMDkxETAPBgNVBAoMCEVyaWNz c29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEQC25W4f0itXPS4586Lu 9guFMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqG SIb3DQEBAQUABIGANEKQJ0p/o2z5q2kZ/9VIY+2iS1d5wwBHrtqIy2gP3OhbuY8PdWMPyOT77Mza POgj6QjbeyiAir3sCTIjLT79TMGGUokL3EIVkT48/W0ZCEqcqg9XZoF2LtGw2E6AeT1iOHP4Ht5y EVLe2evHva6EBemHl/ZRW/TnsXmleiMZ+C0AAAAAAAA= ------=_20110426193827_61219-- From manav.bhatia@alcatel-lucent.com Fri Apr 29 18:46:29 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38245E06C3; Fri, 29 Apr 2011 18:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.288 X-Spam-Level: X-Spam-Status: No, score=-5.288 tagged_above=-999 required=5 tests=[AWL=1.311, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYD9OfBX2sI8; Fri, 29 Apr 2011 18:46:28 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id A143FE06AD; Fri, 29 Apr 2011 18:46:22 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3U1kIff004615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 29 Apr 2011 20:46:21 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3U1kHdi027677 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 30 Apr 2011 07:16:17 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Sat, 30 Apr 2011 07:16:17 +0530 From: "Bhatia, Manav (Manav)" To: "karp@ietf.org" Date: Sat, 30 Apr 2011 07:16:13 +0530 Subject: RE: BFD Security Gap Analysis Thread-Topic: BFD Security Gap Analysis Thread-Index: Acv4+oILfEeuQaBtTK2B2k1+obeqCQN3aQ6Q Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFDBA5810@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFD037C81@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFD037C81@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2011 01:46:29 -0000 Hi, Based on the comments that we received from the BFD WG we have updated the = KARP BFD security analysis draft and the latest version can be found here: http://tools.ietf.org/html/draft-bhatia-zhang-karp-bfd-analysis-01 The diffs from the last version: http://tools.ietf.org/rfcdiff?url2=3Ddraft-bhatia-zhang-karp-bfd-analysis-0= 1.txt Cross posting this to BFD since this is relevant there as well. Cheers, Manav > -----Original Message----- > From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On=20 > Behalf Of Bhatia, Manav (Manav) > Sent: Tuesday, April 12, 2011 3.45 PM > To: karp@ietf.org > Subject: [karp] BFD Security Gap Analysis >=20 > Hi, >=20 > Dacheng and I have posted a draft that does BFD securtity gap=20 > analysis. Would be great if the WG can review this and=20 > provide some feedback. >=20 > http://www.ietf.org/id/draft-bhatia-zhang-karp-bfd-analysis-00.txt >=20 > Cheers, Manav >=20 > -- > Manav Bhatia, > Service Router Product Group (SRPG) > Alcatel-Lucent, India > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > =