Applicability Statement for Virtual Router-based Layer 3 PPVPN Approaches
draft-ietf-l3vpn-as-vr-02

Notify list changed from rick@rhwilder.net, rcallon@juniper.net, rbonica@juniper.net, ananth@juniper.net, suzuki.muneyoshi@lab.ntt.co.jp, j.sumimoto@ntt.com, bensons@savvis.net to j.sumimoto@ntt.com, rbonica@juniper.net, suzuki.muneyoshi@lab.ntt.co.jp, rcallon@juniper.net, bensons@savvis.net, rick@rhwilder.net

-------- Original Message --------
Subject: Re: Review of draft-ietf-l3vpn-as-vr-02.txt
Date: Tue, 26 Sep 2006 15:28:28 -0400
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Mark Townsley <townsley@cisco.com>
References: <20060908195611.A458B222426@laser.networkresonance.com> <tslbqpmp094.fsf@cz.mit.edu> <45191CDC.4060603@cisco.com>


>>>>> "Mark" == Mark Townsley <townsley@cisco.com> writes:

    Mark> If I put this on ballot, will you be handling the DISCUSS of
    Mark> all of this? ekr had a lot of good comments, but do remember
    Mark> that this is simply being published for the historical
    Mark> record.... L3VPN has moved on from the VR approach, and the
    Mark> upcoming recharter is going to reflect that.

Yes, you should ballot this and I'll look over ekr's review and see
what if anything needs a discuss.

Update notice from Anath


-------- Original Message --------
Subject: RE: Proposal for moving CE and VR drafts forward
Date: Sat, 26 Aug 2006 01:44:58 +0800
From: Ananth Nagarajan <ananth@juniper.net>
To: Mark Townsley <townsley@cisco.com>
CC: Ross Callon <rcallon@juniper.net>, <l3vpn-chairs@tools.ietf.org>, Paul Knight <paul.knight@nortel.com>, <bensons@savvis.net>, <j.sumimoto@ntt.com>, <suzuki.muneyoshi@lab.ntt.co.jp>


Mark,

>
>1. Anath or someone needs to update as-vr, or tell me
>definitely that it
>will never happen. This is the only document currently blocking
>bgpvpn-auto as well as vpn-vr. Once this document update is
>resolved, I
>will IETF LC these documents, mentioning that work on VR L3VPNs are no
>longer being pursued by the IETF, and that these documents are being
>published as informational for historical record.


I just posted draft-ietf-l3vpn-as-vr-02 (FINALLY). This version covers
comments and suggestions from Ross in Jan and April last year (I'm
ashamed to say this).  Sorry it took so long.

Ananth

Comment from 04/2005 from Ross Callon

Unfortunately, there are a couple of places where it still needs to be updated
and/or fixed. For example:

13. Scalability

PE-based PPVPNs have better scalability than CE-based PPVPNs, because
the total number of VPN tunnels that need to be managed are far > fewer in the
service provider backbone, than between CEs.

There are of course many people who would disagree with this. With CE-based
VPNs, typically some "over IP" encapsulation is used (such as IPsec). There is
therefore essentially no state in the core of the network. It is hard to >scale better
than this (although there are other issues, such as the network management
effort, equipment cost, etc).

Similarly, the beginning of the introduction says:

1. Introduction

The virtual router concept for L3 PPVPNs was first introduced in
[COREVPN]. This was generalized in [PPVPNVR]. A number of
auto- discovery mechanisms can be used with this approach to L3
PPVPNs, and [COREVPN] represents one such approach using IP
multicast.

In fact, I heard about and worked on the virtual router concept before
[COREVPN] was published. I still remember my first impression when
I first saw a presentation on [COREVPN] -- I felt sorry for the presenter
(who I won''t name) because the approach was so obviously flawed (in
particular due to the way that it used IP Multicast). Thus I don''t think
that the introduction to this approach should start off with [COREVPN]
as the first thing to talk about.

Nonetheless, in spite of a few nits such as this which I would personally
recommend to update, the AS contains a significant amount of useful
information (in my opinion).

Waiting on document update from Ananth

