From jhaas@slice.pfrc.org Thu Aug 2 18:24:05 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 DA9D421F8C0D for ; Thu, 2 Aug 2012 18:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.15 X-Spam-Level: X-Spam-Status: No, score=-102.15 tagged_above=-999 required=5 tests=[AWL=0.115, 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 CMpFwm87SzpX for ; Thu, 2 Aug 2012 18:24:05 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7307921F8AB2 for ; Thu, 2 Aug 2012 18:24:05 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6CB62CD93; Thu, 2 Aug 2012 21:24:00 -0400 (EDT) Date: Thu, 2 Aug 2012 21:24:00 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Minutes for IETF-84 meeting Message-ID: <20120803012400.GA9944@pfrc> 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: Fri, 03 Aug 2012 01:24:06 -0000 Thanks to Dave Ward for taking the session minutes: http://www.ietf.org/proceedings/84/minutes/minutes-84-bfd Please send comments on the draft minutes no later than August 10. -- Jeff and Dave From pabloisnot@gmail.com Wed Aug 8 14:38:13 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 D6E3C11E8123 for ; Wed, 8 Aug 2012 14:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 cQ-EAo5lJ7iP for ; Wed, 8 Aug 2012 14:38:11 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1858211E80AE for ; Wed, 8 Aug 2012 14:38:10 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so723736wgb.13 for ; Wed, 08 Aug 2012 14:38:10 -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=r1Dk7tUyQcwQUiFitxAa5im4SHVWqBZ6RTteZaDcBgc=; b=xLOoJDny07JXvDzcTsiM8sWIBiA+bt64yMVoFA7TSuyB6cnqFWOvIN7V//jpLgaTLp trKjNW3eF1RWEjaBpAFEELzab9ZgEUqa1WTNnXJVwqV53Z6zm+vWOma2S/NNUkDpmONM gNsKaVJyKn3pQzuaft/1LmlJUDYkpM0sXaMW/6iHWQEehsJBeMtb1rAXWpMc1gvjS4X3 GtBNCulxB8i3vktYAcU2sT5iXjMc0Av8L8apMrqx1jDHi1nP3KuM/lzFeoD4SNkg97gP 43wYR6l458Wythmutay8ym0omS1HQUOtuU1r9oWeHJ4+IVZVeTkyxelwsC3/jCO0wf1n Qa3A== MIME-Version: 1.0 Received: by 10.180.84.169 with SMTP id a9mr1022447wiz.8.1344461889881; Wed, 08 Aug 2012 14:38:09 -0700 (PDT) Received: by 10.227.197.206 with HTTP; Wed, 8 Aug 2012 14:38:09 -0700 (PDT) In-Reply-To: <1547F1A4-D799-4BE5-A762-7F3EED769BBA@sniff.de> References: <20120716102532.2738.60203.idtracker@ietfa.amsl.com> <1547F1A4-D799-4BE5-A762-7F3EED769BBA@sniff.de> Date: Wed, 8 Aug 2012 17:38:09 -0400 Message-ID: Subject: Re: I-D Action: draft-akiya-bfd-intervals-03.txt From: Pablo Frank To: Marc Binderberger Content-Type: multipart/alternative; boundary=f46d0418281a5c478604c6c7edeb Cc: rtg-bfd@ietf.org, draft-akiya-bfd-intervals@tools.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, 08 Aug 2012 21:38:14 -0000 --f46d0418281a5c478604c6c7edeb Content-Type: text/plain; charset=ISO-8859-1 Hi Marc, Thanks for considering my comments. See additional comments below PF>> On Tue, Jul 31, 2012 at 6:57 PM, Marc Binderberger wrote: > Hello Greg and Pablo, > > sorry for the late reply, simply busy. And thanks for the feedback! > > > I'm perfectly fine adding the 100msec. For removing the 300msec, true that > 3 x 300msec or 9 x 100msec should cover the same scenarios. I hope that we > get some more feedback from vendors (not just routers) if we can drop > 300msec. > > I do not agree with the sparse list with the large jump from 10msec to > 100msec, even if IEEE does. Reality is not black/white and being close to > 50-60msec detection time is still better than being off like 200-300msec. > Thus the 20msec. It was actually this gap that motivated us writing this > draft :-) > PF>> I think the main issue I have with 20msec is that it doesn't necessarily meet any particular application requirement. It is likely too slow to be useful for sub 50msec protection-switching. For customers who require sub-50ms protection-switching, this is a hard requirement and they will test for it. Being 50ms-ish is usually not good enough, especially when one considers that this is supposed to include restoration time as well as propagation delay over long links. I'm vary wary of adding normative text that requires hardware implementations to support additional intervals, especially if that increases the cost of such solutions. > The draft also suggests 50ms as a rate that some software implementations > can achieve. IMHO, this is irrelevant. > > > With 20msec and 100msec available one may replace 50msec in terms of > dection time. On the other hand 50msec is a value I've seen quite often, > i.e. it's not irrelevant. This draft is about interoperability in the sense > that existing/older software-based implementations can peer with > silicon-based BFD while largely maintaining the existing detection times. But > again, the discussion just started. > PF>> Strictly speaking, you have interoperability, just not at the desired rates. But this strikes me as a nice-to-have as opposed to a mandatory requirement. I think there's some need to specify minimum requirements that have clear application needs (such as 3.3/10ms for protection-switching, 100ms for performance-monitoring, etc.) but the remaining proposed rates can probably be specified as SHOULD/RECOMMENDED requirements. > I've seen merchant silicon implementations that can really only do 3 or 4 > "fast" rates > > > fair point, on the other hand BFD solutions and thus "typical" timer > values are out in the world and the silicon vendors are not reinventing > BFD. Plus you can use silicon for the really fast BFD and use cheaper > software for the not-so-fast timers. > PF>> Be careful with the assumption that "slow" rates like 50ms or 300ms is not imposing a requirement on hardware. If you work on very large devices which are dealing with thousands and tens of thousands of tunnels, even a rate like 50ms / 300ms will require hardware to achieve scale. This is precisely what worries me, in fact. But to find the balance is what this discussion is for :-) > > > Regarding the additional ".5" in your detection time calculation, while I > guess I understand this from a hardware implementation point of view I > somewhat disagree. From RFC5880: > > 6.8.4. Calculating the Detection Time > [...] > In Asynchronous mode, the Detection Time calculated in the local > system is equal to the value of Detect Mult received from the remote > > system, multiplied by the agreed transmit interval of the remote > system (the greater of bfd.RequiredMinRxInterval and the last > received Desired Min TX Interval). > > > So M * I (M: remote Multiplier, I: remote agreed transmit interval) > should be your upper limit until when you have detected that the link or TP > tunnel is interrupted. (M-1) * I would be the lower boundary. > PF>> Yes, the 0.5 that I'm adding is definitely trying to recognize the reality that I've seen in a lot of hardware implementations. A typical hardware implementation does not use dedicated cancellable one-shot timers. For example, a typical implementation uses a sliding window to keep track of how many CCs have been received within a set of intervals. This will lead to some inaccuracy but the inaccuracy is well bounded. 802.1ag recognized this reality and even has normative text requiring that an implementation must detect discontinuity between 3.25 and 3.5 x the CCM interval. RFC 6371 (which I admit is NOT normative) makes a similar suggestion of waiting until 3.5 CC intervals have passed before declaring a defect. IMO, none of this necessarily conflicts with the text that you've cited. The 'detection time' is the definition for a timer and, technically, RFC 5880 has no normative text describing how quickly an implementation must respond to the expiry of this timer. Probably, when the spec was originally written, responsiveness of timers was considered a negligible/irrelevant factor. But as we push the speed limits of software (and hardware), this is no longer negligible. For example, I've seen a few software implementations that claim 10ms CC intervals but when said implementations are hit by a storm of say, 1000 tunnels failing, the 1000th timer expiry is certainly not handled immediately. Even for a small number of failures, such implementations have difficulty responding without some significant slip. Perhaps it's worth having your draft attempt to specify such timer responsiveness requirements? This could also help in improving interoperability. For the larger values that Greg mentioned (10 sec, 1 min, 10 min) I still > have to give this a thought. Larger timer (and multiplier) values are one > way to achieve "graceful restart" for BFD and I've heard about interop > problems with it as well, so maybe worthwhile to cover in this draft as > well. > PF>> I'm ambivalent about any interval larger than 1s since I have a hard time imagining that such intervals would ever be implemented in hardware (famous last words). However, since the focus of your draft is interoperability, specifying these larger intervals and making them consistent with 802.1ag seems like it might be useful. cheers, Pablo > > Anyway, thanks again for the feedback and opinion! > > > Regards, Marc > > > > On 2012-07-31, at 23:28 , Pablo Frank wrote: > > I'd like to echo Greg's suggestion that we should align the minimum set of > required rates against 802.1ag/Y.1731. However, I'd like to make the > argument that you should consider *removing* some of the rates suggested in > the draft. In my mind, the main value in this draft specifying a minimum > set of supported intervals is really to set minimum standards for hardware > implementations. Software implementations of BFD will typically have the > ability to be very flexible above a certain point. In other words, a > software implementation that can minimally support 100ms intervals can > likely support nearly any rate that is slower than 100ms. OTOH, hardware > implementations tend to be fairly restricted in the number of high-speed > rates that they can support. I've seen merchant silicon implementations > that can really only do 3 or 4 "fast" rates (i.e. <1pps). Specifying too > many rates will likely increase the cost of these solutions and we should > only do this if there is a strong use-case to justify pushing these > requirements on silicon vendors. > > In terms of the suggested rates, both 3.3ms and 10ms are rates suggested > for CC/CV for MPLS-TP in RFC 6371 to > support protection-switching so should be included in the minimum set. The > draft suggests 20ms (or 15ms) as another rate that can support 50ms > switchovers but this is impractical since worst-case detection time for > faults using 20ms CC/CV is 2.5 x 20ms = 50ms, which leaves you essentially > no time to perform the actual switchover. > > The draft also suggests 50ms as a rate that some software implementations > can achieve. IMHO, this is irrelevant. There are probably software > implementations that could also achieve 25ms or even 10ms. That doesn't > seem to be a good reason to add it to the list. AFAIK, there is no > application that really benefits from 50ms CC/CV that would not be > adequately served by 100ms. 50ms CC/CV certainly won't achieve 50ms > protection switching times, even with a defect multiplier of 1. > > As Greg suggests, we should certainly add 100ms to the list. RFC 6371 > also lists 100ms as a rate that is useful to support performance-monitoring > applications in MPLS-TP networks. It's worth noting that hardware that > does periodic LM/DM will often share common timer infrastructure with CC/CV > so it's good to align on these rates. 1s is also called out by RFC 6371. > > The draft also suggests 300ms to support VOIP applications that require > <1s detection time. But this makes the same erroneous assumption as the > 20ms rate. With a 300ms CC/CV interval and a defect multiplier of 3, > defect-entry can occur as late as 3.5 x 300ms = 1050ms which violates the > 1s requirement. I would suggest that the 100ms interval can probably serve > this application just fine. But it would be good to get the opinions of > any VOIP experts on the list. > > In summary, I would suggest 3.3ms, 10ms, 100ms, and 1s as the minimal set. > I would delete 20ms, 50ms, and 300ms. > > regards, > Pablo > > On Tue, Jul 24, 2012 at 7:34 PM, Greg Mirsky wrote: > >> Hi Marc, et al., >> I think I'd refer to the set of timer values defined in the >> draft-akiya-bfd-intervals as 'Minimally Required Set" rather than as >> "Standard". >> Second, 3.3 ms interval included in the set for the benefit of MPLS-TP. >> I'd note that OAM for packet transport networks would likely to use from >> set of intervals defined in IEEE 802.1ag/Y.1731, i.e. [3.3 ms, 10 ms, 100 >> ms, 1 sec, 10 sec, 1 min, 10 min]. To make two sets more compatible, I >> propose to include 100 ms interval into the Minimally Required Set that >> proposed in the draft. >> >> Regards, >> Greg >> >> >> On Mon, Jul 16, 2012 at 3:31 AM, Marc Binderberger wrote: >> >>> Hello BFD experts, >>> >>> Nobo and me have uploaded a new version of draft-akiya-bfd-intervals, >>> mainly fixing some typos and adding one clarification. >>> >>> We received (unicast) several feedbacks, in general positive. What still >>> may require a closer look is: >>> >>> (i) the set of Standard Interval values >>> >>> (ii) the Poll/Final sequence example in Appendix B >>> >>> >>> Thanks & Regards, >>> Marc >>> >>> >>> >>> Begin forwarded message: >>> >>> > From: internet-drafts@ietf.org >>> > Date: July 16, 2012 12:25:32 GMT+02:00 >>> > To: i-d-announce@ietf.org >>> > Subject: I-D Action: draft-akiya-bfd-intervals-03.txt >>> > Reply-To: internet-drafts@ietf.org >>> > >>> > >>> > A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> > >>> > >>> > Title : Standardized interval support in BFD >>> > Author(s) : Nobo Akiya >>> > Marc Binderberger >>> > Filename : draft-akiya-bfd-intervals-03.txt >>> > Pages : 8 >>> > Date : 2012-07-16 >>> > >>> > Abstract: >>> > 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. >>> > >>> > 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. >>> > >>> > >>> > >>> > The IETF datatracker status page for this draft is: >>> > https://datatracker.ietf.org/doc/draft-akiya-bfd-intervals >>> > >>> > There's also a htmlized version available at: >>> > http://tools.ietf.org/html/draft-akiya-bfd-intervals-03 >>> > >>> > A diff from previous version is available at: >>> > http://tools.ietf.org/rfcdiff?url2=draft-akiya-bfd-intervals-03 >>> > >>> > >>> > Internet-Drafts are also available by anonymous FTP at: >>> > ftp://ftp.ietf.org/internet-drafts/ >>> > >>> > _______________________________________________ >>> > 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 >>> > >>> >>> -- >>> Marc Binderberger >>> >>> >> > > -- > Marc Binderberger > > --f46d0418281a5c478604c6c7edeb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Marc,

Thanks for considering my comments.
See additional comments below PF>>

On Tue, Jul 31, 2012 at 6:57 PM, Marc Binderberger <marc@sniff.de<= /a>> wrote:
Hello Greg and Pablo,

sorry for the late reply, simply busy. And thank= s for the feedback!


I&#= 39;m perfectly fine adding the 100msec. For removing the 300msec, true that= 3 x 300msec or 9 x 100msec should cover the same scenarios. I hope that we= get some more feedback from vendors (not just routers) if we can drop 300m= sec.

I do= not agree with the sparse list with the large jump from 10msec to 100msec,= even if IEEE does. Reality is not black/white and being close to 50-60msec= detection time is still better than being off like 200-300msec. Thus the 2= 0msec. It was actually this gap that motivated us writing this draft :-)

