Subject: Re: [MBONED] [nvo3] NVO3 Multicast Framework

From: Linda Dunbar <[email-masked]>
Date: Mon, 13 Feb 2017 20:30:21 +0000

Dino and Beau,

We just realized that -6 version didn't address this comment thread from you two.

How about we add the following sentences in Section 3.4 "IP multicast in the underlay" right after mentioning BIDIR?

      With PIM Sparse Mode (PIM-SM), the number of flows required would be (n*g), where n is the number of source NVEs that source packets for the group, and g is the number of groups.  Bidirectional PIM (BIDIR- PIM) would offer better scalability with the number of flows required being g. Unfortunately, many vendors still do not fully support BIDIR or have limitations on its implementation. RFC6831 [RFC6831] has good description of using SSM as an alternative to BIDIR if the VTEP/NVE devices have 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.

Please let us know if this resolution is not Okay with you.

Thanks, Linda

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: 2016年5月24日 13:42
To: Williamson, Beau <[email-masked]>
Cc: Bocci, Matthew (Nokia - GB) <[email-masked]>; MBONED WG <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [nvo3] [MBONED] NVO3 Multicast Framework

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]<mailto:[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-----
> 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]<mailto:[email-masked]>>
> Subject: Re: [MBONED] NVO3 Multicast Framework
>
> 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]<mailto:[email-masked]>> wrote:
>>
>> Hi Dino
>>
>> Could you copy NVO3 on your comments, please?
>>
>> Thanks
>>
>> Matthew
>>
>> From: EXT Dino Farinacci <[email-masked]<mailto:[email-masked]>>
>> Date: Monday, 16 May 2016 at 23:31
>> To: Leonard Giuliano <[email-masked]<mailto:[email-masked]>>
>> Cc: MBONED WG <[email-masked]<mailto:[email-masked]>>, Matthew Bocci <[email-masked]<mailto:[email-masked]>>, Benson Schliesser <[email-masked]<mailto:[email-masked]>>
>> Subject: Re: [MBONED] NVO3 Multicast Framework
>>
>> 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,
>>>
>>> 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])-<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
>>
>
> _______________________________________________
> MBONED mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mboned

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

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 13 Feb 2017 22:00:58 +0000

Dino,

We noticed another comment from you that wasn’t addressed by draft-ietf-nvo3-mcast-framework-06. (We believe this is the last comment from the MBONED peer review process).

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

Since there is no better section in this draft to address this, how about we add a NOTE at the end of the paragraph to emphasize that it may not be the NVE that does the replication if [LIST-Signal-Free] approach is used?

For the support of application-specific multicast traffic, a method similar to that of receiver-sites registration for a particular multicast group described in [LISP-Signal-Free] can be used.  The registrations from different receiver-sites can be merged at the NVA, which can construct a multicast replication-list inclusive of all NVEs to which receivers for a particular multicast group are attached. The replication-list for each specific multicast group is maintained by the NVA. Note: Using LISP-signal-free does not necessarily mean the head-end (i.e. NVE) must do replication. If the mapping database (i.e. NVA) indicates that packets are encapsulated to multicast RLOCs, then there is no replication happening at the NVE.

Please let us know if it is not acceptable.

Thank you very much.

Linda
From: nvo3 [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: 2016年5月24日 14:17
To: Dino Farinacci <[email-masked]>
Cc: Bocci, Matthew (Nokia - GB) <[email-masked]>; MBONED WG <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [nvo3] [MBONED] NVO3 Multicast Framework

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]<mailto:[email-masked]>> wrote:
Sorry, I thought I had. NVo3, see my comments below.

Dino

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