Subject: Re: Re-Charter discussion

From: Eric Rosen <[email-masked]>
Date: Mon, 10 May 2010 13:13:36 -0400

Ben> I have included below proposed text for a modified charter which I hope
Ben> accurately reflects the consensus of the WG from IETF 77.

I have a few comments.

> The WG will extend RFC4364 based solutions to address deployment of the
> following features in a VPN environment:
> 1. IP Multicast
> 2. IPv6

I think the support for IPv6 unicast service has been around for a long
time.  So maybe this should just say:

    The WG will continue to extend and enhance RFC4364-based solutions so
    that these solutions can be used to provide IPv4, IPv6, and MPLS
    multicast services.

If the charter just says "IP multicast", someone will claim that the use of
MPLS multicast at the PE/CE interface is "out of charter".

> The following VPN deployment scenarios will be considered by the WG:
> 1. Internet-wide: VPN sites attached to arbitrary points in the Internet.

Where did this come from?  RFC4364 has never supported VPN sites attached to
arbitrary points in the Internet.  

> 2. Single service provider (SP)/single AS: VPN sites attached to the
>    network of a single provider within the scope of a single AS.

> 3. Single SP/multiple AS'es: VPN sites attached to the network of a single
>    provider consisting of multiple AS'es.

> 4. Cooperating SPs: VPN sites attached to networks of different providers
>    that cooperate with each other to provide VPN service.

Should something specific be said about support for providers with IPv6
backbones?   
 
> As part of this effort the WG will work on the following tasks (additional
> work items will require rechartering):
> 1. Additional requirements and framework for Layer 3 VPNs.
> 2. Solution documents, including applicability statements, for each approach
>    listed above.
> 3. MIB definitions for each approach.
> 4. Security mechanisms for each approach.

This paragraph seems to be left over from the previous charter, as it still
talks of the various "approaches", even though only one approach (i.e.,
RFC4364) is left in the charter.  Also, I thought we didn't want to say
"additional work items will require rechartering").  

> As a general rule, the WG will not create new protocols, but will provide
> functional requirements for extensions of the existing protocols that will
> be discussed in the protocol-specific WGs. L3VPN WG will review proposed
> protocol extensions for L3VPNs before they are recommended to appropriate
> protocol-specific WGs.

This is from the old charter, but we've never paid much attention to it;
certainly there are a lot of BGP extensions in L3VPN documents.  Maybe we
should have a paragraph that more closely reflects reality, perhaps
something like:

        Protocol extensions that provide L3VPN functionality will be
        reviewed by both the L3VPN WG and by the WG responsible for the
        protocol being extended.  

> As stated above, the WG will define an IPv6 over BGP / MPLS VPN solution.

RFC 4659?

> This will include a forwarding plane component and a control plane
> component. In the forwarding plane, IPv6 datagrams will be encapsulated
> within an MPLS header.

Since non-MPLS forwarding methods are not ruled out for IPv4, they should
not be ruled out for IPv6 either.

> If any aspect of IPv6 forwarding over MPLS is as
> yet undefined, the L3VPN WG will defer to the MPLS and appropriate IPv6
> WGs. On the control plane, BGP extensions may also need to be defined. In
> this respect, the L3VPN WG will defer to the IDR and appropriate IPv6 WGs.

Probably this whole paragraph can be left out.
 
> As stated above, the WG will define a multicast over BGP / MPLS VPN
> solution. This will include a forwarding plane component and a control plane
> component. In the forwarding plane, IP multicast datagrams will be
> encapsulated within an MPLS header. If any aspect of IP multicast forwarding
> over MPLS is as yet undefined, the L3VPN WG will defer to the MPLS and
> appropriate multicast WGs. On the control plane, BGP extensions may also
> need to be defined. In this respect, the L3VPN WG will defer to the IDR and
> appropriate multicast WGs.

Since much of the multicast work has already been done, it would probably
just be better to say:

    The WG will continue to extend and enhance the Multicast over BGP/MPLS
    VPN solution.

There is no reason to rule out non-MPLS forwarding techniques.      
 
> QoS support is excluded from the charter at this time. It may be considered
> for inclusion in an updated charter at a later time.

Is there any particular reason for continuing to have this exclusion?

---

From: <[email-masked]>
Date: Mon, 10 May 2010 18:36:25 +0100

Eric,

Thanks for the comments, i will study them along with the one private comment i received and produce an updated draft charter text incorpoating them (or e-mail to the list to discuss individual comments further) in the next few days.

Ben

-----Original Message-----
From: Eric Rosen <[email-masked]>
Sent: 10 May 2010 19:13
To: Niven-jenkins,B,Ben,DMK5 R <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: Re-Charter discussion

I have a few comments.

RFC 4659?

---

From: <[email-masked]>
Date: Sat, 15 May 2010 17:58:50 +0100

Eric,

I have taken your comments onboard and produced a new proposed charter text which I will distribute in a separate e-mail.

See inline below for some comments/responses.

Ben

>     that these solutions can be used to provide IPv4, IPv6, and MPLS

I have changed to a slightly modified version of your suggested text:

The WG will continue to extend and enhance RFC4364 and RFC4659 based solutions so that these solutions can be used to provide IPv4, IPv6, and MPLS services including multicast.

> arbitrary points in the Internet.  

It was in the original charter, I have now removed it from the draft new charter.

> Should something specific be said about support for providers with IPv6

We already state we support IPv4, IPv6 and MPLS services. Is there anything significant that is L3VPN specific when building VPNs over IPv6 provider backbones that would not be captured by IPv6 extensions to the base protocols we have extended?

I have no objections to explicitly calling out a deployment scenario of L3VPN using a IPv6 provider backbone if you would like. Can you suggest text for such a bullet point?
 
> "additional work items will require rechartering").  

I have changed to:

As part of this effort the WG will work on the following tasks: 
1. Additional requirements and framework for Layer 3 VPNs. 
2. Solution documents, including applicability statements.
3. MIB definitions.
4. Security mechanisms.

>         reviewed by both the L3VPN WG and by the WG responsible for the

I have changed to:

As a general rule, the WG will not create new protocols, but will extend existing protocols to provide the necessary L3VPN functionality. Protocol extensions that provide L3VPN functionality will be reviewed by both the L3VPN WG and by the WG responsible for the protocol being extended.

> Probably this whole paragraph can be left out.

I have deleted the entire paragraph.

>     The WG will continue to extend and enhance the Multicast over BGP/MPLS

I have replaced the original paragraph with the sentence you propose.

> Is there any particular reason for continuing to have this exclusion?

No I have removed those two sentences.