From marc@sniff.de Mon Apr 2 02:29:45 2012 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 EC6A621F8957 for ; Mon, 2 Apr 2012 02:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfJIWLdoGilC for ; Mon, 2 Apr 2012 02:29:45 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E5521F8955 for ; Mon, 2 Apr 2012 02:29:45 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 486982AA0F; Mon, 2 Apr 2012 09:29:42 +0000 (GMT) Subject: Re: I-D Action: draft-akiya-bfd-intervals-00.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: <20120402085239.5055.85941.idtracker@ietfa.amsl.com> Date: Mon, 2 Apr 2012 11:29:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5A60B57B-E9FA-4C37-B909-22741B67382F@sniff.de> References: <20120402085239.5055.85941.idtracker@ietfa.amsl.com> To: rtg-bfd@ietf.org X-Mailer: Apple Mail (2.1084) 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: Mon, 02 Apr 2012 09:29:46 -0000 Hello BFD experts, Nobo and me would like to start a discussion about BFD interval values. Many of you are about to implement BFD "in hardware", which typically = means the periodic transmit and the timeout detection is done by some = special processor to achieve more aggressive intervals and/or higher = scale numbers. The gain in speed/scale comes with a price: the supported = interval values are often less, either a few fixed values or a coarse = granularity. What we have seen in interop tests was that both systems ended up at the = next-lowest interval both systems supported - and that was far away from = the original, intended value. The submitted draft proposes to have some = commonly supported interval values so the systems find an agreeable = interval quick and at reasonable value. Discussions are welcome! :-) Best regards, Marc & Nobo > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Mandatory interval support in BFD > Author(s) : Nobo Akiya > Marc Binderberger > Filename : draft-akiya-bfd-intervals-00.txt > Pages : 5 > Date : 2012-04-02 >=20 > This document defines a set of interval values that must be = supported > for transmitting BFD control packets and for calculating the > detection time in the receive direction. Implementations are = allowed > to define a lower limit for the interval so that only set values > equal or larger than the lower limit needs to be supported. >=20 > This solves the problem of finding an interval value that both BFD > speakers can support while allowing a simplified implementation as > seen for hardware-based BFD. >=20 >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-akiya-bfd-intervals-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-akiya-bfd-intervals-00.txt >=20 -- Marc Binderberger From binnyjeshan@gmail.com Mon Apr 2 03:20:28 2012 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 F359F21F8911 for ; Mon, 2 Apr 2012 03:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwhCqnsA7C0m for ; Mon, 2 Apr 2012 03:20:27 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id B241721F86AD for ; Mon, 2 Apr 2012 03:20:26 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so2003839wib.13 for ; Mon, 02 Apr 2012 03:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z6ocuIdJMh6ASoL4i11Fvp2i/otjE68S93awRItbl5Y=; b=UM2c4DdtCYcwVFbWfW+OAqMjCElQ2cRGgZ1yc+ssKq3DwvjPV/6WkG1p6sba9WxqP9 BNr2ZsDPXsGsyvFrAXodW4mXAk0MFvtoin1BP9eLLh4BfzOeSKgRUDD8G1chdP8uCABO G8/CkQoMmkxyBE85LOov5tguTMgHHhBle8xdpMq5y13cS5GDnuSYKmXWaiAHvLXPaHB3 uUOoa9xCzJFl7hm9+1PVCDuz+CdDk7hkBqtBNbYt1b6+haVkba36tWbbAxT5czTKHy3G jY2y3KBxdjfPTGNQLAKjsu9zy8xzcB3QGUnRDz/j+jVy4HbnWF+a4FD9tFcoll87qe54 TRfA== MIME-Version: 1.0 Received: by 10.180.91.168 with SMTP id cf8mr23411439wib.0.1333362025427; Mon, 02 Apr 2012 03:20:25 -0700 (PDT) Received: by 10.223.118.16 with HTTP; Mon, 2 Apr 2012 03:20:25 -0700 (PDT) In-Reply-To: <5A60B57B-E9FA-4C37-B909-22741B67382F@sniff.de> References: <20120402085239.5055.85941.idtracker@ietfa.amsl.com> <5A60B57B-E9FA-4C37-B909-22741B67382F@sniff.de> Date: Mon, 2 Apr 2012 15:50:25 +0530 Message-ID: Subject: Re: I-D Action: draft-akiya-bfd-intervals-00.txt From: binny jeshan To: Marc Binderberger Content-Type: multipart/alternative; boundary=f46d04389347e1f1eb04bcaf8954 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: Mon, 02 Apr 2012 10:20:28 -0000 --f46d04389347e1f1eb04bcaf8954 Content-Type: text/plain; charset=ISO-8859-1 Hello Marc, I may not have understood your draft full intentions, but AFAIK, most of the device manufacturers who complies to BFD and supports it as a Fault detection mechanism, will always support the industry required time intervals, so as a fault is recovered quickly. BUT, some device may not be able to give a requested time interval due to any reason, depending on the situation that the device sees. One example could be that if the device is already occupied with more traffic, it may choose to offer a 30ms timer. rather than the peer who is expecting a 10ms. Moreover, the supported timer intervals of BFD is in the data sheet, and so operator driven configurations should be made with attention. And IMHO i think that any device manufacturer should be able to provide a timer configuration that enables a <50 ms recovery time (a well known industry expectation) along with the use of detect multiplier , and IMHO there need not be any mandate for further support. Thanks, Binny J On 2 April 2012 14:59, Marc Binderberger wrote: > Hello BFD experts, > > Nobo and me would like to start a discussion about BFD interval values. > > Many of you are about to implement BFD "in hardware", which typically > means the periodic transmit and the timeout detection is done by some > special processor to achieve more aggressive intervals and/or higher scale > numbers. The gain in speed/scale comes with a price: the supported interval > values are often less, either a few fixed values or a coarse granularity. > > What we have seen in interop tests was that both systems ended up at the > next-lowest interval both systems supported - and that was far away from > the original, intended value. The submitted draft proposes to have some > commonly supported interval values so the systems find an agreeable > interval quick and at reasonable value. > > > Discussions are welcome! :-) > > > Best regards, > Marc & Nobo > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > Title : Mandatory interval support in BFD > > Author(s) : Nobo Akiya > > Marc Binderberger > > Filename : draft-akiya-bfd-intervals-00.txt > > Pages : 5 > > Date : 2012-04-02 > > > > This document defines a set of interval values that must be supported > > for transmitting BFD control packets and for calculating the > > detection time in the receive direction. Implementations are allowed > > to define a lower limit for the interval so that only set values > > equal or larger than the lower limit needs to be supported. > > > > This solves the problem of finding an interval value that both BFD > > speakers can support while allowing a simplified implementation as > > seen for hardware-based BFD. > > > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-akiya-bfd-intervals-00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-akiya-bfd-intervals-00.txt > > > > -- > Marc Binderberger > > --f46d04389347e1f1eb04bcaf8954 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Marc,
=A0
I may not have understood your draft full intentions, but AFAIK, most = of the device manufacturers who complies to BFD and supports it as a Fault = detection mechanism, will always support the industry required time interva= ls, so as a fault is recovered quickly.
=A0
BUT, some device may not be able to give a requested time interval due= to any reason, depending on the situation that the
device sees. One=A0e= xample could be that if the device is already occupied with more traffic, i= t may choose to offer a 30ms timer. rather than the peer who is expecting a= 10ms.
=A0
Moreover, the supported timer intervals of BFD=A0is in the data sheet,= and so operator driven configurations should be made with attention. And I= MHO i think that any device manufacturer should be able to provide a timer = configuration that enables a <50 ms recovery time (a well known industry= expectation) along with the=A0use of detect multiplier=A0, and IMHO=A0ther= e need not be any mandate for further support.
=A0
Thanks,
Binny J
=A0
On 2 April 2012 14:59, Marc Binderberger <marc@sniff.de> wrote:
Hello BFD experts,

