Re: [bess] bess: draft-zzhang-bess-mvpn-msdp-sa-interoperation

Stig Venaas <stig@venaas.com> Mon, 04 December 2017 22:17 UTC

Return-Path: <stig@venaas.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A787126BF3 for <bess@ietfa.amsl.com>; Mon, 4 Dec 2017 14:17:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-com.20150623.gappssmtp.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 IFlwyDRLBV-m for <bess@ietfa.amsl.com>; Mon, 4 Dec 2017 14:17:45 -0800 (PST)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 467C712785F for <bess@ietf.org>; Mon, 4 Dec 2017 14:17:44 -0800 (PST)
Received: by mail-qt0-x22e.google.com with SMTP id r39so24694235qtr.13 for <bess@ietf.org>; Mon, 04 Dec 2017 14:17:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cKrs0Oh6lDwPr6uEGjXpQLpKM7HHfd1OnvNxw8tqBOM=; b=UyKBzeQk0CBJeECV4xZAhVjS8ekOKOCKFsq8SfUUUJZGOZdAd8cO/ULpyzOU9neUff IIMyCQJCYoK4KSdwO4f2leqhTxD0IKHJpiyIJrIUarBakavUav/vVbX0x/G3CNqlX0De cUo5DCYzkp4WShj4WYRi/1NqxMqZ+YLbX/b8s2pCTQfak3QOGrjBuFPn5KAsOKhHmhRF zc52CekG6yWt3alGbT7Uhu1kyxWGA5pdYFN3CYzJuTW9b1RvZueLVsLiLL8TXcczDHfT +5RCudZfpkhXqG6pvI2QvNWqulYI8uDeT8BAiBrpTqKXvOvax4fTDlIReNWulcyR+kz0 ObzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cKrs0Oh6lDwPr6uEGjXpQLpKM7HHfd1OnvNxw8tqBOM=; b=fwx4/y8tTGVrxgAac8z7OCMqOVXKJbb1JfomZOEXONb5FQ6T0w+Vum7erGJC12efNJ IgWS+47CV4IL3UzpNWJb6qUf5Dy5JmD/lPI6r6tNQzNM42ylbjk8K4urxTqtmJwpK+u6 Xa7yb2yM1xmgmdpyFxfmuFFiwd6VqXVdfxxeCUkiYrEJAdbUq6MdQL5Csz617sd8rIP/ W7vnA8ZBdOuIcERsnUcEs6jC/BPu8h/GHlpcS6RwFjAiGRnWAFjJ43zTtY0P/fhvTnOD S3W6BikpC6O91V3cfK9DE05buCpcMUvWeLCJAvufXabwSYblzp8CdffbkLYU+ddE6ePX WVig==
X-Gm-Message-State: AKGB3mKGHDlhJl23PlQJGeZKBpo4TbVIjxBDiZFMRE4XEyDvFlW0NfkD UD5BfW9um3ilTilJzi3GuJ1pZAlqQ2j2ZaPeH0p3NQ==
X-Google-Smtp-Source: AGs4zMaZo8gsuZhko6ltIqaEIS9R7Jmh/kbXa46M/a5WFJ75SWkHvuRJHwQlCoMVuo4eyWixhL0i8eVFssWc0PiZx2k=
X-Received: by 10.55.72.66 with SMTP id v63mr20925996qka.92.1512425863233; Mon, 04 Dec 2017 14:17:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.20.81 with HTTP; Mon, 4 Dec 2017 14:17:42 -0800 (PST)
In-Reply-To: <20171124152148.GB21793@faui40p.informatik.uni-erlangen.de>
References: <20171114024232.GF19390@faui40p.informatik.uni-erlangen.de> <DM5PR05MB31456805323BF32267D6BBEAD4200@DM5PR05MB3145.namprd05.prod.outlook.com> <alpine.DEB.2.02.1711221417300.10112@svl-jtac-lnx02.juniper.net> <20171124063041.GA21793@faui40p.informatik.uni-erlangen.de> <DM5PR05MB31452E571F227E67EEC50C95D4260@DM5PR05MB3145.namprd05.prod.outlook.com> <20171124152148.GB21793@faui40p.informatik.uni-erlangen.de>
From: Stig Venaas <stig@venaas.com>
Date: Mon, 04 Dec 2017 14:17:42 -0800
Message-ID: <CAHANBtJEaWqQ9hDiM0pyWAH4Trip99HNq1-jePF24OWn6ziGAg@mail.gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Cc: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, MBONED WG <mboned@ietf.org>, Toerless Eckert <tte+ietf@cs.fau.de>, Lenny Giuliano <lenny@juniper.net>, "bess@ietf.org" <bess@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/YTYA61f74WNyhIU6V7OMSLLi-d8>
Subject: Re: [bess] bess: draft-zzhang-bess-mvpn-msdp-sa-interoperation
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Dec 2017 22:17:48 -0000

