Subject: [MBONED] WGLC for draft-ietf-mboned-interdomain-peering-bcp

From: Leonard Giuliano <[email-masked]>
Date: Fri, 2 Oct 2015 11:02:43 -0700

We would like to begin working group last call for 
draft-ietf-mboned-interdomain-peering-bcp.  Please post any and all 
comments supporting/opposing the draft to the list by Nov 2.  This draft 
will not be advanced for publication unless there is sufficient response 
and support from the WG.  And, of course, substantive comments on the 
actual draft are strongly encouraged as well.

Most recent version of the draft can be found here:

https://www.ietf.org/id/draft-ietf-mboned-interdomain-peering-bcp-00.txt

---

From: "TARAPORE, PERCY S" <[email-masked]>
Date: Fri, 2 Oct 2015 19:30:17 +0000

I support the draft.

Percy S. Tarapore
AT&T

-----Original Message-----
From: MBONED [mailto:[email-masked]] On Behalf Of Leonard Giuliano
Sent: Friday, October 02, 2015 2:03 PM
To: MBONED WG
Subject: [MBONED] WGLC for draft-ietf-mboned-interdomain-peering-bcp

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

---

From: Leonard Giuliano <[email-masked]>
Date: Fri, 23 Oct 2015 13:40:57 -0700

<speaking as WG member, chair hat off>

Overall, I think the idea of this draft is very useful for anyone 
interested in bringing up mcast peering with other networks.  It certainly 
would have been more useful 10-15 years ago, but better late than never.  
That said, I think this doc needs to be significantly restructured to meet 
the goal of being useful for those entities looking to start mcast 
peering.

The first issue is length.  28 pages almost guarantees those who might 
need it most will probably never read it.  Length alone isn't the problem 
as much as the fact that it really doesn't need to be this long- there 
isn't 28 pages of novel info here.  For example, most, if not all, of 
sections 4-6 could be summed up with a single sentence: "Do whatever you 
are doing for unicast peering."  Unicast peering has been done for 
decades, and all of these issues have been well understood and addressed.  
As such, these sections do little more than "lecturing birds on flying."

In summary, my suggestion is to start over with the goal of answering the 
question, "If I needed to peer with another network to exchange mcast 
traffic, what would I do."  Focus just on the technical issues of mcast 
peering and the relevant protocols.  Decide if you want to cover both ASM 
and SSM (IMO, ASM is the most deployed scenario on the MBONE today, so 
it's wishful thinking to just ignore it, but I am probably in the minority 
on that) or just SSM.  If ASM, talk about PIM-SM, MSDP, MBGP and 
filtering; if SSM, talk about PIM-SSM, MBGP and filtering.  I don't think 
AMT fits in a peering doc as it's more useful in the case where mcast 
peering doesn't exist. Likewise, GRE tunneling is just a special case of 
general peering.  I would totally skip all the back office stuff as that 
seems out of scope and unnecessary. 

Just my opinion and others may disagree, so I'm very curious to hear the 
perspectives of others in the WG.

More specific comments:

Sect 1:    The scope and assumptions for this document are stated as 
follows:

      o It is understood that several protocols are available for this
         purpose including Protocol Independent Multicast - Source
         Specific Multicast (PIM-SSM) [RFC4607], Internet Group
         Management Protocol (IGMP) [RFC4604], Multicast Listener
         Discovery (MLD) [RFC4604], and Multicast Source Discovery
         Protocol (MSDP) [RFC3618]

-this is an odd list of protocols.  First, MLD/IGMP don't typically come 
into play in interdomain peering.  Second, why PIM-SSM *and* MSDP?  Why 
not PIM-SM if mentioning MSDP? 

Sect 3.1:    
   From the perspective of AD-1, the one disadvantage associated with
   native multicast into AD-2 instead of individual unicast to every EU
   in AD-2 is that it does not have the ability to count the number of
   End Users as well as the transmitted bytes delivered to them. 

-Is it common to count end users and individual unicast flows in unicast 
peering?  I imagine aggregate counts of packets/bits is sufficient for 
unicast peering.  Why should mcast be any different?  And FWIW, RFC 6807 
does specify ways to account for replication, not that I am suggesting it, 
though.

Sect 3.2. Peering Point Enabled with GRE Tunnel
-Not clear why it is pertinent technically to differentiate between native 
and GRE tunneled peering.  Either way, you are connecting via some logical 
interface and running an mcast routing protocol through it (PIM).  Whether 
it's a GRE tunnel or a VLAN, routing and the protocols are pretty much the 
same (modulo unicast routing issues to use the tunnel for RPF, but not use 
itself to reach the other tunnel endpoint, but that doesn't seem to be 
mentioned, so I suspect that's not the intent here).

Sect 3.3. Peering Point Enabled with an AMT
-I struggle to grasp the purpose of AMT as a router-router tunnel.  If you 
want a router-router tunnel, why not use GRE?  I understand it's 
theoretically possible, but the whole point of AMT is to enable end hosts 
to tunnel to routers bc GRE isn't a generally available option for 
tunneling hosts to routers.  And I'm not sure I understand how to get RPF 
to work since you can't run a unicast routing protocol through the AMT 
tunnel.  So what would make the PIM joins in AD2 propagate towards AG?  
Either way, AMT doesn't strike me a valid use case for mcast peering.  
AMT is more like what you have to do in the absence of peering.

Sect 3.4 Peering Point Enabled with an AMT - AD-2 Not Multicast Enabled
-Again, this doesn't seem like a perring use case, but rather why AMT is 
necessary in the absence of mcast peering.

Sect 3.5
-same comments as 3.3

On Fri, 2 Oct 2015, Leonard Giuliano wrote:

| 
| We would like to begin working group last call for
| draft-ietf-mboned-interdomain-peering-bcp.  Please post any and all comments
| supporting/opposing the draft to the list by Nov 2.  This draft will not be
| advanced for publication unless there is sufficient response and support from
| the WG.  And, of course, substantive comments on the actual draft are strongly
| encouraged as well.
| 
| Most recent version of the draft can be found here:
| 
| https://www.ietf.org/id/draft-ietf-mboned-interdomain-peering-bcp-00.txt
|