Subject: [MBONED] Draft revised charter description

From: Hiroshi Ohta <[email-masked]>
Date: Fri, 07 Dec 2007 07:10:45 +0900

Working Group:

I uploaded a draft revised charter description to

http://www3.ietf.org/proceedings/07dec/slides/mboned-5.pdf

Please have a look and post your comments if you have any.  We 
will ask for approval after reflecting ML discussion.

Best regards,
Hiroshi and Marshall

_______________________________________________
MBONED mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mboned

---

From: "Andy Kessler (kessler)" <[email-masked]>
Date: Fri, 7 Dec 2007 10:27:10 -0800

Hiroshi, 

Thanks for sending this out. Overall it looks good. 
I have two comments. 

1. Regularize IPv4 Multicast Address Practice

   Do you want to use the word standardize here ? 

   Or maybe something like: 

   Document IPv4 Multicast Address Practices 
   
   or even:

   Define IPv4 Multicast Address Practices

2. Multicast management
 
   Please add:

   - Have a standard RFC for IP Multicast MIB for IPv4 and IPv6

Thanks, 

Andy

> -----Original Message-----
> From: Hiroshi Ohta [mailto:[email-masked]] 
> Sent: Thursday, December 06, 2007 2:11 PM
> To: [email-masked]
> Subject: [MBONED] Draft revised charter description
> 
> Working Group:
> 
> Please have a look and post your comments if you have any.  
> We will ask for approval after reflecting ML discussion.
> 
> Best regards,
> Hiroshi and Marshall
>

---

From: "Andy Kessler (kessler)" <[email-masked]>
Date: Fri, 7 Dec 2007 10:27:10 -0800

Hiroshi, 

   Or maybe something like: 

   or even:

2. Multicast management
 
   Please add:

Thanks, 

Andy

---

From: Hiroshi Ohta <[email-masked]>
Date: Tue, 11 Dec 2007 10:38:20 +0900

Andy,

Thank you for your comments.  See my response in-line...

Best regards,
Hiroshi

>    Define IPv4 Multicast Address Practices

I think "Document IPv4 Multicast Address Practices" fits well.

>    - Have a standard RFC for IP Multicast MIB for IPv4 and IPv6

OK.

---

From: Hiroshi Ohta <[email-masked]>
Date: Tue, 11 Dec 2007 10:38:20 +0900

Andy,

Best regards,
Hiroshi

OK.

---

From: Leonard Giuliano <[email-masked]>
Date: Wed, 12 Dec 2007 09:27:07 -0800 (PST)

I do not think that MVPNs should be added to the charter of this WG.  
MBONED has always been focused on the deployment issues of multicast on 
the global Internet, not a general all-purpose multicast operational forum 
(hence, the name MBONED as opposed to something like MCAST-OPS).

The difference in this case is more than just semantic- the issues that 
face MVPNs have little to nothing in common with the issues of Mcast over 
the Global Internet (MOGI) that this WG has always focused on.  MOGI is 
concerned with building and maintaining state between sourcing and 
receiving hosts over the global Internet.  In the case of MVPNs, this is 
the easy part and can be taken for granted- MVPNs add no new 
considerations here.  The primary issues regarding MVPNs concern building 
tunnels between provider edge routers to transport customer VPN mcast 
traffic across a provider VPN network.  These router-router tunnels (P2MP 
GRE, P2MP MPLS, etc) have little to no applicability to MOGI.  Much of the 
control-plane protocol extensions used to build and utilize these tunnels 
(BGP, RSVP, etc) have little to no applicability to MOGI.  Where there is 
overlap (eg, PIM used to create PTMP GRE tunnels for MDTs), MVPNs add no 
new considerations.  But where the considerable differences lay, the 
control plane and data plane mechanisms of MVPNs bear little to no 
resemblance to what weve always done in MOGI.  In the case of the Next-Gen 
MVPN solution that the L3VPN WG has consensus, the mechanisms look far 
more like VPNs than mcast as we know it (decoupled data and control 
planes, BGP for exchanging mcast state and maintaining neighbors, label 
stacking, etc).  For this reason, I believe L3VPN WG should continue to 
handle MVPNs, and we should continue to focus on MOGI.

There is plenty of precedent here.  When issues of multicast in mobile 
environments have arisen, they have generally been more germane to 
mobility than multicast.  When our input and expertise has been sought, 
the issues and concerns have been introduced into MBONED.  However, the 
work has been done in the relevant mobility working groups.  I think we 
should take this same approach with MVPNs.  Let the relevant WGs that have 
the expertise in VPN environments continue to work on this, and where our 
input is desired, or when updates as to what solutions have been agreed 
upon are necessary, they can be presented to MBONED.  Otherwise, why stop 
at MVPNs?  Why not just take on all operational issues related to 
multicast, be they Mobile, L2VPNs, PWs, MPLS, etc?

The main reason it seems to be adding MVPNs to our charter and going 
beyond the focus of MOGI that MBONED has always had is that a handful of 
people simply do not like some of the solutions that the L3VPN WG has 
agreed upon.  This is not an assertion, but rather has been stated 
explicitly and openly on this mailing list in the past.  In any event, 
this is not a good reason to add MVPNs to our charter.  We should also 
keep in mind that we are not talking about 1 draft here.  Adding MVPNs to 
the charter would open the floodgates for a bunch of MVPN drafts that 
could create competing standards with WGs better focused on issues related 
to VPNs.  Getting mcast deployed on the global Internet is tough enough- I 
see no reason to unnecessarily take on the headaches of other WGs.

Thanks,
Lenny

On Fri, 7 Dec 2007, Hiroshi Ohta wrote:

-) Working Group:
-) 
-) I uploaded a draft revised charter description to
-) 
-) http://www3.ietf.org/proceedings/07dec/slides/mboned-5.pdf
-) 
-) Please have a look and post your comments if you have any.  We 
-) will ask for approval after reflecting ML discussion.
-) 
-) Best regards,
-) Hiroshi and Marshall
-) 
-) 
-) 
-) 
-) _______________________________________________
-) MBONED mailing list
-) [email-masked]
-) https://www1.ietf.org/mailman/listinfo/mboned
-)