Hi

On Fri, Nov 24, 2017 at 7:21 AM, Toerless Eckert <tte@cs.fau.de> wrote:
> On Fri, Nov 24, 2017 at 02:26:39PM +0000, Jeffrey (Zhaohui) Zhang wrote:
>> > a) I was asking Jeffrey in the WG meeting if he saw any difference
>> >    between MSDP and 4610 wrt. to the applicability of your draft, and
>> >    he also said no (as i think too), thats where this originated.
>>
>> On the spot I did make a mistake that I thought with 4610 the RPs would propagate registers (received from a C-RP) to another :-) Lenny caught that.

Isn't that exactly what 4610 does though? Any register received by one
RP in the anycast RP set, is replicated and sent to each of the other
routers in the set.

Stig

> Ok. But the fact that it does not just means tht 4610 just acts like
> an MSDP mesh group, and your draft is equally applicable to MSDP mesh
> groups and therefore equally to 4610 (IMHO).
>
> In fact, as soon as you have a setup that is not equivalent to
> a mesh group, considerations for MSDP become more difficult.
>
> [...]
>
>> >    it would be great to give
>> >    examples of the so tht one can check if/how the proposed spec in your
>> >    draft would work in the fce of those cases existing MSDP RPF rules
>> >    (which can of course be quite complex).
>>
>> Yes more text would help. The idea is that MVPN SA messages would just be treated as MSDP SAs from the PE that originated the SAs. Those MSDP SAs received from true MSDP peers and those treated as MSDP SAs would follow the existing MSDP rules.
>
> Right. But the problem is when you have non-PE RPs running MSDP
> without mesh group, so the MSDP connectivity is set up with the assumption
> that some of the RPF rules apply to avid looping MSDP SAs. Now you introduce
> an MVPN core represented in that MSDP SA RPF loop prevention, and
> you need to look how that will work.
>
> I have not tried to imagine any such complex non-mesh-group seteup
> because i have not see this in the real world. If you have, then it would
> be great to explain that example in the draft. But if you have any
> such example from the real world, i think we have a more fundamental
> problem:
>
> If there are really future important non-mesh group MSDP + MVPN examples,
> that can not be converted better to mesh groups, then we have the
> fundamental problem that we have no solution (yet) how to solve
> such setup requirements with IPv6. Because we don't have MSDP there.
> And we established it can't be converted to mesh-group. Aka: can't
> be replaced with 6410.
>
> So, i would suggest the draft distinguishes between mesh-group
> and non-mesh-group MSDP setups. For the mesh-group setups, it should
> be defined to work equally for MSDP and 6410. For the non-mesh group
> setup we shuold vet whether that case is declared to be "non-relevant/
> non-supported" because we have no evidence of need in real-world... OR
> we have to solve another IPv6 issue.
>
> Cheer
>     Toerless
>
>> >
>> > 3) Btw: It would be good if you would add some picture to your draft
>> >    starting from section 2 to illustrate your text example PE1, PE2
>> >    and so on.
>>
>> Sure.
>>
>> >
>> >    Also, your draft says:
>> >
>> >      [RFC6514] only specifies that a PE receiving the MVPN SA routes, say
>> >      PE2, will advertise (C-S,C-G) C-multicast routes if it has
>> >      corresponding (C-*,C-G) state learnt from its CE
>> >
>> >    can you point me to the text in 6514 that says that ?
>>
>> The full text is the following:
>>
>> 14.2.  Receiver(s) within a Site
>>
>>    ...
>>
>>    When (as a result of receiving PIM messages from one of its CEs) a PE
>>    creates, in one of its MVPN-TIBs, a (new) (C-*,C-G) entry with a non-
>>    empty outgoing interface list that contains one or more PE-CE
>>    interfaces, the PE MUST check if it has any matching Source Active
>>    A-D routes.  If there is one or more such matching routes, and the
>>    best path to C-S carried in the matching route(s) is reachable
>>    through some other PE, then for each such route the PE MUST originate
>>    a Source Tree Join C-multicast route.  If there is one or more such
>>    matching routes, and the best path to C-S carried in the matching
>>    route(s) is reachable through a CE connected to the PE, then for each
>>    such route the PE MUST originate a PIM Join (C-S,C-G) towards the CE.
>>
>>    When, as a result of receiving a new Source Active A-D route, a PE
>>    updates its VRF with the route, the PE MUST check if the newly
>>    received route matches any (C-*,C-G) entries.  If there is a matching
>>    entry, and the best path to C-S carried in the (A-D) route is
>>    reachable through some other PE, the PE MUST originate a Source Tree
>>    Join C-multicast route for the (C-S,C-G) carried by the route.  If
>>    there is a matching entry, and the best path to C-S carried in the
>>    (A-D) route is reachable through a CE connected to the PE, the PE
>>    MUST originate a PIM Join (C-S,C-G) towards the CE.
>>
>> Jeffrey
>>
>> >
>> > Cheers
>> >     Toerless
>> >
>> > On Wed, Nov 22, 2017 at 02:38:09PM -0800, Leonard Giuliano wrote:
>> > > Toerless,
>> > >
>> > > Thanks for the comments.  After thinking about your feedback on RFC4610 a
>> > > bit, I'm not sure that case is applicable here.  Consider the 2 directions
>> > > of interworking:
>> > >
>> > > 1) MSDP SA/AnycastRP_PIM_Register -> MVPN SA
>> > >
>> > > 2) MVPN SA -> MSDP SA/AnycastRP_PIM_Register
>> > >
>> > > As I understand, #1 is already covered by RFC6513/6514.  #2 is the missing
>> > > piece that this draft attempts to address.  I don't believe #2 will be
>> > > applicable for RFC4610, as these registers only go to members of the RP
>> > > set.  And the RP set should be configured on all the C-RPs.  It wouldn't
>> > > make much sense to have these registers transit the MVPN domain to go to
>> > > an AnycastRP not in the configured RP set.
>> > >
>> > > Hope this is clear, and let me know if I'm missing anything.
>> > >
>> > > -Lenny
>> > >
>> > > | -----Original Message-----
>> > > | From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Toerless Eckert
>> > > | Sent: Monday, November 13, 2017 9:43 PM
>> > > | To: bess@ietf.org
>> > > | Cc: mboned@ietf.org
>> > > | Subject: [bess] bess: draft-zzhang-bess-mvpn-msdp-sa-interoperation
>> > > |
>> > > | Jeffrey presented subject draft in mboned. Given how i am
>> > > | not usually tracking BESS WG mailing list and may not be around:
>> > > |
>> > > | I would like to see subject draft to be adopted as a WG document in BESS
>> > > | and become an update to RFC6514 (not to say bugfix ;-).
>> > > |
>> > > | Feeedback detail: The draft should be amended to fix the same problem
>> > not only for
>> > > | MSDP SA but also RFC4610 and probably accordingly change the draft
>> > name.
>> > > |
>> > > | Cross-posted to mboned (sorry) because there where a couple of MBoned
>> > > | participants expressing support for the draft in BESS and may like me not
>> > > | be BESS regulars.
>> > > |
>> > > | Cheers
>> > > |     Toerless
>> >
>> > --
>> > ---
>> > tte@cs.fau.de
>> >
>> > _______________________________________________
>> > BESS mailing list
>> > BESS@ietf.org
>> > https://urldefense.proofpoint.com/v2/url?u=https-
>> > 3A__www.ietf.org_mailman_listinfo_bess&d=DwICAg&c=HAkYuh63rsuhr6Scbf
>> > h0UjBXeMK-
>> > ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
>> > m=hQz-NA6r7ahWKqMy6aI7ZXX5lvGX1ubRovr3Co5_VNE&s=rC5k8JOSHYD-
>> > XaNaPGxhtl-yyDQhzqd909XjwXnS5EI&e=
>
> --
> ---
> tte@cs.fau.de
>
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess