Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDED12D5DF; Fri, 8 Apr 2016 12:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mvt73LMit1lG; Fri, 8 Apr 2016 12:01:20 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24C7A12D61B; Fri, 8 Apr 2016 12:01:04 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id t10so145518967ywa.0; Fri, 08 Apr 2016 12:01:04 -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; bh=euJG4Y4zwsnPxPTaQ2xlW4mmIOPwK8y5Qk8Ev2buoI8=; b=QsHPFe5W3pkhg040xEDx3mQ/nf9+uuhRQVyMvPkyEC/aLT5sYG4upCRgh8dVE4ygBM guvCBMdIxVsStoKxKYQhI18dw/1Ym/tP/SBV6FpL1aCYFKOEZp9lsHu376lWdhYQkNLP 3F92hi6QfYm0t7cNW801SzLTnecOg8yGKZ2RyVj+ClAwww9VH0rPe3l0xrc18gDfnFaC Hi7MLUmFiTQ23tIwl4Eruw8pday9wbZASvAF47vAzW144dgh67Y9HcHpzicxdfW2hm8v wx+pJxIH8n68dCLtX1l9ufAiF9tPuVjJSNioaC4npaLp0UXHiJhZ/PVlrBg/4ouwP2in Tg3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=euJG4Y4zwsnPxPTaQ2xlW4mmIOPwK8y5Qk8Ev2buoI8=; b=kpa9wiD1eMhn91nBkoeks88UlayuXM1yCK82KIJ8Bzkl+bQ5KCnNkdUX/gsK4nUEuW EfPbiwL1Ev1Vb92Apv/WneGVuVQt2D/MZZLEIYQzJdPNfcV1k/EIp42oCCCEjxW5aZR0 rllnxjf47T9+CUF87kAhtOWD5XMJgV9tINYcE0bTApr1aDHqSblyWTr1aRR5AAVnwd/+ mtWaHzfzHny5JpUNHbnzrcJF5TENvzJFVd4dnnrd7WyGyHBytXm3bJ5dpJFgLEqPno6I 0X/4DGKawwGqWprY9DSk1uifMfzUO4y/zJ/HDlxuxXC3S1reJvNf0AARCHNfzzhL9Uv4 eXpQ== X-Gm-Message-State: AD7BkJLscjatv1B+E1rl0HVCwwriNDM4kofmnsEeWbJ5a5UI9hxT43IWmm9nWVu8EB2VyWQLsah888xfxclfHA== MIME-Version: 1.0 X-Received: by 10.13.220.197 with SMTP id f188mr5232114ywe.172.1460142064034; Fri, 08 Apr 2016 12:01:04 -0700 (PDT) Received: by 10.37.215.143 with HTTP; Fri, 8 Apr 2016 12:01:03 -0700 (PDT) Received: by 10.37.215.143 with HTTP; Fri, 8 Apr 2016 12:01:03 -0700 (PDT) In-Reply-To: References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40798@eusaamb103.ericsson.se> Date: Fri, 8 Apr 2016 12:01:03 -0700 Message-ID: From: Greg Mirsky To: Manav Bhatia Content-Type: multipart/alternative; boundary=94eb2c07bc900c8772052ffdd182 Archived-At: Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org, "rtg-bfd-chairs@ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 19:01:24 -0000 --94eb2c07bc900c8772052ffdd182 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Manav, the update could be in addition of either broadcast or link local multicast or both with appropriate normative language. But I would not agree that these wouldn't work. Regards, Greg On Apr 8, 2016 12:34 PM, "Manav Bhatia" wrote: > Hi Greg, > > Not sure i understand how it can "update RFC 7130". Is that by using a > link local mcast IP instead of a Unicast IP? > > We know that, that wouldnt work. > > Cheers, Manav > > On Fri, Apr 8, 2016 at 9:44 PM, Gregory Mirsky < > gregory.mirsky@ericsson.com> wrote: > >> Hi Reshad, >> >> thank you for your comments. Indeed, RFC 7130 is restricted and thus >> hardly applicable to MC-LAG case. We realize that if this proposal is >> adopted it not only enhance applicability on u-BFD but will update RFC 7= 130. >> >> >> >> Regards, >> >> Greg >> >> >> >> *From:* Reshad Rahman (rrahman) [mailto:rrahman@cisco.com] >> *Sent:* Friday, April 08, 2016 8:51 AM >> *To:* Manav Bhatia; Gregory Mirsky >> *Cc:* draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; >> mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com); rtg-bfd@ietf.org; >> rtg-bfd-chairs@ietf.org >> >> *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces >> >> >> >> I agree with Manav, and nothing in RFC7130 seems to preclude using >> different unicast IP address as destination on different member links. >> >> >> >> Regards, >> >> Reshad (as individual contributor). >> >> >> >> *From: *Rtg-bfd on behalf of Manav Bhatia < >> manavbhatia@gmail.com> >> *Date: *Friday, April 8, 2016 at 11:04 AM >> *To: *Gregory Mirsky >> *Cc: *"draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" < >> draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>, "mpls@ietf.org" < >> mpls@ietf.org>, "mpls-chairs@ietf.org" , "Alia >> Atlas (akatlas@gmail.com)" , "rtg-bfd@ietf.org" < >> rtg-bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" >> *Subject: *Re: Two new drafts on (micro-)BFD over MC-LAG interfaces >> >> >> >> Hi Greg, >> >> >> >> Why cant different micro-BFD packets use the IP address of the MC-LAG en= d >> points? Ones going to router 1 will all carry the same unicast IP addres= s. >> The ones going towards the other router will all carry some other IP >> address, which would be configured along with the MC-LAG configs. >> >> >> >> In fact i would argue that the u-bfd packets going to different routers >> must use different IP addresses so that you can actually verify the data >> plane liveliness. Whats the point in sending a contrived IP address if t= he >> path that it takes is different from the other regular packets? >> >> >> >> Cheers, Manav >> >> >> >> On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky < >> gregory.mirsky@ericsson.com> wrote: >> >> Hi Manav, >> >> thank you for sharing insight view of discussions around RFC 7130, >> extremely helpful. >> >> We believe, and Jeff is co-author of RFC 7130 too, that MC-LAG presents >> different case and the compromise that you=E2=80=99ve pointed too is jus= tified. We >> will add more details on the potential differences between unicast and >> multicast fast paths in the next update. >> >> We are open to the discussion and always welcome comments and alternativ= e >> proposals. >> >> >> >> Regards, >> >> Greg >> >> >> >> *From:* Manav Bhatia [mailto:manavbhatia@gmail.com] >> *Sent:* Thursday, April 07, 2016 7:39 PM >> *To:* Mach Chen >> *Cc:* Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; >> draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org= ; >> mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) >> *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces >> >> >> >> I believe it had to do with multicast datapath (especially link local) >> being different from the unicast datapath in most routers. Using link lo= cal >> multicast IP addresses may not necessarily guarantee Unicast IP >> reachability. >> >> >> >> When writing 7130 we spent quite a bit of time ensuring that we dont >> carve out a special data path for the micro-BFD packets. Using link loca= l >> would have made it a lot simpler. >> >> >> >> And this is where i think the current proposal is flawed -- they use lin= k >> local multicast to ensure IP unicast reachability which is incorrect. >> >> >> >> Cheers, Manav >> >> >> >> On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen wrote: >> >> Hi Greg and all, >> >> >> >> I just have quick review on the drafts. If my understanding is correct, >> the idea is to use multicast destination address other than unicast addr= ess >> when sending BFD packets over LAG links. And actually this idea has bee= n >> proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the >> predecessor of RFC 7130). And at that time, the co-authors of RFC 7130 d= id >> discuss the idea of using multicast destination address, but for some >> reason I forget now(I may need to reiterate the discussions on the >> archive), the idea was abandoned, although I still think multicast >> destination address is a smart idea. >> >> >> >> Best regards, >> >> Mach >> ------------------------------ >> >> *From:* Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [ >> gregory.mirsky@ericsson.com] >> *Sent:* Tuesday, April 05, 2016 6:16 >> *To:* rtg-bfd@ietf.org; mpls@ietf.org >> *Cc:* draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; >> rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas ( >> akatlas@gmail.com) >> *Subject:* Two new drafts on (micro-)BFD over MC-LAG interfaces >> >> Dear All, >> >> two new drafts, related to RFC 7130, were published before the meeting: >> >> =C2=B7 BFD on MC-LAG interfaces in IP network >> >> >> =C2=B7 BFD on MC-LAG interfaces in IP/MPLS network >> >> >> >> >> Greatly appreciate your reviews, comments, questions and suggestions. >> >> >> >> Regards, >> >> Greg >> >> >> >> >> > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --94eb2c07bc900c8772052ffdd182 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Manav,
the update could be in addition of either broadcast or link local multicast= or both with appropriate normative language. But I would not agree that th= ese wouldn't work.
Regards, Greg

