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

[Tim Chown <[e-mail]>]

Hi,

> On 2 Feb 2016, at 23:16, Leonard Giuliano <[e-mail]> wrote:
> 
> 
> 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.

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

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