---

From: Leonard Giuliano <[email-masked]>
Date: Wed, 12 Dec 2007 09:27:07 -0800 (PST)

Thanks,
Lenny

-) Working Group:
-)

---

From: "John Meylor (jmeylor)" <[email-masked]>
Date: Wed, 12 Dec 2007 12:20:49 -0800

Hiroshi and Marshall,

This looks very good.

 John Meylor

---

From: "John Meylor (jmeylor)" <[email-masked]>
Date: Wed, 12 Dec 2007 12:20:49 -0800

Hiroshi and Marshall,

This looks very good.

 John Meylor

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Wed, 12 Dec 2007 21:22:08 +0100

even if some of the concerns expressed are valid (in part. BGP for
exchanging mcast state), they are independent of the MBONED work.
indeed, deltas in protocols are/should have been be discussed in the
protocol/VPN working groups themselves where they have been defined.
MBONED from this perspective can provide for experience/lessons learned
from implementing and deploying multicast routing protocols   

now, when reading the first line of the charter, it states:

"The MBONE Deployment Working Group is a forum for coordinating the
deployment, engineering, and operation of multicast routing protocols
and procedures in IP based networks including the global Internet." 

you seem to infer that such statement is only valid if the protocol set
is unique and exclusively applicable in the global Internet          

but this sentence explicitly says -- including -- and not exclusively
for the global Internet. in addition, it does not refer to a specific
set of protocols and/or procedures.

in brief, the charter itself does not prevent including topics on
multicast in VPN context. in particular, it is a suitable place to
discuss MVPN using PIM with GRE tunnels deployments.  

-d.

> From: Leonard Giuliano [mailto:[email-masked]] 
> Sent: Wednesday, December 12, 2007 6:27 PM
> To: [email-masked]
> Subject: Re: [MBONED] Draft revised charter description
> 
>

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Wed, 12 Dec 2007 21:22:08 +0100

-d.

---

From: Leonard Giuliano <[email-masked]>
Date: Wed, 12 Dec 2007 12:29:47 -0800 (PST)

Good point, and to clarify I suggest keeping the current wording of the 
charter:

"The MBONE Deployment Working Group is a forum for coordinating the 
deployment, engineering, and operation of multicast routing protocols and 
procedures in the global Internet."

On Wed, 12 Dec 2007, PAPADIMITRIOU Dimitri wrote:

-) even if some of the concerns expressed are valid (in part. BGP for
-) exchanging mcast state), they are independent of the MBONED work.
-) indeed, deltas in protocols are/should have been be discussed in the
-) protocol/VPN working groups themselves where they have been defined.
-) MBONED from this perspective can provide for experience/lessons learned
-) from implementing and deploying multicast routing protocols   
-) 
-) now, when reading the first line of the charter, it states:
-) 
-) "The MBONE Deployment Working Group is a forum for coordinating the
-) deployment, engineering, and operation of multicast routing protocols
-) and procedures in IP based networks including the global Internet." 
-) 
-) you seem to infer that such statement is only valid if the protocol set
-) is unique and exclusively applicable in the global Internet          
-) 
-) but this sentence explicitly says -- including -- and not exclusively
-) for the global Internet. in addition, it does not refer to a specific
-) set of protocols and/or procedures.
-) 
-) in brief, the charter itself does not prevent including topics on
-) multicast in VPN context. in particular, it is a suitable place to
-) discuss MVPN using PIM with GRE tunnels deployments.  
-) 
-) -d.
-) 
-) 
-) 
-) 
-) > -----Original Message-----
-) > From: Leonard Giuliano [mailto:[email-masked]] 
-) > Sent: Wednesday, December 12, 2007 6:27 PM
-) > To: [email-masked]
-) > Subject: Re: [MBONED] Draft revised charter description
-) > 
-) > 
-) > I do not think that MVPNs should be added to the charter of this WG.  
-) > MBONED has always been focused on the deployment issues of 
-) > multicast on 
-) > the global Internet, not a general all-purpose multicast 
-) > operational forum 
-) > (hence, the name MBONED as opposed to something like MCAST-OPS).
-) > 
-) > The difference in this case is more than just semantic- the 
-) > issues that 
-) > face MVPNs have little to nothing in common with the issues 
-) > of Mcast over 
-) > the Global Internet (MOGI) that this WG has always focused 
-) > on.  MOGI is 
-) > concerned with building and maintaining state between sourcing and 
-) > receiving hosts over the global Internet.  In the case of 
-) > MVPNs, this is 
-) > the easy part and can be taken for granted- MVPNs add no new 
-) > considerations here.  The primary issues regarding MVPNs 
-) > concern building 
-) > tunnels between provider edge routers to transport customer VPN mcast 
-) > traffic across a provider VPN network.  These router-router 
-) > tunnels (P2MP 
-) > GRE, P2MP MPLS, etc) have little to no applicability to MOGI. 
-) >  Much of the 
-) > control-plane protocol extensions used to build and utilize 
-) > these tunnels 
-) > (BGP, RSVP, etc) have little to no applicability to MOGI.  
-) > Where there is 
-) > overlap (eg, PIM used to create PTMP GRE tunnels for MDTs), 
-) > MVPNs add no 
-) > new considerations.  But where the considerable differences lay, the 
-) > control plane and data plane mechanisms of MVPNs bear little to no 
-) > resemblance to what weve always done in MOGI.  In the case of 
-) > the Next-Gen 
-) > MVPN solution that the L3VPN WG has consensus, the mechanisms 
-) > look far 
-) > more like VPNs than mcast as we know it (decoupled data and control 
-) > planes, BGP for exchanging mcast state and maintaining 
-) > neighbors, label 
-) > stacking, etc).  For this reason, I believe L3VPN WG should 
-) > continue to 
-) > handle MVPNs, and we should continue to focus on MOGI.
-) > 
-) > There is plenty of precedent here.  When issues of multicast 
-) > in mobile 
-) > environments have arisen, they have generally been more germane to 
-) > mobility than multicast.  When our input and expertise has 
-) > been sought, 
-) > the issues and concerns have been introduced into MBONED.  
-) > However, the 
-) > work has been done in the relevant mobility working groups.  
-) > I think we 
-) > should take this same approach with MVPNs.  Let the relevant 
-) > WGs that have 
-) > the expertise in VPN environments continue to work on this, 
-) > and where our 
-) > input is desired, or when updates as to what solutions have 
-) > been agreed 
-) > upon are necessary, they can be presented to MBONED.  
-) > Otherwise, why stop 
-) > at MVPNs?  Why not just take on all operational issues related to 
-) > multicast, be they Mobile, L2VPNs, PWs, MPLS, etc?
-) > 
-) > The main reason it seems to be adding MVPNs to our charter and going 
-) > beyond the focus of MOGI that MBONED has always had is that a 
-) > handful of 
-) > people simply do not like some of the solutions that the L3VPN WG has 
-) > agreed upon.  This is not an assertion, but rather has been stated 
-) > explicitly and openly on this mailing list in the past.  In 
-) > any event, 
-) > this is not a good reason to add MVPNs to our charter.  We 
-) > should also 
-) > keep in mind that we are not talking about 1 draft here.  
-) > Adding MVPNs to 
-) > the charter would open the floodgates for a bunch of MVPN drafts that 
-) > could create competing standards with WGs better focused on 
-) > issues related 
-) > to VPNs.  Getting mcast deployed on the global Internet is 
-) > tough enough- I 
-) > see no reason to unnecessarily take on the headaches of other WGs.
-) > 
-) > 
-) > Thanks,
-) > Lenny
-) > 
-) > 
-) > On Fri, 7 Dec 2007, Hiroshi Ohta wrote:
-) > 
-) > -) Working Group:
-) > -) 
-) > -) I uploaded a draft revised charter description to
-) > -) 
-) > -) http://www3.ietf.org/proceedings/07dec/slides/mboned-5.pdf
-) > -) 
-) > -) Please have a look and post your comments if you have any.  We 
-) > -) will ask for approval after reflecting ML discussion.
-) > -) 
-) > -) Best regards,
-) > -) Hiroshi and Marshall
-) > -) 
-) > -) 
-) > -) 
-) > -) 
-) > -) _______________________________________________
-) > -) MBONED mailing list
-) > -) [email-masked]
-) > -) https://www1.ietf.org/mailman/listinfo/mboned
-) > -) 
-) > 
-) > 
-) > _______________________________________________
-) > MBONED mailing list
-) > [email-masked]
-) > https://www1.ietf.org/mailman/listinfo/mboned
-) > 
-)

---

From: Leonard Giuliano <[email-masked]>
Date: Wed, 12 Dec 2007 12:29:47 -0800 (PST)

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 13 Dec 2007 04:28:56 +0100

then, i suggest one does a reality check. mcast routing protocols are
also being deployed in MVPNs (in part. PIM with GRE tunnels). this is a
fact.

from that perspective, the newly proposed charter looks very good to me.

-d.

> Sent: Wednesday, December 12, 2007 9:30 PM
> To: PAPADIMITRIOU Dimitri
> Cc: [email-masked]
> Subject: RE: [MBONED] Draft revised charter description
> 
>

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 13 Dec 2007 04:28:56 +0100

-d.

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 13 Dec 2007 07:49:18 -0800 (PST)

Actually, I did address that.  While PIM is certainly used in the 
provider network to create router-router P2MP GRE tunnels, 
these have no applicability to MOGI.  Further, these tunnels are sometimes 
setup using a BGP SSM-SAFI, which provides the source for tunnel setup.  
This has even less applicability to MOGI.

But even if there were more applicability to the work we've always done, 
the question remains why now should we expand the charter to MVPNs when 
for over a decade MBONED has focused on multicast deployment on the 
MBONE?

If all it takes is the existence of mcast routing protocols like PIM or 
group membership protocols like IGMP, then why not expand the charter to 
include mobile environments, L2VPNs, L2PWs, enterprises, video distr, 
financials, walled gardens, etc?  MVPNs have been alive in production 
networks for at least 5 years now, why all of the sudden is MBONED being 
expanded outside of the global Internet just to accomodate this one 
technology?

Other than the existence a new solution in the L3VPN WG for MVPNs, what's 
changed in 5 years?

On Thu, 13 Dec 2007, PAPADIMITRIOU Dimitri wrote:

-) then, i suggest one does a reality check. mcast routing protocols are
-) also being deployed in MVPNs (in part. PIM with GRE tunnels). this is a
-) fact.
-) 
-) from that perspective, the newly proposed charter looks very good to me.
-) 
-) -d.
-) 
-) > -----Original Message-----
-) > From: Leonard Giuliano [mailto:[email-masked]] 
-) > Sent: Wednesday, December 12, 2007 9:30 PM
-) > To: PAPADIMITRIOU Dimitri
-) > Cc: [email-masked]
-) > Subject: RE: [MBONED] Draft revised charter description
-) > 
-) > 
-) > Good point, and to clarify I suggest keeping the current 
-) > wording of the 
-) > charter:
-) > 
-) > "The MBONE Deployment Working Group is a forum for coordinating the 
-) > deployment, engineering, and operation of multicast routing 
-) > protocols and 
-) > procedures in the global Internet."
-) > 
-) > 
-) > On Wed, 12 Dec 2007, PAPADIMITRIOU Dimitri wrote:
-) > 
-) > -) even if some of the concerns expressed are valid (in part. BGP for
-) > -) exchanging mcast state), they are independent of the MBONED work.
-) > -) indeed, deltas in protocols are/should have been be 
-) > discussed in the
-) > -) protocol/VPN working groups themselves where they have 
-) > been defined.
-) > -) MBONED from this perspective can provide for 
-) > experience/lessons learned
-) > -) from implementing and deploying multicast routing protocols   
-) > -) 
-) > -) now, when reading the first line of the charter, it states:
-) > -) 
-) > -) "The MBONE Deployment Working Group is a forum for coordinating the
-) > -) deployment, engineering, and operation of multicast 
-) > routing protocols
-) > -) and procedures in IP based networks including the global 
-) > Internet." 
-) > -) 
-) > -) you seem to infer that such statement is only valid if the 
-) > protocol set
-) > -) is unique and exclusively applicable in the global 
-) > Internet          
-) > -) 
-) > -) but this sentence explicitly says -- including -- and not 
-) > exclusively
-) > -) for the global Internet. in addition, it does not refer to 
-) > a specific
-) > -) set of protocols and/or procedures.
-) > -) 
-) > -) in brief, the charter itself does not prevent including topics on
-) > -) multicast in VPN context. in particular, it is a suitable place to
-) > -) discuss MVPN using PIM with GRE tunnels deployments.  
-) > -) 
-) > -) -d.
-) > -) 
-) > -) 
-) > -) 
-) > -) 
-) > -) > -----Original Message-----
-) > -) > From: Leonard Giuliano [mailto:[email-masked]] 
-) > -) > Sent: Wednesday, December 12, 2007 6:27 PM
-) > -) > To: [email-masked]
-) > -) > Subject: Re: [MBONED] Draft revised charter description
-) > -) > 
-) > -) > 
-) > -) > I do not think that MVPNs should be added to the charter 
-) > of this WG.  
-) > -) > MBONED has always been focused on the deployment issues of 
-) > -) > multicast on 
-) > -) > the global Internet, not a general all-purpose multicast 
-) > -) > operational forum 
-) > -) > (hence, the name MBONED as opposed to something like MCAST-OPS).
-) > -) > 
-) > -) > The difference in this case is more than just semantic- the 
-) > -) > issues that 
-) > -) > face MVPNs have little to nothing in common with the issues 
-) > -) > of Mcast over 
-) > -) > the Global Internet (MOGI) that this WG has always focused 
-) > -) > on.  MOGI is 
-) > -) > concerned with building and maintaining state between 
-) > sourcing and 
-) > -) > receiving hosts over the global Internet.  In the case of 
-) > -) > MVPNs, this is 
-) > -) > the easy part and can be taken for granted- MVPNs add no new 
-) > -) > considerations here.  The primary issues regarding MVPNs 
-) > -) > concern building 
-) > -) > tunnels between provider edge routers to transport 
-) > customer VPN mcast 
-) > -) > traffic across a provider VPN network.  These router-router 
-) > -) > tunnels (P2MP 
-) > -) > GRE, P2MP MPLS, etc) have little to no applicability to MOGI. 
-) > -) >  Much of the 
-) > -) > control-plane protocol extensions used to build and utilize 
-) > -) > these tunnels 
-) > -) > (BGP, RSVP, etc) have little to no applicability to MOGI.  
-) > -) > Where there is 
-) > -) > overlap (eg, PIM used to create PTMP GRE tunnels for MDTs), 
-) > -) > MVPNs add no 
-) > -) > new considerations.  But where the considerable 
-) > differences lay, the 
-) > -) > control plane and data plane mechanisms of MVPNs bear 
-) > little to no 
-) > -) > resemblance to what weve always done in MOGI.  In the case of 
-) > -) > the Next-Gen 
-) > -) > MVPN solution that the L3VPN WG has consensus, the mechanisms 
-) > -) > look far 
-) > -) > more like VPNs than mcast as we know it (decoupled data 
-) > and control 
-) > -) > planes, BGP for exchanging mcast state and maintaining 
-) > -) > neighbors, label 
-) > -) > stacking, etc).  For this reason, I believe L3VPN WG should 
-) > -) > continue to 
-) > -) > handle MVPNs, and we should continue to focus on MOGI.
-) > -) > 
-) > -) > There is plenty of precedent here.  When issues of multicast 
-) > -) > in mobile 
-) > -) > environments have arisen, they have generally been more 
-) > germane to 
-) > -) > mobility than multicast.  When our input and expertise has 
-) > -) > been sought, 
-) > -) > the issues and concerns have been introduced into MBONED.  
-) > -) > However, the 
-) > -) > work has been done in the relevant mobility working groups.  
-) > -) > I think we 
-) > -) > should take this same approach with MVPNs.  Let the relevant 
-) > -) > WGs that have 
-) > -) > the expertise in VPN environments continue to work on this, 
-) > -) > and where our 
-) > -) > input is desired, or when updates as to what solutions have 
-) > -) > been agreed 
-) > -) > upon are necessary, they can be presented to MBONED.  
-) > -) > Otherwise, why stop 
-) > -) > at MVPNs?  Why not just take on all operational issues 
-) > related to 
-) > -) > multicast, be they Mobile, L2VPNs, PWs, MPLS, etc?
-) > -) > 
-) > -) > The main reason it seems to be adding MVPNs to our 
-) > charter and going 
-) > -) > beyond the focus of MOGI that MBONED has always had is that a 
-) > -) > handful of 
-) > -) > people simply do not like some of the solutions that the 
-) > L3VPN WG has 
-) > -) > agreed upon.  This is not an assertion, but rather has 
-) > been stated 
-) > -) > explicitly and openly on this mailing list in the past.  In 
-) > -) > any event, 
-) > -) > this is not a good reason to add MVPNs to our charter.  We 
-) > -) > should also 
-) > -) > keep in mind that we are not talking about 1 draft here.  
-) > -) > Adding MVPNs to 
-) > -) > the charter would open the floodgates for a bunch of 
-) > MVPN drafts that 
-) > -) > could create competing standards with WGs better focused on 
-) > -) > issues related 
-) > -) > to VPNs.  Getting mcast deployed on the global Internet is 
-) > -) > tough enough- I 
-) > -) > see no reason to unnecessarily take on the headaches of 
-) > other WGs.
-) > -) > 
-) > -) > 
-) > -) > Thanks,
-) > -) > Lenny
-) > -) > 
-) > -) > 
-) > -) > On Fri, 7 Dec 2007, Hiroshi Ohta wrote:
-) > -) > 
-) > -) > -) Working Group:
-) > -) > -) 
-) > -) > -) I uploaded a draft revised charter description to
-) > -) > -) 
-) > -) > -) http://www3.ietf.org/proceedings/07dec/slides/mboned-5.pdf
-) > -) > -) 
-) > -) > -) Please have a look and post your comments if you have 
-) > any.  We 
-) > -) > -) will ask for approval after reflecting ML discussion.
-) > -) > -) 
-) > -) > -) Best regards,
-) > -) > -) Hiroshi and Marshall
-) > -) > -) 
-) > -) > -) 
-) > -) > -) 
-) > -) > -) 
-) > -) > -) _______________________________________________
-) > -) > -) MBONED mailing list
-) > -) > -) [email-masked]
-) > -) > -) https://www1.ietf.org/mailman/listinfo/mboned
-) > -) > -) 
-) > -) > 
-) > -) > 
-) > -) > _______________________________________________
-) > -) > MBONED mailing list
-) > -) > [email-masked]
-) > -) > https://www1.ietf.org/mailman/listinfo/mboned
-) > -) > 
-) > -) 
-) > 
-)

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 13 Dec 2007 07:49:18 -0800 (PST)

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 13 Dec 2007 09:26:28 -0800