On Apr 8, 2016 12:34 PM, "Manav Bhatia"= ; <manavbhatia@gmail.com>= ; wrote:
Hi Greg,

Not sure i understand how it can "up= date RFC 7130". Is that by using a link local mcast IP instead of a Un= icast IP?

We know that, that wouldnt work.

Cheers, Manav

On Fri, Apr 8, 2016 at 9:44 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Reshad,<= /span>

thank you for your commen= ts. Indeed, RFC 7130 is restricted and thus hardly applicable to MC-LAG cas= e. We realize that if this proposal is adopted it not only enhance applicability on u-BFD but will update RFC 7130.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Greg

=C2=A0

From: Reshad R= ahman (rrahman) [mailto:rrahman@cisco.com]
Sent: Friday, April 08, 2016 8:51 AM
To: Manav Bhatia; Gregory Mirsky
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; <= a href=3D"mailto:mpls@ietf.org" target=3D"_blank">mpls@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatl= as@gmail.com); rt= g-bfd@ietf.org; rtg-bfd-chairs@ietf.org


Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces=

=C2=A0

I agree with Manav, and not= hing in RFC7130 seems to preclude using different unicast IP address as des= tination on different member links.

=C2=A0=

Regards,

Reshad (as individual contr= ibutor).

=C2=A0=

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on beha= lf of Manav Bhatia <manavbhatia@gmail.com>
Date: Friday, April 8, 2016 at 11:04 AM
To: Gregory Mirsky <gregory.mirsky@ericsson.com>
Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org<= /a>" <draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org= >, "mpls@ietf.or= g" <mpls@ietf.org&g= t;, "mpls-ch= airs@ietf.org" <mpls-chairs@ietf.org>, "Alia Atlas (akatlas@gmail.com)" <akatlas@gmail.com&= gt;, "rtg-bfd@ietf.o= rg" <rtg-= bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" <rtg-bfd-chairs@ietf.org>
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces=

