Subject: [MBONED] WG Last Call - draft-ietf-mboned-interdomain-peering-bcp-03

From: Greg Shepherd <[email-masked]>
Date: Wed, 1 Jun 2016 09:23:26 -0700

This email restarts the WG Last Call two week counter for the draft:
draft-ietf-mboned-interdomain-peering-bcp-03

Please read and respond to the list for or against, and any edits or nits.
This two week counter will expire on 14-June.

Chairs

---

From: "TARAPORE, PERCY S" <[email-masked]>
Date: Wed, 1 Jun 2016 17:11:50 +0000

I support the BCP

Percy

From: MBONED [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Wednesday, June 01, 2016 12:23 PM
To: [email-masked]
Subject: [MBONED] WG Last Call - draft-ietf-mboned-interdomain-peering-bcp-03

Please read and respond to the list for or against, and any edits or nits. This two week counter will expire on 14-June.

Chairs

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 1 Jun 2016 19:00:12 +0000

For.

Thanks.

Bert

From: MBONED [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Wednesday, June 01, 2016 12:23
To: [email-masked]
Subject: [MBONED] WG Last Call - draft-ietf-mboned-interdomain-peering-bcp-03

Chairs

---

From: Tim Chown <[email-masked]>
Date: Wed, 1 Jun 2016 22:15:19 +0100

Hi,

> On 1 Jun 2016, at 17:23, Greg Shepherd <[email-masked]> wrote:
> 

My OPS-DIR review comments from February were largely addressed, e.g. the focus on recommending SSM, so I’m happy in that regard, and would vote ‘for’.

The document still seems quite verbose, though I wouldn’t object to it progressing on that basis alone.

Tim

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 3 Jun 2016 11:51:45 +0200 (CEST)

On Wed, 1 Jun 2016, Greg Shepherd wrote:

> Please read and respond to the list for or against, and any edits or 
> nits. This two week counter will expire on 14-June.

Never read it, reading it and writing as I read it:

1. "In the case of inter-domain peering, it is recommended to use only SSM 
protocols."

A reference here would be nice?

3.1. Should there be a reference to some document dscribing BCP for what 
to run on the IX equipment? PIM Snooping for instance? For v4 and v6? Or 
is the term "peering point" used as a "cable" and there is no active 
equipment? No IXP? "peering point" for me is the same as an "Internet 
Exchange". "peering point" here seems to be something else? I would change 
the term to "peering connection" or "private network 
interconnect" or some term that ISPs normally use to describe these.
Doesn't this require running PIM between AD-1 and AD-2 ? There is no 
mention of it... Only MBGP/BGMP.

I have set up multicast (PIM-SM) between operators over for instance AMSIX 
and their dedicated multicast vlan. Netnod does the same, but as far as I 
know, they're using the same vlan, and not a dedicated one.

As far as I can tell, this document doesn't make any differentiation 
between a multiaccess IXP peering connection and a dedicated cable / 
wavelength between two entities. Is there a reason to do so? Is there a 
reason to explicitly in the document say something about that?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "TARAPORE, PERCY S" <[email-masked]>
Date: Mon, 13 Jun 2016 22:03:36 +0000

Hi Mikael,

Thanks for your feedback. Our responses are inline (in red):

Percy & Bob

-----Original Message-----
From: MBONED [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: Friday, June 03, 2016 5:52 AM
To: Greg Shepherd <[email-masked]>
Cc: [email-masked]
Subject: Re: [MBONED] WG Last Call - draft-ietf-mboned-interdomain-peering-bcp-03

protocols."

Percy & Bob: A reference for PIM-SSM (RFC 4607) is listed in the previous sentence. We believe that should be sufficient.

Percy & Bob: Your questions seem to indicate that the mechanics of HOW a peering point (or peering connection as you call it) is setup should be included here. We state in our Scope and Assumptions (see bullet list at the end of page 3 - first bullet):

o        Administrative Domain 1 (AD-1) is enabled with native multicast. A peering point exists between AD-1 and AD-2.

Our contention is that a peering point (or connection) has been previously setup and is up and running. HOW that has been done (the method of doing so) is not in scope for this BCP. Given that such a peering point is available, the scope then deals with the practices of what two Administrative Domains (AD) need to do to deliver multicast-based services from AD-1 to AD-2.

--

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

_______________________________________________

MBONED mailing list

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

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 25 Jun 2016 09:08:53 +0200 (CEST)

> Percy & Bob: A reference for PIM-SSM (RFC 4607) is listed in the previous sentence. We believe that should be sufficient.

My point was more a "citation needed" for the "recommended" part. Why is 
this recommended?

> Percy & Bob: Your questions seem to indicate that the mechanics of HOW a 
> peering point (or peering connection as you call it) is setup should be 
> included here. We state in our Scope and Assumptions (see bullet list at 
> the end of page 3 - first bullet):
>
>
>
> Our contention is that a peering point (or connection) has been 
> previously setup and is up and running. HOW that has been done (the 
> method of doing so) is not in scope for this BCP. Given that such a 
> peering point is available, the scope then deals with the practices of 
> what two Administrative Domains (AD) need to do to deliver 
> multicast-based services from AD-1 to AD-2.

You seem to be missing my point completely. When you put this document in 
the hand of an operator, they'll be very confused. It uses terminology in 
a way that is foreign to a person working operationally with 
interconnections/peerings at an operator, and it completely avoids saying 
anything what would be recommended in case this "peering point" is a 
shared lan at an IXP.

When you say "Peering point" to an operator, they think "IXP" as in a 
shared lan. At least I do, and I'd imagine most others do as well.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sat, 25 Jun 2016 23:08:33 +0000

> shared lan. At least I do, and I'd imagine most others do as well.

I won't speak for traditional operators, but to me a peering point is a router that sits between two different administrative domains. So the document is not confusing. Maybe "peering point" needs an explicit definition, then?

Bert

---

From: "TARAPORE, PERCY S" <[email-masked]>
Date: Thu, 30 Jun 2016 17:29:44 +0000

Mikael,

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.

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 terminology internally and with external sources with no discernible confusion. Regardless of how we word this (peering point, peering connection, or whatever), our main point is that a peering mechanism exists between operators of two domains. Given that, our goal and scope is to describe the needed best practices to enable the delivery of content via multicast between the two domain operators.

Thanks

Percy & Bob

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]]
Sent: Saturday, June 25, 2016 3:09 AM
To: TARAPORE, PERCY S <[email-masked]>
Cc: Greg Shepherd <[email-masked]>; [email-masked]; SAYKO, ROBERT J <[email-masked]>; NORTZ, DOUG <[email-masked]>
Subject: RE: [MBONED] WG Last Call - draft-ietf-mboned-interdomain-peering-bcp-03

this recommended?

shared lan at an IXP.

--