Dimitri,

> discuss MVPN using PIM with GRE tunnels deployments.  

For the discussion "MVPN using PIM with GRE tunnels" to be useful
requires expertise in 2547 VPNs.

And such expertise is *not* in MBONED, but in L3VPN WG.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 13 Dec 2007 09:26:28 -0800

Dimitri,

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 13 Dec 2007 09:27:05 -0800

Lenny,

> procedures in the global Internet."

Agreed.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 13 Dec 2007 09:27:05 -0800

Lenny,

Agreed.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 13 Dec 2007 09:28:59 -0800

Dimitri,

> also being deployed in MVPNs (in part. PIM with GRE tunnels). this is a

Yes, but it does not mean that MBONED has to work on this.

> from that perspective, the newly proposed charter looks very good to me.

Multicast routing protocols also being deployed in VPLS. Should the
WG include work on this as well ?

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 13 Dec 2007 09:28:59 -0800

Dimitri,

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 13 Dec 2007 09:34:07 -0800

Lenny,

> explicitly and openly on this mailing list in the past.  

And here are the relevant e-mails:

>From MikeMcBride (Cisco) e-mail to mboned on 2/20:

   What can/should we do in MBONED to prevent the L3VPN WG from
   further delaying documentation of a well known and accepted
   solution while it works on incomplete options?

>From John Meylor (Cisco) e-mail to mboned on 2/21:

   So really the focus and concern of the MBONED and IETF should
   be how to move L3VPN wg forward toward standardization of the
   mVPN GRE solution.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 13 Dec 2007 09:34:07 -0800

Lenny,

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 13 Dec 2007 09:35:38 -0800

Lenny,

> (hence, the name MBONED as opposed to something like MCAST-OPS).

Agreed (for the reasons you mentioned below).

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 13 Dec 2007 09:35:38 -0800

Lenny,

Yakov.

---

From: John Zwiebel <[email-masked]>
Date: Thu, 13 Dec 2007 09:46:36 -0800

FWIW:

As someone who thinks that the VPN "solutions" being discussed are  
stupid.

I find it rather disingenuous for you to work so hard to stand in the
way of MVPNs through this purely political procedure.

---

From: John Zwiebel <[email-masked]>
Date: Thu, 13 Dec 2007 09:46:36 -0800

FWIW:

---

From: Beau Williamson <[email-masked]>
Date: Thu, 13 Dec 2007 12:05:10 -0600

>And such expertise is *not* in MBONED, but in L3VPN WG.
Yakov,

I'm sorry but that is simply fallacious and in many way 
insulting.  It is like saying that MBONED should not be concerned 
about Multicast over Ethernet since it requires expertise in IEEE 
802.3 protocols and such expertise is not in MBONED.

