From muly_i@rad.com Tue Sep 4 02:24:32 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 98AEB21F8646 for ; Tue, 4 Sep 2012 02:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ubfo54YNwsZZ for ; Tue, 4 Sep 2012 02:24:30 -0700 (PDT) Received: from rad.co.il (mailrelay02-q.rad.co.il [94.188.133.159]) by ietfa.amsl.com (Postfix) with ESMTP id DB2DF21F8645 for ; Tue, 4 Sep 2012 02:24:27 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from muly?i@rad.com) with AES128-SHA encrypted SMTP; 4 Sep 2012 11:35:58 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.02.0298.004; Tue, 4 Sep 2012 12:24:08 +0300 From: Muly Ilan To: "Carlos Pignataro (cpignata)" Subject: RE: [mpls] LSP ping as bootstrap for G-ACh encapsulated BFD Thread-Topic: [mpls] LSP ping as bootstrap for G-ACh encapsulated BFD Thread-Index: Ac1MpEwc7lLKqFncQ4ebgze3TT5Trg9lXFYAABDxxiA= Date: Tue, 4 Sep 2012 09:24:08 +0000 Message-ID: <32CB7A1F0806AB4688CE3F22C29DAC8704316FC6@EXRAD5.ad.rad.co.il> References: <32CB7A1F0806AB4688CE3F22C29DAC87042C27ED@EXRAD5.ad.rad.co.il> <21D4E582-9050-47AF-A1D8-B17B58BDCCAE@cisco.com> In-Reply-To: <21D4E582-9050-47AF-A1D8-B17B58BDCCAE@cisco.com> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.170.136] Content-Type: multipart/alternative; boundary="_000_32CB7A1F0806AB4688CE3F22C29DAC8704316FC6EXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A020203.5045C8B9.0145,ss=1,fgs=0 Cc: "mpls@ietf.org" , "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, 04 Sep 2012 09:24:32 -0000 --_000_32CB7A1F0806AB4688CE3F22C29DAC8704316FC6EXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Carlos. Yes, IMHO the procedure of RFC 5885 that you quoted below can be adopted al= so for MPLS-TP. Assuming that in practice there is no PHP in MPLS-TP, the MPLS label provid= es the context to the first BFD control packet and there is no need for LSP= Ping bootstrapping. Muly From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] Sent: Tuesday, September 04, 2012 7:08 AM To: Muly Ilan Cc: mpls@ietf.org Subject: Re: [mpls] LSP ping as bootstrap for G-ACh encapsulated BFD What you describe seems to be the single-hop BFD initialization procedures,= which are also used in RFC 5885 [1] It is not totally clear to me how tightly tied the procedures from RFC 6428= are to the bootstrapping from RFC 5884 using LSP Ping, versus a single-hop= initialization without discriminators exchanged. The document seems to be = slightly vague there, though I do not know how it would affect. Thanks, -- Carlos. [1] http://tools.ietf.org/html/rfc5885#section-3.1 o The BFD Control packets are sent on the VCCV control channel. The use of the VCCV control channel provides the context required to bind and bootstrap the BFD session, since discriminator values are not exchanged; the pseudowire demultiplexer field (e.g., MPLS PW Label or L2TPv3 Session ID) provides the context to demultiplex the first BFD Control packet, and thus single-hop BFD initialization procedures are followed (see Section 3 of [RFC5881] and Section 6 of [RFC5882]). o A single BFD session exists per pseudowire. Both PW endpoints take the Active role sending initial BFD Control packets with a Your Discriminator field of zero, and BFD Control packets received with a Your Discriminator field of zero are associated to the BFD session bound to the PW. On Jun 17, 2012, at 12:14 PM, Muly Ilan wrote: Hi, We plan to implement the CC-CV-RDI functionality per RFC6428. Is it mandatory to support LSP ping as a bootstrap for the BFD i.e. using L= SP ping with TLV type 15 in the echo request/reply to exchange discriminato= r values? RFC6428 is quite vague on this issue. It only states "Overall operation is = as specified in RFC 5880 [4] and augmented for MPLS in RFC 5884 [8].". IMHO, the initial value of the remote discriminator can be zero and replace= d with the correct value when the 1stcontrol packet is received from the pe= er. This behavior complies with another statement of the RFC "The transmitted Y= our Discriminator value MUST reflect back the received value of the My Disc= riminator field or be set to zero if that value is not known". Thanks, Muly _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_32CB7A1F0806AB4688CE3F22C29DAC8704316FC6EXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Carlos.=

 <= /p>

Yes, IMHO the procedure o= f RFC 5885 that you quoted below can be adopted also for MPLS-TP.

Assuming that in practice= there is no PHP in MPLS-TP, the MPLS label provides the context to the fir= st BFD control packet and there is no need for LSP Ping bootstrapping.

 <= /p>

Muly

 <= /p>

From: Carlos P= ignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: Tuesday, September 04, 2012 7:08 AM
To: Muly Ilan
Cc: mpls@ietf.org
Subject: Re: [mpls] LSP ping as bootstrap for G-ACh encapsulated BFD=

 

What you describe seems to be the single-hop BF= D initialization procedures, which are also used in RFC 5885 [1]<= /o:p>

 

It is not totally clear to me how tightly tied the p= rocedures from RFC 6428 are to the bootstrapping from RFC 5884 using LSP Pi= ng, versus a single-hop initialization without discriminators exchanged. Th= e document seems to be slightly vague there, though I do not know how it would affect.

 

Thanks,

 

-- Carlos.

 

 

   o  Th=
e BFD Control packets are sent on the VCCV control channel.  The<=
/o:p>
      use of the VCCV control channel pr=
ovides the context required to
      bind and bootstrap the BFD session=
, since discriminator values are
      not exchanged; the pseudowire demu=
ltiplexer field (e.g., MPLS PW
      Label or L2TPv3 Session ID) provid=
es the context to demultiplex
      the first BFD Control packet, and =
thus single-hop BFD
      initialization procedures are foll=
owed (see Section&=
nbsp;3 of [RFC5881]
      and Section 6 of [RFC5882]).
 
   o  A single BFD session exists per pseudowire.&=
nbsp; Both PW endpoints
    =
;  take the Active role sending initial BFD Control packets with a
      Your Discriminator field of zero, =
and BFD Control packets received
      with a Your Discriminator field of=
 zero are associated to the BFD
      session bound to the PW.

 

 

On Jun 17, 2012, at 12:14 PM, Muly Ilan wrote:<= /o:p>



Hi,

 

We plan to implement the CC-CV-RDI func= tionality per RFC6428.

 

Is it mandatory to support LSP ping as = a bootstrap for the BFD i.e. using LSP ping with TLV type 15 in the echo re= quest/reply to exchange discriminator values?

 

RFC6428 is quite vague on this issue. I= t only states “Overall operation is as specified in RFC 5880 [4] and augmented for MPLS in RFC 5884 [8].”.

 

IMHO, the initial value of the remote d= iscriminator can be zero and replaced with the correct value when the 1stcontrol packet is received from the peer.

This behavior complies with another sta= tement of the RFC “The transmitted Your Discriminator value MUST reflect back the received value of the My Discriminator field or be set to zero if= that value is not known”.

 

 

Thanks,

 

Muly

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org= /mailman/listinfo/mpls

 

