Re: What should we do next?

[ycai <ycai at cisco.com>]

Here is what I think.

1. There are many pieces that an SP can use to build a network offering MVPN
services,  ranging from PE-PE signaling, the transport (and its signaling)
mechanism in the core, to the various optimization schemes suitable for the
above.   I personally don't believe there will be *one* solution that can
fit all the requirements, or even the representative ones.

As such,  I support the approach using profiles to describe, within each
profile, the minimum interop requirement.  The WG will indeed be challenged
to figure out the interop between certain profiles, or between certain
elements of the relevant profiles.  But this can't possibly be a surprise to
anyone.  The challenge is already in front of us with or without the
profiles.   

This leads to my second comment.

2. One reason we are here today is because between when MVPN started in
1999/2000 (or maybe earlier, but I can only go back that far;) and 2004,
IETF effectively ignored it and let the SPs/vendors do their best, and on
their own, to come up with a solution (hopefully interoperable). As a
result, when IETF comes up with a different mechanism than the one deployed,
we will end up dealing with three, instead of one (as some would hope).
Because we all have to deal with the deployed base, the new one, and the
path from the deployed to the new.

However, my point is not that we should stop developing BGP based
mechanisms.  Rather,  I want to point out that we should be realistic of
what will happen which is eventually determined by the market place.  More
importantly,  I want to point out that we can't  ignore new requirement
(e.g., one from Maria) just because the WG already has the plates full.  SPs
and vendors can rarely afford to wait for the next solution coming out of
IETF.  For new requirement, the WG should try our best to evaluate and
accommodate so that an interoperable solution can be produced as early as
possible.  Otherwise,  we will be stuck in this perpetual spiral of catching
up and creating three instead of one solution to a single problem.

Have fun in Dublin and travel safely.



On 7/21/08 1:04 PM, "Ron Bonica" <rbonica at juniper.net> wrote:

> Folks,
> 
> The purpose of this message is to summarize WG status and begin a
> discussion of ways to proceed. The following comments are offered as an
> individual contributor.
> 
> For the last several years, the working group has been ruminating over
> multicast VPN architectures. So far the WG produced the following documents:
> 
> - draft-ietf-l3vpn-2547bis-mcast
> - draft-ietf-l3vpn-2547bis-mcast-bgp
> 
> These documents offer a plethora of possible MVPN options, without
> specifying which MUST be implemented, which SHOULD be implemented, and
> which are MAY be implemented.
> 
> Thomas Morin attempted to fill the void by introducing
> draft-morin-l3vpn-mvpn-considerations. This document specifies *single*
> subset of options that all vendors MUST implement. It also specifies a
> subset that vendors SHOULD and MAY implement. Although this document was
> generally well received by the working group, it was not adopted as a
> working group item because approval was not unanimous.
> 
> Later, Eric Rosen introduced draft-rosen-l3vpn-mvpn-profiles. This draft
> specified a set of MVPN profiles drawn from the two documents mentioned
> above. Other, possibly non-interoperable profiles also may be developed.
> draft-rosen-l3vpn-mvpn-profiles was never proposed as a working group item.
> 
> In the interest of making progress I would suggest that it is time for
> the WG to decide whether to accept draft-morin-l3vpn-mvpn-considerations
> as the WG document, or to follow the profile approach, as outlined in
> draft-rosen-l3vpn-mvpn-profiles (with the end result of multiple
> possibly non-interoperable profiles).
> 
> With this in mind I would like to ask the WG chairs for a consensus call
> on either (a) accepting  draft-morin-l3vpn-mvpn-considerations as the
> WG, or (b) following the profile approach, as outlined in
> draft-rosen-l3vpn-mvpn-profiles
> 
>                                         Ron
> 


-- 
Yiqun