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

[Yakov Rekhter <[e-mail]>]

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.