PF>> I think the main issue I = have with 20msec is that it doesn't necessarily meet any particular app= lication requirement. =A0It is likely too slow to be useful for sub 50msec = protection-switching. =A0For customers who require sub-50ms protection-swit= ching, this is a hard requirement and they will test for it. =A0Being 50ms-= ish is usually not good enough, especially when one considers that this is = supposed to include restoration time as well as propagation delay over long= links. =A0I'm vary wary of adding normative text that requires hardwar= e implementations to support additional intervals, especially if that incre= ases the cost of such solutions.
=A0
The dr= aft also suggests 50ms as a rate that some software implementations can ach= ieve. =A0IMHO, this is irrelevant.

With 20msec = and 100msec available one may replace 50msec in terms of dection time. On t= he other hand 50msec is a value I've seen quite often, i.e. it's no= t irrelevant. This draft is about interoperability in the sense that existi= ng/older software-based implementations can peer with silicon-based BFD whi= le largely maintaining the existing detection times.=A0But again, the discussion just started.

PF>> Strictly speaking, you ha= ve interoperability, just not at the desired rates. =A0But this strikes me = as a nice-to-have as opposed to a mandatory requirement. =A0I think there&#= 39;s some need to specify minimum requirements that have clear application = needs (such as 3.3/10ms for protection-switching, 100ms for performance-mon= itoring, etc.) but the remaining proposed rates can probably be specified a= s SHOULD/RECOMMENDED requirements.
I've seen merchant si= licon implementations that can really only do 3 or 4 "fast" rates=

fair point, on the other hand BFD solutions and thus "t= ypical" timer values are out in the world and the silicon vendors are = not reinventing BFD. Plus you can use silicon for the really fast BFD and u= se cheaper software for the not-so-fast timers.


But to find the balance is what this disc= ussion is for :-)=A0


=
Regarding the additional ".5&q= uot; in your detection time calculation, while I guess I understand this fr= om a hardware implementation point of view I somewhat disagree. From RFC588= 0:

6.8.= 4. =A0Calculating the Detection Time
[...]
=A0 =A0In Asynchronous mode, the Detection Time calculated in the local
=A0 =A0system is equal to the value of Detect Mult received from the= remote =A0 =A0=A0
=A0 =A0system, multiplied by the agreed transm= it interval of the remote
=A0 =A0system (the greater of bfd.RequiredMinRxInterval and the last
=A0 =A0received Desired Min TX Interval).
<= font face=3D"Monaco">

So =A0M * I (M: remote Multiplier, I: remote agreed t= ransmit interval) should be your upper limit until when you have detected t= hat the link or TP tunnel is interrupted. (M-1) * I would be the lower boun= dary.

PF>> =A0Yes, the 0.5 that I= 9;m adding is definitely trying to recognize the reality that I've seen= in a lot of hardware implementations. =A0A typical hardware implementation= does not use dedicated=A0cancellable=A0one-shot timers. =A0For example, a = typical implementation uses a sliding window to keep track of how many CCs = have been received within a set of intervals. =A0This will lead to some ina= ccuracy but the inaccuracy is well bounded. =A0802.1ag recognized this real= ity and even has normative text requiring that an implementation must detec= t discontinuity between 3.25 and 3.5 x the CCM interval. =A0

RFC 6371 (which I admit is NOT normative) makes a simil= ar suggestion of waiting until 3.5 CC intervals have passed before declarin= g a defect. =A0IMO, none of this necessarily conflicts with the text that y= ou've cited. =A0The 'detection time' is the definition for a ti= mer and, technically, RFC 5880 has no normative text describing how quickly= an implementation must respond to the expiry of this timer. =A0Probably, w= hen the spec was originally written, responsiveness of timers was considere= d a negligible/irrelevant factor. =A0But as we push the speed limits of sof= tware (and hardware), this is no longer negligible. =A0For example, I'v= e seen a few software implementations that claim 10ms CC intervals but when= said implementations are hit by a storm of say, 1000 tunnels failing, the = 1000th timer expiry is certainly not handled immediately. =A0Even for a sma= ll number of failures, such implementations have difficulty responding with= out some significant slip. =A0

Perhaps it's worth having your draft attempt to spe= cify such timer responsiveness requirements? =A0This could also help in imp= roving interoperability. =A0

For the larger values that Greg mentioned= (10 sec, 1 min, 10 min) =A0I sti= ll have to give this a thought. Larger timer (and multiplier) values are on= e way to achieve "graceful restart" for BFD and I've heard ab= out interop problems with it as well, so maybe worthwhile to cover in this = draft as well.

PF>> I'm ambivalent about = any interval larger than 1s since I have a hard time imagining that such in= tervals would ever be implemented in hardware (famous last words). =A0Howev= er, since the focus of your draft is interoperability, specifying these lar= ger intervals and making them consistent with 802.1ag seems like it might b= e useful.

cheers,
Pablo



Anyway, thanks again for the feedback and opinion!
<= span style=3D"font-family:Monaco">

= Regards, Marc


<= div>
On 2012-07-= 31, at 23:28 , Pablo Frank wrote:

I'= d like to echo Greg's suggestion that we should align the minimum set o= f required rates against 802.1ag/Y.1731. =A0However, I'd like to make t= he argument that you should consider *removing* some of the rates suggested= in the draft. =A0In my mind, the main value in this draft specifying a min= imum set of supported intervals is really to set minimum standards for hard= ware implementations. =A0Software implementations of BFD will typically hav= e the ability to be very flexible above a certain point. =A0In other words,= a software implementation that can minimally support 100ms intervals can l= ikely support nearly any rate that is slower than 100ms. =A0OTOH, hardware = implementations tend to be fairly restricted in the number of high-speed ra= tes that they can support. =A0I've seen merchant silicon implementation= s that can really only do 3 or 4 "fast" rates (i.e. <1pps). = =A0Specifying too many rates will likely increase the cost of these solutio= ns and we should only do this if there is a strong use-case to justify push= ing these requirements on silicon vendors.

In terms of the suggested rates, both 3.3ms and 10ms are rat= es suggested for CC/CV for MPLS-TP in=A0RFC 6371=A0to support prote= ction-switching so should be included in the minimum set. =A0The draft sugg= ests 20ms (or 15ms) as another rate that can support 50ms switchovers but t= his is impractical since worst-case detection time for faults using 20ms CC= /CV is 2.5 x 20ms =3D 50ms, which leaves you essentially no time to perform= the actual switchover. =A0

The draft also suggests 50ms as a rate that some softwa= re implementations can achieve. =A0IMHO, this is irrelevant. =A0There are p= robably software implementations that could also achieve 25ms or even 10ms.= =A0That doesn't seem to be a good reason to add it to the list. =A0AFA= IK, there is no application that really benefits from 50ms CC/CV that would= not be adequately served by 100ms. =A050ms CC/CV certainly won't achie= ve 50ms protection switching times, even with a defect multiplier of 1.

As Greg suggests, we should certainly add 100ms to the = list. =A0RFC 6371 also lists 100ms as a rate that is useful to support perf= ormance-monitoring applications in MPLS-TP networks. =A0It's worth noti= ng that hardware that does periodic LM/DM will often share common timer inf= rastructure with CC/CV so it's good to align on these rates. =A01s is a= lso called out by RFC 6371.

The draft also suggests 300ms to support VOIP applicati= ons that require <1s detection time. =A0But this makes the same erroneou= s assumption as the 20ms rate. =A0With a 300ms CC/CV interval and a defect = multiplier of 3, defect-entry can occur as late as 3.5 x 300ms =3D 1050ms w= hich violates the 1s requirement. =A0I would suggest that the 100ms interva= l can probably serve this application just fine. =A0But it would be good to= get the opinions of any VOIP experts on the list.

In summary, I would suggest 3.3ms, 10ms, 100ms, and 1s = as the minimal set. =A0I would delete 20ms, 50ms, and 300ms.

=
regards,
Pablo

On Tue, Jul 24, 2012 at 7:34 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Marc, et al.,
I think I'd refer to the set of timer values define= d in the draft-akiya-bfd-intervals as 'Minimally Required Set" rat= her than as "Standard".
Second, 3.3 ms interval included in th= e set for the benefit of MPLS-TP. I'd note that OAM for packet transpor= t networks would likely to use from set of intervals defined in IEEE 802.1a= g/Y.1731, i.e. [3.3 ms, 10 ms, 100 ms, 1 sec, 10 sec, 1 min, 10 min]. To ma= ke two sets more compatible, I propose to include 100 ms interval into the = Minimally Required Set that proposed in the draft.

Regards,
Greg


On Mon, Ju= l 16, 2012 at 3:31 AM, Marc Binderberger <marc@sniff.de> wrote:<= br>
Hello BFD experts,

Nobo and me have uploaded a new version of draft-akiya-bfd-intervals, mainl= y fixing some typos and adding one clarification.

We received (unicast) several feedbacks, in general positive. What still ma= y require a closer look is:

(i) =A0the set of Standard Interval values

(ii) the Poll/Final sequence example in Appendix B


Thanks & Regards,
Marc



Begin forwarded message:

> From: in= ternet-drafts@ietf.org
> Date: July 16, 2012 12:25:32 GMT+02:00
> To: i-d-ann= ounce@ietf.org
> Subject: I-D Action: draft-akiya-bfd-intervals-03.txt
> Reply-To: internet-drafts@ietf.org
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Standardized 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 Filename =A0 =A0 =A0 =A0: draft-akiya-bfd-intervals-03.txt=
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 8
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-07-16
>
> Abstract:
> =A0 This document defines a set of interval values that we call "= Standard
> =A0 intervals". =A0Values of this set must be supported for trans= mitting
> =A0 BFD control packets and for calculating the detection time in the<= br> > =A0 receive direction when the value is equal or larger than the faste= st,
> =A0 i.e. lowest, interval a particular BFD implementation supports. >
> =A0 This solves the problem of finding an interval value that both BFD=
> =A0 speakers can support while allowing a simplified implementation as=
> =A0 seen for hardware-based BFD.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-akiya-bfd-interva= ls
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-akiya-bfd-intervals-03=
>
> A diff from previous version is available at:
> http://tools.ietf.org/rfcdiff?url2=3Ddraft-akiya-= bfd-intervals-03
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announc= e@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
>

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




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