Nobo and me= would like to start a discussion about BFD interval values.

Many of= you are about to implement BFD "in hardware", which typically me= ans the periodic transmit and the timeout detection is done by some special= processor to achieve more aggressive intervals and/or higher scale numbers= . The gain in speed/scale comes with a price: the supported interval values= are often less, either a few fixed values or a coarse granularity.

What we have seen in interop tests was that both systems ended up at th= e next-lowest interval both systems supported - and that was far away from = the original, intended value. The submitted draft proposes to have some com= monly supported interval values so the systems find an agreeable interval q= uick and at reasonable value.


Discussions are welcome! :-)


Best regards,
Marc &= Nobo


> A New Internet-Draft is available from the on-line In= ternet-Drafts directories.
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 = =A0 =A0 : Mandatory interval support in BFD
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Nobo Akiya
> =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Marc Binderberger
> =A0 =A0 =A0 F= ilename =A0 =A0 =A0 =A0: draft-akiya-bfd-intervals-00.txt
> =A0 =A0 = =A0 Pages =A0 =A0 =A0 =A0 =A0 : 5
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 = =A0 =A0: 2012-04-02
>
> =A0 This document defines a set of interval values that must b= e supported
> =A0 for transmitting BFD control packets and for calcul= ating the
> =A0 detection time in the receive direction. =A0Implement= ations are allowed
> =A0 to define a lower limit for the interval so that only set values> =A0 equal or larger than the lower limit needs to be supported.
&= gt;
> =A0 This solves the problem of finding an interval value that b= oth BFD
> =A0 speakers can support while allowing a simplified implementation as=
> =A0 seen for hardware-based BFD.
>
>
>
> A= URL for this Internet-Draft is:
> http://www= .ietf.org/internet-drafts/draft-akiya-bfd-intervals-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
>= ; ftp://f= tp.ietf.org/internet-drafts/
>
> This Internet-Draft can be= retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-akiya-= bfd-intervals-00.txt
>

--
Marc Binderberger =A0 =A0 =A0= =A0 =A0 <marc@sniff.de>


