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

From: Leonard Giuliano <[email-masked]>
Date: Tue, 8 Mar 2016 13:09:11 -0800

Thanks, more comments inline

On Mon, 29 Feb 2016, TARAPORE, PERCY S wrote:

| | Sect 3.3. Peering Point Enabled with an AMT
<snipped>
| 
| 
| 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.
| 
| 
| 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.

The fact that AD2 is mcast enabled really is immaterial to the use case if 
the peering isn't enabled.  Again, for all practical purposes, it's no 
different than 3.4.  From the point of the use case, it's a distinction 
without a difference.

AMT is a dynamic tunnel that gets created automatically between 2 IP 
endpoints.  So I wouldn't consider it to be "configured through a peering" 
any more than my smartphone with an AMT GW app could be considered to 
have "AMT configured across the peering points to it's relay."

We may have to agree to disagree here, but I'm struggling to see how AMT 
is a germane use case in a BCP on mcast peering- there are no practical 
networking protocols configured and managed through the peering point- as 
long as there is IP connectivity between Relay and GW, all the protocol 
stuff just happens magically under the covers.

Again, I would be curious to hear what others think about AMT as a use 
case in a peering BCP.

| 
| 
| | Sect 3.5
<snipped>
| 
| 
| 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?

I guess I just don't understand this use case.  In any event, it's again 
no different from the standpoint of the peering point than 3.3 or 3.4.

---

From: "TARAPORE, PERCY S" <[email-masked]>
Date: Tue, 22 Mar 2016 14:46:26 +0000

Hi Lenny,

Thanks for your comments. We can summarize our response very simply by agreeing to disagree with you as you suggest. From our perspective (network operator), we can and HAVE encountered all of the five Use Cases that we describe in the BCP. The implicit assumption here is that there are two administrative domains with an existing peering point previously established between them. The only requirement is that the first domain MUST be multicast enabled. That then allows us to come up with the following scenarios or Use Cases:

1.     Both AD's & the peering point are multicast enabled natively.
2.     Both AD's are multicast enabled but the peering point is not. In which case, the 2 AD's decide to provision a GRE across the previously established peering point to facilitate multicast based delivery.
3.     Same as 2, except the two AD's decide to provision an AMT across the previously established peering point.
4.     AD-2 is not multicast enabled. The two AD's decide to setup multicast delivery by having all End Users on AD-2 receive the multicast stream over several AMT tunnels between the AR in AD-1 and the Gateway client in the End User devices. Depending on the number of End Users, this could result in multiple AMT tunnels across the peering point. The advantages and disadvantages of such a case are outlined in the BCP.
5.     To minimize the number of AMT tunnels, there are sequential cascading tunnels starting from the AR in AD-1 through AD-2 setup. This minimizes capacity usage but adds operational complexity.

Again, we CURRENTLY HAVE ALL FIVE CONFIGURATIONS SETUP between our network and partner networks. Each setup is specific to the discussions that we enter into with the partnering network domain. THEY ALL WORK FINE!!

So yes Lenny, we agree to disagree with you. The latest version of the draft BCP has been uploaded - we have added additional text in the assumptions to make this more explicit.

See you in April

Percy & Bob

-----Original Message-----
From: Leonard Giuliano [mailto:[email-masked]]
Sent: Tuesday, March 08, 2016 4:09 PM
To: TARAPORE, PERCY S <[email-masked]>
Cc: [email-masked]
Subject: RE: FW: [MBONED] WGLC for draft-ietf-mboned-interdomain-peering-bcp (fwd)

<snipped>

|

|

|

|

without a difference.

case in a peering BCP.

|

|

| | Sect 3.5

<snipped>

|

|

| it?