-------- Original Message --------
Subject: More, Re: Fwd: Re: L3VPN IPsec and VR documents
Date: Thu, 14 Apr 2005 12:12:47 -0400
From: Ross Callon <rcallon@juniper.net>
To: W. Mark Townsley <townsley@cisco.com>
CC: paul.knight@nortelnetworks.com, narten@us.ibm.com, margaret@thingmagic.com,        rick@rhwilder.net, rbonica@juniper.net
References: <425D908C.5080002@cisco.com> <6204FDDE129D364D8040A98BCCB290EF151C6CFD@zbl6c004.corpeast.baynetworks.com> <6204FDDE129D364D8040A98BCCB290EF151C6CFD@zbl6c004.corpeast.baynetworks.com>

Looking through old email, I found a message from me dated
January 19th containing comments on the VR applicability
statement (as well as VR architecture), and a reply from
Ananth saying he was intending to update it. This missed
the comment in my email from last night regarding the first
paragraph from section 13.

I therefore have pinged Ananth asking for him to update the
AS, and included comments on the paragraph in section 13.

I think that the next step is to get an update on the VR AS
from Ananth, in addition to the update on the VR architecture
from Paul.

Thanks, Ross

At 11:44 PM 4/13/2005 -0400, Ross Callon wrote:
>At 05:35 PM 4/13/2005 -0400, W. Mark Townsley wrote:
>>...
>>>That is, I''m not sure if we are moving the A.S. along as an
>>>Informational RFC or not.  It''s a useful document, but I did not recall
>>>what the WG decided to do with it.  I know the main VR draft
>>>(draft-ietf-l3vpn-vpn-vr) is on track, but not sure about the A.S. plan.
>>
>>Well, I inherited it from Thomas'' plate, so I suspect that the WG decided
>>to advance it. Chairs, can you fill me in on the history a bit more, do
>>we still want to advance the AS doc?
>>
>>Thanks,
>>
>>- Mark
>
>The current intention is to progress it. My recollection is that there was
>working group consensus on this although there was a lot of indifference.
>I think that there is some significant useful information in it. Looking
>it over
>again, most of it is in quite good shape (I only found a couple of places
>where it seems to need update -- although I should take another look
>tomorrow since it is a bit late to finish tonight).
>
>Unfortunately, there are a couple of places where it still needs to be updated
>and/or fixed. For example:
>
>         13. Scalability
>
>         PE-based PPVPNs have better scalability than CE-based PPVPNs, because
>         the total number of VPN tunnels that need to be managed are far
> fewer in the
>         service provider backbone, than between CEs.
>
>There are of course many people who would disagree with this. With CE-based
>VPNs, typically some "over IP" encapsulation is used (such as IPsec). There is
>therefore essentially no state in the core of the network. It is hard to
>scale better
>than this (although there are other issues, such as the network management
>effort, equipment cost, etc).
>
>Similarly, the beginning of the introduction says:
>
>         1. Introduction
>
>         The virtual router concept for L3 PPVPNs was first introduced in
>         [COREVPN]. This was generalized in [PPVPNVR]. A number of
>         auto- discovery mechanisms can be used with this approach to L3
>         PPVPNs, and [COREVPN] represents one such approach using IP
>         multicast.
>
>In fact, I heard about and worked on the virtual router concept before
>[COREVPN] was published. I still remember my first impression when
>I first saw a presentation on [COREVPN] -- I felt sorry for the presenter
>(who I won''t name) because the approach was so obviously flawed (in
>particular due to the way that it used IP Multicast). Thus I don''t think
>that the introduction to this approach should start off with [COREVPN]
>as the first thing to talk about.
>
>Nonetheless, in spite of a few nits such as this which I would personally
>recommend to update, the AS contains a significant amount of useful
>information (in my opinion).
>
>Ross
>

