Subject: [MBONED] NVO3 Multicast Framework

From: Leonard Giuliano <[email-masked]>
Date: Thu, 12 May 2016 14:52:30 -0700

MBONED,

The following draft recently went through WG last call in the NVO3 working group:

https://datatracker.ietf.org/doc/draft-ietf-nvo3-mcast-framework/

This doc covers multicast in data center overlay networks.  As you know, 
it is part of our charter in MBONED to provide feedback to other relevant 
working groups.  Please review and send any comments to the NVO3 WG 
mailing list ([email-masked])- all comments will be greatly appreciated by 
NVO3.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 16 May 2016 15:31:38 -0700

I just have one minor comment. Regarding the second paragraph:

Using LISP-signal-free does not mean the head-end must do replication. The draft indicates that a mapping system is used to decide where packets go. If the mapping database indicates that packets are encapsulated to multicast RLOCs, or unicast RLOCs, or both in one set, so be it.

And note if there is a single multicast RLOC, then there is no replication happening at the head-end, just one packet encapsulting multicast in multicast.

So what is written above is true, but it may be associated with an incorrect section title.

Dino

> On May 12, 2016, at 2:52 PM, Leonard Giuliano <[email-masked] <mailto:[email-masked]>> wrote:
> 
> MBONED,
> 
> https://datatracker.ietf.org/doc/draft-ietf-nvo3-mcast-framework/ <https://datatracker.ietf.org/doc/draft-ietf-nvo3-mcast-framework/>
> 
> This doc covers multicast in data center overlay networks.  As you know, it is part of our charter in MBONED to provide feedback to other relevant working groups.  Please review and send any comments to the NVO3 WG mailing list ([email-masked])- all comments will be greatly appreciated by NVO3.
> 
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 16 May 2016 15:31:57 -0700

Dino

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 16 May 2016 22:54:11 +0000

Many of these same issues were addressed over 15-20 years ago now, by the Internetworking over NBMA (ION) working group. Might be worth revisiting some of the solutions from those days, including MARS, RFC 2022, which emulated IP multicast over unicast or ATM-layer multicast virtual circuits.

Bert