--f46d0418281a5c478604c6c7edeb-- From marc@sniff.de Tue Aug 14 08:17: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 1DE3821F85AD for ; Tue, 14 Aug 2012 08:17:31 -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 Q+EfA0Htm2oy for ; Tue, 14 Aug 2012 08:17: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 DAF8D21F85AA for ; Tue, 14 Aug 2012 08:17:29 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 816882AA0F; Tue, 14 Aug 2012 15:17:27 +0000 (GMT) Subject: Re: draft-mmm-bfd-on-lags Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6702E16333FA@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Date: Tue, 14 Aug 2012 17:17:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <14C7F4F06DB5814AB0DE29716C4F6D6702E16333FA@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> To: "Henderickx, Wim (Wim)" X-Mailer: Apple Mail (2.1084) Cc: "rtg-bfd@ietf.org" , "draft-mmm-bfd-on-lags@tools.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, 14 Aug 2012 15:17:31 -0000 Hello Wim et al., my apology for answering late. day-to-day business was taking it's toll = :-) > Can this be more relaxed in the sense that micro-BFD session could = keep using the dedicated MAC address during the complete lifetime of the = session? in general fine with me. Waiting for more comments from the list :-) Now the reason we have written it with a stubborn "MUST" was a bit of = fear that implementations will largely avoid the MAC learning, which = would practically obsolete this part of the draft. Nevertheless, changing the last MUST into a SHOULD is what you have in = mind? ----snip----snap----snip----snap---- 2.3. Micro BFD session Ethernet details On Ethernet-based LAG member links the destination MAC is a dedicated MAC address (to be assigned by IANA according to [RFC5342]) to be the immediate next hop. This dedicated MAC address MUST be used for the initial BFD packets of a micro BFD session when in the Down/AdminDown and Init state. When sending BFD packets for the micro BFD session in the Up state, the MAC address from the received BFD packets for the session SHOULD be used. ----snip----snap----snip----snap---- > This might make implementations easier. That is true. But if we all do it for all our implementations the easier = way then it is effectively obsolete to write it down. And hardware with = small MAC tables will have at least a performance challenge. Regards, Marc On 2012-07-27, at 7:23 , Henderickx, Wim (Wim) wrote: > Hi, >=20 > I have a question on section 2.3 with respect to the use of the = destination MAC in the micro BFD section. >=20 > The current draft says that: When sending BFD packets for the micro = BFD session > in the Up state, the MAC address from the received BFD packets for > the session MUST be used. >=20 > Can this be more relaxed in the sense that micro-BFD session could = keep using the dedicated MAC address during the complete lifetime of the = session? >=20 > This might make implementations easier. >=20 > Cheers, > Wim >=20 -- Marc Binderberger From marc@sniff.de Tue Aug 14 09:29:21 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 2CE1321F8789 for ; Tue, 14 Aug 2012 09:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.148, 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 q0fIgoOc8QR2 for ; Tue, 14 Aug 2012 09:29:20 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3FE21F876E for ; Tue, 14 Aug 2012 09:29:17 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id B4D322AA0F; Tue, 14 Aug 2012 16:29:15 +0000 (GMT) From: Marc Binderberger Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? Date: Tue, 14 Aug 2012 18:29:12 +0200 Message-Id: To: rtg-bfd@ietf.org, Pablo Frank Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: draft-mmm-bfd-on-lags@tools.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, 14 Aug 2012 16:29:21 -0000 Hello BFD experts, for draft-mmm-bfd-on-lags-05 I would like to bring a question into the = discussion that I have heard now several times (thanks Pablo!) since the = latest draft is out: why is the draft so strict in enforcing the micro = sessions to be either IPv4 exclusive-or IPv6 ? Why not allowing both? 2.1. Micro BFD session address family Only one address family MUST be used for all micro BFD sessions running on all LAG member links. I.e. all member link micro BFD sessions of a particular LAG MUST either use IPv4 or IPv6. As we want to cover the layer-3 aspects of the LAG and member links as = well, having a liveness test for both IPv4 and IPv6 seems reasonable. = The draft states 5. Detecting a member link failure When a micro BFD session goes down then this member link MUST be taken out of the LAG L2 load balance table. One could rewrite this statement that when _any_ micro BFD session of a = member link goes down that the link MUST be taken out of the load = balance table. Plus the comment that in case the LAG load balance table = is address-family aware that an implementation MAY remove the link from = the load-balance table only that matches the failing micro session's = address family (not sure if such an implementation of LAG load balance = tables exist at all? Otherwise we could skip this 2nd part). Comments? Regards, Marc -- Marc Binderberger From wim.henderickx@alcatel-lucent.com Tue Aug 14 10:27:48 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 D4B0721F8775 for ; Tue, 14 Aug 2012 10:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.721 X-Spam-Level: X-Spam-Status: No, score=-9.721 tagged_above=-999 required=5 tests=[AWL=0.528, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 OR5VKHzpRGat for ; Tue, 14 Aug 2012 10:27:48 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id ADB2A21F8769 for ; Tue, 14 Aug 2012 10:27:47 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q7EHRjP1027248 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Aug 2012 19:27:45 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 14 Aug 2012 19:27:45 +0200 From: "Henderickx, Wim (Wim)" To: Marc Binderberger Date: Tue, 14 Aug 2012 19:27:44 +0200 Subject: RE: draft-mmm-bfd-on-lags Thread-Topic: draft-mmm-bfd-on-lags Thread-Index: Ac16L/ESBs35AZvORCK0cTdTYNoN8wADmyIQ Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702E1792951@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <14C7F4F06DB5814AB0DE29716C4F6D6702E16333FA@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "rtg-bfd@ietf.org" , "draft-mmm-bfd-on-lags@tools.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, 14 Aug 2012 17:27:48 -0000 Marc, thx for following up. I was indeed suggesting the statement to be cha= nged to SHOULD iso MUST. We should leave the statement there to guide imple= mentation to take into account devices which don't have big MAC tables. -----Original Message----- From: Marc Binderberger [mailto:marc@sniff.de]=20 Sent: dinsdag 14 augustus 2012 17:17 To: Henderickx, Wim (Wim) Cc: draft-mmm-bfd-on-lags@tools.ietf.org; rtg-bfd@ietf.org Subject: Re: draft-mmm-bfd-on-lags=20 Hello Wim et al., my apology for answering late. day-to-day business was taking it's toll :-) > Can this be more relaxed in the sense that micro-BFD session could keep u= sing the dedicated MAC address during the complete lifetime of the session? in general fine with me. Waiting for more comments from the list :-) Now the reason we have written it with a stubborn "MUST" was a bit of fear = that implementations will largely avoid the MAC learning, which would pract= ically obsolete this part of the draft. Nevertheless, changing the last MUST into a SHOULD is what you have in mind= ? ----snip----snap----snip----snap---- 2.3. Micro BFD session Ethernet details On Ethernet-based LAG member links the destination MAC is a dedicated MAC address (to be assigned by IANA according to [RFC5342]) to be the immediate next hop. This dedicated MAC address MUST be used for the initial BFD packets of a micro BFD session when in the Down/AdminDown and Init state. When sending BFD packets for the micro BFD session in the Up state, the MAC address from the received BFD packets for the session SHOULD be used. ----snip----snap----snip----snap---- > This might make implementations easier. That is true. But if we all do it for all our implementations the easier wa= y then it is effectively obsolete to write it down. And hardware with small= MAC tables will have at least a performance challenge. Regards, Marc On 2012-07-27, at 7:23 , Henderickx, Wim (Wim) wrote: > Hi, >=20 > I have a question on section 2.3 with respect to the use of the destinati= on MAC in the micro BFD section. >=20 > The current draft says that: When sending BFD packets for the micro BFD s= ession > in the Up state, the MAC address from the received BFD packets for > the session MUST be used. >=20 > Can this be more relaxed in the sense that micro-BFD session could keep u= sing the dedicated MAC address during the complete lifetime of the session? >=20 > This might make implementations easier. >=20 > Cheers, > Wim >=20 -- Marc Binderberger From wim.henderickx@alcatel-lucent.com Tue Aug 14 10:53:14 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 417BF21F86E2 for ; Tue, 14 Aug 2012 10:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.765 X-Spam-Level: X-Spam-Status: No, score=-7.765 tagged_above=-999 required=5 tests=[AWL=-1.516, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 KJEU9rGFhqOP for ; Tue, 14 Aug 2012 10:53:13 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0DC21F86B0 for ; Tue, 14 Aug 2012 10:53:12 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q7EHr1dA004974 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Aug 2012 19:53:08 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 14 Aug 2012 19:53:05 +0200 From: "Henderickx, Wim (Wim)" To: Marc Binderberger , "rtg-bfd@ietf.org" , Pablo Frank Date: Tue, 14 Aug 2012 19:53:04 +0200 Subject: RE: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? Thread-Topic: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? Thread-Index: Ac16OqYmoPVhuDOLQ4yxcQXzWoOv+wACtJkw Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702E1792964@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "draft-mmm-bfd-on-lags@tools.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, 14 Aug 2012 17:53:14 -0000 I believe the main reason for allowing one or the other and not both was to= avoid scale impact. If you want to run both we should allow it but we shou= ld state that this is not intended by default. -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Marc Binderberger Sent: dinsdag 14 augustus 2012 18:29 To: rtg-bfd@ietf.org; Pablo Frank Cc: draft-mmm-bfd-on-lags@tools.ietf.org Subject: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? Hello BFD experts, for draft-mmm-bfd-on-lags-05 I would like to bring a question into the disc= ussion that I have heard now several times (thanks Pablo!) since the latest= draft is out: why is the draft so strict in enforcing the micro sessions t= o be either IPv4 exclusive-or IPv6 ? Why not allowing both? 2.1. Micro BFD session address family Only one address family MUST be used for all micro BFD sessions running on all LAG member links. I.e. all member link micro BFD sessions of a particular LAG MUST either use IPv4 or IPv6. As we want to cover the layer-3 aspects of the LAG and member links as well= , having a liveness test for both IPv4 and IPv6 seems reasonable. The draft= states 5. Detecting a member link failure When a micro BFD session goes down then this member link MUST be taken out of the LAG L2 load balance table. One could rewrite this statement that when _any_ micro BFD session of a mem= ber link goes down that the link MUST be taken out of the load balance tabl= e. Plus the comment that in case the LAG load balance table is address-fami= ly aware that an implementation MAY remove the link from the load-balance t= able only that matches the failing micro session's address family (not sure= if such an implementation of LAG load balance tables exist at all? Otherwi= se we could skip this 2nd part). Comments? Regards, Marc -- Marc Binderberger From jeff.tantsura@ericsson.com Tue Aug 14 11:02:11 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 7BB3C21F8734 for ; Tue, 14 Aug 2012 11:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 fQvoE6bHTvCG for ; Tue, 14 Aug 2012 11:02:07 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id D219021F8733 for ; Tue, 14 Aug 2012 11:02:06 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q7EI2IGk024597; Tue, 14 Aug 2012 13:02:20 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.154]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 14 Aug 2012 14:01:59 -0400 From: Jeff Tantsura To: "Henderickx, Wim (Wim)" Date: Tue, 14 Aug 2012 14:01:57 -0400 Subject: Re: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? Thread-Topic: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? Thread-Index: Ac16RuXMLk76KRURRyCzE3QUFC5KDA== Message-ID: References: <14C7F4F06DB5814AB0DE29716C4F6D6702E1792964@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6702E1792964@FRMRSSXCHMBSB1.dc-m.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 Cc: "rtg-bfd@ietf.org" , "draft-mmm-bfd-on-lags@tools.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, 14 Aug 2012 18:02:11 -0000 Agree with Wim. Regards, Jeff On Aug 14, 2012, at 10:53, "Henderickx, Wim (Wim)" wrote: > I believe the main reason for allowing one or the other and not both was = to avoid scale impact. If you want to run both we should allow it but we sh= ould state that this is not intended by default. >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behal= f Of Marc Binderberger > Sent: dinsdag 14 augustus 2012 18:29 > To: rtg-bfd@ietf.org; Pablo Frank > Cc: draft-mmm-bfd-on-lags@tools.ietf.org > Subject: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? >=20 > Hello BFD experts, >=20 > for draft-mmm-bfd-on-lags-05 I would like to bring a question into the di= scussion that I have heard now several times (thanks Pablo!) since the late= st draft is out: why is the draft so strict in enforcing the micro sessions= to be either IPv4 exclusive-or IPv6 ? Why not allowing both? >=20 >=20 > 2.1. Micro BFD session address family >=20 > Only one address family MUST be used for all micro BFD sessions > running on all LAG member links. I.e. all member link micro BFD > sessions of a particular LAG MUST either use IPv4 or IPv6. >=20 >=20 > As we want to cover the layer-3 aspects of the LAG and member links as we= ll, having a liveness test for both IPv4 and IPv6 seems reasonable. The dra= ft states >=20 >=20 > 5. Detecting a member link failure >=20 > When a micro BFD session goes down then this member link MUST be > taken out of the LAG L2 load balance table. >=20 >=20 > One could rewrite this statement that when _any_ micro BFD session of a m= ember link goes down that the link MUST be taken out of the load balance ta= ble. Plus the comment that in case the LAG load balance table is address-fa= mily aware that an implementation MAY remove the link from the load-balance= table only that matches the failing micro session's address family (not su= re if such an implementation of LAG load balance tables exist at all? Other= wise we could skip this 2nd part). >=20 >=20 > Comments? >=20 >=20 > Regards, Marc > -- > Marc Binderberger >=20 From mach.chen@huawei.com Tue Aug 14 18:13:04 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 9C0F721F8709 for ; Tue, 14 Aug 2012 18:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.547 X-Spam-Level: X-Spam-Status: No, score=0.547 tagged_above=-999 required=5 tests=[AWL=-2.241, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 wn5MpPinTYEJ for ; Tue, 14 Aug 2012 18:13:04 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 06A7521F8702 for ; Tue, 14 Aug 2012 18:13:03 -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.3.5-GA FastPath) with ESMTP id AJK62135; Tue, 14 Aug 2012 17:13:03 -0800 (PST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 18:10:25 -0700 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 18:10:28 -0700 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.86]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Wed, 15 Aug 2012 09:10:24 +0800 From: Mach Chen To: "Henderickx, Wim (Wim)" , Marc Binderberger , "rtg-bfd@ietf.org" , Pablo Frank Subject: =?gb2312?B?tPC4tDogZHJhZnQtbW1tLWJmZC1vbi1sYWdzOiBJUHY0IF9hbmRfIElQdjYg?= =?gb2312?Q?=3F?= Thread-Topic: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? Thread-Index: AQHNejn47nmYU4J0zUC05DqQqAiGgJdZEL4AgAD+h7A= Date: Wed, 15 Aug 2012 01:10:23 +0000 Message-ID: References: <14C7F4F06DB5814AB0DE29716C4F6D6702E1792964@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6702E1792964@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.190] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-mmm-bfd-on-lags@tools.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, 15 Aug 2012 01:13:04 -0000 QWdyZWUuDQoNCkluIGFkZGl0aW9uLCBpbiBvcmRlciBmb3IgZGVwbG95bWVudCBhbmQgb3BlcmF0 aW9uYWwgc2ltcGxpZmljYXRpb24sIGl0IG1heSBiZSBiZXR0ZXIgdG8gc3BlY2lmeSB0aGUgZGVm YXVsdCBhZGRyZXNzIGZhbWlseSAoZS5nLiwgSVB2NCkuDQoNCkJlc3QgcmVnYXJkcywNCk1hY2gN Cg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBydGctYmZkLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddILT6se0NCj4gSGVuZGVyaWNreCwg V2ltIChXaW0pDQo+ILeiy83KsbzkOiAyMDEyxOo41MIxNcjVIDE6NTMNCj4gytW8/sjLOiBNYXJj IEJpbmRlcmJlcmdlcjsgcnRnLWJmZEBpZXRmLm9yZzsgUGFibG8gRnJhbmsNCj4gs63LzTogZHJh ZnQtbW1tLWJmZC1vbi1sYWdzQHRvb2xzLmlldGYub3JnDQo+INb3zOI6IFJFOiBkcmFmdC1tbW0t YmZkLW9uLWxhZ3M6IElQdjQgX2FuZF8gSVB2NiA/DQo+IA0KPiBJIGJlbGlldmUgdGhlIG1haW4g cmVhc29uIGZvciBhbGxvd2luZyBvbmUgb3IgdGhlIG90aGVyIGFuZCBub3QgYm90aCB3YXMgdG8N Cj4gYXZvaWQgc2NhbGUgaW1wYWN0LiBJZiB5b3Ugd2FudCB0byBydW4gYm90aCB3ZSBzaG91bGQg YWxsb3cgaXQgYnV0IHdlIHNob3VsZA0KPiBzdGF0ZSB0aGF0IHRoaXMgaXMgbm90IGludGVuZGVk IGJ5IGRlZmF1bHQuDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBy dGctYmZkLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZg0KPiBNYXJjIEJpbmRlcmJlcmdlcg0KPiBTZW50OiBkaW5zZGFnIDE0IGF1 Z3VzdHVzIDIwMTIgMTg6MjkNCj4gVG86IHJ0Zy1iZmRAaWV0Zi5vcmc7IFBhYmxvIEZyYW5rDQo+ IENjOiBkcmFmdC1tbW0tYmZkLW9uLWxhZ3NAdG9vbHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogZHJh ZnQtbW1tLWJmZC1vbi1sYWdzOiBJUHY0IF9hbmRfIElQdjYgPw0KPiANCj4gSGVsbG8gQkZEIGV4 cGVydHMsDQo+IA0KPiBmb3IgZHJhZnQtbW1tLWJmZC1vbi1sYWdzLTA1IEkgd291bGQgbGlrZSB0 byBicmluZyBhIHF1ZXN0aW9uIGludG8gdGhlDQo+IGRpc2N1c3Npb24gdGhhdCBJIGhhdmUgaGVh cmQgbm93IHNldmVyYWwgdGltZXMgKHRoYW5rcyBQYWJsbyEpIHNpbmNlIHRoZSBsYXRlc3QNCj4g ZHJhZnQgaXMgb3V0OiB3aHkgaXMgdGhlIGRyYWZ0IHNvIHN0cmljdCBpbiBlbmZvcmNpbmcgdGhl IG1pY3JvIHNlc3Npb25zIHRvIGJlDQo+IGVpdGhlciBJUHY0IGV4Y2x1c2l2ZS1vciBJUHY2ID8g IFdoeSBub3QgYWxsb3dpbmcgYm90aD8NCj4gDQo+IA0KPiAyLjEuICBNaWNybyBCRkQgc2Vzc2lv biBhZGRyZXNzIGZhbWlseQ0KPiANCj4gICAgT25seSBvbmUgYWRkcmVzcyBmYW1pbHkgTVVTVCBi ZSB1c2VkIGZvciBhbGwgbWljcm8gQkZEIHNlc3Npb25zDQo+ICAgIHJ1bm5pbmcgb24gYWxsIExB RyBtZW1iZXIgbGlua3MuICBJLmUuIGFsbCBtZW1iZXIgbGluayBtaWNybyBCRkQNCj4gICAgc2Vz c2lvbnMgb2YgYSBwYXJ0aWN1bGFyIExBRyBNVVNUIGVpdGhlciB1c2UgSVB2NCBvciBJUHY2Lg0K PiANCj4gDQo+IEFzIHdlIHdhbnQgdG8gY292ZXIgdGhlIGxheWVyLTMgYXNwZWN0cyBvZiB0aGUg TEFHIGFuZCBtZW1iZXIgbGlua3MgYXMgd2VsbCwNCj4gaGF2aW5nIGEgbGl2ZW5lc3MgdGVzdCBm b3IgYm90aCBJUHY0IGFuZCBJUHY2IHNlZW1zIHJlYXNvbmFibGUuIFRoZSBkcmFmdA0KPiBzdGF0 ZXMNCj4gDQo+IA0KPiA1LiAgRGV0ZWN0aW5nIGEgbWVtYmVyIGxpbmsgZmFpbHVyZQ0KPiANCj4g ICAgV2hlbiBhIG1pY3JvIEJGRCBzZXNzaW9uIGdvZXMgZG93biB0aGVuIHRoaXMgbWVtYmVyIGxp bmsgTVVTVCBiZQ0KPiAgICB0YWtlbiBvdXQgb2YgdGhlIExBRyBMMiBsb2FkIGJhbGFuY2UgdGFi bGUuDQo+IA0KPiANCj4gT25lIGNvdWxkIHJld3JpdGUgdGhpcyBzdGF0ZW1lbnQgdGhhdCB3aGVu IF9hbnlfIG1pY3JvIEJGRCBzZXNzaW9uIG9mIGENCj4gbWVtYmVyIGxpbmsgZ29lcyBkb3duIHRo YXQgdGhlIGxpbmsgTVVTVCBiZSB0YWtlbiBvdXQgb2YgdGhlIGxvYWQgYmFsYW5jZQ0KPiB0YWJs ZS4gUGx1cyB0aGUgY29tbWVudCB0aGF0IGluIGNhc2UgdGhlIExBRyBsb2FkIGJhbGFuY2UgdGFi bGUgaXMNCj4gYWRkcmVzcy1mYW1pbHkgYXdhcmUgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBNQVkg cmVtb3ZlIHRoZSBsaW5rIGZyb20gdGhlDQo+IGxvYWQtYmFsYW5jZSB0YWJsZSBvbmx5IHRoYXQg bWF0Y2hlcyB0aGUgZmFpbGluZyBtaWNybyBzZXNzaW9uJ3MgYWRkcmVzcyBmYW1pbHkNCj4gKG5v dCBzdXJlIGlmIHN1Y2ggYW4gaW1wbGVtZW50YXRpb24gb2YgTEFHIGxvYWQgYmFsYW5jZSB0YWJs ZXMgZXhpc3QgYXQgYWxsPw0KPiBPdGhlcndpc2Ugd2UgY291bGQgc2tpcCB0aGlzIDJuZCBwYXJ0 KS4NCj4gDQo+IA0KPiBDb21tZW50cz8NCj4gDQo+IA0KPiBSZWdhcmRzLCBNYXJjDQo+IC0tDQo+ IE1hcmMgQmluZGVyYmVyZ2VyICAgICAgICAgICA8bWFyY0BzbmlmZi5kZT4NCg0K From manav.bhatia@alcatel-lucent.com Wed Aug 15 20:17:27 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 EE35511E80E4 for ; Wed, 15 Aug 2012 20:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 FDhfGEVAxBOI for ; Wed, 15 Aug 2012 20:17:27 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4092B11E80DE for ; Wed, 15 Aug 2012 20:17:27 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q7G3HMCw007833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Aug 2012 22:17:25 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7G3HIIJ024267 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Aug 2012 08:47:19 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 16 Aug 2012 08:47:18 +0530 From: "Bhatia, Manav (Manav)" To: Marc Binderberger , "rtg-bfd@ietf.org" , Pablo Frank Date: Thu, 16 Aug 2012 08:47:41 +0530 Subject: RE: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? Thread-Topic: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? Thread-Index: Ac16OftgLYbVmwzPTOSy60qIYcFdsgBInqSg Message-ID: <7C362EEF9C7896468B36C9B79200D8350D063A0B51@INBANSXCHMBSA1.in.alcatel-lucent.com> References: 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "draft-mmm-bfd-on-lags@tools.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, 16 Aug 2012 03:17:28 -0000 >=20 > for draft-mmm-bfd-on-lags-05 I would like to bring a question=20 > into the discussion that I have heard now several times=20 > (thanks Pablo!) since the latest draft is out: why is the=20 > draft so strict in enforcing the micro sessions to be either=20 > IPv4 exclusive-or IPv6 ? Why not allowing both? >=20 >=20 > 2.1. Micro BFD session address family >=20 > Only one address family MUST be used for all micro BFD sessions > running on all LAG member links. I.e. all member link micro BFD > sessions of a particular LAG MUST either use IPv4 or IPv6. The above statement was written to preclude the possibility of someone usin= g IPv4 for one member link and IPv6 for the other member link within the sa= me LAG. Clearly, what we're saying here is that either use IPv4 or IPv6 for= all micro sessions - don't do a mix and match. The text as it appears seems to suggest that we're discouraging running bot= h IPv4 and IPv6 for all micro sessions. The reason is scale, as already ans= wered by Wim. If an IP interface has both IPv4 and IPv6, folks could use on= e address family (IPv4 or IPv6) for all micro BFD sessions and the other ad= dress family for a more sedate BFD session over that IP interface. > As we want to cover the layer-3 aspects of the LAG and member=20 > links as well, having a liveness test for both IPv4 and IPv6=20 > seems reasonable. The draft states >=20 >=20 > 5. Detecting a member link failure >=20 > When a micro BFD session goes down then this member link MUST be > taken out of the LAG L2 load balance table. >=20 >=20 > One could rewrite this statement that when _any_ micro BFD=20 > session of a member link goes down that the link MUST be=20 > taken out of the load balance table. Plus the comment that in=20 > case the LAG load balance table is address-family aware that=20 > an implementation MAY remove the link from the load-balance=20 > table only that matches the failing micro session's address=20 > family (not sure if such an implementation of LAG load=20 > balance tables exist at all? Otherwise we could skip this 2nd part). I don't think there are such address family aware load balancers existing t= oday. However, I don't see a harm in adding such a text.=20 Cheers, Manav= From pabloisnot@gmail.com Thu Aug 16 07:32:20 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 3B7D621F85DA for ; Thu, 16 Aug 2012 07:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.376 X-Spam-Level: X-Spam-Status: No, score=-3.376 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 r6EP8X1F0h+z for ; Thu, 16 Aug 2012 07:32:19 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id CDA1B21F85D5 for ; Thu, 16 Aug 2012 07:32:18 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so576004wib.13 for ; Thu, 16 Aug 2012 07:32:18 -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=0hOjIs01mnCOeiWsPql9lZIusYJvaD4ge5FxMmQzovQ=; b=c5wCezjYN1314TMnWSZaHibtGSnHtUnbtiOQyVsHPr49ul9kHVCkk5rXoJKuiV3v4b xpVtQD0QFdLyxl0JfFZdvp3dDslALyHSv/hwdSKPR2jL3VhgyHCbJvjz2ipuD6lSWJIN Favo+lzUfJ1yTpOm39YBvZeY5OhBWUiOt1gnTsp7uRT41Z4mfDlph5hnYsqlsu1uXp5E DMrxyTMZLY4dwaXftihYBG27UvuLsjhmJUReE5sRWHkimgW3jMrU1/a27NHCrHhVElB+ V8dXVl9Mgxw5PGk3vzLRFJNx5M+u91bfdWjlmB6kYNKomdgKl+zIw4pqrQMYR5bJ2AR3 fSdw== MIME-Version: 1.0 Received: by 10.180.91.169 with SMTP id cf9mr4400121wib.1.1345127537904; Thu, 16 Aug 2012 07:32:17 -0700 (PDT) Received: by 10.227.200.78 with HTTP; Thu, 16 Aug 2012 07:32:17 -0700 (PDT) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D063A0B51@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D063A0B51@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Thu, 16 Aug 2012 10:32:17 -0400 Message-ID: Subject: Re: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? From: Pablo Frank To: "Bhatia, Manav (Manav)" Content-Type: multipart/alternative; boundary=f46d043891af130dc304c762e902 Cc: "rtg-bfd@ietf.org" , "draft-mmm-bfd-on-lags@tools.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, 16 Aug 2012 14:32:20 -0000 --f46d043891af130dc304c762e902 Content-Type: text/plain; charset=ISO-8859-1 In my original comments on this topic, I had suggested that one should be able to run separate IPv4 and IPv6 micro-BFD sessions on the same member link. They would be separate sessions for all intents and purposes. Because of the scale problem, I also suggested that you should run one of the address families at a more sedate rate but I was still thinking it would be a set of (separate) micro-BFD sessions. It seems inconsistent to me to suggest that one address family should use micro-BFD and the other address family should use regular BFD. If that's acceptable, then why did we use IP encapsulation in the first place for micro-BFD? regards, Pablo On Wed, Aug 15, 2012 at 11:17 PM, Bhatia, Manav (Manav) < manav.bhatia@alcatel-lucent.com> wrote: > > > > for draft-mmm-bfd-on-lags-05 I would like to bring a question > > into the discussion that I have heard now several times > > (thanks Pablo!) since the latest draft is out: why is the > > draft so strict in enforcing the micro sessions to be either > > IPv4 exclusive-or IPv6 ? Why not allowing both? > > > > > > 2.1. Micro BFD session address family > > > > Only one address family MUST be used for all micro BFD sessions > > running on all LAG member links. I.e. all member link micro BFD > > sessions of a particular LAG MUST either use IPv4 or IPv6. > > The above statement was written to preclude the possibility of someone > using IPv4 for one member link and IPv6 for the other member link within > the same LAG. Clearly, what we're saying here is that either use IPv4 or > IPv6 for all micro sessions - don't do a mix and match. > > The text as it appears seems to suggest that we're discouraging running > both IPv4 and IPv6 for all micro sessions. The reason is scale, as already > answered by Wim. If an IP interface has both IPv4 and IPv6, folks could use > one address family (IPv4 or IPv6) for all micro BFD sessions and the other > address family for a more sedate BFD session over that IP interface. > > > As we want to cover the layer-3 aspects of the LAG and member > > links as well, having a liveness test for both IPv4 and IPv6 > > seems reasonable. The draft states > > > > > > 5. Detecting a member link failure > > > > When a micro BFD session goes down then this member link MUST be > > taken out of the LAG L2 load balance table. > > > > > > One could rewrite this statement that when _any_ micro BFD > > session of a member link goes down that the link MUST be > > taken out of the load balance table. Plus the comment that in > > case the LAG load balance table is address-family aware that > > an implementation MAY remove the link from the load-balance > > table only that matches the failing micro session's address > > family (not sure if such an implementation of LAG load > > balance tables exist at all? Otherwise we could skip this 2nd part). > > I don't think there are such address family aware load balancers existing > today. However, I don't see a harm in adding such a text. > > Cheers, Manav --f46d043891af130dc304c762e902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In my original comments on this topic, I had suggested that one should be a= ble to run separate IPv4 and IPv6 micro-BFD sessions on the same member lin= k. =A0They would be separate sessions for all intents and purposes. =A0Beca= use of the scale problem, I also suggested that you should run one of the a= ddress families at a more sedate rate but I was still thinking it would be = a set of (separate) micro-BFD sessions. =A0

It seems inconsistent to me to suggest that one address fami= ly should use micro-BFD and the other address family should use regular BFD= . =A0If that's acceptable, then why did we use IP encapsulation in the = first place for micro-BFD? =A0

regards,
Pablo

On Wed, Aug 15, 2012 at 11:17 PM, Bhatia, Manav (Manav) <manav.bhatia@alcatel-lucent.com> wrote:
>
> for draft-mmm-bfd-on-lags-05 I would like to bring a question
> into the discussion that I have heard now several times
> (thanks Pablo!) since the latest draft is out: why is the
> draft so strict in enforcing the micro sessions to be either
> IPv4 exclusive-or IPv6 ? =A0Why not allowing both?
>
>
> 2.1. =A0Micro BFD session address family
>
> =A0 =A0Only one address family MUST be used for all micro BFD sessions=
> =A0 =A0running on all LAG member links. =A0I.e. all member link micro = BFD
> =A0 =A0sessions of a particular LAG MUST either use IPv4 or IPv6.

The above statement was written to preclude the possibility of someon= e using IPv4 for one member link and IPv6 for the other member link within = the same LAG. Clearly, what we're saying here is that either use IPv4 o= r IPv6 for all micro sessions - don't do a mix and match.

The text as it appears seems to suggest that we're discouraging running= both IPv4 and IPv6 for all micro sessions. The reason is scale, as already= answered by Wim. If an IP interface has both IPv4 and IPv6, folks could us= e one address family (IPv4 or IPv6) for all micro BFD sessions and the othe= r address family for a more sedate BFD session over that IP interface.

> As we want to cover the layer-3 aspects of the LAG and member
> links as well, having a liveness test for both IPv4 and IPv6
> seems reasonable. The draft states
>
>
> 5. =A0Detecting a member link failure
>
> =A0 =A0When a micro BFD session goes down then this member link MUST b= e
> =A0 =A0taken out of the LAG L2 load balance table.
>
>
> One could rewrite this statement that when _any_ micro BFD
> session of a member link goes down that the link MUST be
> taken out of the load balance table. Plus the comment that in
> case the LAG load balance table is address-family aware that
> an implementation MAY remove the link from the load-balance
> table only that matches the failing micro session's address
> family (not sure if such an implementation of LAG load
> balance tables exist at all? Otherwise we could skip this 2nd part).
I don't think there are such address family aware load balancers = existing today. However, I don't see a harm in adding such a text.

Cheers, Manav

--f46d043891af130dc304c762e902-- From manav.bhatia@alcatel-lucent.com Thu Aug 16 08:11:55 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 BF2CC21F85EF for ; Thu, 16 Aug 2012 08:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.487 X-Spam-Level: X-Spam-Status: No, score=-7.487 tagged_above=-999 required=5 tests=[AWL=-0.889, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 6fIPI4SoqYzv for ; Thu, 16 Aug 2012 08:11:54 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id B2A7421F85A0 for ; Thu, 16 Aug 2012 08:11:54 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q7GFBkrF000479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Aug 2012 10:11:48 -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 q7GFBijs016382 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Aug 2012 20:41:44 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 16 Aug 2012 20:41:44 +0530 From: "Bhatia, Manav (Manav)" To: Pablo Frank Date: Thu, 16 Aug 2012 20:42:14 +0530 Subject: RE: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? Thread-Topic: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? Thread-Index: Ac17vAERDIlGT5HVSdKk5uEAplCHNwABPmKw Message-ID: <7C362EEF9C7896468B36C9B79200D8350D063A0D7A@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D063A0B51@INBANSXCHMBSA1.in.alcatel-lucent.com> 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_7C362EEF9C7896468B36C9B79200D8350D063A0D7AINBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "rtg-bfd@ietf.org" , "draft-mmm-bfd-on-lags@tools.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, 16 Aug 2012 15:11:55 -0000 --_000_7C362EEF9C7896468B36C9B79200D8350D063A0D7AINBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe there is nothing in the draft that precludes somebody from runnin= g separate IPv4 and IPv6 micro BFD sessions on the same member link. I coul= d be missing something but i just cant think of why somebody would want to = do that. Do you have some scenarios in mind? Cheers, Manav ________________________________ From: Pablo Frank [mailto:pabloisnot@gmail.com] Sent: Thursday, August 16, 2012 8:02 PM To: Bhatia, Manav (Manav) Cc: Marc Binderberger; rtg-bfd@ietf.org; draft-mmm-bfd-on-lags@tools.ietf.o= rg Subject: Re: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? In my original comments on this topic, I had suggested that one should be a= ble to run separate IPv4 and IPv6 micro-BFD sessions on the same member lin= k. They would be separate sessions for all intents and purposes. Because = of the scale problem, I also suggested that you should run one of the addre= ss families at a more sedate rate but I was still thinking it would be a se= t of (separate) micro-BFD sessions. It seems inconsistent to me to suggest that one address family should use m= icro-BFD and the other address family should use regular BFD. If that's ac= ceptable, then why did we use IP encapsulation in the first place for micro= -BFD? regards, Pablo On Wed, Aug 15, 2012 at 11:17 PM, Bhatia, Manav (Manav) > wrote: > > for draft-mmm-bfd-on-lags-05 I would like to bring a question > into the discussion that I have heard now several times > (thanks Pablo!) since the latest draft is out: why is the > draft so strict in enforcing the micro sessions to be either > IPv4 exclusive-or IPv6 ? Why not allowing both? > > > 2.1. Micro BFD session address family > > Only one address family MUST be used for all micro BFD sessions > running on all LAG member links. I.e. all member link micro BFD > sessions of a particular LAG MUST either use IPv4 or IPv6. The above statement was written to preclude the possibility of someone usin= g IPv4 for one member link and IPv6 for the other member link within the sa= me LAG. Clearly, what we're saying here is that either use IPv4 or IPv6 for= all micro sessions - don't do a mix and match. The text as it appears seems to suggest that we're discouraging running bot= h IPv4 and IPv6 for all micro sessions. The reason is scale, as already ans= wered by Wim. If an IP interface has both IPv4 and IPv6, folks could use on= e address family (IPv4 or IPv6) for all micro BFD sessions and the other ad= dress family for a more sedate BFD session over that IP interface. > As we want to cover the layer-3 aspects of the LAG and member > links as well, having a liveness test for both IPv4 and IPv6 > seems reasonable. The draft states > > > 5. Detecting a member link failure > > When a micro BFD session goes down then this member link MUST be > taken out of the LAG L2 load balance table. > > > One could rewrite this statement that when _any_ micro BFD > session of a member link goes down that the link MUST be > taken out of the load balance table. Plus the comment that in > case the LAG load balance table is address-family aware that > an implementation MAY remove the link from the load-balance > table only that matches the failing micro session's address > family (not sure if such an implementation of LAG load > balance tables exist at all? Otherwise we could skip this 2nd part). I don't think there are such address family aware load balancers existing t= oday. However, I don't see a harm in adding such a text. Cheers, Manav --_000_7C362EEF9C7896468B36C9B79200D8350D063A0D7AINBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 believe there is nothing in the draft that precludes somebody from running= =20 separate IPv4 and IPv6 micro BFD sessions on the same member link. I could = be=20 missing something but i just cant think of why somebody would want to do th= at.=20 Do you have some scenarios in mind?
 
Cheers, Manav

From: Pablo Frank=20 [mailto:pabloisnot@gmail.com]
Sent: Thursday, August 16, 2012 = 8:02=20 PM
To: Bhatia, Manav (Manav)
Cc: Marc Binderberger;=20 rtg-bfd@ietf.org; draft-mmm-bfd-on-lags@tools.ietf.org
Subject:= Re:=20 draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ?

In my original comments on this topic, I had suggested that on= e=20 should be able to run separate IPv4 and IPv6 micro-BFD sessions on the sa= me=20 member link.  They would be separate sessions for all intents and=20 purposes.  Because of the scale problem, I also suggested that you s= hould=20 run one of the address families at a more sedate rate but I was still thi= nking=20 it would be a set of (separate) micro-BFD sessions.  

It seems inconsistent to me to suggest that one address family shoul= d use=20 micro-BFD and the other address family should use regular BFD.  If t= hat's=20 acceptable, then why did we use IP encapsulation in the first place for=20 micro-BFD?  

regards,
Pablo

On Wed, Aug 15, 2012 at 11:17 PM, Bhatia, Manav = (Manav)=20 <manav.bhatia@alcatel-lucent.com> wrote:
>
> for draft-mmm-bfd-on-lags-05 I would like = to=20 bring a question
> into the discussion that I have heard now seve= ral=20 times
> (thanks Pablo!) since the latest draft is out: why is=20 the
> draft so strict in enforcing the micro sessions to be=20 either
> IPv4 exclusive-or IPv6 ?  Why not allowing=20 both?
>
>
> 2.1.  Micro BFD session address=20 family
>
>    Only one address family MUST be use= d for=20 all micro BFD sessions
>    running on all LAG member l= inks.=20  I.e. all member link micro BFD
>    sessions of a= =20 particular LAG MUST either use IPv4 or IPv6.

The above=20 statement was written to preclude the possibility of someone using IPv4= for=20 one member link and IPv6 for the other member link within the same LAG.= =20 Clearly, what we're saying here is that either use IPv4 or IPv6 for all= =20 micro sessions - don't do a mix and match.

The text as it appear= s=20 seems to suggest that we're discouraging running both IPv4 and IPv6 for= all=20 micro sessions. The reason is scale, as already answered by Wim. If an = IP=20 interface has both IPv4 and IPv6, folks could use one address family (I= Pv4=20 or IPv6) for all micro BFD sessions and the other address family for a = more=20 sedate BFD session over that IP interface.

> As we want to cover the layer-3 aspects of the= LAG=20 and member
> links as well, having a liveness test for both IPv4 = and=20 IPv6
> seems reasonable. The draft states
>
>
>= 5.=20  Detecting a member link failure
>
>    When= a=20 micro BFD session goes down then this member link MUST be
>  = ;=20  taken out of the LAG L2 load balance table.
>
>
&g= t;=20 One could rewrite this statement that when _any_ micro BFD
> sess= ion=20 of a member link goes down that the link MUST be
> taken out of t= he=20 load balance table. Plus the comment that in
> case the LAG load= =20 balance table is address-family aware that
> an implementation MA= Y=20 remove the link from the load-balance
> table only that matches t= he=20 failing micro session's address
> family (not sure if such an=20 implementation of LAG load
> balance tables exist at all? Otherwi= se we=20 could skip this 2nd part).

I don't think there are such ad= dress=20 family aware load balancers existing today. However, I don't see a harm= in=20 adding such a text.

Cheers,=20 Manav

--_000_7C362EEF9C7896468B36C9B79200D8350D063A0D7AINBANSXCHMBSA_-- From Alexander.Vainshtein@ecitele.com Thu Aug 16 08:16:37 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 5D14E21F85AC for ; Thu, 16 Aug 2012 08:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.208 X-Spam-Level: X-Spam-Status: No, score=-5.208 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 hnfBy2coV5iH for ; Thu, 16 Aug 2012 08:16:34 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE0521F85A7 for ; Thu, 16 Aug 2012 08:16:33 -0700 (PDT) Received: from [85.158.143.35:52681] by server-3.bemta-4.messagelabs.com id 17/6A-09529-0DE0D205; Thu, 16 Aug 2012 15:16:32 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1345130191!12255573!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.6.1.3; banners=-,-,- Received: (qmail 14579 invoked from network); 16 Aug 2012 15:16:31 -0000 Received: from unknown (HELO fridlppsb001.ecitele.com) (168.87.1.157) by server-7.tower-21.messagelabs.com with SMTP; 16 Aug 2012 15:16:31 -0000 X-AuditID: a8571401-b7fb06d0000013b7-df-502d10c363f1 Received: from FRGRWPVCH001.ecitele.com (Unknown_Domain [10.1.18.35]) by fridlppsb001.ecitele.com (Symantec Messaging Gateway) with SMTP id 80.06.05047.3C01D205; Thu, 16 Aug 2012 17:24:51 +0200 (CEST) Received: from FRIDWPPMB002.ecitele.com ([169.254.4.244]) by FRGRWPVCH001.ecitele.com ([10.1.18.35]) with mapi id 14.01.0339.001; Thu, 16 Aug 2012 17:16:30 +0200 From: Alexander Vainshtein To: Pablo Frank Subject: RE: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? Thread-Topic: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? Thread-Index: AQHNejqivJw/3krbhEqGSQVFnHQIxpdbpWeAgAC8e4CAACHMoA== Date: Thu, 16 Aug 2012 15:16:30 +0000 Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D063A0B51@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA020D6406FRIDWPPMB002ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0wUVxjt3ZmdHZCxwwLudWuacZr1R3Vx8bkmLD7SxjXGsLbGJsQWrzOX 3dHdmcnMotDUZDUKifWFqWlARE2o0GKKIQKlrZHHDwNK1NYQUZf4JBFNm6jRgGI7syPIH/+d +53zne/M3O/ShLPW4aYlOY41GUV5Kp1MBx+4vT2sN+QbHV/if/WikvTXDg3Z/T8+vkj5n71u AyvI4N7h8/ZgR03SEayvH7UFn//9jAqRRQmQj2RZiaM45kSsCwE+pEnbkVDOc5IY4PN4To0i AcewHA/wSFWxLPIF6flGUZI5LAuKKMnhAL/my0Kv3794mTePL9gQkXQOe2NIinIxrOsojDmj YuaVRSxyJYrGxSOY07AgqRLefICI3H1y0KHebQNlfWNnQAJcqgP7QBoN2UXwUtN+m4VnwKtD zdQ+kE472T4A7+w59/bwE4AVA7WpDooNwJamJGXibHYO/LWqGpgigu0A8FD1KdIkstjFsOL2 EcISLYF1Y0eAhVfBO2f/dZiYZD2w5eAPKT3DroO3zpl6c9oAgJXD+1PNaex62D7UnBIBI9/L vjOprATrgjcfnHibm4X1f14hLJwDH91/Y7fwx3D3z9cdll6B/W1NlDUsE/ZWPyAtzUzY1XiD PAxm1EyxrZnSUjOlxarPgyf/eEpZeC48feoxMYEvd963Ta2fBI5fgKtEk0RV1bf4fHm5xoXE cRTnCkqsBRhr1fhVNvgN3DuQ2w1YGvAZTFXbvJDTjrbr5bFuMJO28TnM0QxvyDl9iyKWR5Ae KdZKo1jvBpAm+Gxmk93gGBGVf4s1ZYL63Pi5VYR7mqCYCxEvXujzvf/Au5jmLwoKnWzYWNBt GKtYm/CZRdM8ZJZPN0ZkajiMy0qkaPwdbaPTzBgZRgxoahhdRTFdClt8H/DQ//X2JoGTlBUZ u13MAlPEmqJIqTzpMwJcxodnMbNMNsNY4UmHEcPcZphXXphrmhsPaJJyJ8Dm1iBoqBPW/PNC eb1g4eph2Llj/Jvvvz7sae+Uj39SsbSndU/uwCbPq5Xk2uLkxiR/vfN3oSyr49jG9ZELXfbB s2yRhyhoz+wPlGatGL8M/2rYWYpsqHfQuWv+qob5n6F7CTE7/9pH/T0Pg7OvNFHfjX04rbAl Z/R0YtnswcHdXVt5Uo+gvE8JTUf/A/88vWEvBAAA Cc: "rtg-bfd@ietf.org" , "draft-mmm-bfd-on-lags@tools.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, 16 Aug 2012 15:16:37 -0000 --_000_F9336571731ADE42A5397FC831CEAA020D6406FRIDWPPMB002ecite_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Pablo, and all, I suspect that the problems with IPv4/IPv6 (and some other problems) stem fr= om the desire to kill two birds with one stone: 1. To detect failure of individual physical links comprising LAG in th= e situations when lower layers do not provide suitable detection techniques. a. Ethernet over SONET is a classic example of such a link (unless yo= u want to use ETH-AIS). 2. To verify that IP connectivity across an individual link is "up and= running". a. This has been the rationale for using IP encapsulation for micro-BF= D sessions b. Judging by the level of support on the list, this is not an esoteric= situation but a problem from real networking life c. Such verification would be admittedly implementation-specific with= IMHO high potential for: i. False-= positives (e.g., micro-BFD session is UP because local IP addresses used in= these sessions are identified correctly, but IP packets to remote destinati= ons are not forwarded because the LPM tables are corrupted). Note that this= can happen with "normal" BFD ii. False-n= egatives (e.g., micro-BFD session does not come up because specific Destinat= ion MAC addresses it uses are not recognized as "local", but IP packets usi= ng MAC address of the LAG as their destination MAC address are treated norm= ally) d. Separate verifications (and hence separate micro-BFD sessions) are r= equired for IPv4 and IPv6 if both run over the LAG. Quoting from my favorite RFC 1925: It is always possible to agglutinate multiple separate problems into a singl= e complex interdependent solution. In most cases this is a bad idea. Regards, Sasha From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf O= f Pablo Frank Sent: Thursday, August 16, 2012 5:32 PM To: Bhatia, Manav (Manav) Cc: rtg-bfd@ietf.org; draft-mmm-bfd-on-lags@tools.ietf.org Subject: Re: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? In my original comments on this topic, I had suggested that one should be ab= le to run separate IPv4 and IPv6 micro-BFD sessions on the same member link.= They would be separate sessions for all intents and purposes. Because of= the scale problem, I also suggested that you should run one of the address= families at a more sedate rate but I was still thinking it would be a set o= f (separate) micro-BFD sessions. It seems inconsistent to me to suggest that one address family should use mi= cro-BFD and the other address family should use regular BFD. If that's acce= ptable, then why did we use IP encapsulation in the first place for micro-BF= D? regards, Pablo On Wed, Aug 15, 2012 at 11:17 PM, Bhatia, Manav (Manav) > wrote: > > for draft-mmm-bfd-on-lags-05 I would like to bring a question > into the discussion that I have heard now several times > (thanks Pablo!) since the latest draft is out: why is the > draft so strict in enforcing the micro sessions to be either > IPv4 exclusive-or IPv6 ? Why not allowing both? > > > 2.1. Micro BFD session address family > > Only one address family MUST be used for all micro BFD sessions > running on all LAG member links. I.e. all member link micro BFD > sessions of a particular LAG MUST either use IPv4 or IPv6. The above statement was written to preclude the possibility of someone using= IPv4 for one member link and IPv6 for the other member link within the same= LAG. Clearly, what we're saying here is that either use IPv4 or IPv6 for al= l micro sessions - don't do a mix and match. The text as it appears seems to suggest that we're discouraging running both= IPv4 and IPv6 for all micro sessions. The reason is scale, as already answe= red by Wim. If an IP interface has both IPv4 and IPv6, folks could use one a= ddress family (IPv4 or IPv6) for all micro BFD sessions and the other addres= s family for a more sedate BFD session over that IP interface. > As we want to cover the layer-3 aspects of the LAG and member > links as well, having a liveness test for both IPv4 and IPv6 > seems reasonable. The draft states > > > 5. Detecting a member link failure > > When a micro BFD session goes down then this member link MUST be > taken out of the LAG L2 load balance table. > > > One could rewrite this statement that when _any_ micro BFD > session of a member link goes down that the link MUST be > taken out of the load balance table. Plus the comment that in > case the LAG load balance table is address-family aware that > an implementation MAY remove the link from the load-balance > table only that matches the failing micro session's address > family (not sure if such an implementation of LAG load > balance tables exist at all? Otherwise we could skip this 2nd part). I don't think there are such address family aware load balancers existing to= day. However, I don't see a harm in adding such a text. Cheers, Manav 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. --_000_F9336571731ADE42A5397FC831CEAA020D6406FRIDWPPMB002ecite_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Pablo, and all,<= /span>

I suspect that the problems= with IPv4/IPv6 (and some other problems) stem from the desire to kill two b= irds with one stone:

1. &n= bsp;     To detect failure of individual physical links comprising LAG in the s= ituations when lower layers do not provide suitable detection techniques.

a.  &nbs= p;     Ethernet over SONET is a classic example of such a link (unless= you want to use ETH-AIS).

2. &n= bsp;     To verify that IP connectivity across an individual link is “up= and running”.

a.  &nbs= p;    This has been the rationale for using IP encapsulation for micro-BFD s= essions

b.  &nbs= p;   Judging by the level of support on the list, this is not an esoteric s= ituation but a problem from real networking life

c.  &nbs= p;    Such verification would be admittedly implementation-specific with IMH= O high potential for:

   =             &nbs= p;            &n= bsp;            =             &nbs= p;        i.  =     <= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-se= rif";color:#1F497D">False-positives (e.g., micro-BFD session is UP beca= use local IP addresses used in these sessions are identified correctly, but IP packets to remote d= estinations are not forwarded because the LPM tables are corrupted). Note th= at this can happen with “normal” BFD

   =             &nbs= p;            &n= bsp;            =             &nbs= p;      ii.  = ;    = False-negatives (e.g., micro-BFD session does not= come up because specific Destination MAC addresses it uses  are not recognized as R= 20;local”, but IP packets using  MAC address of the LAG as their= destination MAC address are treated normally)

d.  &nbs= p;   Separate verifications (and hence separate micro-BFD sessions) are req= uired for IPv4 and IPv6 if both run over the LAG.

 

Quoting from my favorite RFC 1925:

 

It is always possible to agglut= inate multiple separate problems into a single complex interdependent soluti= on. In most cases this is a bad idea.

 

Regards,<= /p>

     Sa= sha

 

From: rtg-bfd-bou= nces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Pablo Frank
Sent: Thursday, August 16, 2012 5:32 PM
To: Bhatia, Manav (Manav)
Cc: rtg-bfd@ietf.org; draft-mmm-bfd-on-lags@tools.ietf.org
Subject: Re: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ?

 

In my original comments on this topic, I had suggeste= d that one should be able to run separate IPv4 and IPv6 micro-BFD sessions o= n the same member link.  They would be separate sessions for all intent= s and purposes.  Because of the scale problem, I also suggested that you should run one of the address families a= t a more sedate rate but I was still thinking it would be a set of (separate= ) micro-BFD sessions.  

 

It seems inconsistent to me to suggest that one addre= ss family should use micro-BFD and the other address family should use regul= ar BFD.  If that's acceptable, then why did we use IP encapsulation in= the first place for micro-BFD?  

 

regards,

Pablo

On Wed, Aug 15, 2012 at 11:17 PM, Bhatia, Manav (Mana= v) <= manav.bhatia@alcatel-lucent.com> wrote:

>
> for draft-mmm-bfd-on-lags-05 I would like to bring a question
> into the discussion that I have heard now several times
> (thanks Pablo!) since the latest draft is out: why is the
> draft so strict in enforcing the micro sessions to be either
> IPv4 exclusive-or IPv6 ?  Why not allowing both?
>
>
> 2.1.  Micro BFD session address family
>
>    Only one address family MUST be used for all micro BFD ses= sions
>    running on all LAG member links.  I.e. all member lin= k micro BFD
>    sessions of a particular LAG MUST either use IPv4 or IPv6.=

The above statement was written to preclude the possi= bility of someone using IPv4 for one member link and IPv6 for the other memb= er link within the same LAG. Clearly, what we're saying here is that either= use IPv4 or IPv6 for all micro sessions - don't do a mix and match.

The text as it appears seems to suggest that we're discouraging running both= IPv4 and IPv6 for all micro sessions. The reason is scale, as already answe= red by Wim. If an IP interface has both IPv4 and IPv6, folks could use one a= ddress family (IPv4 or IPv6) for all micro BFD sessions and the other address family for a more sedate B= FD session over that IP interface.


> As we want to cover the layer-3 aspects of the LAG and member
> links as well, having a liveness test for both IPv4 and IPv6
> seems reasonable. The draft states
>
>
> 5.  Detecting a member link failure
>
>    When a micro BFD session goes down then this member link M= UST be
>    taken out of the LAG L2 load balance table.
>
>
> One could rewrite this statement that when _any_ micro BFD
> session of a member link goes down that the link MUST be
> taken out of the load balance table. Plus the comment that in
> case the LAG load balance table is address-family aware that
> an implementation MAY remove the link from the load-balance
> table only that matches the failing micro session's address
> family (not sure if such an implementation of LAG load
> balance tables exist at all? Otherwise we could skip this 2nd part).

I don't think there are such address family aware loa= d balancers existing today. However, I don't see a harm in adding such a tex= t.

Cheers, Manav

 

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. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA020D6406FRIDWPPMB002ecite_-- From marc@sniff.de Thu Aug 16 08:20: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 4858721F84F3 for ; Thu, 16 Aug 2012 08:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] 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 nP0JR3k1Xx+T for ; Thu, 16 Aug 2012 08:20: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 7567921F8494 for ; Thu, 16 Aug 2012 08:20:15 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 1E0932AA0F; Thu, 16 Aug 2012 15:20:09 +0000 (GMT) Subject: Re: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-32--396498967 From: Marc Binderberger In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D063A0D7A@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Thu, 16 Aug 2012 17:20:04 +0200 Message-Id: <0D1B9ACE-889A-4090-88CC-BA7E3652117F@sniff.de> References: <7C362EEF9C7896468B36C9B79200D8350D063A0B51@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D063A0D7A@INBANSXCHMBSA1.in.alcatel-lucent.com> To: Pablo Frank , "Bhatia, Manav (Manav)" X-Mailer: Apple Mail (2.1084) Cc: rtg-bfd@ietf.org, draft-mmm-bfd-on-lags@tools.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, 16 Aug 2012 15:20:31 -0000 --Apple-Mail-32--396498967 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Manav, Pablo et al., I think we will work on an update with a better wording. What we have = now can be misunderstood. I agree with Manav's comment that what we = really want to enforce is: when you run a micro session for a particular address family on one = member link then you must run micro sessions for this address family on = all member links (of the LAG). > Do you have some scenarios in mind? I have a (big) customer in mind who was just asking for this :-) The reason is that BFD micro sessions do cover layer-3 aspects as well = and the customer thinks we should cover both, IPv4 and IPv6 code path. = Sounds reasonable. Regards, Marc On 2012-08-16, at 17:12 , Bhatia, Manav (Manav) wrote: > I believe there is nothing in the draft that precludes somebody from = running separate IPv4 and IPv6 micro BFD sessions on the same member = link. I could be missing something but i just cant think of why somebody = would want to do that. Do you have some scenarios in mind? > =20 > Cheers, Manav >=20 > From: Pablo Frank [mailto:pabloisnot@gmail.com]=20 > Sent: Thursday, August 16, 2012 8:02 PM > To: Bhatia, Manav (Manav) > Cc: Marc Binderberger; rtg-bfd@ietf.org; = draft-mmm-bfd-on-lags@tools.ietf.org > Subject: Re: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? >=20 > In my original comments on this topic, I had suggested that one should = be able to run separate IPv4 and IPv6 micro-BFD sessions on the same = member link. They would be separate sessions for all intents and = purposes. Because of the scale problem, I also suggested that you = should run one of the address families at a more sedate rate but I was = still thinking it would be a set of (separate) micro-BFD sessions. =20 >=20 > It seems inconsistent to me to suggest that one address family should = use micro-BFD and the other address family should use regular BFD. If = that's acceptable, then why did we use IP encapsulation in the first = place for micro-BFD? =20 >=20 > regards, > Pablo >=20 > On Wed, Aug 15, 2012 at 11:17 PM, Bhatia, Manav (Manav) = wrote: > > > > for draft-mmm-bfd-on-lags-05 I would like to bring a question > > into the discussion that I have heard now several times > > (thanks Pablo!) since the latest draft is out: why is the > > draft so strict in enforcing the micro sessions to be either > > IPv4 exclusive-or IPv6 ? Why not allowing both? > > > > > > 2.1. Micro BFD session address family > > > > Only one address family MUST be used for all micro BFD sessions > > running on all LAG member links. I.e. all member link micro BFD > > sessions of a particular LAG MUST either use IPv4 or IPv6. >=20 > The above statement was written to preclude the possibility of someone = using IPv4 for one member link and IPv6 for the other member link within = the same LAG. Clearly, what we're saying here is that either use IPv4 or = IPv6 for all micro sessions - don't do a mix and match. >=20 > The text as it appears seems to suggest that we're discouraging = running both IPv4 and IPv6 for all micro sessions. The reason is scale, = as already answered by Wim. If an IP interface has both IPv4 and IPv6, = folks could use one address family (IPv4 or IPv6) for all micro BFD = sessions and the other address family for a more sedate BFD session over = that IP interface. >=20 > > As we want to cover the layer-3 aspects of the LAG and member > > links as well, having a liveness test for both IPv4 and IPv6 > > seems reasonable. The draft states > > > > > > 5. Detecting a member link failure > > > > When a micro BFD session goes down then this member link MUST be > > taken out of the LAG L2 load balance table. > > > > > > One could rewrite this statement that when _any_ micro BFD > > session of a member link goes down that the link MUST be > > taken out of the load balance table. Plus the comment that in > > case the LAG load balance table is address-family aware that > > an implementation MAY remove the link from the load-balance > > table only that matches the failing micro session's address > > family (not sure if such an implementation of LAG load > > balance tables exist at all? Otherwise we could skip this 2nd part). >=20 > I don't think there are such address family aware load balancers = existing today. However, I don't see a harm in adding such a text. >=20 > Cheers, Manav >=20 -- Marc Binderberger --Apple-Mail-32--396498967 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello = Manav, Pablo et al.,

I think we will work on an = update with a better wording. What we have now can be misunderstood. I = agree with Manav's comment that what we really want to enforce = is:

when you run a micro session for a = particular address family on one member link then you must run micro = sessions for this address family on all member links (of the = LAG).


Do you have some = scenarios in = mind?

I = have a (big) customer in mind who was just asking for this = :-)
The reason is that BFD micro sessions do cover layer-3 = aspects as well and the customer thinks we should cover both, IPv4 and = IPv6 code path. Sounds = reasonable.


