Subject: Re: Discussing additional milestones that could be adopted by the WG?

From: Yakov Rekhter <[email-masked]>
Date: Mon, 22 Nov 2010 10:21:47 -0800

Ben,

> Colleagues,
> 
> To follow-up on this, from comments on the mailing list and private
> conversations between the chairs and some participants it would
> appear that for BiDir P- tunnels at least:
> 
> - There is interest in the work and some loose agreement among the people 
>   that we spoke with that the existing specifications only minimally 
>   specify solutions using BiDir P-tunnels
> 
> - But that there are some quite different views on what the scope of any work
>   on BiDir P-tunnels should be.
> 
> We already have draft-rosen-l3vpn-mvpn-bidir on the table which has
> received some debate. It would be useful if one or more of the
> people that are not happy with the scope of draft-rosen-l3vpn-mvpn-bidir
> were to make alternative proposal(s) for the scope of work required
> to address BiDir P-tunnels so we can see where the common ground
> may be as a start to see if we can progress a specification for
> BiDir P-tunnels.

The scope of work in support of mp2mp P-tunnels should be guided by
draft-ietf-l3vpn-mvpn-considerations.

>From draft-ietf-l3vpn-mvpn-considerations:

   The use of MP2MP P-tunnels may provide
   some scaling benefits to the service provider as only a single MP2MP
   P-tunnel need be deployed per VPN, thus reducing by an order of
   magnitude the amount of multicast state that needs to be maintained
   by P routers. 

Therefore, the scope of work should be limited to the cases where
mp2mp P-tunnels do provide scaling benefits in conjunction with
the C-multicast routing schemes defined in [MVPN]. Specifically, the
scope of work should be limited to (1) use of mp2mp P-tunnels for
I-PMSI, and (2) support of C-bidir with the "Partitioned Sets of
PEs" method using a partial mesh of mp2mp P-tunnels (as discussed in 
section 11.2.3 of [MVPN]). 

>From draft-ietf-l3vpn-mvpn-considerations:

   5.  Avoiding duplicates

   It is recommended that implementations support the procedures
   described in section 9.1.1 of [I-D.ietf-l3vpn-2547bis-mcast]
   "Discarding Packets from Wrong PE", allowing fully avoiding
   duplicates.

Therefore, use of mp2mp P-tunnels for I-PMSI must fully specify
procedures to support 9.1.1 of [MVPN].

New work must not change/modify the existing procedures specified
in [MVPN] and [BGP-MVPN]. New work must not introduce new mechanisms
and/or procedures unless it shows that the mechanisms/procedures
specified in [MVPN] and [BGP-MVPN] are insufficient for the purpose
of delivering what is within the scope (as described above).

Yakov.

---

From: Eric Rosen <[email-masked]>
Date: Mon, 29 Nov 2010 11:30:21 -0500

Yakov> The scope of work in support of mp2mp P-tunnels should be guided by
Yakov> draft-ietf-l3vpn-mvpn-considerations.

That document was never intended as a guide to future work; certainly when
it was adopted by the WG it was presented as establishing a particular set
of features as mandatory; it was not presented as a restriction on future
charter modifications.

I do agree that any option that is mandated or recommended in that document
is a valid topic for the WG to consider taking up.

But I don't agree with the converse.