--_000_32CB7A1F0806AB4688CE3F22C29DAC8704316FC6EXRAD5adradcoil_-- From jhaas@slice.pfrc.org Tue Sep 11 10:54:46 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 10AD121F8555 for ; Tue, 11 Sep 2012 10:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[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 JPi7kFSco1F5 for ; Tue, 11 Sep 2012 10:54:45 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A2C0021F855A for ; Tue, 11 Sep 2012 10:54:45 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2B489C36C; Tue, 11 Sep 2012 13:54:45 -0400 (EDT) Date: Tue, 11 Sep 2012 13:54:45 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: IETF 85 - Atlanta Message-ID: <20120911175445.GB8139@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) 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, 11 Sep 2012 17:54:46 -0000 Working Group, At this point it doesn't look like there will be need for us to meet in Atlanta. The primary work in the working group is progress on BFD over LAGs and that work is mostly in spec refinement and implementation. (Plus getting it formally adopted as part of our charter.) My intention is that we'll get a status slide deck generated prior to the IETF meeting for all open drafts. I'll also try to generate pointers to BFD related work happening in other working groups. -- Jeff From jhaas@slice.pfrc.org Wed Sep 12 06:34: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 E063F21F8564 for ; Wed, 12 Sep 2012 06:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.19 X-Spam-Level: X-Spam-Status: No, score=-102.19 tagged_above=-999 required=5 tests=[AWL=0.075, 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 EjGdhebCG+3H for ; Wed, 12 Sep 2012 06:34:11 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7426521F855F for ; Wed, 12 Sep 2012 06:34:11 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 939C0C386; Wed, 12 Sep 2012 09:34:10 -0400 (EDT) Date: Wed, 12 Sep 2012 09:34:10 -0400 From: Jeffrey Haas To: Marc Binderberger Subject: Re: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? Message-ID: <20120912133410.GB25037@pfrc> References: <7C362EEF9C7896468B36C9B79200D8350D063A0B51@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D063A0D7A@INBANSXCHMBSA1.in.alcatel-lucent.com> <0D1B9ACE-889A-4090-88CC-BA7E3652117F@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0D1B9ACE-889A-4090-88CC-BA7E3652117F@sniff.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: draft-mmm-bfd-on-lags@tools.ietf.org, rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 13:34:12 -0000 Just to prod this particular topic a bit: On Thu, Aug 16, 2012 at 05:20:04PM +0200, Marc Binderberger wrote: > 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. Let us presume that we arrive at wording that effectively says "if you run micro sessions in a given address family, do it on all links". Presume also you run both IPv4 and IPv6. The implication is that if IPv4 drops, but IPv6 stays up, that the LMM should remove *only* the impacted address family from use. However, we're also suggesting that a scenario where one runs only one address family across the LAG is sufficient to impact all layer 3 traffic for the LMM. Harkening back to the IS-IS observations, I'm fine with this. What this means is we need language that says all of this. -- Jeff (speaking as an individual contributor) From marc@sniff.de Wed Sep 12 06:57: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 687C921F8607 for ; Wed, 12 Sep 2012 06:57:20 -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 V3CEt+N5p6bi for ; Wed, 12 Sep 2012 06:57:19 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E7A21F85A4 for ; Wed, 12 Sep 2012 06:57:19 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 4F3B82AA0F; Wed, 12 Sep 2012 13:57:16 +0000 (GMT) Subject: Re: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: <20120912133410.GB25037@pfrc> Date: Wed, 12 Sep 2012 15:57:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <98FA4437-6313-442D-B181-974CEA623363@sniff.de> References: <7C362EEF9C7896468B36C9B79200D8350D063A0B51@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D063A0D7A@INBANSXCHMBSA1.in.alcatel-lucent.com> <0D1B9ACE-889A-4090-88CC-BA7E3652117F@sniff.de> <20120912133410.GB25037@pfrc> To: Jeffrey Haas X-Mailer: Apple Mail (2.1084) Cc: draft-mmm-bfd-on-lags@tools.ietf.org, rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 13:57:20 -0000 Hello Jeff, > The implication is that if IPv4 drops, but IPv6 stays up, that the LMM > should remove *only* the impacted address family from use. ... if the implementation can differentiate between IPv4 and IPv6 in the = load balance. I have no intention to make such an AF-aware load-balance = table a requirement. The fact that either an IPv4 or an IPv6 BFD failure = can remove the link for all traffic is understood by (my) customers and = acceptable. But with such an "if an implementation's distribution algorithm can = differentiate between IPv4 and IPv6 then ..." condition I can add = something to the draft. Has anyone implemented such an AF-ware load-balancer? Just for my = curiosity. Regards, Marc On 2012-09-12, at 15:34 , Jeffrey Haas wrote: > Just to prod this particular topic a bit: >=20 > On Thu, Aug 16, 2012 at 05:20:04PM +0200, Marc Binderberger wrote: >> Hello Manav, Pablo et al., >>=20 >> 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: >>=20 >> 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). >>=20 >>=20 >>> Do you have some scenarios in mind? >>=20 >> 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. >=20 > Let us presume that we arrive at wording that effectively says "if you = run > micro sessions in a given address family, do it on all links". >=20 > Presume also you run both IPv4 and IPv6. >=20 > The implication is that if IPv4 drops, but IPv6 stays up, that the LMM > should remove *only* the impacted address family from use. >=20 > However, we're also suggesting that a scenario where one runs only one > address family across the LAG is sufficient to impact all layer 3 = traffic > for the LMM. Harkening back to the IS-IS observations, I'm fine with = this. >=20 > What this means is we need language that says all of this. >=20 > -- Jeff (speaking as an individual contributor) >=20 -- Marc Binderberger From jhaas@slice.pfrc.org Wed Sep 12 07:04:51 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 5EBD621F859B for ; Wed, 12 Sep 2012 07:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.205 X-Spam-Level: X-Spam-Status: No, score=-102.205 tagged_above=-999 required=5 tests=[AWL=0.060, 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 TmpMXP4NmSbx for ; Wed, 12 Sep 2012 07:04:49 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id F08E821F8574 for ; Wed, 12 Sep 2012 07:04:48 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 69944C386; Wed, 12 Sep 2012 10:04:48 -0400 (EDT) Date: Wed, 12 Sep 2012 10:04:48 -0400 From: Jeffrey Haas To: Marc Binderberger Subject: Re: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? Message-ID: <20120912140448.GA25587@pfrc> References: <7C362EEF9C7896468B36C9B79200D8350D063A0B51@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D063A0D7A@INBANSXCHMBSA1.in.alcatel-lucent.com> <0D1B9ACE-889A-4090-88CC-BA7E3652117F@sniff.de> <20120912133410.GB25037@pfrc> <98FA4437-6313-442D-B181-974CEA623363@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <98FA4437-6313-442D-B181-974CEA623363@sniff.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: draft-mmm-bfd-on-lags@tools.ietf.org, rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:04:51 -0000 On Wed, Sep 12, 2012 at 03:57:14PM +0200, Marc Binderberger wrote: > > The implication is that if IPv4 drops, but IPv6 stays up, that the LMM > > should remove *only* the impacted address family from use. > > ... if the implementation can differentiate between IPv4 and IPv6 in the load balance. I have no intention to make such an AF-aware load-balance table a requirement. The fact that either an IPv4 or an IPv6 BFD failure can remove the link for all traffic is understood by (my) customers and acceptable. Agreed - we don't want to force implementations to have unnecessary abstractions. (We're not OSI.) But... > But with such an "if an implementation's distribution algorithm can differentiate between IPv4 and IPv6 then ..." condition I can add something to the draft. Exactly. Let's be thorough. > Has anyone implemented such an AF-ware load-balancer? Just for my curiosity. FWIW, this is one of those "I'm not concerned about this year's implementations. It's next year's that I'm worried about" issues. Prophylactic standardization, if you will. -- Jeff From marc@sniff.de Wed Sep 12 09:29:51 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 878AE21F861F for ; Wed, 12 Sep 2012 09:29:51 -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 1x7uRZg1ay-8 for ; Wed, 12 Sep 2012 09:29: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 D3A8221F861E for ; Wed, 12 Sep 2012 09:29:50 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 9325A2AA0F; Wed, 12 Sep 2012 16:29:46 +0000 (GMT) Subject: Re: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: <20120912140448.GA25587@pfrc> Date: Wed, 12 Sep 2012 18:29:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <165FD086-EC34-4658-9B76-C93F64B93C08@sniff.de> References: <7C362EEF9C7896468B36C9B79200D8350D063A0B51@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D063A0D7A@INBANSXCHMBSA1.in.alcatel-lucent.com> <0D1B9ACE-889A-4090-88CC-BA7E3652117F@sniff.de> <20120912133410.GB25037@pfrc> <98FA4437-6313-442D-B181-974CEA623363@sniff.de> <20120912140448.GA25587@pfrc> To: Jeffrey Haas X-Mailer: Apple Mail (2.1084) Cc: draft-mmm-bfd-on-lags@tools.ietf.org, rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 16:29:51 -0000 Hello Jeff et al., is the following text achieving what we want? ----snip----snap----snip----snap---- 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(s). In case an implementation has separate load balance tables for IPv4 and IPv6 then if both an IPv4 and IPv6 micro session exist for a member link an implementation MAY remove the member link from the load balance table only that matches the address family of the failing BFD session. If for example the IPv4 micro session fails but the IPv6 micro session stays up then the member link MAY be removed from the IPv4 load balance table only but remains forwarding in the IPv6 load balance table. ----snip----snap----snip----snap---- And similar for the part where we describe adding a member link to the = table. Regards, Marc On 2012-09-12, at 16:04 , Jeffrey Haas wrote: > On Wed, Sep 12, 2012 at 03:57:14PM +0200, Marc Binderberger wrote: >>> The implication is that if IPv4 drops, but IPv6 stays up, that the = LMM >>> should remove *only* the impacted address family from use. >>=20 >> ... if the implementation can differentiate between IPv4 and IPv6 in = the load balance. I have no intention to make such an AF-aware = load-balance table a requirement. The fact that either an IPv4 or an = IPv6 BFD failure can remove the link for all traffic is understood by = (my) customers and acceptable. >=20 > Agreed - we don't want to force implementations to have unnecessary > abstractions. (We're not OSI.) But... >=20 >> But with such an "if an implementation's distribution algorithm can = differentiate between IPv4 and IPv6 then ..." condition I can add = something to the draft. >=20 > Exactly. Let's be thorough. >=20 >> Has anyone implemented such an AF-ware load-balancer? Just for my = curiosity. >=20 > FWIW, this is one of those "I'm not concerned about this year's > implementations. It's next year's that I'm worried about" issues. >=20 > Prophylactic standardization, if you will. >=20 > -- Jeff >=20 -- Marc Binderberger From jhaas@slice.pfrc.org Wed Sep 12 09:38:08 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 480C121F84E6 for ; Wed, 12 Sep 2012 09:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.215 X-Spam-Level: X-Spam-Status: No, score=-102.215 tagged_above=-999 required=5 tests=[AWL=0.050, 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 32j0LqGJfUVt for ; Wed, 12 Sep 2012 09:38:07 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id DCEC821F84AE for ; Wed, 12 Sep 2012 09:38:07 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2C595C3A3; Wed, 12 Sep 2012 12:38:02 -0400 (EDT) Date: Wed, 12 Sep 2012 12:38:02 -0400 From: Jeffrey Haas To: Marc Binderberger Subject: Re: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ? Message-ID: <20120912163802.GC25587@pfrc> References: <7C362EEF9C7896468B36C9B79200D8350D063A0B51@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D063A0D7A@INBANSXCHMBSA1.in.alcatel-lucent.com> <0D1B9ACE-889A-4090-88CC-BA7E3652117F@sniff.de> <20120912133410.GB25037@pfrc> <98FA4437-6313-442D-B181-974CEA623363@sniff.de> <20120912140448.GA25587@pfrc> <165FD086-EC34-4658-9B76-C93F64B93C08@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <165FD086-EC34-4658-9B76-C93F64B93C08@sniff.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: draft-mmm-bfd-on-lags@tools.ietf.org, rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 16:38:08 -0000 On Wed, Sep 12, 2012 at 06:29:45PM +0200, Marc Binderberger wrote: > Hello Jeff et al., > > is the following text achieving what we want? > > > ----snip----snap----snip----snap---- > 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(s). > > In case an implementation has separate load balance tables for IPv4 > and IPv6 then if both an IPv4 and IPv6 micro session exist for a > member link an implementation MAY remove the member link from the > load balance table only that matches the address family of the > failing BFD session. If for example the IPv4 micro session fails but > the IPv6 micro session stays up then the member link MAY be removed > from the IPv4 load balance table only but remains forwarding in the > IPv6 load balance table. > ----snip----snap----snip----snap---- > > > And similar for the part where we describe adding a member link to the table. Perfect. -- Jeff From jhaas@slice.pfrc.org Tue Sep 25 13:57:45 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D1821F881F for ; Tue, 25 Sep 2012 13:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.228 X-Spam-Level: X-Spam-Status: No, score=-103.228 tagged_above=-999 required=5 tests=[AWL=1.037, BAYES_00=-2.599, GB_I_LETTER=-2, 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 uwfGvyl5lKm3 for ; Tue, 25 Sep 2012 13:57:44 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8A29C21F8811 for ; Tue, 25 Sep 2012 13:57:44 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2051EC3FD; Tue, 25 Sep 2012 16:57:44 -0400 (EDT) Date: Tue, 25 Sep 2012 16:57:44 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: [lsmt@ietf.org: New Liaison Statement, "In response to liaison statement to the IETF regarding Proposed IETF BFD WG work on Ethernet LAG"] Message-ID: <20120925205744.GJ1854@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) 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, 25 Sep 2012 20:57:45 -0000 Official response to the IEEE 802.1 group. ----- Forwarded message from Liaison Statement Management Tool ----- Date: Tue, 25 Sep 2012 13:55:02 -0700 From: Liaison Statement Management Tool To: tony@jeffree.co.uk Cc: adrian@olddog.co.uk, dromasca@avaya.com, eric.gray@ericsson.com, jhaas@pfrc.org, wardd@cisco.com Subject: New Liaison Statement, "In response to liaison statement to the IETF regarding Proposed IETF BFD WG work on Ethernet LAG" Title: In response to liaison statement to the IETF regarding Proposed IETF BFD WG work on Ethernet LAG Submission Date: 2012-09-25 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1192/ From: Bidirectional Forwarding Detection (Jeffrey Haas ) To: IEEE 802.1 (tony@jeffree.co.uk) Cc: adrian@olddog.co.uk,dromasca@avaya.com,eric.gray@ericsson.com Reponse Contact: Technical Contact: jhaas@pfrc.org,wardd@cisco.com Purpose: In response Referenced liaison: Liaison response to IETF regarding Proposed IETF BFD WG work on Ethernet LAG (http://datatracker.ietf.org/liaison/1152/) Body: Dear Tony, Thank you for your prompt response with regards to our liaison letter regarding BFD over Ethernet LAGs. The IETF BFD Working Group is happy to hear that IEEE is willing to work with us in specifying the interworking of BFD over Ethernet LAGs. In particular, your response seems to provide good guidance in how we may be able to draft a specification for BFD in this scenario. After further consideration of our proposal, the authors of the BFD over Ethernet LAG draft have largely decoupled the BFD functionality from LACP. When using LACP for a LAG, BFD will monitor the fact that the LAG member link has entered the Distributing state and use this transition to activate the BFD session. Furthermore, the BFD working group will not make any modifications to LACP, and this work will not be used to influence the LACP state machine. Our intent is that BFD solely influences the traffic load balancer, an implementation detail we believe is outside the scope of 802.1ax, to control whether traffic is sent on a LAG member link or not. With regard to your comment: "We must point out Link Aggregation is a (lower) Layer 2 construct, not a Layer 3 construct. It is not uncommon to connect a router to a bridge via an aggregated link. In this case, it is not clear how one uses a Layer 3 protocol to support the aggregation, or how to achieve interoperability when two different protocols are used (i.e. BFD and CFM) for the same purpose for the two connected systems." the Working Group even at this early stage is in agreement with you. The initial Internet-Draft (which at this stage is still not a working group document) for BFD over Ethernet LAGs is currently intended to only address the case where there is no bridging involved, and intended to operate over LAG members that are each IP-capable links. Some discussion has occurred among the draft authors about BFD over Ethernet LAGs with bridges and we may pursue this scenario at a later date, in which case we may discuss the details with you further. In the meantime, you can see the latest copy of the Internet-Draft at http://datatracker.ietf.org/doc/draft-mmm-bfd-on-lags/ Please be aware that the BFD working group is now considering adopting this document as formally part of its work. We look forward to continuing to work with you on this problem space. Regards, Jeffrey Haas, David Ward IETF BFD Co-Chairs Attachments: No document has been attached ----- End forwarded message ----- From siraj@kth.se Tue Sep 18 01:31:38 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 855A321F877C for ; Tue, 18 Sep 2012 01:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.648 X-Spam-Level: X-Spam-Status: No, score=-3.648 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_SE=0.35, 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 WkMpAhswlRnu for ; Tue, 18 Sep 2012 01:31:37 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by ietfa.amsl.com (Postfix) with ESMTP id 76EBE21F877A for ; Tue, 18 Sep 2012 01:31:37 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id ECC6914EA15 for ; Tue, 18 Sep 2012 10:31:05 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id bfSJ2Rwy-tO0 for ; Tue, 18 Sep 2012 10:31:05 +0200 (CEST) Received: from EXHUB1.ug.kth.se (exhub1.ug.kth.se [130.237.32.134]) by smtp-2.sys.kth.se (Postfix) with ESMTP id F084A14C113 for ; Tue, 18 Sep 2012 10:31:04 +0200 (CEST) Received: from EXDB3.ug.kth.se ([169.254.3.36]) by EXHUB1.ug.kth.se ([130.237.32.134]) with mapi id 14.02.0318.001; Tue, 18 Sep 2012 10:31:04 +0200 From: Siraj Rathore To: "rtg-bfd@ietf.org" Subject: bfd implementation Thread-Topic: bfd implementation Thread-Index: Ac2Vd/ChwD1PfecXSUyZcBMc79lR8g== Date: Tue, 18 Sep 2012 08:31:03 +0000 Message-ID: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.229.174.96] Content-Type: multipart/alternative; boundary="_000_F13AB7B8CD4A3D4D8E853993CA30D5CF0DC8A43EEXDB3ugkthse_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 26 Sep 2012 08:22:34 -0700 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, 18 Sep 2012 08:34:21 -0000 --_000_F13AB7B8CD4A3D4D8E853993CA30D5CF0DC8A43EEXDB3ugkthse_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Can some one comment about following bfd implementation. http://www.phelan-4.com/bfd/ Is it open source (GPL) and permitted to use in a research project? Thank you and Best Regards, Siraj --_000_F13AB7B8CD4A3D4D8E853993CA30D5CF0DC8A43EEXDB3ugkthse_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi

Can some one comment about following bfd implementation.

http://www.phelan-4.com/bfd/

Is it open source (GPL) and permitted to use in a research project?

Thank you and Best Regards,
Siraj
--_000_F13AB7B8CD4A3D4D8E853993CA30D5CF0DC8A43EEXDB3ugkthse_-- From arulmohan.jovelponnaien@alcatel-lucent.com Fri Sep 28 03:45:38 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 D4E5821F8516 for ; Fri, 28 Sep 2012 03:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_HI=-8] 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 oqUF1KMpwQEe for ; Fri, 28 Sep 2012 03:45:38 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5059F21F8495 for ; Fri, 28 Sep 2012 03:45:37 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q8SAjXWO014402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 28 Sep 2012 05:45:36 -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 q8SAjWR1009530 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 28 Sep 2012 16:15:32 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 28 Sep 2012 16:15:31 +0530 From: "JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)" To: "rtg-bfd@ietf.org" Date: Fri, 28 Sep 2012 16:15:28 +0530 Subject: Comment on DestinationMac in draft-mmm-bfd-on-lags Thread-Topic: Comment on DestinationMac in draft-mmm-bfd-on-lags Thread-Index: Ac2dZmAFGHKo16jGQjqD/3BGsTTLJA== Message-ID: <7A2E55DFE338EE418E3B95A0C388997D075E407F79@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7A2E55DFE338EE418E3B95A0C388997D075E407F79INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 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, 28 Sep 2012 10:45:39 -0000 --_000_7A2E55DFE338EE418E3B95A0C388997D075E407F79INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Micro-BFD session would use dedicated destination MAC address allocated for= IANA range(RFC 5342). But this MAC address range is not link-level and wou= ld allow forwarding of Link-Level BFD packets by intermediate L2 switches. Assume case below, here it is possible that 3 micro BFD sessions from Route= r1 could be forwarded on single-port to Router2. Router1 ------------(3-port) LAG------------L2 Switch-------(1-port LAG)---= --------Router2 If MAC-address is chosen from range 01:80:c2:xx:xx:xx, then this case would= not arise. Micro-BFD session would then be terminated by L2 switch immedia= tely. By 802.1d standard 01:80:c2:xx:xx:xx would be terminated by L2 switch= . Is it not better if we choose a MAC address in 01:80:c2 range similar to LA= CP to make sure micro-BFD session remains link-level protocol? Regards, Arul Mohan. --_000_7A2E55DFE338EE418E3B95A0C388997D075E407F79INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi All,
 
Micro-BFD session would use dedicated destination MAC address allocate= d for IANA range(RFC 5342). But this MAC address range is not link-level an= d would allow forwarding of Link-Level BFD packets by intermediate L2 switc= hes.
 
Assume case below, here it is possible that 3 micro BFD sessions from = Router1 could be forwarded on single-port to Router2.
Router1 ------------(3-port) LAG------------L2 Switch-------(1-port LA= G)-----------Router2
 
If MAC-address is chosen from range 01:80:c2:xx:xx:xx, then this case = would not arise. Micro-BFD session would then be terminated by L2 switch im= mediately. By 802.1d standard 01:80:c2:xx:xx:xx would be terminated by L2 s= witch.
 
Is it not better if we choose a MAC address in 01:80:c2 range similar = to LACP to make sure micro-BFD session remains link-level protocol?
 
Regards,
Arul Mohan.
 
  --_000_7A2E55DFE338EE418E3B95A0C388997D075E407F79INBANSXCHMBSA_-- From d3e3e3@gmail.com Sun Sep 30 12:52:32 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 4A77E21F8578 for ; Sun, 30 Sep 2012 12:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.267 X-Spam-Level: X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[AWL=-0.968, BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1, 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 dqEWUKctdfWg for ; Sun, 30 Sep 2012 12:52:27 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id CAA5F21F84DF for ; Sun, 30 Sep 2012 12:52:27 -0700 (PDT) Received: by iec9 with SMTP id 9so12397415iec.31 for ; Sun, 30 Sep 2012 12:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nFLKRUy9BnFzo+DaKU+EQYHy5FS2bKWnr/4Mxr/5ftU=; b=OITfIMp/3oZ/LCyoTUUMk5aWBa0v2zBK9meW3MIWkjyg8ao5knl0CwehRfFQxpwCnJ vOcL/LY18IKxNgjpzEda0anNsudlh1GMr3+f0yoJZhpcu911L4TGLHQulMby1E64wNTw nQAFcrMtcy56Q/kKYiHN3Ws3K2BI7BatLovTecpkHMBuOJ8lnOOKwV0P2rTgr6EnHjRG C1C5/CA8xULEh1d7kvgHGLZB5uGW2Fe4vZI6By2iwCKbSmm20npsYB19VlcKVkZqTfSp ylh5MKjz3GpjzxmlnBt3ZrLln/FlvHB751PssdZ/kMlfbRr4FGMOYRy6UiJ4pY1/k8Jg gt5Q== Received: by 10.50.185.230 with SMTP id ff6mr4491667igc.0.1349034747140; Sun, 30 Sep 2012 12:52:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.113 with HTTP; Sun, 30 Sep 2012 12:52:06 -0700 (PDT) In-Reply-To: <7A2E55DFE338EE418E3B95A0C388997D075E407F79@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7A2E55DFE338EE418E3B95A0C388997D075E407F79@INBANSXCHMBSA1.in.alcatel-lucent.com> From: Donald Eastlake Date: Sun, 30 Sep 2012 15:52:06 -0400 Message-ID: Subject: Re: Comment on DestinationMac in draft-mmm-bfd-on-lags To: "JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)" Content-Type: text/plain; charset=ISO-8859-1 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: Sun, 30 Sep 2012 19:52:32 -0000 Hi, On Fri, Sep 28, 2012 at 6:45 AM, JOVELPONNAIEN, ARULMOHAN (ARULMOHAN) wrote: > Hi All, > > Micro-BFD session would use dedicated destination MAC address allocated for > IANA range (RFC 5342). But this MAC address range is not link-level and would > allow forwarding of Link-Level BFD packets by intermediate L2 switches. > > Assume case below, here it is possible that 3 micro BFD sessions from > Router1 could be forwarded on single-port to Router2. > Router1 ------------(3-port) LAG------------L2 Switch-------(1-port > LAG)-----------Router2 > > If MAC-address is chosen from range 01:80:c2:xx:xx:xx, then this case would > not arise. Micro-BFD session would then be terminated by L2 switch > immediately. By 802.1d standard 01:80:c2:xx:xx:xx would be terminated by L2 > switch. I believe you will find that the range of addresses that are blocked by 802.1 bridges if they do not understand them is MUCH narrower. It is, in fact, only the block of 16 addresses from 01:80:C2:00:00:00 to 01:80:C2:00:00:0F. For example, 01-80-C2-00-00-14 and 01-80-C2-00-00-15 are the addresses used by IS-IS for All Level 1 and All Level 2 Intermediate Systems, respectively, and which must be transparently handled by bridges or you couldn't have a bridge in between two Layer 3 IP routers. > Is it not better if we choose a MAC address in 01:80:c2 range similar to > LACP to make sure micro-BFD session remains link-level protocol? If you want an address of that type, you could apply to the IEEE Registration Authority although the WG should probably coordinate that with you AD. Only a tiny fraction of those addresses, which are intended for standards use, have been allocated. But, as I say, it will not make any difference to the behavior and it seems easier for an IETF WG to get a 48-bit multicast address using the procedures in RFC 5342. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Regards, > Arul Mohan. > > From marc@sniff.de Sun Sep 30 14:54: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 DE20621F846C for ; Sun, 30 Sep 2012 14:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_TOOL=2.3] 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 yC9VxQ9XJDPi for ; Sun, 30 Sep 2012 14:54:13 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F9421F846A for ; Sun, 30 Sep 2012 14:54:12 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 3220C2AA0F; Sun, 30 Sep 2012 21:54:10 +0000 (GMT) Subject: Re: Comment on DestinationMac in 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: Date: Sun, 30 Sep 2012 23:54:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2C22A8F0-BBC9-413C-9AD9-95813973BAA9@sniff.de> References: <7A2E55DFE338EE418E3B95A0C388997D075E407F79@INBANSXCHMBSA1.in.alcatel-lucent.com> To: "JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)" , Donald Eastlake 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: Sun, 30 Sep 2012 21:54:14 -0000 Hello Donald and Arul, > I believe you will find that the range of addresses that are blocked > by 802.1 bridges if they do not understand them is MUCH narrower. It > is, in fact, only the block of 16 addresses from 01:80:C2:00:00:00 to > 01:80:C2:00:00:0F. indeed, see e.g. = http://standards.ieee.org/develop/regauth/tut/macgrp.pdf and = http://standards.ieee.org/develop/regauth/grpmac/public.html . So yes, in the setup you describe - and which is not supported as of now = by the draft - it can get confusing. Why do we look at a RFC5342 IANA MAC address?=20 - unlikely we get our own address out of the scarce resource of the 16 = link-local addresses - sharing a MAC out of this range is mixing IEEE and IETF and side = effects may occur - we actually want to have a dedicated MAC "only for us", as some = implementation may use the MAC to know it's a micro session and process = it accordingly. This processing may be very different from 802.1D, 802.3 = and other IEEE-related processing (hardware vs. software, distributed = vs. central, delay/jitter of processing and so on) - using link-local MAC would require a new allocation if we want to = extend the draft across layer-2 bridges. We haven't cracked this problem = yet but like to keep it open. (okay, not a strong point, if we would need another MAC we could get one = from IANA I suppose) I would say we need practical experience to see how bad your scenario = actually is and if we need to introduce e.g. some "jabber control" on = the BFD level, i.e. detecting when multiple sessions end up on one link. = Or we just state clearly what is and what is not supported. Regards, Marc On 2012-09-30, at 21:52 , Donald Eastlake wrote: > Hi, >=20 > On Fri, Sep 28, 2012 at 6:45 AM, JOVELPONNAIEN, ARULMOHAN (ARULMOHAN) > wrote: >> Hi All, >>=20 >> Micro-BFD session would use dedicated destination MAC address = allocated for >> IANA range (RFC 5342). But this MAC address range is not link-level = and would >> allow forwarding of Link-Level BFD packets by intermediate L2 = switches. >>=20 >> Assume case below, here it is possible that 3 micro BFD sessions from >> Router1 could be forwarded on single-port to Router2. >> Router1 ------------(3-port) LAG------------L2 Switch-------(1-port >> LAG)-----------Router2 >>=20 >> If MAC-address is chosen from range 01:80:c2:xx:xx:xx, then this case = would >> not arise. Micro-BFD session would then be terminated by L2 switch >> immediately. By 802.1d standard 01:80:c2:xx:xx:xx would be terminated = by L2 >> switch. >=20 > I believe you will find that the range of addresses that are blocked > by 802.1 bridges if they do not understand them is MUCH narrower. It > is, in fact, only the block of 16 addresses from 01:80:C2:00:00:00 to > 01:80:C2:00:00:0F. For example, 01-80-C2-00-00-14 and > 01-80-C2-00-00-15 are the addresses used by IS-IS for All Level 1 and > All Level 2 Intermediate Systems, respectively, and which must be > transparently handled by bridges or you couldn't have a bridge in > between two Layer 3 IP routers. >=20 >> Is it not better if we choose a MAC address in 01:80:c2 range similar = to >> LACP to make sure micro-BFD session remains link-level protocol? >=20 > If you want an address of that type, you could apply to the IEEE > Registration Authority although the WG should probably coordinate that > with you AD. Only a tiny fraction of those addresses, which are > intended for standards use, have been allocated. But, as I say, it > will not make any difference to the behavior and it seems easier for > an IETF WG to get a 48-bit multicast address using the procedures in > RFC 5342. >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com >=20 >> Regards, >> Arul Mohan. >>=20 >>=20 >=20