=C2=A0=

Hi Greg,

=C2=A0=

Why cant different micro-BF= D packets use the IP address of the MC-LAG end points? Ones going to router= 1 will all carry the same unicast IP address. The ones going towards the other router will all carry some other IP address, which= would be configured along with the MC-LAG configs.

=C2=A0=

In fact i would argue that = the u-bfd packets going to different routers must use different IP addresse= s so that you can actually verify the data plane liveliness. Whats the point in sending a contrived IP address if the path that it take= s is different from the other regular packets?

=C2=A0=

Cheers, Manav=

=C2=A0=

On Fri, Apr 8, 2016 at 6:09= PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Manav,

thank you for sharing ins= ight view of discussions around RFC 7130, extremely helpful.

We believe, and Jeff is c= o-author of RFC 7130 too, that MC-LAG presents different case and the compr= omise that you=E2=80=99ve pointed too is justified. We will add more details on = the potential differences between unicast and multicast fast paths in the n= ext update.

We are open to the discus= sion and always welcome comments and alternative proposals.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,=

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Greg

=C2=A0

From: Manav Bhatia [mailto:= manavbhatia@gmail.com]
Sent: Thursday, April 07, 2016 7:39 PM
To: Mach Chen
Cc: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

=C2=A0

I believe it had to do w= ith multicast datapath (especially link local) being different from the uni= cast datapath in most routers. Using link local multicast IP addresses may not necessarily guarantee Unicast IP reachability.=C2=A0<= u>

=C2=A0

When writing 7130 we spe= nt quite a bit of time ensuring that we dont carve out a special data path = for the micro-BFD packets. Using link local would have made it a lot simpler.

=C2=A0

And this is where i thin= k the current proposal is flawed -- they use link local multicast to ensure= IP unicast reachability which is incorrect.

=C2=A0

Cheers, Manav<= /u>

=C2=A0

On Thu, Apr 7, 2016 at 1= 1:16 PM, Mach Chen <mach.chen@huawei.com> wrote:

Hi Greg and all,=

=C2=A0=

I just have quick review on the drafts. If my un= derstanding is correct, the idea is to use multicast destination address ot= her than unicast address when=C2=A0=C2=A0sending BFD packets over LAG links. And actually this idea has been proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00=C2=A0(the prede= cessor of RFC 7130). And at=C2=A0that time, the co-authors of RFC 7130 did = discuss=C2=A0the idea of using multicast destination address, but for some = reason I forget now(I may need to reiterate the discussions on the archive), the idea was abandoned, although I still thin= k multicast destination address is a smart idea.

=C2=A0=

Best regards,=

Mach=C2=A0

From: Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ie= tf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces=

Dear All,<= /span>

two new drafts, related = to RFC 7130, were published before the meeting:

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BFD on MC-LAG interfaces= in IP network

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BFD on MC-LAG interfac= es in IP/MPLS network

=C2=A0

Greatly appreciate your = reviews, comments, questions and suggestions.

=C2=A0

Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg=

=C2=A0

=C2=A0=



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

--94eb2c07bc900c8772052ffdd182--