--f46d04389347e1f1eb04bcaf8954-- From marc@sniff.de Mon Apr 2 05:34:31 2012 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 55E9A21F866A for ; Mon, 2 Apr 2012 05:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUKmnCULasir for ; Mon, 2 Apr 2012 05:34:30 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C911D21F866E for ; Mon, 2 Apr 2012 05:34:29 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id F26372AA0F; Mon, 2 Apr 2012 12:34:27 +0000 (GMT) Subject: Re: I-D Action: draft-akiya-bfd-intervals-00.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-20-728060218 From: Marc Binderberger In-Reply-To: Date: Mon, 2 Apr 2012 14:34:21 +0200 Message-Id: <39C5ED88-4DD5-4D19-87AA-3CD03DD2BA99@sniff.de> References: <20120402085239.5055.85941.idtracker@ietfa.amsl.com> <5A60B57B-E9FA-4C37-B909-22741B67382F@sniff.de> To: binny jeshan 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: Mon, 02 Apr 2012 12:34:31 -0000 --Apple-Mail-20-728060218 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Binny, > will always support the industry required time intervals that is exactly the point: there are no defined values. And as the draft = in section 2 shows even when both vendors for themselves support = reasonably fast values this still does not guarantee a fast detection = time when they interop. Btw, the example is section 2 was - with slightly different values - a = real life experience. This is not academic. I take your email as a feedback that the draft should be more explicit = in mentioning this is about a problem between two different = devices/vendors here. You won't see this between two devices of the same = kind. Thanks & Regards, Marc On 2012-04-02, at 12:20 , binny jeshan wrote: > Hello Marc, > =20 > I may not have understood your draft full intentions, but AFAIK, most = of the device manufacturers who complies to BFD and supports it as a = Fault detection mechanism, will always support the industry required = time intervals, so as a fault is recovered quickly. > =20 > BUT, some device may not be able to give a requested time interval due = to any reason, depending on the situation that the > device sees. One example could be that if the device is already = occupied with more traffic, it may choose to offer a 30ms timer. rather = than the peer who is expecting a 10ms. > =20 > Moreover, the supported timer intervals of BFD is in the data sheet, = and so operator driven configurations should be made with attention. And = IMHO i think that any device manufacturer should be able to provide a = timer configuration that enables a <50 ms recovery time (a well known = industry expectation) along with the use of detect multiplier , and IMHO = there need not be any mandate for further support. > =20 > Thanks, > Binny J > =20 > On 2 April 2012 14:59, Marc Binderberger wrote: > Hello BFD experts, >=20 > Nobo and me would like to start a discussion about BFD interval = values. >=20 > Many of you are about to implement BFD "in hardware", which typically = means the periodic transmit and the timeout detection is done by some = special processor to achieve more aggressive intervals and/or higher = scale numbers. The gain in speed/scale comes with a price: the supported = interval values are often less, either a few fixed values or a coarse = granularity. >=20 > What we have seen in interop tests was that both systems ended up at = the next-lowest interval both systems supported - and that was far away = from the original, intended value. The submitted draft proposes to have = some commonly supported interval values so the systems find an agreeable = interval quick and at reasonable value. >=20 >=20 > Discussions are welcome! :-) >=20 >=20 > Best regards, > Marc & Nobo >=20 >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > > > > Title : Mandatory interval support in BFD > > Author(s) : Nobo Akiya > > Marc Binderberger > > Filename : draft-akiya-bfd-intervals-00.txt > > Pages : 5 > > Date : 2012-04-02 > > > > This document defines a set of interval values that must be = supported > > for transmitting BFD control packets and for calculating the > > detection time in the receive direction. Implementations are = allowed > > to define a lower limit for the interval so that only set values > > equal or larger than the lower limit needs to be supported. > > > > This solves the problem of finding an interval value that both BFD > > speakers can support while allowing a simplified implementation as > > seen for hardware-based BFD. > > > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-akiya-bfd-intervals-00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-akiya-bfd-intervals-00.txt > > >=20 > -- > Marc Binderberger >=20 >=20 -- Marc Binderberger --Apple-Mail-20-728060218 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello = Binny,

will always = support the industry required time = intervals

that is exactly = the point: there are no defined values. And as the draft in section 2 = shows even when both vendors for themselves support reasonably fast = values this still does not guarantee a fast detection time when they = interop.

Btw, the example is section 2 was - = with slightly different values - a real life experience. This is not = academic.


I take your email as a = feedback that the draft should be more explicit in mentioning this is = about a problem between two different devices/vendors here. You won't = see this between two devices of the same = kind.


Thanks & = Regards,
Marc



<= div>On 2012-04-02, at 12:20 , binny jeshan wrote:

Hello = Marc,
 
I may not have understood your draft full intentions, but AFAIK, = most of the device manufacturers who complies to BFD and supports it as = a Fault detection mechanism, will always support the industry required = time intervals, so as a fault is recovered quickly.
 
BUT, some device may not be able to give a requested time interval = due to any reason, depending on the situation that the
device sees. = One example could be that if the device is already occupied with = more traffic, it may choose to offer a 30ms timer. rather than the peer = who is expecting a 10ms.
 
Moreover, the supported timer intervals of BFD is in the data = sheet, and so operator driven configurations should be made with = attention. And IMHO i think that any device manufacturer should be able = to provide a timer configuration that enables a <50 ms recovery time = (a well known industry expectation) along with the use of detect = multiplier , and IMHO there need not be any mandate for = further support.
 
Thanks,
Binny J
 
On 2 April 2012 14:59, Marc Binderberger = <marc@sniff.de> wrote:
Hello BFD = experts,

Nobo and me would like to start a discussion about BFD = interval values.

Many of you are about to implement BFD "in = hardware", which typically means the periodic transmit and the timeout = detection is done by some special processor to achieve more aggressive = intervals and/or higher scale numbers. The gain in speed/scale comes = with a price: the supported interval values are often less, either a few = fixed values or a coarse granularity.

What we have seen in interop tests was that both systems ended up at = the next-lowest interval both systems supported - and that was far away = from the original, intended value. The submitted draft proposes to have = some commonly supported interval values so the systems find an agreeable = interval quick and at reasonable value.


Discussions are welcome! :-)


Best regards,
Marc = & Nobo


> A New Internet-Draft is available from the = on-line Internet-Drafts directories.
>
>     =   Title           : Mandatory interval = support in BFD
>       Author(s)       : Nobo = Akiya
>                 =          Marc Binderberger
>   =     Filename        : = draft-akiya-bfd-intervals-00.txt
>       Pages =           : 5
>       Date =            : 2012-04-02
>
>   This document defines a set of interval values that = must be supported
>   for transmitting BFD control packets = and for calculating the
>   detection time in the receive = direction.  Implementations are allowed
>   to define a lower limit for the interval so that only set = values
>   equal or larger than the lower limit needs to be = supported.
>
>   This solves the problem of finding an = interval value that both BFD
>   speakers can support while allowing a simplified = implementation as
>   seen for hardware-based = BFD.
>
>
>
> A URL for this Internet-Draft = is:
> http://www.ietf.org/internet-drafts/draft-akiya-bfd-inte= rvals-00.txt
>
> Internet-Drafts are also available by anonymous FTP = at:
> ftp://ftp.ietf.org/internet-drafts/
>
> = This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-akiya-bfd-inter= vals-00.txt
>

--
Marc Binderberger     =       <marc@sniff.de>



--
marc@sniff.de>

= --Apple-Mail-20-728060218-- From jhaas@slice.pfrc.org Tue Apr 3 11:23:45 2012 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 8EEF811E8099 for ; Tue, 3 Apr 2012 11:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.917 X-Spam-Level: X-Spam-Status: No, score=-100.917 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9MVLb4HRyKm for ; Tue, 3 Apr 2012 11:23:44 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CAFAE11E8076 for ; Tue, 3 Apr 2012 11:23:44 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7B960170412; Tue, 3 Apr 2012 14:23:44 -0400 (EDT) Date: Tue, 3 Apr 2012 14:23:44 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Draft minutes from IETF 83 session Message-ID: <20120403182344.GF7467@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) 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, 03 Apr 2012 18:23:45 -0000 Thanks to Dave Ward for taking minutes. Please send amendments or corrections to the mail list by April 11. -- Jeff --------------------------------8<---- cut here ---->8------------------------- BFD IETF 83 I. Agenda bashing II. Charter and Administrivia See slides DWard: The discussion of IPR disclosure is so that we can discuss with the group if an IPR unencumbered solution. III. BFD for DS-lite - See slides Jeff: only take on if soft wires accepts work DWard: not going to add any perf, delay, etc into BFD DWard: need to know more about config/bootstrapping, etc before we take it on Swallow: maybe use LSPping IV. MPLS-TP MIB - Sam Aldrin see slides DWard: Do we need configuration objects in MPLS-TP MIB? Swallow: We should add config objects DWard: Do we need a NetConf/Yang model? Swallow: not yet. No requirement DWard: The MIB is necessary but, is it sufficient for all requirements of MPLS-TP from the ITU or elsewhere? Swallow: the management of MPLS-TP LSPs is not specified by the ITU so, it's unclear if or which management protocol or data model is required DWard: Can we just add configuration objects and "be done?" Sam: Yes, I will add config objects. Jeff: Take the conversation to the list as the work is "in charter" but, we haven't "accepted this as a WG item ? let's get that done" Jeff: can have "read-only" advisory comment as you like ... V. BFD over LAG - Manav see slides Jeff: see WG list and agenda for copy - positive response to complete work - technical suggestion on how to solve the problem (use ifOperStatus object) IEEE "told" us what they need to hear, it makes sense Bootstrapping of IP adds is beyond scope of this draft though there is another draft Jeff: We will go forth and take this on as a WG item. Stewart: Please send an "acceptance liaison" to the IEEE and show them the next copy of the draft Sami Boutros: The draft discusses how to run with or without LACP. Should be similar to any L2 OAM running on the component links. Jeff: Please spec if CFM is also running at the same time and what happens or state that both should not be run. Rob Shakir: Please have in the draft "what happens" including the disaster scenarios. Jeff: We are programming an input into LACP and not LACP itself Rudiger: Did I hear you mention a hack for the link address using a special address Manav: Defined 2 mechanisms: a) use mcast or b) use 127/8 Jeff: poll for interest in mcast vs unicast All for unicast None for mcast Vikas Hegde: Are we getting a code point from IEEE? Jeff: BFD over IP and therefore using UDP and not over a new ether type. No new code point. --------------------------------8<---- cut here ---->8------------------------- From internet-drafts@ietf.org Wed Apr 4 22:51:33 2012 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 7F7BD21F8672; Wed, 4 Apr 2012 22:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3y66fVkqwZ1; Wed, 4 Apr 2012 22:51:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C27D21F85B6; Wed, 4 Apr 2012 22:51:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-generic-crypto-auth-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120405055128.13805.33449.idtracker@ietfa.amsl.com> Date: Wed, 04 Apr 2012 22:51:28 -0700 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, 05 Apr 2012 05:51:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Wo= rking Group of the IETF. Title : BFD Generic Cryptographic Authentication Author(s) : Manav Bhatia Vishwas Manral Dacheng Zhang Filename : draft-ietf-bfd-generic-crypto-auth-01.txt Pages : 12 Date : 2012-04-04 This document proposes an extension to Bidirectional Forwarding Detection (BFD) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes described in the base specification. This document adds the basic infrastructure thats required for supporting algorithm and key agility for BFD. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-generic-crypto-auth-01.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-bfd-generic-crypto-auth-01.txt From Tina.Tsou.Zouting@huawei.com Mon Apr 9 11:12:49 2012 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 BB21321F87C5 for ; Mon, 9 Apr 2012 11:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcIdW4vrFW+d for ; Mon, 9 Apr 2012 11:12:49 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1154A21F87DD for ; Mon, 9 Apr 2012 11:12:49 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFB75400; Mon, 09 Apr 2012 14:12:48 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 11:11:19 -0700 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 11:11:20 -0700 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.22]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Tue, 10 Apr 2012 02:11:12 +0800 From: Tina TSOU To: "rtg-bfd@ietf.org" Subject: FW: [pim] Comment on draft-lts-pim-hello-mtu? Thread-Topic: [pim] Comment on draft-lts-pim-hello-mtu? Thread-Index: Ac0TbPRReFB8+MLJQ6Wly2HsnKucXQCys0+AABEIDTA= Date: Mon, 9 Apr 2012 18:11:11 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected 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: Mon, 09 Apr 2012 18:12:49 -0000 > My main comment is that MTU is important for other protocols too, and > also for traffic/data, so I'm wondering if it would be better to do it > with some more general protocol. Maybe BFD or in the IGP? Tina > -----Original Message----- > From: Stig Venaas [mailto:stig@venaas.com] > Sent: Monday, April 09, 2012 11:02 AM > To: Tina TSOU > Cc: pim@ietf.org > Subject: Re: [pim] Comment on draft-lts-pim-hello-mtu? >=20 > On 4/5/2012 1:44 PM, Tina TSOU wrote: > > Dear all, > > May the author of draft-lts-pim-hello-mtu ask people to read the > draft and provide comments? > > > > http://datatracker.ietf.org/doc/draft-lts-pim-hello-mtu/ > > > > Thank you in advance. >=20 > See the minutes I just posted if you like. >=20 > My main comment is that MTU is important for other protocols too, and > also for traffic/data, so I'm wondering if it would be better to do it > with some more general protocol. Maybe BFD or in the IGP? > For IPv6 one could perhaps use RAs? >=20 > Stig >=20 > > > > > > Best Regards, > > Tina TSOU > > > > > > _______________________________________________ > > pim mailing list > > pim@ietf.org > > https://www.ietf.org/mailman/listinfo/pim From helen.liu@huawei.com Tue Apr 10 04:09:00 2012 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 26AD821F8731; Tue, 10 Apr 2012 04:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omCGx+M3DyYX; Tue, 10 Apr 2012 04:08:59 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 43D3121F872F; Tue, 10 Apr 2012 04:08:59 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFC29919; Tue, 10 Apr 2012 07:08:59 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Apr 2012 04:06:42 -0700 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Apr 2012 04:06:41 -0700 Received: from SZXEML501-MBS.china.huawei.com ([169.254.5.163]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Tue, 10 Apr 2012 19:06:30 +0800 From: Liuhui To: Stig Venaas , Tina TSOU Subject: RE: [pim] Comment on draft-lts-pim-hello-mtu? Thread-Topic: [pim] Comment on draft-lts-pim-hello-mtu? Thread-Index: Ac0TbPRReFB8+MLJQ6Wly2HsnKucXQCys0+AADOfugA= Date: Tue, 10 Apr 2012 11:06:30 +0000 Message-ID: <0521328FA8CCCE4089CA3C9261A28DD9374E43D0@SZXEML501-MBS.china.huawei.com> References: <4F832403.3060607@venaas.com> In-Reply-To: <4F832403.3060607@venaas.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rtg-bfd@ietf.org" , "pim@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, 10 Apr 2012 11:09:00 -0000 Hi Stig, Thanks for the comments. I also introduce the points in minutes below for d= iscussion. Thanks, Liu Hui > -----Original Message----- > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of > Stig Venaas > Sent: Tuesday, April 10, 2012 2:02 AM > To: Tina TSOU > Cc: pim@ietf.org > Subject: Re: [pim] Comment on draft-lts-pim-hello-mtu? >=20 > On 4/5/2012 1:44 PM, Tina TSOU wrote: > > Dear all, > > May the author of draft-lts-pim-hello-mtu ask people to read the draft > and provide comments? > > > > http://datatracker.ietf.org/doc/draft-lts-pim-hello-mtu/ > > > > Thank you in advance. >=20 > See the minutes I just posted if you like. "Stig: Useful if there are msiconfigurations or asymmetric MTUs for routers= on a link. But not just a PIM problem." [LH] Agree. E.g. OSPF also has MTU option carried in its Database Descripti= on packet.=20 =20 "Bill: If you are using MTU for control packets you may be able to send goo= d control packets but if the data packets are still too big, this could be = a bad thing. We need to make sure that this isn't a bad thing and explain i= t" [LH] Accepted. Could we explain it in this way: the control and data plane = are run independently. The control plane makes sure that forwarding paths a= re setup even though there exists asymmetric MTUs. Even though some data pa= ckets exceeding MTU limitation of some point of paths cannot be processed p= roperly, other packets in scope will be normally forwarded and delivered. A= nd it's up to first-hop or head- end to determine the length of a data pack= et, with other measures such as PMTU. "Dino: Population count helps because you can drop the packets at the first= hop router." [LH]Pop count is a PMTU-like method, which should deal with data packet. >=20 > My main comment is that MTU is important for other protocols too, [LH] It's important for protocol between its adjacent peers when they have = to exchange volumes of data, such as PIM Join with large amounts of group s= tates, and OSPF Database Description carrying all link-states during initia= lization. > and also for traffic/data,=20 [LH] I suppose PMTU-like methods are more applicable for traffic/data, whil= e for PIM and OSPF the key issue is between two adjacent hops where message= s often having to be segmented. They are for different purpose and should u= se different measures > so I'm wondering if it would be better > to do it with some more general protocol. Maybe BFD or in the IGP? > For IPv6 one could perhaps use RAs? [LH] Good points. Please see my considerations: For per-hop MTU here there are two steps implied, i.e., how PIM acquire= s its peer MTU info, and how it uses it. The first step has the possibility= to be generalized, and the second is somewhat protocol specific Then does this 'generalization' mean BFD or IGP or RA? As PIM is protoc= ol independent, we cannot assume it always run with IGP. So IGP might be no= t a good option for generalization.=20 RA has already had MTU option there, but it's for use for the nodes not= the routers. Even if the router takes the role of a node, there are no exp= licit peer and one common MTU is taken for all nodes in RA case, which is d= ifferent from the PIM one. And RA is applicable to only IPv6 network. BFD is more general. Should it be extended as here to cover most protoc= ols? It is not impossible, but the precondition is every protocol expects t= he same information from the common structure maintained by BFD. It deserve= s it if the number of protocols having this control message segmenting requ= irement is not small. PIM extension is proposed because there is no common structure availabl= e right now, and promoted by resolving the current network issues. It can b= e applied to both IPv4 and IPv6 networks, and doesn't mind whether IGP or B= FD is running or not.=20 >=20 > Stig >=20 > > > > > > Best Regards, > > Tina TSOU > > > > > > _______________________________________________ > > pim mailing list > > pim@ietf.org > > https://www.ietf.org/mailman/listinfo/pim >=20 > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From jhaas@slice.pfrc.org Thu Apr 12 09:30:12 2012 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 B804121F8674 for ; Thu, 12 Apr 2012 09:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.826 X-Spam-Level: X-Spam-Status: No, score=-101.826 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3bYXmr8zbUD for ; Thu, 12 Apr 2012 09:30:12 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E902D21F8653 for ; Thu, 12 Apr 2012 09:30:11 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9BD5C170208; Thu, 12 Apr 2012 12:30:11 -0400 (EDT) Date: Thu, 12 Apr 2012 12:30:11 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Re: Draft minutes from IETF 83 session Message-ID: <20120412163011.GD9700@slice> References: <20120403182344.GF7467@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120403182344.GF7467@slice> User-Agent: Mutt/1.5.20 (2009-06-14) 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, 12 Apr 2012 16:30:12 -0000 On Tue, Apr 03, 2012 at 02:23:44PM -0400, Jeffrey Haas wrote: > Thanks to Dave Ward for taking minutes. > Please send amendments or corrections to the mail list by April 11. Given that there are no comments on the minutes, they're accepted as-is. :-) -- Jeff From helen.liu@huawei.com Tue Apr 17 03:05:44 2012 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 92A2121F8608; Tue, 17 Apr 2012 03:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43r2crd-+1fD; Tue, 17 Apr 2012 03:05:40 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA8021F85CF; Tue, 17 Apr 2012 03:05:40 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFH17739; Tue, 17 Apr 2012 06:05:36 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 17 Apr 2012 03:03:25 -0700 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 17 Apr 2012 03:03:27 -0700 Received: from SZXEML501-MBS.china.huawei.com ([169.254.5.163]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Tue, 17 Apr 2012 18:03:14 +0800 From: Liuhui To: Chiranjeevi Ramana Rao , Stig Venaas , Tina TSOU Subject: RE: [pim] Comment on draft-lts-pim-hello-mtu? Thread-Topic: [pim] Comment on draft-lts-pim-hello-mtu? Thread-Index: Ac0TbPRReFB8+MLJQ6Wly2HsnKucXQCys0+AADOfugABVx0+cAAFWgrQ Date: Tue, 17 Apr 2012 10:03:14 +0000 Message-ID: <0521328FA8CCCE4089CA3C9261A28DD9374E922B@SZXEML501-MBS.china.huawei.com> References: <4F832403.3060607@venaas.com> <0521328FA8CCCE4089CA3C9261A28DD9374E43D0@SZXEML501-MBS.china.huawei.com> <660B7A61018B0247A5427EA250EACE67261054A6F6@ESESSCMS0359.eemea.ericsson.se> In-Reply-To: <660B7A61018B0247A5427EA250EACE67261054A6F6@ESESSCMS0359.eemea.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rtg-bfd@ietf.org" , "pim@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, 17 Apr 2012 10:05:44 -0000 Hi, For IGMPv3, do you mean when it is running between a host and a router? The= n it is quite different from what is resolved by this draft. PIM specific processing also has its benefits, as explained below. General = solution is not impossible, but it's better we collect enough use cases bef= ore we decide to turn to that direction. Thanks, Liu Hui >=20 > Hello > I second Stig on this, MTU problem mentioned here is general problem. > This draft is proposing solution for PIM. IGMPv3 also will have same > problem right? > It is not good idea to solve MTU problem per protocol. It will be nice,= if a > general solution is found for this problem. > Thanks > Chiranjeevi >=20 >=20 > -----Original Message----- > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of > Liuhui > Sent: Tuesday, April 10, 2012 4:37 PM > To: Stig Venaas; Tina TSOU > Cc: rtg-bfd@ietf.org; pim@ietf.org > Subject: Re: [pim] Comment on draft-lts-pim-hello-mtu? >=20 > Hi Stig, >=20 > Thanks for the comments. I also introduce the points in minutes below for > discussion. >=20 > Thanks, > Liu Hui >=20 > > -----Original Message----- > > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of > > Stig Venaas > > Sent: Tuesday, April 10, 2012 2:02 AM > > To: Tina TSOU > > Cc: pim@ietf.org > > Subject: Re: [pim] Comment on draft-lts-pim-hello-mtu? > > > > On 4/5/2012 1:44 PM, Tina TSOU wrote: > > > Dear all, > > > May the author of draft-lts-pim-hello-mtu ask people to read the > > > draft > > and provide comments? > > > > > > http://datatracker.ietf.org/doc/draft-lts-pim-hello-mtu/ > > > > > > Thank you in advance. > > >=20 > > See the minutes I just posted if you like. >=20 > "Stig: Useful if there are msiconfigurations or asymmetric MTUs for route= rs > on a link. But not just a PIM problem." > [LH] Agree. E.g. OSPF also has MTU option carried in its Database > Description packet. >=20 > "Bill: If you are using MTU for control packets you may be able to send g= ood > control packets but if the data packets are still too big, this could be = a bad > thing. We need to make sure that this isn't a bad thing and explain it" >=20 > [LH] Accepted. Could we explain it in this way: the control and data plan= e > are run independently. The control plane makes sure that forwarding paths > are setup even though there exists asymmetric MTUs. Even though some > data packets exceeding MTU limitation of some point of paths cannot be > processed properly, other packets in scope will be normally forwarded and > delivered. And it's up to first-hop or head- end to determine the length = of a > data packet, with other measures such as PMTU. >=20 > "Dino: Population count helps because you can drop the packets at the fir= st > hop router." > [LH]Pop count is a PMTU-like method, which should deal with data packet. >=20 > > > > My main comment is that MTU is important for other protocols too, >=20 > [LH] It's important for protocol between its adjacent peers when they hav= e > to exchange volumes of data, such as PIM Join with large amounts of group > states, and OSPF Database Description carrying all link-states during > initialization. >=20 > > and also for traffic/data, > [LH] I suppose PMTU-like methods are more applicable for traffic/data, > while for PIM and OSPF the key issue is between two adjacent hops where > messages often having to be segmented. They are for different purpose and > should use different measures >=20 > > so I'm wondering if it would be better > > to do it with some more general protocol. Maybe BFD or in the IGP? > > For IPv6 one could perhaps use RAs? >=20 > [LH] Good points. Please see my considerations: > For per-hop MTU here there are two steps implied, i.e., how PIM > acquires its peer MTU info, and how it uses it. The first step has the > possibility to be generalized, and the second is somewhat protocol specif= ic > Then does this 'generalization' mean BFD or IGP or RA? As PIM is > protocol independent, we cannot assume it always run with IGP. So IGP > might be not a good option for generalization. > RA has already had MTU option there, but it's for use for the nodes n= ot > the routers. Even if the router takes the role of a node, there are no ex= plicit > peer and one common MTU is taken for all nodes in RA case, which is > different from the PIM one. And RA is applicable to only IPv6 network. > BFD is more general. Should it be extended as here to cover most > protocols? It is not impossible, but the precondition is every protocol > expects the same information from the common structure maintained by > BFD. It deserves it if the number of protocols having this control messag= e > segmenting requirement is not small. > PIM extension is proposed because there is no common structure > available right now, and promoted by resolving the current network issues= . > It can be applied to both IPv4 and IPv6 networks, and doesn't mind whethe= r > IGP or BFD is running or not. >=20 > > > > Stig > > > > > > > > > > > Best Regards, > > > Tina TSOU > > > > > > > > > _______________________________________________ > > > pim mailing list > > > pim@ietf.org > > > https://www.ietf.org/mailman/listinfo/pim > > > > _______________________________________________ > > pim mailing list > > pim@ietf.org > > https://www.ietf.org/mailman/listinfo/pim > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From marc@sniff.de Wed Apr 25 16:43:24 2012 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 4526C21E808F for ; Wed, 25 Apr 2012 16:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgaV6f-SexNa for ; Wed, 25 Apr 2012 16:43:23 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C72BB21E8082 for ; Wed, 25 Apr 2012 16:43:18 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 3FE332AA0F for ; Wed, 25 Apr 2012 23:43:16 +0000 (GMT) From: Marc Binderberger Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Fwd: I-D Action: draft-akiya-bfd-intervals-01.txt Date: Thu, 26 Apr 2012 01:43:15 +0200 References: <20120425232912.26402.17632.idtracker@ietfa.amsl.com> To: rtg-bfd@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) 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, 25 Apr 2012 23:43:24 -0000 Hello BFD experts, after some feedback Nobo and me updated the document. We changed the = wording from "Mandatory interval support" towards "Standardized interval = support". The "Mandatory" was an unfortunate word choice and caused = confusion; my apology for this. We also added some clarifications. To summarize this draft is about an interoperability problem between BFD = speakers when the number of supported intervals is small, as it may = happen with hardware-based BFD. Such implementations are more difficult = to upgrade (or even impossible), compared to software on general-purpose = CPU, thus the attempt to avoid a foreseeable problem. Discussions are welcome :-) Best Regards, Nobo & Marc Begin forwarded message: > From: internet-drafts@ietf.org > Date: April 26, 2012 1:29:12 GMT+02:00 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-akiya-bfd-intervals-01.txt > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Standardized interval support in BFD > Author(s) : Nobo Akiya > Marc Binderberger > Filename : draft-akiya-bfd-intervals-01.txt > Pages : 6 > Date : 2012-04-25 >=20 > This document defines a set of interval values that we call = "Standard > intervals". Values of this set must be supported for transmitting > BFD control packets and for calculating the detection time in the > receive direction when the value is equal or larger than the = fastest, > i.e. lowest, interval a particular BFD implementation supports. >=20 > This solves the problem of finding an interval value that both BFD > speakers can support while allowing a simplified implementation as > seen for hardware-based BFD. >=20 >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-akiya-bfd-intervals-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-akiya-bfd-intervals-01.txt >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-akiya-bfd-intervals/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 -- Marc Binderberger From toms.sanders@gmail.com Wed Apr 25 18:13:41 2012 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 457E921F86B8 for ; Wed, 25 Apr 2012 18:13:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rk0KRo4cK4cl for ; Wed, 25 Apr 2012 18:13:40 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 25AF421F8672 for ; Wed, 25 Apr 2012 18:13:21 -0700 (PDT) Received: by werb10 with SMTP id b10so508052wer.31 for ; Wed, 25 Apr 2012 18:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EB3tFFGsSVlXMW+aBSsdgc+pLuLZWvZkcr4AbxrXPJE=; b=ELJ7zFqKL6EelO3KNm5CoxUb0BBzGJsPX91E97sjjxt2Nt08MsE483/0JgBr8q3vam 86owho2Xrsq3HTlV7zehU5jr0em1JzN1MRH9cNwyIpbFzg5mWuD2aF0hhK2aNZch700E zsThSktOCoSr2YoP6AdKBi0elyvmJ2CsgTaYnRjdqzPBwa4z0wpOKFlkqlyaTPBOCrpe dnzjprkIGL+bzlxvSS/Fmr0HhVuVdejI40ywSRoEyLPPM4wRAqb9WSpxtzpZcOzzoYms fVkcbKefUbThNblfwqC4/DN4crQHiv7dPzrP3NulxW47ZAohVE0hT3t3OSLiRNTYQw5h b/dg== MIME-Version: 1.0 Received: by 10.216.135.105 with SMTP id t83mr2854159wei.105.1335402801170; Wed, 25 Apr 2012 18:13:21 -0700 (PDT) Received: by 10.223.103.14 with HTTP; Wed, 25 Apr 2012 18:13:21 -0700 (PDT) In-Reply-To: <20120325082306.GC24448@slice> References: <20120325082306.GC24448@slice> Date: Thu, 26 Apr 2012 06:43:21 +0530 Message-ID: Subject: Re: [lsmt@ietf.org: New Liaison Statement, "Liaison response to IETF regarding Proposed IETF BFD WG work on Ethernet LAG"] From: Tom Sanders To: Jeffrey Haas , "Bhatia, Manav (Manav)" , David Ward 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: Thu, 26 Apr 2012 01:13:41 -0000 Hi Jeff, Dave and Manav, Arent you guys coming out with a new version that incorporates the following comments from IEEE? I also did not see any progress on the updated charter. Is anything happening on that front? Toms On 25 March 2012 13:53, Jeffrey Haas wrote: > Working group, > > We have received a response from IEEE regarding the proposed charter work > for BFD over LAGs. =C2=A0Please take this opportunity to review their res= ponse > and consider its implications on the discussion about how we'd go about > implementing BFD over LAG. > > -- Jeff > > ----- Forwarded message from Liaison Statement Management Tool ----- > > Date: Mon, 19 Mar 2012 14:09:43 -0700 > From: Liaison Statement Management Tool > To: Stewart Bryant , > =C2=A0 =C2=A0 =C2=A0 =C2=A0Adrian Farrel > Cc: The IETF Chair , Eric Gray , > =C2=A0 =C2=A0 =C2=A0 =C2=A0David Ward , Jeffrey Haas , > =C2=A0 =C2=A0 =C2=A0 =C2=A0Dan Romascanu , > =C2=A0 =C2=A0 =C2=A0 =C2=A0Stephen Haddock , > =C2=A0 =C2=A0 =C2=A0 =C2=A0Tony Jeffree > Subject: New Liaison Statement, > =C2=A0 =C2=A0 =C2=A0 =C2=A0"Liaison response to IETF regarding Proposed I= ETF BFD WG work on > =C2=A0 =C2=A0 =C2=A0 =C2=A0Ethernet LAG" > > Title: Liaison response to IETF regarding Proposed IETF BFD WG work on Et= hernet LAG > Submission Date: 2012-03-15 > URL of the IETF Web page: http://datatracker.ietf.org/liaison/1152/ > > From: IEEE 802.1 (Tony Jeffree ) > To: Routing Area (Stewart Bryant , Adrian Farrel ) > Cc: The IETF Chair ,Eric Gray ,Da= vid Ward ,Jeffrey Haas ,Dan Romascanu > Reponse Contact: Stephen Haddock , Tony Jeff= ree > Technical Contact: > Purpose: For information > Referenced liaison: Proposed IETF BFD WG Work on Ethernet LAG (http://dat= atracker.ietf.org/liaison/1145/) > Body: > Attachments: > > =C2=A0 =C2=A0Liaison response to IETF regarding Proposed IETF BFD WG work= on Ethernet LAG > =C2=A0 =C2=A0https://datatracker.ietf.org/documents/LIAISON/liaison-2012-= 03-15-ieee-8021-rtg-liaison-response-to-ietf-regarding-proposed-ietf-bfd-wg= -work-on-ethernet-lag-attachment-1.pdf > > ----- End forwarded message ----- --=20 Toms.