Regards, = Marc



On = 2012-08-16, at 17:12 , Bhatia, Manav (Manav) wrote:

I=20= believe there is nothing in the draft that precludes somebody from = running=20 separate IPv4 and IPv6 micro BFD sessions on the same member link. I = could be=20 missing something but i just cant think of why somebody would want to do = that.=20 Do you have some scenarios in mind?
 
Cheers, = Manav

From: Pablo Frank=20 [mailto:pabloisnot@gmail.com]
Sent: Thursday, August 16, = 2012 8:02=20 PM
To: Bhatia, Manav (Manav)
Cc: Marc = Binderberger;=20 rtg-bfd@ietf.org; draft-mmm-bfd-on-lags= @tools.ietf.org
Subject: Re:=20 draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ?

In my original comments on this topic, I had suggested that = one=20 should be able to run separate IPv4 and IPv6 micro-BFD sessions on the = same=20 member link.  They would be separate sessions for all intents and=20= purposes.  Because of the scale problem, I also suggested that = you should=20 run one of the address families at a more sedate rate but I was still = thinking=20 it would be a set of (separate) micro-BFD sessions.  

It seems inconsistent to me to suggest that one address family = should use=20 micro-BFD and the other address family should use regular BFD. =  If that's=20 acceptable, then why did we use IP encapsulation in the first place = for=20 micro-BFD?  

regards,
Pablo

On Wed, Aug 15, 2012 at 11:17 PM, Bhatia, = Manav (Manav)=20 <manav.bhatia@alcatel-lucent.com> = wrote:
>
> for draft-mmm-bfd-on-lags-05 I would = like to=20 bring a question
> into the discussion that I have heard now = several=20 times
> (thanks Pablo!) since the latest draft is out: why is=20= the
> draft so strict in enforcing the micro sessions to be=20 either
> IPv4 exclusive-or IPv6 ?  Why not allowing=20 both?
>
>
> 2.1.  Micro BFD session address=20= family
>
>    Only one address family MUST be = used for=20 all micro BFD sessions
>    running on all LAG = member links.=20  I.e. all member link micro BFD
>    sessions = of a=20 particular LAG MUST either use IPv4 or IPv6.

The above=20= statement was written to preclude the possibility of someone using = IPv4 for=20 one member link and IPv6 for the other member link within the same = LAG.=20 Clearly, what we're saying here is that either use IPv4 or IPv6 for = all=20 micro sessions - don't do a mix and match.

The text as it = appears=20 seems to suggest that we're discouraging running both IPv4 and IPv6 = for all=20 micro sessions. The reason is scale, as already answered by Wim. If = an IP=20 interface has both IPv4 and IPv6, folks could use one address family = (IPv4=20 or IPv6) for all micro BFD sessions and the other address family for = a more=20 sedate BFD session over that IP interface.