[Note]: 'Waiting on update from Ananth. -------- Original Message --------<br>Subject: More, Re: Fwd: Re: L3VPN IPsec and VR documents<br>Date: Thu, 14 Apr 2005 12:12:47 -0400<br>From: Ross Callon <rcallon@juniper.net><br>To: W. Mark Townsley <townsley@cisco.com><br>CC: paul.knight@nortelnetworks.com, narten@us.ibm.com, margaret@thingmagic.com,        rick@rhwilder.net, rbonica@juniper.net<br>References: <425D908C.5080002@cisco.com> <6204FDDE129D364D8040A98BCCB290EF151C6CFD@zbl6c004.corpeast.baynetworks.com> <6204FDDE129D364D8040A98BCCB290EF151C6CFD@zbl6c004.corpeast.baynetworks.com> Looking through old email, I found a message from me dated<br>January 19th containing comments on the VR applicability<br>statement (as well as VR architecture), and a reply from<br>Ananth saying he was intending to update it. This missed<br>the comment in my email from last night regarding the first<br>paragraph from section 13. I therefore have pinged Ananth asking for him to update the<br>AS, and included comments on the paragraph in section 13. I think that the next step is to get an update on the VR AS<br>from Ananth, in addition to the update on the VR architecture<br>from Paul. Thanks, Ross At 11:44 PM 4/13/2005 -0400, Ross Callon wrote:<br>>At 05:35 PM 4/13/2005 -0400, W. Mark Townsley wrote:<br>>>...<br>>>>That is, I''m not sure if we are moving the A.S. along as an >>>Informational RFC or not.  It''s a useful document, but I did not recall >>>what the WG decided to do with it.  I know the main VR draft >>>(draft-ietf-l3vpn-vpn-vr) is on track, but not sure about the A.S. plan.<br>>><br>>>Well, I inherited it from Thomas'' plate, so I suspect that the WG decided >>to advance it. Chairs, can you fill me in on the history a bit more, do >>we still want to advance the AS doc?<br>>><br>>>Thanks,<br>>><br>>>- Mark<br>><br>>The current intention is to progress it. My recollection is that there was<br>>working group consensus on this although there was a lot of indifference.<br>>I think that there is some significant useful information in it. Looking >it over<br>>again, most of it is in quite good shape (I only found a couple of places<br>>where it seems to need update -- although I should take another look<br>>tomorrow since it is a bit late to finish tonight).<br>><br>>Unfortunately, there are a couple of places where it still needs to be updated<br>>and/or fixed. For example:<br>><br>>        13. Scalability<br>><br>>        PE-based PPVPNs have better scalability than CE-based PPVPNs, because<br>>        the total number of VPN tunnels that need to be managed are far > fewer in the<br>>        service provider backbone, than between CEs.<br>><br>>There are of course many people who would disagree with this. With CE-based<br>>VPNs, typically some "over IP" encapsulation is used (such as IPsec). There is<br>>therefore essentially no state in the core of the network. It is hard to >scale better<br>>than this (although there are other issues, such as the network management<br>>effort, equipment cost, etc).<br>><br>>Similarly, the beginning of the introduction says:<br>><br>>        1. Introduction<br>><br>>        The virtual router concept for L3 PPVPNs was first introduced in<br>>        [COREVPN]. This was generalized in [PPVPNVR]. A number of<br>>        auto- discovery mechanisms can be used with this approach to L3<br>>        PPVPNs, and [COREVPN] represents one such approach using IP<br>>        multicast.<br>><br>>In fact, I heard about and worked on the virtual router concept before<br>>[COREVPN] was published. I still remember my first impression when<br>>I first saw a presentation on [COREVPN] -- I felt sorry for the presenter<br>>(who I won''t name) because the approach was so obviously flawed (in<br>>particular due to the way that it used IP Multicast). Thus I don''t think<br>>that the introduction to this approach should start off with [COREVPN]<br>>as the first thing to talk about.<br>><br>>Nonetheless, in spite of a few nits such as this which I would personally<br>>recommend to update, the AS contains a significant amount of useful<br>>information (in my opinion).<br>><br>>Ross<br>>' added by Mark Townsley

