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

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:tjc@ecs.soton.ac.uk]
Sent: Monday, February 08, 2016 6:11 AM
To: Leonard Giuliano
Cc: TARAPORE, PERCY S; mboned@ietf.org
Subject: Re: [MBONED] WGLC for draft-ietf-mboned-interdomain-peering-bcp (fwd)

Hi,

> On 2 Feb 2016, at 23:16, Leonard Giuliano <lenny@juniper.net<mailto:lenny@juniper.net>> 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

> |

> | MBONED@ietf.org<mailto:MBONED@ietf.org<mailto:MBONED@ietf.org%3cmailto:MBONED@ietf.org>>

> |

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

> |

>

> _______________________________________________

> MBONED mailing list

> MBONED@ietf.org<mailto:MBONED@ietf.org>

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