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