[Note]: '<br>Waiting on update from Ananth.<br><br>-------- Original Message --------<br>Subject: More, Re: Fwd: Re: L3VPN IPsec and VR documents<br>Date: Thu, 14 Apr 2005 12:12:47 -0400<br>From: Ross Callon <rcallon@juniper.net><br>To: W. Mark Townsley <townsley@cisco.com><br>CC: paul.knight@nortelnetworks.com, narten@us.ibm.com, margaret@thingmagic.com,        rick@rhwilder.net, rbonica@juniper.net<br>References: <425D908C.5080002@cisco.com> <6204FDDE129D364D8040A98BCCB290EF151C6CFD@zbl6c004.corpeast.baynetworks.com> <6204FDDE129D364D8040A98BCCB290EF151C6CFD@zbl6c004.corpeast.baynetworks.com><br><br>Looking through old email, I found a message from me dated<br>January 19th containing comments on the VR applicability<br>statement (as well as VR architecture), and a reply from<br>Ananth saying he was intending to update it. This missed<br>the comment in my email from last night regarding the first<br>paragraph from section 13.<br><br>I therefore have pinged Ananth asking for him to update the<br>AS, and included comments on the paragraph in section 13.<br><br>I think that the next step is to get an update on the VR AS<br>from Ananth, in addition to the update on the VR architecture<br>from Paul.<br><br>Thanks, Ross<br><br>At 11:44 PM 4/13/2005 -0400, Ross Callon wrote:<br>>At 05:35 PM 4/13/2005 -0400, W. Mark Townsley wrote:<br>>>...<br>>>>That is, I''m not sure if we are moving the A.S. along as an <br>>>>Informational RFC or not.  It''s a useful document, but I did not recall <br>>>>what the WG decided to do with it.  I know the main VR draft <br>>>>(draft-ietf-l3vpn-vpn-vr) is on track, but not sure about the A.S. plan.<br>>><br>>>Well, I inherited it from Thomas'' plate, so I suspect that the WG decided <br>>>to advance it. Chairs, can you fill me in on the history a bit more, do <br>>>we still want to advance the AS doc?<br>>><br>>>Thanks,<br>>><br>>>- Mark<br>><br>>The current intention is to progress it. My recollection is that there was<br>>working group consensus on this although there was a lot of indifference.<br>>I think that there is some significant useful information in it. Looking <br>>it over<br>>again, most of it is in quite good shape (I only found a couple of places<br>>where it seems to need update -- although I should take another look<br>>tomorrow since it is a bit late to finish tonight).<br>><br>>Unfortunately, there are a couple of places where it still needs to be updated<br>>and/or fixed. For example:<br>><br>>         13. Scalability<br>><br>>         PE-based PPVPNs have better scalability than CE-based PPVPNs, because<br>>         the total number of VPN tunnels that need to be managed are far <br>> fewer in the<br>>         service provider backbone, than between CEs.<br>><br>>There are of course many people who would disagree with this. With CE-based<br>>VPNs, typically some "over IP" encapsulation is used (such as IPsec). There is<br>>therefore essentially no state in the core of the network. It is hard to <br>>scale better<br>>than this (although there are other issues, such as the network management<br>>effort, equipment cost, etc).<br>><br>>Similarly, the beginning of the introduction says:<br>><br>>         1. Introduction<br>><br>>         The virtual router concept for L3 PPVPNs was first introduced in<br>>         [COREVPN]. This was generalized in [PPVPNVR]. A number of<br>>         auto- discovery mechanisms can be used with this approach to L3<br>>         PPVPNs, and [COREVPN] represents one such approach using IP<br>>         multicast.<br>><br>>In fact, I heard about and worked on the virtual router concept before<br>>[COREVPN] was published. I still remember my first impression when<br>>I first saw a presentation on [COREVPN] -- I felt sorry for the presenter<br>>(who I won''t name) because the approach was so obviously flawed (in<br>>particular due to the way that it used IP Multicast). Thus I don''t think<br>>that the introduction to this approach should start off with [COREVPN]<br>>as the first thing to talk about.<br>><br>>Nonetheless, in spite of a few nits such as this which I would personally<br>>recommend to update, the AS contains a significant amount of useful<br>>information (in my opinion).<br>><br>>Ross<br>><br><br><br>' added by Mark Townsley

State Change Notice email list have been change to rick@rhwilder.net, rcallon@juniper.net, rbonica@juniper.net, ananth@juniper.net, suzuki.muneyoshi@lab.ntt.co.jp, j.sumimoto@ntt.com, bensons@savvis.net from rick@rhwilder.net, rcallon@juniper.net, ronald.p.bonica@mci.com, ananth@juniper.net, suzuki.muneyoshi@lab.ntt.co.jp, j.sumimoto@ntt.com, bensons@savvis.net

[Note]: '2004-08-25: draft-ietf-l3vpn-as-vr-01.txt &<br>draft-ietf-l3vpn-vpn-vr-02.txt go together. Need to better understand<br>what wording/changes are needed to make clear that these documents are<br>not a protocol spec from which one can achieve interoperability.<br>' added by Thomas Narten

State Change Notice email list have been change to rick@rhwilder.net, rcallon@juniper.net, ronald.p.bonica@mci.com, ananth@juniper.net, suzuki.muneyoshi@lab.ntt.co.jp, j.sumimoto@ntt.com, bensons@savvis.net from <rick@rhwilder.net>, <rcallon@juniper.net>, <ronald.p.bonica@mci.com>