Re: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8
Mahesh Jethanandani <mjethanandani@gmail.com> Tue, 29 October 2013 23:47 UTC
Return-Path: <mjethanandani@gmail.com>
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 8408811E80E7 for <rtg-bfd@ietfa.amsl.com>; Tue, 29 Oct 2013 16:47:02 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mc0JmfukOJey for <rtg-bfd@ietfa.amsl.com>; Tue, 29 Oct 2013 16:47:01 -0700 (PDT)
Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 58F6011E81C5 for <rtg-bfd@ietf.org>; Tue, 29 Oct 2013 16:46:58 -0700 (PDT)
Received: by mail-ve0-f175.google.com with SMTP id jz11so456901veb.6 for <rtg-bfd@ietf.org>; Tue, 29 Oct 2013 16:46:57 -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=B8KmoW/WZmCSDd57EUwlZ7aasfl8xyYbGJvC/+2gPMM=; b=YxOhwg+tyb6iAkZOb5xztoQIELG7G8ZS6sP5Iw5XF/m82CEr3a5WkslDAspR5DRMoM xFhS56rsPFbpf+QoZXSvSMfGwMDoWrHECDTBoOXSnfYJbVgIHFhfFto7i0g+KY2p9d45 VdyVXkHi6EY4fRu/1m5BPr8xk3fN0mx85bDVpWaXgMQYIOEO4s11ml/jLCPzGfuzGnIu 7M0Fn8h6XbIrnwvXzLPd/LBk9iNCRtA7JlwdzCFMMPoeReoLiF76aZ5fM7ED8luTTLyg fSlE46mBpxQrDW7c4by7MMbsuIhbB7QbmfLZKWqLAgWjrKGqfTBjP0T02C5nk0tS5mgH ku0w==
MIME-Version: 1.0
X-Received: by 10.221.6.195 with SMTP id ol3mr1079525vcb.34.1383090417830; Tue, 29 Oct 2013 16:46:57 -0700 (PDT)
Received: by 10.52.34.16 with HTTP; Tue, 29 Oct 2013 16:46:57 -0700 (PDT)
In-Reply-To: <20211F91F544D247976D84C5D778A4C32E4EEE0D@SG70YWXCHMBA05.zap.alcatel-lucent.com>
References: <20131024191431.GO17538@pfrc> <315041E4211CB84E86EF7C25A2AB583D337EBFB3@xmb-rcd-x15.cisco.com> <425296D4-F96F-49FF-86D2-40737B64E117@gmail.com> <20211F91F544D247976D84C5D778A4C32E4EEE0D@SG70YWXCHMBA05.zap.alcatel-lucent.com>
Date: Tue, 29 Oct 2013 16:46:57 -0700
Message-ID: <CAAchPMsYyDTiONE1v=vKsebF8JPnnHiOFWEE_b0uR6zh8W+E=g@mail.gmail.com>
Subject: Re: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8
From: Mahesh Jethanandani <mjethanandani@gmail.com>
To: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="089e013cbc8c0c1a1704e9e9d5cc"
Cc: "rtg-bfd@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" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-bfd>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Oct 2013 23:47:04 -0000
Manav, I have problems with the draft in its current format for two reasons. The fundamental issue is that the proposal requires BFD protocol to rely on information that is not carried in the frame itself. Unless by interface check you mean check against IP address. I do not know of many protocols that require one to validate/use information that is not part of the frame itself. Protocols that have stood the test of time, like TCP, do not look beyond their own layers in the frame for validation of a frame. Even if we have breached the OSI layer, at least we have restricted ourselves to looking at what is in the frame. The second issue as I highlighted is that there is an assumption that systems carry interface information up to the protocol itself for it to validate/use the information. Again, I assume you mean the check will be against the physical interface and not the IP address. That as I mentioned is a huge assumption. There is no precedence for this. There are couple of ways to solve the problem. One way would be to use the IP address on the individual member link to map a packet to a BFD session running on a member link. When the initial BFD frame is received with your discriminator as zero, you would use the destination IP address contained in the packet to figure out which link the packet was received on. The same would be true of validation of frame. This will not work for unnumbered interfaces. The other would be use the individual link MAC address as a way to co-relate a BFD packet to a particular link both to set up a BFD session (when the discriminator is zero) and for future validation of the frame (to a particular link). This would mean that we cannot use the multicast address to send the BFD frame. How the IP/MAC address is collected and setup is beyond the scope of this document. On Sun, Oct 27, 2013 at 4:37 AM, Bhatia, Manav (Manav) < manav.bhatia@alcatel-lucent.com> wrote: > Hi Mahesh, > > This draft only talks about BFD sessions between directly connected boxes. > > > For initial DOWN BFD packet, where the Your Discriminator field is 0, > > the draft suggests that demultiplexing MUST be based on some > > combination of other fields which MUST include the interface > > information of the member link. That assumes that systems are aware of > > what interface the BFD packet came on. That is not always the case, and > > in a global label/IP space, systems do not have to know the physical > > Can you explain the scenario where you think its not possible for a system > to know the ifindex of the IP interface over which an incoming packet > arrived? > > > link traffic came on. I am struggling to suggest an alternative, but > > would like to see the issue addressed particularly since it is a MUST. > > > > Same is true for the procedure for the reception of BFD control packet > > and its verification of the interface that it came on. > > I think youre missing something because we already have 3 interoperable > implementations of this draft. Clearly, those implementations were able to > identify the IP interface over which the uBFD packet arrived. > > Cheers, Manav > > > > > On Oct 24, 2013, at 10:00 PM, Vengada Prasad Govindan (venggovi) wrote: > > > > > Support > > > > > > -----Original Message----- > > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > > Behalf Of Jeffrey Haas > > > Sent: Friday, October 25, 2013 12:45 AM > > > To: rtg-bfd@ietf.org > > > Subject: WGLC for BFD over Link Aggregate Group Interfaces - ends > > November 8 > > > > > > This email is to initiate working group last call on the BFD on Link > > Aggregate Group Interfaces document: > > > > > > http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01 > > > > > > The last call will complete on November 8, the end of IETF week. > > Time will be available during the Vancouver IETF BFD session to discuss > > last call comments. > > > > > > Nobo Akiya will be serving as document shepherd (RFC 4858) for this > > WGLC. > > > > > > Due to the small nature of the BFD working group and the fact that > > both working group chairs have contributed to this document, we have > > gotten Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as > > an independent party to gauge working group consensus. > > > > > > In order to facilitate the transparency of this WGLC, please remember > > to send all comments to the working group mailing list. > > > > > > IPR declarations have been filed against this draft and the document > > authors and contributors have been polled for any further IPR. Current > > IPR declarations may be seen at the following link: > > > > > > > > http://datatracker.ietf.org/ipr/search/?option=document_search&id=draft > > -ietf-bfd-on-lags > > > > > > If you are aware of additional IPR against this document please > > declare so, per the IETF Note Well. > > > > > > Finally, the IEEE has expressed interest in the disposition of this > > draft. > > > They will likely provide additional commentary, if any, via the IETF > > liaison process. This process will likely happen after WGLC concludes. > > Depending on their feedback, WGLC may re-open to address their > > concerns. > > > > > > -- Jeff (for the chairs) > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > -- Mahesh Jethanandani mjethanandani@gmail.com
- WGLC for BFD over Link Aggregate Group Interfaces… Jeffrey Haas
- Re: WGLC for BFD over Link Aggregate Group Interf… Henderickx, Wim (Wim)
- Re: WGLC for BFD over Link Aggregate Group Interf… Jeff Tantsura
- RE: WGLC for BFD over Link Aggregate Group Interf… Bhatia, Manav (Manav)
- Re: WGLC for BFD over Link Aggregate Group Interf… Srihari Raghavan (srihari)
- Re: WGLC for BFD over Link Aggregate Group Interf… Marc Binderberger
- Re: WGLC for BFD over Link Aggregate Group Interf… Shishio Tsuchiya
- RE: WGLC for BFD over Link Aggregate Group Interf… Vengada Prasad Govindan (venggovi)
- Re: WGLC for BFD over Link Aggregate Group Interf… Mahesh Jethanandani
- RE: WGLC for BFD over Link Aggregate Group Interf… Bhatia, Manav (Manav)
- Re: WGLC for BFD over Link Aggregate Group Interf… Carlos Pignataro (cpignata)
- Re: WGLC for BFD over Link Aggregate Group Interf… Mahesh Jethanandani
- RE: WGLC for BFD over Link Aggregate Group Interf… Bhatia, Manav (Manav)
- Re: WGLC for BFD over Link Aggregate Group Interf… Marc Binderberger
- RE: WGLC for BFD over Link Aggregate Group Interf… Marc Binderberger
- Re: WGLC for BFD over Link Aggregate Group Interf… Mahesh Jethanandani
- Re: WGLC for BFD over Link Aggregate Group Interf… Jeffrey Haas
- Re: WGLC for BFD over Link Aggregate Group Interf… Mahesh Jethanandani
- Re: WGLC for BFD over Link Aggregate Group Interf… Marc Binderberger
- Re: WGLC for BFD over Link Aggregate Group Interf… Mahesh Jethanandani
- Re: WGLC for BFD over Link Aggregate Group Interf… Marc Binderberger
- RE: WGLC for BFD over Link Aggregate Group Interf… Bhatia, Manav (Manav)
- WGLC for BFD over Link Aggregate Group Interfaces… Ashesh Mishra
- Re: WGLC for BFD over Link Aggregate Group Interf… Marc Binderberger
- RE: WGLC for BFD over Link Aggregate Group Interf… Ashesh Mishra
- Re: WGLC for BFD over Link Aggregate Group Interf… Glen Kent
- Re: WGLC for BFD over Link Aggregate Group Interf… Carlos Pignataro (cpignata)
- RE: WGLC for BFD over Link Aggregate Group Interf… Nobo Akiya (nobo)