From: MBONED [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Monday, May 16, 2016 18:32
To: Leonard Giuliano <[email-masked]>
Cc: MBONED WG <[email-masked]>; Bocci, Matthew (Nokia - GB) <[email-masked]>; Benson Schliesser <[email-masked]>
Subject: Re: [MBONED] NVO3 Multicast Framework

Dino

On May 12, 2016, at 2:52 PM, Leonard Giuliano <[email-masked]<mailto:[email-masked]>> wrote:

MBONED,

This doc covers multicast in data center overlay networks.  As you know, it is part of our charter in MBONED to provide feedback to other relevant working groups.  Please review and send any comments to the NVO3 WG mailing list ([email-masked]<mailto:[email-masked]>)- all comments will be greatly appreciated by NVO3.

_______________________________________________
MBONED mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mboned

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 17 May 2016 07:41:08 +0800

> Many of these same issues were addressed over 15-20 years ago now, by the Internetworking over NBMA (ION) working group. Might be worth revisiting some of the solutions from those days, including M…

Yes I was there. For all of it. Considering all the R&D efforts over that time, what we are doing in LISP is new at the control-plane. At the data-plane there are only 3 ways to achieve forwarding, regular multicast (which BIER is included), head-end-replication, or a combo of both. 

Dino

---

From: Leonard Giuliano <[email-masked]>
Date: Tue, 24 May 2016 07:03:24 -0700

The NVO3 would like to close this out by the end of the month, so if you 
do plan to review and provide comment, please do so by 5/31.

For those who have responded thus far, the NVO3 folks have been greatly 
appreciative.

On Thu, 12 May 2016, Leonard Giuliano wrote:

| MBONED,
| 
| The following draft recently went through WG last call in the NVO3 working
| group:
| 
| https://datatracker.ietf.org/doc/draft-ietf-nvo3-mcast-framework/
| 
| This doc covers multicast in data center overlay networks.  As you know, it is
| part of our charter in MBONED to provide feedback to other relevant working
| groups.  Please review and send any comments to the NVO3 WG mailing list
| ([email-masked])- all comments will be greatly appreciated by NVO3.
| 
|

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 24 May 2016 10:20:50 -0700

Sorry, I thought I had. NVo3, see my comments below.

Dino

> On May 24, 2016, at 6:14 AM, Bocci, Matthew (Nokia - GB) <[email-masked]> wrote:
> 
> Hi Dino
> 
> Could you copy NVO3 on your comments, please?
> 
> Thanks
> 
> Matthew
> 
> From: EXT Dino Farinacci <[email-masked]>
> Date: Monday, 16 May 2016 at 23:31
> Cc: MBONED WG <[email-masked]>, Matthew Bocci <[email-masked]>, Benson Schliesser <[email-masked]>
>> On May 12, 2016, at 2:52 PM, Leonard Giuliano <[email-masked]> wrote:
>> 
>> MBONED,
>>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 24 May 2016 11:42:05 -0700

If a reference to RFC6831 is provided, then there are many details on how an underlay can support ASM, Bidir, and SSM.

Dino

> On May 24, 2016, at 11:35 AM, Williamson, Beau <[email-masked]> wrote:
> 
> I'd like to see Section 3.4, "IP multicast in the underlay" expanded a bit.  
> 
> The section mentions the use of BIDIR for a scalable underlay.  The sad fact is that many vendors still do not fully support BIDIR in their devices (after how many years?) or have limitations on its use that preclude it as a viable option.  I'm no expert in these Underlay sort of DC to DC networks but it seems that SSM would not have that issue since it is basically a subset (and much simpler to implement and configure) of the PIM protocol and would therefore be available in pretty much all vendor devices that support multicast.  The problem is one of Source Discovery of the VTEPs (or, in the case of this draft I think the term is NVE) which would be the sources of the multicast traffic in each TS.
> 
> At the very least, I'd like to see a paragraph discussing the possible use of SSM as an alternative to BIDIR if the VTEP/NVE devices had a way to learn of each other's IP address so that they could join all SSM SPT's to create/maintain an underlay SSM IP Multicast tunnel solution.  This would greatly simplify the configuration and management of the underlay IP Multicast environment.
> 
> I realize that the VTEP/NVE Source Discovery problem is beyond the scope of this Framework document but I'd like to see the above mentioned to possibly encourage more work in this area if it is not already underway.
> 
> 
> Beau Williamson
> CCIE #1346 R/S Emeritus
> Principal Member of Technical Staff
> Corporate Engineering
> metroPCS/T-Mobile
> Internal: 314982
> Office:   469.330.4982
> Mobile:   972.679.4334
> 
> 
> -----Original Message-----
> Sent: Tuesday, May 24, 2016 12:21 PM
> To: Bocci, Matthew (Nokia - GB)
> Cc: MBONED WG; <[email-masked]>

---

From: "Williamson, Beau" <[email-masked]>
Date: Tue, 24 May 2016 18:35:24 +0000

Beau Williamson
CCIE #1346 R/S Emeritus

-----Original Message-----
From: MBONED [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Tuesday, May 24, 2016 12:21 PM
To: Bocci, Matthew (Nokia - GB)
Cc: MBONED WG; <[email-masked]>
Subject: Re: [MBONED] NVO3 Multicast Framework

Dino

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 24 May 2016 12:17:13 -0700

Hi Dino,

Thanks for pointing that out.  Indeed that is not specific to head end
replication.  We can move that text to a separate section that is
referenced by the sections for all of the multicast methods.  Let me know
if that would address the comment.

Thanks,
Anoop

On Tue, May 24, 2016 at 10:20 AM, Dino Farinacci <[email-masked]>
wrote:

> > Cc: MBONED WG <[email-masked]>, Matthew Bocci <
> [email-masked]>, Benson Schliesser <
> [email-masked]>
> > Using LISP-signal-free does not mean the head-end must do replication.
> The draft indicates that a mapping system is used to decide where packets
> go. If the mapping database indicates that packets are encapsulated to
> multicast RLOCs, or unicast RLOCs, or both in one set, so be it.
> >
> > And note if there is a single multicast RLOC, then there is no
> replication happening at the head-end, just one packet encapsulting
> multicast in multicast.
> >
> >> This doc covers multicast in data center overlay networks.  As you
> know, it is part of our charter in MBONED to provide feedback to other
> relevant working groups.  Please review and send any comments to the NVO3
> WG mailing list ([email-masked])- all comments will be greatly appreciated
> by NVO3.
> >>
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 24 May 2016 12:18:17 -0700

I think so Anoop.

Dino

> On May 24, 2016, at 12:17 PM, Anoop Ghanwani <[email-masked]> wrote:
> 
> Hi Dino,
> 
> Thanks for pointing that out.  Indeed that is not specific to head end replication.  We can move that text to a separate section that is referenced by the sections for all of the multicast methods.  Let me know if that would address the comment.
> 
> Thanks,
> Anoop
> 
> On Tue, May 24, 2016 at 10:20 AM, Dino Farinacci <[email-masked]> wrote:

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 24 May 2016 12:35:03 -0700

Thanks Beau & Dino.

We'll add a reference to RFC 6831 and a brief discussion of SSM.

Anoop

On Tue, May 24, 2016 at 11:42 AM, Dino Farinacci <[email-masked]>
wrote:

> If a reference to RFC6831 is provided, then there are many details on how
> an underlay can support ASM, Bidir, and SSM.
>
> Dino
>
> > The section mentions the use of BIDIR for a scalable underlay.  The sad
> fact is that many vendors still do not fully support BIDIR in their devices
> (after how many years?) or have limitations on its use that preclude it as
> a viable option.  I'm no expert in these Underlay sort of DC to DC networks
> but it seems that SSM would not have that issue since it is basically a
> subset (and much simpler to implement and configure) of the PIM protocol
> and would therefore be available in pretty much all vendor devices that
> support multicast.  The problem is one of Source Discovery of the VTEPs
> (or, in the case of this draft I think the term is NVE) which would be the
> sources of the multicast traffic in each TS.
> >
> > At the very least, I'd like to see a paragraph discussing the possible
> use of SSM as an alternative to BIDIR if the VTEP/NVE devices had a way to
> learn of each other's IP address so that they could join all SSM SPT's to
> create/maintain an underlay SSM IP Multicast tunnel solution.  This would
> greatly simplify the configuration and management of the underlay IP
> Multicast environment.
> >
> > I realize that the VTEP/NVE Source Discovery problem is beyond the scope
> of this Framework document but I'd like to see the above mentioned to
> possibly encourage more work in this area if it is not already underway.
> >
> >
> > Beau Williamson
> > CCIE #1346 R/S Emeritus

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 24 May 2016 12:37:03 -0700

Both RFC6831 and draft-ietf-lisp-signal-free describe why SSM is a preferred solution. 

Dino

> On May 24, 2016, at 12:35 PM, Anoop Ghanwani <[email-masked]> wrote:
> 
> Thanks Beau & Dino.
> 
>> On Tue, May 24, 2016 at 11:42 AM, Dino Farinacci <[email-masked]> wrote:

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 24 May 2016 15:37:42 -0700

Hi Dino,

If switch table sizes for IP multicast forwarding are a consideration,
would SSM still be the preferred method?

Thanks,
Anoop

On Tue, May 24, 2016 at 12:37 PM, Dino Farinacci <[email-masked]>
wrote:

>> > On May 24, 2016, at 11:35 AM, Williamson, Beau <
>> [email-masked] <[email-masked]>> wrote:
>> >
>> > I realize that the VTEP/NVE Source Discovery problem is beyond the
>> scope of this Framework document but I'd like to see the above mentioned to
>> WG mailing list ([email-masked])- all comments will be greatly
>> appreciated by NVO3.
>> >>>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 24 May 2016 15:48:16 -0700

> On May 24, 2016, at 3:37 PM, Anoop Ghanwani <[email-masked]> wrote:
> 
> Hi Dino,
> 
> If switch table sizes for IP multicast forwarding are a consideration, would SSM still be the preferred method?

It depends on the number of sources. But an (S,G) and a (*,G), each represent one entry. If you use Bidir, then only (*,G) entries are supported at the expense of longer paths from any source.

The same ole tradeoff.

But for multicast overlays, where the underlay supports multicast, that state in the core can be reduced to the number ITRs (source-VTEP) sending to the ETR (destination-VTEP) group. So, for example,
1000 sources behind ITRa, that sends to many different groups where the same set of ETRb and ETRc have receivers, then only a single (ITRa,G) entry is necessary in the multicast underlay.

Dino

> 
> Thanks,
> Anoop
> 
> On Tue, May 24, 2016 at 12:37 PM, Dino Farinacci <[email-masked]> wrote:

---

From: Truman Boyes <[email-masked]>
Date: Tue, 24 May 2016 22:59:47 +0000

Switch table sizes should always be considered. Current (S,G) scaling on
today's powerful routers are still an issue when rebuilding trees. The
Bidir approach or overlay approach with MC underlay support are good target
architectures to address tree creation/convergence.

//Truman

On Tue, May 24, 2016 at 6:48 PM Dino Farinacci <[email-masked]> wrote:

> It depends on the number of sources. But an (S,G) and a (*,G), each
> represent one entry. If you use Bidir, then only (*,G) entries are
> supported at the expense of longer paths from any source.
>
> The same ole tradeoff.
>
> But for multicast overlays, where the underlay supports multicast, that
> state in the core can be reduced to the number ITRs (source-VTEP) sending
> to the ETR (destination-VTEP) group. So, for example,
> 1000 sources behind ITRa, that sends to many different groups where the
> same set of ETRb and ETRc have receivers, then only a single (ITRa,G) entry
> is necessary in the multicast underlay.
>
> Dino
>
> >
> > Thanks,
> > Anoop
> >
> >> If a reference to RFC6831 is provided, then there are many details on
> how an underlay can support ASM, Bidir, and SSM.
> >>
> >> Dino
> >>
> >> > The section mentions the use of BIDIR for a scalable underlay.  The
> sad fact is that many vendors still do not fully support BIDIR in their
> devices (after how many years?) or have limitations on its use that
> preclude it as a viable option.  I'm no expert in these Underlay sort of DC
> to DC networks but it seems that SSM would not have that issue since it is
> basically a subset (and much simpler to implement and configure) of the PIM
> protocol and would therefore be available in pretty much all vendor devices
> that support multicast.  The problem is one of Source Discovery of the
> VTEPs (or, in the case of this draft I think the term is NVE) which would
> be the sources of the multicast traffic in each TS.
> >> >
> >> > At the very least, I'd like to see a paragraph discussing the
> possible use of SSM as an alternative to BIDIR if the VTEP/NVE devices had
> a way to learn of each other's IP address so that they could join all SSM
> SPT's to create/maintain an underlay SSM IP Multicast tunnel solution.
> This would greatly simplify the configuration and management of the
> underlay IP Multicast environment.
> >> >
> >> >> Using LISP-signal-free does not mean the head-end must do
> replication. The draft indicates that a mapping system is used to decide
> where packets go. If the mapping database indicates that packets are
> encapsulated to multicast RLOCs, or unicast RLOCs, or both in one set, so
> be it.
> >> >>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 24 May 2016 16:08:43 -0700

> Switch table sizes should always be considered. Current (S,G) scaling on today's powerful routers are still an issue when rebuilding trees. The Bidir approach or overlay approach with MC underlay support are good target architectures to address tree creation/convergence. 

Again, the same ole tradeoff, if you want the best (S,G) scaling and no convergence problems in the underlay, then you do head-end-replication at the expense of extra bandwidth from the head-end.

However, with LISP signal-free multicast you can use a core based RTR so there is one copy sent from head-end and the RTR(s) replicate in the core where there is more bandwidth attached on the RTR then there was on the head-end. And you still require no state in the core routers other than the RTR.

The same ole tradeoff, state versus bandwidth.

Dino