I could make the same argument about requiring Multicast expertise to 
do mVPN and such expertise *not* being in L3VPN WG. (Especially given 
the foot dragging on a well known and documented mVPN solution but 
that's just my personal opinion.)

Now if you want to argue which WG charter best covers MVPN, then that 
is fine but it is insulting to folks in the MBONED WG to make such statements.

Personally I don't think that this topic has to be EXCLUSIVELY 
associated within a single WG given the huge overlap of technologies.

Beau Williamson

---

From: Beau Williamson <[email-masked]>
Date: Thu, 13 Dec 2007 12:05:10 -0600

Yakov,

Beau Williamson

---

From: "John Meylor (jmeylor)" <[email-masked]>
Date: Thu, 13 Dec 2007 10:34:32 -0800

Dimitri, Hiroshi, Marshall, 

 I agree, the new charter looks good, and adding "in IP based networks"
may better describe the historical scope under which we've always
operated.  

 I also agree that arbitrarily restricting this scope and WG discussions
now (under old or new charter) doesn't reflect the reality of how ip
multicast deployments work.

 Further, MBONED as chartered from day-one (ie "coordinating the
deployment") has always provided deployment review and input to all
other WGs throughout the IETF regarding any protocol work which might be
associated with ip multicast deployments.   This role has always been
seen as a positive contribution to other working groups since they don't
have the ip multicast deployment expertise of MBONED, and because they
end up with proposals which are more likely to work within the context
of real end-end ip multicast deployments.

 I'm not sure why we would restrict this scope or role now for any
arbitrary subset of the problem space.

 john

> From: PAPADIMITRIOU Dimitri 
> [mailto:[email-masked]] 
> Sent: Wednesday, December 12, 2007 7:29 PM
> To: Leonard Giuliano
> Cc: [email-masked]
> then, i suggest one does a reality check. mcast routing 
> protocols are also being deployed in MVPNs (in part. PIM with 
> GRE tunnels). this is a fact.
> 
> > and procedures in the global Internet."
> > 
> >

---

From: "John Meylor (jmeylor)" <[email-masked]>
Date: Thu, 13 Dec 2007 10:34:32 -0800

john

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 13 Dec 2007 15:03:17 -0500

In message <[email-masked]
>multicast deployments work.

The scope of the working group should be restricted (not arbitrarily)
to the deployment of IETF standards track protocols and not the
broader reality of multicast deployments that include protocols
that never made it through the standarization process.

I don't think this necessarily conflicts with what you say but just
clarifies it.

Thanks,
Tom

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 13 Dec 2007 15:03:17 -0500

Thanks,
Tom

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 13 Dec 2007 13:58:18 -0800 (PST)

On Thu, 13 Dec 2007, John Meylor (jmeylor) wrote:

-) Dimitri, Hiroshi, Marshall, 
-) 
-)  I agree, the new charter looks good, and adding "in IP based networks"
-) may better describe the historical scope under which we've always
-) operated.  
-) 

John- could you provide some examples?  I can't recall any document that 
MBONED has adopted that didn't involve in some way connecting to or being 
applicable to the global Internet.

I totally agree that providing input and review for other WGs is a 
positive and is appropriate.  However, adopting WG documents goes well 
beyond that.  And creating competing standards is a negative.

