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

From: Toerless Eckert <[email-masked]>
Date: Tue, 14 Nov 2017 03:42:33 +0100

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

---

From: Leonard Giuliano <[email-masked]>
Date: Wed, 22 Nov 2017 14:38:09 -0800

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:[email-masked]] On Behalf Of Toerless Eckert
| Sent: Monday, November 13, 2017 9:43 PM
| To: [email-masked]
| Cc: [email-masked]
| 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

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 24 Nov 2017 07:30:41 +0100

Hi Lenny,

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.

b) Wrt to your contentions below:

   1) I agree, #1 is covered - for both MVPN SA and rfc4610 register
   messages according to rfc6514, 14.1.

   2) Let first make the argument where MSDP and rfc4610 operate equally:
   when you configure an MSDP mesh group. If all the non-PE RPs in an
   MVPN C domain are either an MSDP mesh group or an rfc4610 RP-set
   (same function, different names), then you could just add some PE
   as members of the MSDP mesh group or the RFC4610 RP-set and that
   would work "fine" without extending rfc6514 14.1, aka: those PEs
   would learn active C (S,G) and distribute it to all other PE, and
   they would not need to send any (S,G) SA/register messages back to the
   non-PE mesh group/rp-set because those RPs already have all state
   they need. And, as your draft says, as soon as you add more than
   one PE this way, you have multiple PEs that will send to all other
   PEs all active C (S,G) state info. And its kinda difficult to figure
   out how much redundancy one wants to set up that way.

   So, the model that i thought your draft meant to establish is one
   where you would avoid having to build a mesh-group/RP-set across all
   non-PE RPs in a large network:

   You would logically have a per-MVPN-site mesh-group/RP-set between
   the PEs of that site (one or more) and one or more non-PE RP. 
   Whenenver a PE receives an MVPN SA that comes from another site,
   it would forward it to the other non-PE members of this mesh-group/RP-set,
   and your new draft section 3 would permit this type of source check
   (i am not completeley through understanding that part of your draft).

   So, that would be a very scaleable setup as soon as you have
   non-PE RPs in the MVPN.

   3) MSDP of course has setup options not shared with rfc6410, aka:
   any setup that is more than a mesh-group. If you intended for the
   draft to also apply to such cases, 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).

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.

   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 ?

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 24 Nov 2017 14:26:39 +0000

Hi Toerless,

> -----Original Message-----
> From: BESS [mailto:[email-masked]] On Behalf Of Toerless Eckert
> Sent: Friday, November 24, 2017 1:31 AM
> To: Lenny Giuliano <[email-masked]>
> Cc: MBONED WG <[email-masked]>; Toerless Eckert <[email-masked]>;
> [email-masked]
> Subject: Re: [bess] bess: draft-zzhang-bess-mvpn-msdp-sa-interoperation
> 
> Hi Lenny,
> 

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.

>    out how much redundancy one wants to set up that way.

Correct.

>    non-PE RPs in a large network:

Not to "avoid" -- just to make it work (better) -- when there is no such mesh-group/RP-set across all non-PE RPs, by making all RP-PEs into an MSDP mesh-group of their own (though replacing MSDP session with BGP-MVPN session).

>    the PEs of that site (one or more) and one or more non-PE RP.

And the RP-PEs will be in their own "core" mesh.

>    draft to also apply to such cases,

Yes.

>    it would be great to give

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.

>    starting from section 2 to illustrate your text example PE1, PE2

Sure.

>    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

> _______________________________________________
> BESS mailing list
> [email-masked]
> 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=

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 24 Nov 2017 16:21:49 +0100

> 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.

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.

[...]

> 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…

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

-- 
---
[email-masked]