> As we want to cover the layer-3 aspects = of the LAG=20 and member
> links as well, having a liveness test for both = IPv4 and=20 IPv6
> seems reasonable. The draft = states
>
>
> 5.=20  Detecting a member link failure
>
>   =  When a=20 micro BFD session goes down then this member link MUST be
> =  =20  taken out of the LAG L2 load balance = table.
>
>
>=20 One could rewrite this statement that when _any_ micro BFD
> = session=20 of a member link goes down that the link MUST be
> taken out = of the=20 load balance table. Plus the comment that in
> case the LAG = load=20 balance table is address-family aware that
> an implementation = MAY=20 remove the link from the load-balance
> table only that = matches the=20 failing micro session's address
> family (not sure if such an=20= implementation of LAG load
> balance tables exist at all? = Otherwise we=20 could skip this 2nd part).

I don't think there are such = address=20 family aware load balancers existing today. However, I don't see a = harm in=20 adding such a text.

Cheers,=20 Manav


--
marc@sniff.de>

= --Apple-Mail-32--396498967-- From toms.sanders@gmail.com Sun Aug 19 18:02:53 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 E0F7021F861D for ; Sun, 19 Aug 2012 18:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.855 X-Spam-Level: X-Spam-Status: No, score=-2.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] 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 Q7FKR-kFsmj6 for ; Sun, 19 Aug 2012 18:02:53 -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 316CF21F861B for ; Sun, 19 Aug 2012 18:02:52 -0700 (PDT) Received: by weyu54 with SMTP id u54so4165457wey.31 for ; Sun, 19 Aug 2012 18:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=1mwdYxd8glQxpcBz3ZP9KY8NWwJBWMrNZLPr5ckkGVE=; b=aY3ms91NyttGaJWhbCGyrg8BvcpWoLu97o37QpKiod6M7HHtYON7HaV7pQsay81uL/ NAqZnpkt728NdveJOdl2bDA3695xDu8gtnSuFrIiSF0PiSxVs+ZV4Z09wFnG3i4r54hZ s0Ov3xlHkAJK8RHLjioeznC8x3kSritXFseCtOcR4h5R4cZjJaWsWzEcrThLJd+hoXCi jQXiBucx8vmicXJyLAgo0aI67q5BBJeAZdZT8kgxRfn+1Iz+QRvKCIq3IvRkFEKVjOto LWCdrWAUsKjxwihEEtFwBPQPwUUJNXcFPhmPQMmjeBQEJ4WGDGDigMeYXZafDrcdZOSN ysfQ== MIME-Version: 1.0 Received: by 10.216.212.228 with SMTP id y78mr6023260weo.43.1345424572133; Sun, 19 Aug 2012 18:02:52 -0700 (PDT) Received: by 10.223.172.194 with HTTP; Sun, 19 Aug 2012 18:02:52 -0700 (PDT) Date: Mon, 20 Aug 2012 06:32:52 +0530 Message-ID: Subject: MIB for BFD over LAGs From: Tom Sanders To: rtg-bfd@ietf.org Content-Type: text/plain; charset=UTF-8 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, 20 Aug 2012 01:02:54 -0000 Hi, Is there any interest in writing a BFD MIB extensions draft for BFD over LAGs? That would imo help quite a bit in the interoperability. -- Toms. From marc@sniff.de Tue Aug 21 11:50:34 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 8FFD321F875A for ; Tue, 21 Aug 2012 11:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 cmv2hmKLlOUC for ; Tue, 21 Aug 2012 11:50:28 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [82.212.219.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4C26321F8685 for ; Tue, 21 Aug 2012 11:50:28 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 4973F2AA0F; Tue, 21 Aug 2012 18:49:44 +0000 (GMT) Subject: Re: MIB for BFD over LAGs Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Tue, 21 Aug 2012 20:49:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <682D6C0B-4E7E-4B01-83D6-A1F102AC9403@sniff.de> References: To: Tom Sanders 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: Tue, 21 Aug 2012 18:50:34 -0000 Hello Tom, myself not being a MIB expert at all. Just wondering what you have in = mind :-) The per-member link sessions are - effectively - singlehop BFD sessions, = following RFC5880/5881 but with a different UDP destination port. So = would the existing MIB not be sufficient to cover the per-member link = sessions? Regards, Marc =20 On 2012-08-20, at 3:02 , Tom Sanders wrote: > Hi, >=20 > Is there any interest in writing a BFD MIB extensions draft for BFD > over LAGs? That would imo help quite a bit in the interoperability. >=20 > --=20 > Toms. >=20 -- Marc Binderberger From marc@sniff.de Mon Aug 27 10:18:52 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 0B3DB21F8551 for ; Mon, 27 Aug 2012 10:18:52 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7lJ5tETLiNO for ; Mon, 27 Aug 2012 10:18:51 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C092121F8535 for ; Mon, 27 Aug 2012 10:18:50 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 78F432AA0F; Mon, 27 Aug 2012 17:18:48 +0000 (GMT) Subject: Re: Comments on draft-mmm-bfd-on-lags-05.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D0615BC47@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Mon, 27 Aug 2012 19:18:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <33ABBF9D-293E-41FC-99FB-07456E92FB7A@sniff.de> References: <4FFBB2A4.2040803@alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D0615B7BA@INBANSXCHMBSA1.in.alcatel-lucent.com> <4FFD2086.9070404@alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D0615BC47@INBANSXCHMBSA1.in.alcatel-lucent.com> To: Gregory Mirsky , "Bhatia, Manav (Manav)" 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, 27 Aug 2012 17:18:52 -0000 Hello Gregory and Manav, with "some" delay replying. Personally I'm fine with replacing "connectivity" with "continuity". = Although, we have this part in the draft The procedure for the Reception of BFD Control Packets in Section 6.8.6 of [RFC5880] is amended as follows for per member link micro BFD over LAG sessions: "If the Your Discriminator field is non-zero and a micro BFD over LAG session is found, the interface on which the micro BFD control packet arrived on MUST correspond to the interface associated with that session." Maybe we should be clear here that "otherwise the BFD packet must be = dropped"? Found this obvious but if you think this should be added we = can do. Anyway, it means we do check the "correct" connectivity. Actually we = check the connectivity is not suddenly changing while the session is in = "Up" state. > I hear you when you say that using IP encapsulation for monitoring = link status could give a few false positives/negatives. I don't see anything "false" here. You would use BFD with IP = encapsulation exactly to test the LAG port - very LAG port - is handling = IP traffic well. If someone wants to stay solely in the Ethernet/layer-2 domain then I = would recommend CFM. We do not try to replace CFM with this draft :-) I understood Gregory that he doesn't want to limit all the draft = statements to IP encapsulation as someone may want to use pure G-ACh/GAL = encapsulation for a "TP Bundle" or such. And the generic statements of = draft-mmm-bfd-on-lags probably can be worded more generically that BFD = allows a verification above layer-2 per LAG port. (What is above 2? MPLS is often named layer 2.5 :-) But maybe I misunderstand Gregory? Regards, Marc On 2012-07-12, at 12:07 , Bhatia, Manav (Manav) wrote: > Hi Greg, > =20 > I hear you when you say that using IP encapsulation for monitoring = link status could give a few false positives/negatives. However, i am = wondering if its a practical concern. Since all micro BFD sessions are = single hop, the packets will get dropped if they get rerouted out of = some other IP interface, in effect bringing the micro BFD session down. = I, on my part, am unable to envisage a scenario when using L3 encap = could lead to a false negative/positive. Do you have a scenario or a = sequence of events in mind which can demonstrate the fate of a micro = session and the real link status diverging? > =20 > Isnt the argument akin to saying that ISIS can introduce false = positives since its riding on top of Layer 2? > =20 > Please note that i have no issues in adding the text that you have = suggested. I am merely ensuring that we all understand why we're adding = the text. > =20 > Cheers, Manav > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]=20 > Sent: Wednesday, July 11, 2012 11:39 PM > To: Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: RE: Comments on draft-mmm-bfd-on-lags-05.txt >=20 > Hi Manav, > Glad we're converging. > Certainly the editorial changes you've proposing will address my = concern. > But I frankly don't see need for a separate document just to express = my concern regarding use of IP encapsulation. Simple sentense like "Use = of IP encapsulation may introduce Layer 3 defects that be positive = negatives to monitored LAG." would be sufficient IMHO. > =20 > Regards, > Greg > =20 > -----Original Message----- > From: Manav Bhatia [mailto:manav.bhatia@alcatel-lucent.com] > Sent: Tuesday, July 10, 2012 11:43 PM > To: Gregory Mirsky > Cc: rtg-bfd@ietf.org > Subject: Re: Comments on draft-mmm-bfd-on-lags-05.txt > =20 > Hi Gregory, > =20 > > GIM>>>> No, I'm not suggesting not to use IP encapsulation of BFD = but > > I'm suggesting thoroughly document what could be implications of = using > > IP encapsulation of BFD to monitor Layer 2 path. > =20 > Sure this should be done. We can take it up as an additional draft so = that we dont stall the progress of this one. This is precisely why we = kept the mechanism to dynamically learn the remote IP addresses in a = separate draft (draft-mmsn-bfd-on-lags-address-00.txt). > =20 > We can also later explore the possibility of merging these drafts into = the main draft, if thats the WG consensus then. > =20 > > I would wager that the entry and exit criteron for micro BFD would = be > > the same as the regular rfc 5881 BFD. Why would this be any = different? > > > > GIM>>>> As I've noted earlier, many BFD related document use term > > "connectivity" when in fact discussing "continuity". But these are = not > > the same, not identical. If the draft we're discussing uses > > "connectivity" in place of"continuity", then a note with explanation > > should, IMHO, suffice. But if intention is to go beyond RFC 5880 and > > monitor connectivity, then mis-connection defects have to be = defined. > =20 > Would s/connectivity/continuity help? :-) > =20 > Cheers, Manav > =20 -- Marc Binderberger From gregory.mirsky@ericsson.com Mon Aug 27 17:06: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 2A25521F84D5 for ; Mon, 27 Aug 2012 17:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 bYUdcKr73WfS for ; Mon, 27 Aug 2012 17:06:23 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id E8B6D21F84CF for ; Mon, 27 Aug 2012 17:06:22 -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 q7S089Mb029220; Mon, 27 Aug 2012 19:08:11 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.138]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 27 Aug 2012 20:06:11 -0400 From: Gregory Mirsky To: Marc Binderberger , "Bhatia, Manav (Manav)" Date: Mon, 27 Aug 2012 20:06:10 -0400 Subject: RE: Comments on draft-mmm-bfd-on-lags-05.txt Thread-Topic: Comments on draft-mmm-bfd-on-lags-05.txt Thread-Index: Ac2EeA9KBE+LHxMxSuO5s+qyhMwfVwANLSNA Message-ID: References: <4FFBB2A4.2040803@alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D0615B7BA@INBANSXCHMBSA1.in.alcatel-lucent.com> <4FFD2086.9070404@alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D0615BC47@INBANSXCHMBSA1.in.alcatel-lucent.com> <33ABBF9D-293E-41FC-99FB-07456E92FB7A@sniff.de> In-Reply-To: <33ABBF9D-293E-41FC-99FB-07456E92FB7A@sniff.de> 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_FE60A4E52763E84B935532D7D9294FF13928072DFAEUSAACMS0715e_" 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: Tue, 28 Aug 2012 00:06:24 -0000 --_000_FE60A4E52763E84B935532D7D9294FF13928072DFAEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Marc, greatly appreciate your consideration of my earlier comments. Two more to clarify: * part of connectivity monitoring or checking are defects that charac= terize type of mis-connection. Thus, in your example, not only BFD packet w= ill be dropped but a mis-connectivity defect state entered, reported and, p= ossibly, acted upon. An exit from this defect state might be defined as lac= k of mis-connected micro-BFD packets for 3.5*max(bfd.RequiredMinRxInterval,= remote bfd.DesiredMinTxInterval) msec. But discussion of BFD as connectivi= ty monitoring protocol is outside of scope for micro-BFD. Authors might con= sider to mention the difference between continuity and connectivity monitor= ing with the latter being outside of scope, left for further study. * yes, since BFD is link layer independent protocol, we don't want to= limit ouselves to IP/UDP encapsulation over LAG and possibly Composite Lin= ks. Regards, Greg -----Original Message----- From: Marc Binderberger [mailto:marc@sniff.de] Sent: Monday, August 27, 2012 10:19 AM To: Gregory Mirsky; Bhatia, Manav (Manav) Cc: rtg-bfd@ietf.org Subject: Re: Comments on draft-mmm-bfd-on-lags-05.txt Hello Gregory and Manav, with "some" delay replying. Personally I'm fine with replacing "connectivity" with "continuity". Althou= gh, we have this part in the draft The procedure for the Reception of BFD Control Packets in Section 6.8.6 of [RFC5880] is amended as follows for per member link micro BFD over LAG sessions: "If the Your Discriminator field is non-zero and a micro BFD over LAG session is found, the interface on which the micro BFD control packet arrived on MUST correspond to the interface associated with that session." Maybe we should be clear here that "otherwise the BFD packet must be droppe= d"? Found this obvious but if you think this should be added we can do. Anyway, it means we do check the "correct" connectivity. Actually we check = the connectivity is not suddenly changing while the session is in "Up" stat= e. > I hear you when you say that using IP encapsulation for monitoring link s= tatus could give a few false positives/negatives. I don't see anything "false" here. You would use BFD with IP encapsulation = exactly to test the LAG port - very LAG port - is handling IP traffic well. If someone wants to stay solely in the Ethernet/layer-2 domain then I would= recommend CFM. We do not try to replace CFM with this draft :-) I understood Gregory that he doesn't want to limit all the draft statements= to IP encapsulation as someone may want to use pure G-ACh/GAL encapsulatio= n for a "TP Bundle" or such. And the generic statements of draft-mmm-bfd-on= -lags probably can be worded more generically that BFD allows a verificatio= n above layer-2 per LAG port. (What is above 2? MPLS is often named layer 2.5 :-) But maybe I misunderstand Gregory? Regards, Marc On 2012-07-12, at 12:07 , Bhatia, Manav (Manav) wrote: > Hi Greg, > > I hear you when you say that using IP encapsulation for monitoring link s= tatus could give a few false positives/negatives. However, i am wondering i= f its a practical concern. Since all micro BFD sessions are single hop, the= packets will get dropped if they get rerouted out of some other IP interfa= ce, in effect bringing the micro BFD session down. I, on my part, am unable= to envisage a scenario when using L3 encap could lead to a false negative/= positive. Do you have a scenario or a sequence of events in mind which can = demonstrate the fate of a micro session and the real link status diverging? > > Isnt the argument akin to saying that ISIS can introduce false positives = since its riding on top of Layer 2? > > Please note that i have no issues in adding the text that you have sugges= ted. I am merely ensuring that we all understand why we're adding the text. > > Cheers, Manav > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Wednesday, July 11, 2012 11:39 PM > To: Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: RE: Comments on draft-mmm-bfd-on-lags-05.txt > > Hi Manav, > Glad we're converging. > Certainly the editorial changes you've proposing will address my concern. > But I frankly don't see need for a separate document just to express my c= oncern regarding use of IP encapsulation. Simple sentense like "Use of IP e= ncapsulation may introduce Layer 3 defects that be positive negatives to mo= nitored LAG." would be sufficient IMHO. > > Regards, > Greg > > -----Original Message----- > From: Manav Bhatia [mailto:manav.bhatia@alcatel-lucent.com] > Sent: Tuesday, July 10, 2012 11:43 PM > To: Gregory Mirsky > Cc: rtg-bfd@ietf.org > Subject: Re: Comments on draft-mmm-bfd-on-lags-05.txt > > Hi Gregory, > > > GIM>>>> No, I'm not suggesting not to use IP encapsulation of BFD > > GIM>>>> but > > I'm suggesting thoroughly document what could be implications of > > using IP encapsulation of BFD to monitor Layer 2 path. > > Sure this should be done. We can take it up as an additional draft so tha= t we dont stall the progress of this one. This is precisely why we kept the= mechanism to dynamically learn the remote IP addresses in a separate draft= (draft-mmsn-bfd-on-lags-address-00.txt). > > We can also later explore the possibility of merging these drafts into th= e main draft, if thats the WG consensus then. > > > I would wager that the entry and exit criteron for micro BFD would > > be the same as the regular rfc 5881 BFD. Why would this be any differen= t? > > > > GIM>>>> As I've noted earlier, many BFD related document use term > > "connectivity" when in fact discussing "continuity". But these are > > not the same, not identical. If the draft we're discussing uses > > "connectivity" in place of"continuity", then a note with explanation > > should, IMHO, suffice. But if intention is to go beyond RFC 5880 and > > monitor connectivity, then mis-connection defects have to be defined. > > Would s/connectivity/continuity help? :-) > > Cheers, Manav > -- Marc Binderberger --_000_FE60A4E52763E84B935532D7D9294FF13928072DFAEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Marc,
greatly appreciate your consideration of my earlier comments.
Two more to clarify:
  • part of connectivity monitoring or checking are defects that characteri= ze type of mis-connection. Thus, in your example, not only BFD packet will = be dropped but a mis-connectivity defect state entered, reported and, possi= bly, acted upon. An exit from this defect state might be defined as lack of mis-connected micro-BFD packets fo= r 3.5*max(bfd.RequiredMinRxInterval, remote bfd.DesiredMinTxInterval) msec.= But discussion of BFD as connectivity monitoring protocol is outside of sc= ope for micro-BFD. Authors might consider to mention the difference between continuity and connectivity moni= toring with the latter being outside of scope, left for further study.
    • =
  • yes, since BFD is link layer independent protocol, we don't want to lim= it ouselves to IP/UDP encapsulation over LAG and possibly Composite Links.<= /li>
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: Marc Binderberger [mailto:marc@sniff.de]
Sent: Monday, August 27, 2012 10:19 A= M
To: Gregory Mirsky; Bhatia, Manav (Ma= nav)
Cc: rtg-bfd@ietf.org
Subject: Re: Comments on draft-mmm-bf= d-on-lags-05.txt
 
Hello Gregory and Manav,
 
with "some" delay replying.=
 
Personally I'm fine with replacing &q= uot;connectivity" with "continuity". Although, we have this = part in the draft
 
   The procedure for the Re= ception of BFD Control Packets in Section
   6.8.6 of [RFC5880] is am= ended as follows for per member link micro
   BFD over LAG sessions: &= quot;If the Your Discriminator field is non-zero
   and a micro BFD over LAG= session is found, the interface on which the
   micro BFD control packet= arrived on MUST correspond to the interface
   associated with that ses= sion."
 
 
Maybe we should be clear here that &q= uot;otherwise the BFD packet must be dropped"?   Found this = obvious but if you think this should be added we can do.
 
Anyway, it means we do check the &quo= t;correct" connectivity. Actually we check the connectivity is not sud= denly changing while the session is in "Up" state.
 
 
> I hear you when you say that usi= ng IP encapsulation for monitoring link status could give a few false posit= ives/negatives.
 
 
I don't see anything "false"= ; here. You would use BFD with IP encapsulation exactly to test the LAG por= t - very LAG port - is handling IP traffic well.
 
If someone wants to stay solely in th= e Ethernet/layer-2 domain then I would recommend CFM. We do not try to repl= ace CFM with this draft :-)
 
 
I understood Gregory that he doesn't = want to limit all the draft statements to IP encapsulation as someone may w= ant to use pure G-ACh/GAL encapsulation for a "TP Bundle" or such= . And the generic statements of draft-mmm-bfd-on-lags probably can be worded more generically that BFD allows a verification abov= e layer-2 per LAG port.
(What is above 2?  MPLS is often= named layer 2.5 :-)
 
 
But maybe I misunderstand Gregory?
 
 
Regards, Marc
 
 
 
 
 