-)  I also agree that arbitrarily restricting this scope and WG discussions
-) now (under old or new charter) doesn't reflect the reality of how ip
-) multicast deployments work.
-) 
-)  Further, MBONED as chartered from day-one (ie "coordinating the
-) deployment") has always provided deployment review and input to all
-) other WGs throughout the IETF regarding any protocol work which might be
-) associated with ip multicast deployments.   This role has always been
-) seen as a positive contribution to other working groups since they don't
-) have the ip multicast deployment expertise of MBONED, and because they
-) end up with proposals which are more likely to work within the context
-) of real end-end ip multicast deployments.
-) 
-)  I'm not sure why we would restrict this scope or role now for any
-) arbitrary subset of the problem space.
-) 
-)  john
-) 
-) > -----Original Message-----
-) > From: PAPADIMITRIOU Dimitri 
-) > [mailto:[email-masked]] 
-) > Sent: Wednesday, December 12, 2007 7:29 PM
-) > To: Leonard Giuliano
-) > Cc: [email-masked]
-) > Subject: RE: [MBONED] Draft revised charter description
-) > 
-) > then, i suggest one does a reality check. mcast routing 
-) > protocols are also being deployed in MVPNs (in part. PIM with 
-) > GRE tunnels). this is a fact.
-) > 
-) > from that perspective, the newly proposed charter looks very 
-) > good to me.
-) > 
-) > -d.
-) > 
-) > > -----Original Message-----
-) > > From: Leonard Giuliano [mailto:[email-masked]]
-) > > Sent: Wednesday, December 12, 2007 9:30 PM
-) > > To: PAPADIMITRIOU Dimitri
-) > > Cc: [email-masked]
-) > > Subject: RE: [MBONED] Draft revised charter description
-) > > 
-) > > 
-) > > Good point, and to clarify I suggest keeping the current wording of 
-) > > the
-) > > charter:
-) > > 
-) > > "The MBONE Deployment Working Group is a forum for coordinating the 
-) > > deployment, engineering, and operation of multicast routing 
-) > protocols 
-) > > and procedures in the global Internet."
-) > > 
-) > > 
-) > > On Wed, 12 Dec 2007, PAPADIMITRIOU Dimitri wrote:
-) > > 
-) > > -) even if some of the concerns expressed are valid (in 
-) > part. BGP for
-) > > -) exchanging mcast state), they are independent of the MBONED work.
-) > > -) indeed, deltas in protocols are/should have been be 
-) > > discussed in the
-) > > -) protocol/VPN working groups themselves where they have 
-) > > been defined.
-) > > -) MBONED from this perspective can provide for 
-) > > experience/lessons learned
-) > > -) from implementing and deploying multicast routing protocols   
-) > > -) 
-) > > -) now, when reading the first line of the charter, it states:
-) > > -) 
-) > > -) "The MBONE Deployment Working Group is a forum for 
-) > coordinating the
-) > > -) deployment, engineering, and operation of multicast 
-) > > routing protocols
-) > > -) and procedures in IP based networks including the global 
-) > > Internet." 
-) > > -) 
-) > > -) you seem to infer that such statement is only valid if the 
-) > > protocol set
-) > > -) is unique and exclusively applicable in the global 
-) > > Internet          
-) > > -) 
-) > > -) but this sentence explicitly says -- including -- and not 
-) > > exclusively
-) > > -) for the global Internet. in addition, it does not refer to 
-) > > a specific
-) > > -) set of protocols and/or procedures.
-) > > -) 
-) > > -) in brief, the charter itself does not prevent including topics on
-) > > -) multicast in VPN context. in particular, it is a 
-) > suitable place to
-) > > -) discuss MVPN using PIM with GRE tunnels deployments.  
-) > > -) 
-) > > -) -d.
-) > > -) 
-) > > -) 
-) > > -) 
-) > > -) 
-) > > -) > -----Original Message-----
-) > > -) > From: Leonard Giuliano [mailto:[email-masked]] 
-) > > -) > Sent: Wednesday, December 12, 2007 6:27 PM
-) > > -) > To: [email-masked]
-) > > -) > Subject: Re: [MBONED] Draft revised charter description
-) > > -) > 
-) > > -) > 
-) > > -) > I do not think that MVPNs should be added to the charter 
-) > > of this WG.  
-) > > -) > MBONED has always been focused on the deployment issues of 
-) > > -) > multicast on 
-) > > -) > the global Internet, not a general all-purpose multicast 
-) > > -) > operational forum 
-) > > -) > (hence, the name MBONED as opposed to something like 
-) > MCAST-OPS).
-) > > -) > 
-) > > -) > The difference in this case is more than just semantic- the 
-) > > -) > issues that 
-) > > -) > face MVPNs have little to nothing in common with the issues 
-) > > -) > of Mcast over 
-) > > -) > the Global Internet (MOGI) that this WG has always focused 
-) > > -) > on.  MOGI is 
-) > > -) > concerned with building and maintaining state between 
-) > > sourcing and 
-) > > -) > receiving hosts over the global Internet.  In the case of 
-) > > -) > MVPNs, this is 
-) > > -) > the easy part and can be taken for granted- MVPNs add no new 
-) > > -) > considerations here.  The primary issues regarding MVPNs 
-) > > -) > concern building 
-) > > -) > tunnels between provider edge routers to transport 
-) > > customer VPN mcast 
-) > > -) > traffic across a provider VPN network.  These router-router 
-) > > -) > tunnels (P2MP 
-) > > -) > GRE, P2MP MPLS, etc) have little to no applicability to MOGI. 
-) > > -) >  Much of the 
-) > > -) > control-plane protocol extensions used to build and utilize 
-) > > -) > these tunnels 
-) > > -) > (BGP, RSVP, etc) have little to no applicability to MOGI.  
-) > > -) > Where there is 
-) > > -) > overlap (eg, PIM used to create PTMP GRE tunnels for MDTs), 
-) > > -) > MVPNs add no 
-) > > -) > new considerations.  But where the considerable 
-) > > differences lay, the 
-) > > -) > control plane and data plane mechanisms of MVPNs bear 
-) > > little to no 
-) > > -) > resemblance to what weve always done in MOGI.  In the case of 
-) > > -) > the Next-Gen 
-) > > -) > MVPN solution that the L3VPN WG has consensus, the mechanisms 
-) > > -) > look far 
-) > > -) > more like VPNs than mcast as we know it (decoupled data 
-) > > and control 
-) > > -) > planes, BGP for exchanging mcast state and maintaining 
-) > > -) > neighbors, label 
-) > > -) > stacking, etc).  For this reason, I believe L3VPN WG should 
-) > > -) > continue to 
-) > > -) > handle MVPNs, and we should continue to focus on MOGI.
-) > > -) > 
-) > > -) > There is plenty of precedent here.  When issues of multicast 
-) > > -) > in mobile 
-) > > -) > environments have arisen, they have generally been more 
-) > > germane to 
-) > > -) > mobility than multicast.  When our input and expertise has 
-) > > -) > been sought, 
-) > > -) > the issues and concerns have been introduced into MBONED.  
-) > > -) > However, the 
-) > > -) > work has been done in the relevant mobility working groups.  
-) > > -) > I think we 
-) > > -) > should take this same approach with MVPNs.  Let the relevant 
-) > > -) > WGs that have 
-) > > -) > the expertise in VPN environments continue to work on this, 
-) > > -) > and where our 
-) > > -) > input is desired, or when updates as to what solutions have 
-) > > -) > been agreed 
-) > > -) > upon are necessary, they can be presented to MBONED.  
-) > > -) > Otherwise, why stop 
-) > > -) > at MVPNs?  Why not just take on all operational issues 
-) > > related to 
-) > > -) > multicast, be they Mobile, L2VPNs, PWs, MPLS, etc?
-) > > -) > 
-) > > -) > The main reason it seems to be adding MVPNs to our 
-) > > charter and going 
-) > > -) > beyond the focus of MOGI that MBONED has always had is that a 
-) > > -) > handful of 
-) > > -) > people simply do not like some of the solutions that the 
-) > > L3VPN WG has 
-) > > -) > agreed upon.  This is not an assertion, but rather has 
-) > > been stated 
-) > > -) > explicitly and openly on this mailing list in the past.  In 
-) > > -) > any event, 
-) > > -) > this is not a good reason to add MVPNs to our charter.  We 
-) > > -) > should also 
-) > > -) > keep in mind that we are not talking about 1 draft here.  
-) > > -) > Adding MVPNs to 
-) > > -) > the charter would open the floodgates for a bunch of 
-) > > MVPN drafts that 
-) > > -) > could create competing standards with WGs better focused on 
-) > > -) > issues related 
-) > > -) > to VPNs.  Getting mcast deployed on the global Internet is 
-) > > -) > tough enough- I 
-) > > -) > see no reason to unnecessarily take on the headaches of 
-) > > other WGs.
-) > > -) > 
-) > > -) > 
-) > > -) > Thanks,
-) > > -) > Lenny
-) > > -) > 
-) > > -) > 
-) > > -) > On Fri, 7 Dec 2007, Hiroshi Ohta wrote:
-) > > -) > 
-) > > -) > -) Working Group:
-) > > -) > -) 
-) > > -) > -) I uploaded a draft revised charter description to
-) > > -) > -) 
-) > > -) > -) http://www3.ietf.org/proceedings/07dec/slides/mboned-5.pdf
-) > > -) > -) 
-) > > -) > -) Please have a look and post your comments if you have 
-) > > any.  We 
-) > > -) > -) will ask for approval after reflecting ML discussion.
-) > > -) > -) 
-) > > -) > -) Best regards,
-) > > -) > -) Hiroshi and Marshall
-) > > -) > -) 
-) > > -) > -) 
-) > > -) > -) 
-) > > -) > -) 
-) > > -) > -) _______________________________________________
-) > > -) > -) MBONED mailing list
-) > > -) > -) [email-masked]
-) > > -) > -) https://www1.ietf.org/mailman/listinfo/mboned
-) > > -) > -) 
-) > > -) > 
-) > > -) > 
-) > > -) > _______________________________________________
-) > > -) > MBONED mailing list
-) > > -) > [email-masked]
-) > > -) > https://www1.ietf.org/mailman/listinfo/mboned
-) > > -) > 
-) > > -) 
-) > > 
-) > 
-) > 
-) > _______________________________________________
-) > MBONED mailing list
-) > [email-masked]
-) > https://www1.ietf.org/mailman/listinfo/mboned
-) > 
-) 
-) 
-) _______________________________________________
-) MBONED mailing list
-) [email-masked]
-) https://www1.ietf.org/mailman/listinfo/mboned
-)

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 13 Dec 2007 13:58:18 -0800 (PST)

