Subject: Re: [MBONED] WGLC for draft-ietf-mboned-interdomain-peering-bcp (fwd)

From: Leonard Giuliano <[email-masked]>
Date: Fri, 22 Jan 2016 13:43:50 -0800

Resending

---------- Forwarded message ----------
Date: Fri, 23 Oct 2015 13:40:57 -0700 (PDT)
From: Leonard Giuliano <[email-masked]>
To: MBONED WG <[email-masked]>
Subject: Re: WGLC for draft-ietf-mboned-interdomain-peering-bcp

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

---

From: "TARAPORE, PERCY S" <[email-masked]>
Date: Wed, 27 Jan 2016 21:44:35 +0000

Lenny,

We are providing our responses to your comments - see inline.

Percy & Bob

peering.

Our Response: Thanks for the complement. We do not agree with the restructuring part - see responses below.

Our Response: This argument about the excessive length has been made repeatedly by you several times. And yet again, we totally disagree with this sentiment as follows:

1.     The intent of this BCP is to offer Service Providers, Content Source Providers, and Third Party Distributors on the potential for distributing video content via multicast across multiple administrative domains. The goal of this BCP is to offer a concise overview of ALL aspects of inter-domain multicast transport for content that covers every possible aspect necessary. We have covered this in 28 pages. We are not aware of any provider that would NOT do business with us just because they may have to read a 28 page document. That is simply an absurd assumption.

2.     Your assertion that sections 4-6 could be summarized by "Do whatever you are doing for unicast peering" is interesting. If that was truly the case, then perhaps there is zero justification for the CDNi Working Group to exist?? The CDNi WG deals exclusively with unicast delivery of content. From their IETF Charter Page:

"The goal of the CDNI Working Group is to allow the interconnection of

separately administered CDNs in support of the end-to-end delivery of

content from CSPs through multiple CDNs and ultimately to end users (via

their respective User Agents). The CDNI WG aims at delivering a

targeted, deployable solution in a short timeframe as

needed by the industry. It is expected that the CDNI interfaces will be

realized using existing IETF protocols for transport and message

exchange, and using existing object notation grammars/languages for the

definition of CDNI objects and semantics."

The key assertion here is NOT that something special needs to be done with unicast; rather the focus is on the communication of necessary information over the interface (or peering point) between administrative domains over which unicast streams will be transported such that ALL aspects of successful delivery of service is achieved. To that end, the CDNi WG has developed and is developing many RFC's to support several critical aspects of service delivery. For example, they have a Logging Interface I-D that is 49 pages in length!! Are you saying that providers would stop CDNi service just because they have to read a 49 page document?? Followed by several other documents of equal or greater length??

Note that our original intent (stated 2 years ago), once this BCP got past Last Call, was to submit it the CDNi WG so they could have a starting basis for developing more detailed specifications on multicast-based content delivery across CDNi's.

3.     Regarding the breakdown in length for sections 4-6, we deleted the previous section 4.4 (Settlements). The remaining sections are as follows in length:

a.     Section 4.1 (Transport & Security):                   1 Page

b.    Section 4.2 (Routing for 5 Use Cases):              4 Pages

c.      Section 4.3 (Provisioning & Logging):             3 Pages

d.    Section 4.4 (Operations):                                    2 Pages

e.     Section 4.5 (Reliability Models):                       0.5 Page

f.       Section 5 (Troubleshooting):                              0.5 Page

g.    Section 6 (Security):                                           0.5 Page

10.5 pages in total - compare to the CDNi Logging Interface I-D of 49 pages!!

Note that Section 5 was created as a response to comments made during the Dallas meeting last year and extended now based on text provided by Dale Garder - there are people who WANT this information.

Our Response: We totally disagree. The Back Office stuff is critical from a Service Provider perspective; these are the nuts and bolts that enable providers to create peering agreements. Again that is evident from the attention that the CDNi WG is paying to this kind of stuff. Specific responses to the protocols, GRE & AMT below.

More specific comments:

follows:

Our Response: There seems to be some confusion here. The intent is not to recommend a specific list of protocols for the peering point. Rather, we say that there are many possible multicast protocols that could be used within each Administrative Domain. The transport of content via multicast over the peering point itself is independent of the choice of protocols deployed in either domain.

Note that we do not support PIM-SM as operators have found it to have too much overhead and it does not scale well. We can also remove MSDP from the list. So one suggestion is to change the paragraph as follows:

It is understood that several protocols are available by network operators for use in each AD including Protocol Independent Multicast - Source Specific Multicast (PIM-SSM) [RFC4607], Internet Group Management Protocol (IGMP) [RFC4604], and Multicast Listener Discovery (MLD) [RFC4604].

If you have a preference for wording this differently, please let us know.

Sect 3.1:

though.

Our Response: Our Content Source Providers want - and need - to know who is getting their content and how much of it. This based on several conversations we have with our Providers. Is it common yet? Perhaps not that much today, but it is certainly going to be more so as content goes inter-domain CDN. Is it done with unicast today? Yes it is. Certainly if content owners want to charge for their product. Also, in the mobility world a network operator might need to know this information because you are on a limited data plan. Things are easier in unicast because the number of EU can directly translate to flows and bytes. And that is the point for including it in multicast-based content delivery.

Our Response: We are submitting this as a different Use Case because in essence, it is different - the peering point is not multicast enabled. Hence we pinup a GRE tunnel across the peering point. There are similarities certainly. And we can phrase the Use Case as "Logical Interface (e.g., GRE or VLAN)" if you so prefer. And we could remove text here that is duplicated from Use Case 3.1 if you so desire. But for completeness, this is a separate Use Case and it needs to stay.

Our Response: Your concern is not clear. We are NOT suggesting a router-router tunnel. We are stating that an AMT tunnel is setup across a previously established peering point to transport multicast-based applications. The focus is not on "peering" as a verb; rather we are setting up an AMT tunnel across an established peering point between 2 AD's. Again, we do not understand the issue. We have setup such tunnels across internal AD's and they work successfully. If you have alternate language that makes this clear, please recommend some text.

Our Response: Same response as 3.3.

Sect 3.5

-same comments as 3.3

Our Response: Same response as 3.3

|

| encouraged as well.

|

|

|

_______________________________________________

MBONED mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/mboned