Re: WG Last Call - draft-ietf-mboned-interdomain-peering-bcp-03
Tim Chown <tjc <at> ecs.soton.ac.uk>
2016-07-07 15:52:25 GMT
> On 7 Jul 2016, at 16:49, TARAPORE, PERCY S <pt5947 <at> att.com> wrote:
> Thanks Tim,
> Just to be clear - your proposed draft would be a new document correct?
Though it would be rather unlikely to progress to RFC before or at the same time as yours unless we had very
quick consensus on its contents and message. But if it’s not a normative reference you could cite it in
draft form, I believe.
> -----Original Message-----
> From: Tim Chown [mailto:tjc <at> ecs.soton.ac.uk]
> Sent: Thursday, July 07, 2016 11:48 AM
> To: TARAPORE, PERCY S <pt5947 <at> att.com>
> Cc: Mikael Abrahamsson <swmike <at> swm.pp.se>; mboned <at> ietf.org; NORTZ, DOUG <dn2984 <at> att.com>
> Subject: Re: [MBONED] WG Last Call - draft-ietf-mboned-interdomain-peering-bcp-03
>> On 7 Jul 2016, at 16:29, TARAPORE, PERCY S <pt5947 <at> att.com> wrote:
>> OK Mikael,
>> Here's how we plan on resolving your comments.
>> Since Lenny Giuliano had provided the text recommending the use of PIM-SSM, I have asked Lenny to try and
include some additional text illustrating the benefits of PIM-SSM. Tim Chown's response on pointing to
such benefits currently described in RFC 4607 was very helpful.
> Mikael and I have grabbed this issue by the horns and have authored a (very rough) -00 draft of a multicast
service model draft which will allow the WG the opportunity to make a firmer and documented statement on
SSM in the form or an Informational or BCP RFC. We’ll post it on Friday (Lenny is having a look at it). The
chairs have been kind enough to give the draft a short slot in Berlin for discussion.
>> Regarding your comment on the term "peering point", your suggestion to include a sentence describing
what is meant is fine. We have used this term in our dealings with ALL our Service Provider and ISP partners.
In our Service Level Agreements with all our partners, we state that a peering point is a "Location where
traffic is exchanged between two networks". Please indicate if this is sufficient. If not, please
provide additional text and/or alternate text that we can include in the Draft.
>> My request to Lenny and Mikael is to provide their texts/responses before the Berlin IETF meeting (July
18). That will enable us to have a discussion on these changes to the MBONE WG. All other comments in
Mikael's latest email can also be discussed in Berlin.
>> Thank you
>> Percy & Bob
>> -----Original Message-----
>> From: Mikael Abrahamsson [mailto:swmike <at> swm.pp.se]
>> Sent: Sunday, July 03, 2016 3:22 AM
>> To: TARAPORE, PERCY S <pt5947 <at> att.com>
>> Cc: Greg Shepherd <gjshep <at> gmail.com>; mboned <at> ietf.org; SAYKO, ROBERT J <rs1983 <at> att.com>; NORTZ,
DOUG <dn2984 <at> att.com>
>> Subject: RE: [MBONED] WG Last Call - draft-ietf-mboned-interdomain-peering-bcp-03
>> On Thu, 30 Jun 2016, TARAPORE, PERCY S wrote:
>>> Re: your first point about a citation, the text that is currently
>>> adopted is a result of many comments made during the Working Group
>>> meetings as well as previous Last Calls that needed to be resolved by
>>> us. What you see is proposed text that we accepted from one of the
>>> commenters. At this late stage, we do not wish to make changes that may
>>> reignite previous concerns.
>> So you think it's fine that the document makes statements about things
>> that are recommended without any pointers as to why? There is no document
>> to point to that says why PIM-SSM is better than PIM-SM?
>> I have set up PIM-SM with anycast RP with MSDP to multiple large
>> international operators and NRENs. I know why PIM-SSM is beneficial, but
>> another reader might not.
>>> Re: your second point about confusing terminology for operators, please
>>> realize that Bob Sayko and I (two of the lead co-authors of this BCP)
>>> represent AT&T, a rather large operator. We have been using this
>> Well, AT&T is an incumbent telco. A huge one. It's not uncommon for these
>> kinds of companies to have internal terminology that isn't used anywhere
>> else. There are lots of other terms in use today, actually I asked some
>> people who work across different operators and people mentioned NNI, PNI,
>> "Internet exchange point" and multiple other wording.
>> My suggestion is to define "peering point" in the introduction. An
>> additional sentence might be the only thing needed.
>> Another thing, AMT is mentioned 7 times in the document before it's
>> defined in the 8th mention. Also, the reference for AMT points to a draft,
>> not RFC7450, and says it's work in progress (which I hope it no longer
>> Mentions of eBGP, BGMP and MBGP are also done without definition or
>> Mikael Abrahamsson email: swmike <at> swm.pp.se
>> MBONED mailing list
>> MBONED <at> ietf.org
MBONED mailing list
MBONED <at> ietf.org