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

From: Leonard Giuliano <[email-masked]>
Date: Tue, 2 Feb 2016 15:16:26 -0800

Thanks Percy and Bob.  Regarding the pertinence of the back office 
content, I guess we can agree to disagree.  I'd still be very interested 
to hear what others think about the necessity and scope of this content 
in this doc.

Comments inline:

On Wed, 27 Jan 2016, TARAPORE, PERCY S wrote:

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

If the goal is to acknowledge various protocols are used in ADs, perhaps 
list them all (or at least the ones most commonly used).  And maybe this 
is a good place to recommend SSM for at least interdomain mcast- not sure 
if it's been done in any docs yet.  Proposed text:

"It is understood that several protocols are available by network 
operators for use in each AD including PIM-SM, PIM-SSM, MSDP, IGMP and 
MLD.  In the case of interdomain peering, it is recommended to use only 
SSM protocols."

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

Is AG directly connected to EU over I2?  Or is I2 actually a bunch of 
router hops?  If the former, then for all practical purposes case 3.3 is 
the same as 3.4.  In any event, there is basically no peering going on 
over the peering point- AMT is what you do when peering does not exist.

| Sect 3.5
| 
| -same comments as 3.3
| 
| 
| 
| Our Response: Same response as 3.3

I'm struggling to grasp the practical usefulness of cascading AMT tunnels.  
If AD2 is going through the trouble of building this hierarchy of AMT 
gateway-relays, why not use GRE instead?  Or just go native and not bother 
with AMT if they are so worried about inefficient bw.  Do any AMT 
implementations exist which support these types of gateway-relays??  Has 
anyone ever actually deployed this type of AMT hierarchy???  Suggest just 
sticking to what actually has been deployed in the real world.

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

---

From: Tim Chown <[email-masked]>
Date: Mon, 8 Feb 2016 11:10:44 +0000

Hi,

> On 2 Feb 2016, at 23:16, Leonard Giuliano <[email-masked]> wrote:
> 
> 

I read the draft and have a few comments.

Firstly, I agree about the references to MLD, IGMP and especially MSDP; these are not discussed in the draft, so just focus it on PIM-SSM.

As Lenny says, why not focus it on SSM, as the model that the WG is keen to promote?  This could then be the guidance for sites to do inter-domain SSM well, including AMT support (to the client).  As it stands, PIM-SSM is only listed as a ‘protocol that is available’.

If you really want to make it about PIM-SM, then you need to mention that, keep MSDP, but also add Embedded-RP. But I think there’s strong consensus in mobbed to focus on SSM.

The text itself seems good, but it is quite verbose. It could probably be anything up to 50% shorter, and retain most of the key information. The question is whether there’s  appetite to focus it.  There’s nothing wrong per se, it’s just quite a heavy read when the key messages/use cases could be more succinct.  Having stuff like a security breach implementation plan included seems unnecessary detail, for example.

A terminology section at the start might be nice.

It’s also a reminder that draft-ietf-mboned-mdh-04 is now 16 years old. Somewhere on my list is a plan to speak to Dave about an update :)
(which could also now be more focused on SSM deployment)

Tim

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

---

From: "TARAPORE, PERCY S" <[email-masked]>
Date: Mon, 29 Feb 2016 15:48:14 +0000

Hi Lenny,

Thanks for getting back to us on this. Regarding the 3 remaining points you raised from your email, our response below in red:

Percy & Bob

<trimmed>

|

|

|

|

|

|

|

|

|

|

|

| [RFC4604].

|

|

|

SSM protocols."

Percy & Bob: Thanks Lenny - we accept your draft text and will incorporate it into the next version of the draft I-D

|

|

|

|

|

|

|

|

|

|

|

|

Percy & Bob: Yes AG is directly connected to EU over I2. The point here is that both AD-1 & AD-2 ARE multicast enabled but the peering point is NOT. That is the big difference between this Use Case & 3.4 where AD-2 is NOT multicast enabled. So the peering point has a short AMT configured across between the AR and AD-1 and AG in AD-2. This is a valid Use Case in its own right; we have deployed such configurations in our network. So we do not understand your concern.

| Sect 3.5

|

| -same comments as 3.3

|

|

|

Percy & Bob: Your response here is not clear at all. Note that AD-2 is NOT multicast enabled. You are asking why not simply enable it?? Well that is the operator's choice. Also whether the operator uses one GRE or cascading AMTs, it is still a choice left up to the operator. And YES we have adopted this specific configuration with cascading AMT tunnels linking 2 of our domains and it works very well. Again we list this as a viable option for a possible Use Case. Why do you have an objection to it?

|

|

|

|

|

|

|

|

| |

|

|

|

|

|

|

| | encouraged as well.

|

| |

|

|

| |

|

|

| |

|

|

|

|

| MBONED mailing list

|

| [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>

|

|

---

From: "TARAPORE, PERCY S" <[email-masked]>
Date: Mon, 29 Feb 2016 15:51:38 +0000

Hi Tim,

Thanks for your comments. We just responded to Lenny’s email – we agree with the comments on use of SSM and have accepted Lenny’s draft text for the next version.

Regarding your other comments, we will look through the draft in an effort to try and shorten the amount of text. We will have another version ready in time for the April IETF meeting.

Thanks again,

Percy

-----Original Message-----
From: Tim Chown [mailto:[email-masked]]
Sent: Monday, February 08, 2016 6:11 AM
To: Leonard Giuliano
Cc: TARAPORE, PERCY S; [email-masked]
Subject: Re: [MBONED] WGLC for draft-ietf-mboned-interdomain-peering-bcp (fwd)

Hi,

> On 2 Feb 2016, at 23:16, Leonard Giuliano <[email-masked]<mailto:[email-masked]>> wrote:

Tim

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