On 2012-07-12, at 12:07 , Bhatia, Man= av (Manav) wrote:
 
> Hi Greg,
> 
> I hear you when you say that usi= ng IP encapsulation for monitoring link status could give a few false posit= ives/negatives. However, i am wondering if its a practical concern. Since a= ll micro BFD sessions are single hop, the packets will get dropped if they get rerouted out of some other IP inte= rface, in effect bringing the micro BFD session down. I, on my part, am una= ble to envisage a scenario when using L3 encap could lead to a false negati= ve/positive. Do you have a scenario or a sequence of events in mind which can demonstrate the fate of a micro s= ession and the real link status diverging?
> 
> Isnt the argument akin to saying= that ISIS can introduce false positives since its riding on top of Layer 2= ?
> 
> Please note that i have no issue= s in adding the text that you have suggested. I am merely ensuring that we = all understand why we're adding the text.
> 
> Cheers, Manav
> From: Gregory Mirsky [mailto:greg= ory.mirsky@ericsson.com]
> Sent: Wednesday, July 11, 2012 1= 1:39 PM
> To: Bhatia, Manav (Manav)=
> Cc: rtg-bfd@ietf.org
> Subject: RE: Comments on draft-m= mm-bfd-on-lags-05.txt
>
> Hi Manav,
> Glad we're converging.
> Certainly the editorial changes = you've proposing will address my concern.
> But I frankly don't see need for= a separate document just to express my concern regarding use of IP encapsu= lation. Simple sentense like "Use of IP encapsulation may introduce La= yer 3 defects that be positive negatives to monitored LAG." would be sufficient IMHO.
> 
>     &nb= sp;   Regards,
>     &nb= sp;           Greg=
> 
> -----Original Message-----
> Sent: Tuesday, July 10, 2012 11:= 43 PM
> To: Gregory Mirsky
> Cc: rtg-bfd@ietf.org
> Subject: Re: Comments on draft-m= mm-bfd-on-lags-05.txt
> 
> Hi Gregory,
> 
> > GIM>>>> No, I'm= not suggesting not to use IP encapsulation of BFD
> > GIM>>>> but
> > I'm suggesting thoroughly d= ocument what could be implications of
> > using IP encapsulation of B= FD to monitor Layer 2 path.
> 
> Sure this should be done. We can= take it up as an additional draft so that we dont stall the progress of th= is one. This is precisely why we kept the mechanism to dynamically learn th= e remote IP addresses in a separate draft (draft-mmsn-bfd-on-lags-address-00.txt).
> 
> We can also later explore the po= ssibility of merging these drafts into the main draft, if thats the WG cons= ensus then.
> 
> > I would wager that the entr= y and exit criteron for micro BFD would
> > be the same as the regular = rfc 5881 BFD. Why would this be any different?
> >
> > GIM>>>> As I've= noted earlier, many BFD related document use term
> > "connectivity" wh= en in fact discussing "continuity". But these are
> > not the same, not identical= . If the draft we're discussing uses
> > "connectivity" in= place of"continuity", then a note with explanation
> > should, IMHO, suffice. But = if intention is to go beyond RFC 5880 and
> > monitor connectivity, then = mis-connection defects have to be defined.
> 
> Would s/connectivity/continuity = help? :-)
> 
> Cheers, Manav
> 
 
--
Marc Binderberger   &n= bsp;       <marc@sniff.de>
 
 
 --_000_FE60A4E52763E84B935532D7D9294FF13928072DFAEUSAACMS0715e_-- From jhaas@slice.pfrc.org Thu Aug 30 06:56:58 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 6500921F84B6 for ; Thu, 30 Aug 2012 06:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.156 X-Spam-Level: X-Spam-Status: No, score=-102.156 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 UmuUpp4uPEjo for ; Thu, 30 Aug 2012 06:56:56 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 73D8821F84B3 for ; Thu, 30 Aug 2012 06:56:56 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E33D9C685; Thu, 30 Aug 2012 09:56:55 -0400 (EDT) Date: Thu, 30 Aug 2012 09:56:55 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: [nomcom-chair@ietf.org: NomCom 2012-2013: Call for Nominations] Message-ID: <20120830135655.GA24528@pfrc> 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: Thu, 30 Aug 2012 13:56:58 -0000 The 2012 IETF Nomination Committee is looking for candidates for IETF leadership positions. ----- Forwarded message from NomCom Chair ----- Date: Mon, 27 Aug 2012 16:13:17 -0700 From: NomCom Chair To: IETF Announcement List Subject: NomCom 2012-2013: Call for Nominations The 2012-2013 Nominating Committee (NomCom) is seeking nominations from now until September 24, 2012 . The open positions being considered by this year's NomCom can be found at the end of this email or on the NomCom 2012-2013 website: https://www.ietf.org/group/nomcom/2012/ Nominations may be made by selecting the Nominate link at the top of the NomCom 2012-2013 website or by visiting the following URL: https://www.ietf.org/group/nomcom/2012/nominate Note that nominations made using the web tool require an ietf.org (i.e., datatracker) account. You can create an ietf.org account by visiting the following URL: https://datatracker.ietf.org/accounts/create/ Nominations may also be made by email to nomcom12@ietf.org. If you do so, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you wish to nominate someone via email for more than one position, please use separate emails to do so. Self nomination is welcome. NomCom 2012-2013 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. As stated in RFC 5680: "The list of nominees willing to be considered for positions under review in the current NomCom cycle is not confidential". Willing Nominees for each position will be publicly listed. With the exception of publicly listing willing nominees, the confidentiality requirements of RFC 3777 remain in effect. All feedback and NomCom deliberations will remain confidential and will not be disclosed. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the NomCom on or before September 24, 2012. The NomCom appoints individuals to fill the open slots on the IAOC, the IAB, and the IESG. This year, the NomCom willing be filling the positions currently held by the following individuals, whose terms expire in March 2013: IAOC: -------- Dave Crocker IAB: -------- Alissa Cooper Joel Halpern David Kessens Danny McPherson Jon Peterson Dave Thaler IESG: -------- Russ Housley (IETF Chair) Pete Resnick (Applications Area) Ralph Droms (Internet Area) Ronald Bonica (Operations and Management Area) Robert Sparks (Real-Time Applications and Infrastructure Area) Adrian Farrel (Routing Area) Stephen Farrell (Security Area) Wesley Eddy (Transport Area) In addition to nominations, the Nominating Committee is actively seeking community input on the jobs that need to be filled. We have received the job descriptions from the IAB, IESG, and IAOC and they can be found at: https://www.ietf.org/group/nomcom/2012/iaoc-requirements https://www.ietf.org/group/nomcom/2012/iab-requirements https://www.ietf.org/group/nomcom/2012/chair-requirements https://www.ietf.org/group/nomcom/2012/iesg-requirements However, we also need the community's views and input on the jobs within each organization. If you have ideas on job responsibilities (more, less, different), please let us know. Please send suggestions and feedback to nomcom12@ietf.org. Thank you for your help in identifying qualified nominees. Matt Lepinski nomcom-chair@ietf.org ----- End forwarded message -----