---

From: "John Meylor (jmeylor)" <[email-masked]>
Date: Thu, 13 Dec 2007 16:15:27 -0800

Tom, 

> From: Tom Pusateri [mailto:[email-masked]] 
> Sent: Thursday, December 13, 2007 12:03 PM
> To: John Meylor (jmeylor)
> Cc: PAPADIMITRIOU Dimitri; Hiroshi Ohta; Marshall Eubanks; 
> [email-masked]
> In message 
> <[email-masked]
> >
> > I also agree that arbitrarily restricting this scope and WG 
> >discussions now (under old or new charter) doesn't reflect 
> the reality 
> >of how ip multicast deployments work.
> 
> The scope of the working group should be restricted (not 
> arbitrarily) to the deployment of IETF standards track 
> protocols and not the broader reality of multicast 
> deployments that include protocols that never made it through 
> the standarization process.
> 
> I don't think this necessarily conflicts with what you say 
> but just clarifies it.

I think that is a good and useful clarification.

>From this, it would be in scope to discuss deployment experience with
PIM + GRE based mVPNs, as mVPNs based on these RFC'd protocols are
included in the active standards-track proposal
(draft-ietf-l3vpn-2547bis-mcast-05.txt).

But from this same clarification, we should note in MBONED discussions
or documents that any such pre-standards deployment experience may not
necessarily reflect final standards work.  This is in line with mVPN
deployment authors intent which is to document pre-standard experience,
not imply a standard.

 john

---

From: "John Meylor (jmeylor)" <[email-masked]>
Date: Thu, 13 Dec 2007 16:15:27 -0800

Tom, 

 john

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 14 Dec 2007 05:56:36 -0800

John,

> (draft-ietf-l3vpn-2547bis-mcast-05.txt).

Deployment experience, as documented in draft-ycai-mboned-mvpn-pim-deploy,
refers to the technology that is *not* included in
draft-ietf-l3vpn-2547bis-mcast-05.txt.  Quoting
draft-ycai-mboned-mvpn-pim-deploy:

    the document, where the term "MVPN" is used, the
    reference is to the original MVPN deployment based upon the Rosen-08

And Rosen-08 is *not* included in draft-ietf-l3vpn-2547bis-mcast-05.txt
(e.g., while Rosen-08 mandates such mechanisms as MDT-SAFI and BGP
Connector attribute, neither of these are even mentioned in
draft-ietf-l3vpn-2547bis-mcast-05.txt).
  
> necessarily reflect final standards work.  

And therefore the WG should not spend its time on such discussions/documents.

> This is in line with mVPN

This is in line with the efforts by mVPN deployment authors to market 
draft-rosen-08 and use MBONED as a marketing avenue for doing this.
As you said yourself in your e-mail to mboned on 2/21:

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 14 Dec 2007 05:56:36 -0800

John,

  

Yakov.

---

From: "Greg Shepherd" <[email-masked]>
Date: Fri, 14 Dec 2007 06:19:40 -0800

> draft-ietf-l3vpn-2547bis-mcast-05.txt).

Derailing this a bit here..

Why are they not mentioned in draft-ietf-l3vpn-2547bis-mcast-05.txt?
It clearly represents the largest population of MVPN deployments but
yet l3vpn removed it from the standards track draft? Please educate me
with a non-political, technical response. Thanks.

Greg

---

From: "Greg Shepherd" <[email-masked]>
Date: Fri, 14 Dec 2007 06:19:40 -0800

Greg

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 14 Dec 2007 18:54:43 +0100

yakov, 

> From: Yakov Rekhter [mailto:[email-masked]] 
> Sent: Friday, December 14, 2007 2:57 PM
> Cc: [email-masked]; PAPADIMITRIOU Dimitri

the purpose is to document implementation and deployment experience
using indeed what can be referred to as a "pre-standard" like any other
intermediate WG I-D based implementation. the doc is clear about this
(see abstract).
  
no one claims it is the ultimate solution (neither any RFC can do
anyway). but certain important aspects of the PIM protocol elements that
it documents e.g. in terms of scalability and experience gathered from
deployment and usage are helpful for subsequent
development/implementation using PIM for mVPN and its overall
applicability in other context also. 

> And therefore the WG should not spend its time on such 

documenting such developments is part of the experience learned from a
large community. i read behind your statement: this is not the final
solution why implementation of a pre-standard matters. 

my answer to this is very simple. documenting experimentation and
lessons learned from intermediate steps is important to understand where
obstacles have been encountered to not reproduce them at the next step
and where specification were not adequately documented. certain parts of
that document can also be considered as useful to motivate further
elaboration of protocol mechanism at appropriate WGs.

> draft-rosen-08 and use MBONED as a marketing avenue for doing this.

i do not see such intention as suitable either because i do not consider
MBONED as a "marketing avenue" but at a place where operational feedback
can be obtained from running code and deployments - which at the end the
purpose of the OPS Area.

hope this clarifies the position.
-d.

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 14 Dec 2007 18:54:43 +0100

yakov,