From l3vpn-bounces@ietf.org Mon Aug 01 01:01:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzSQX-0004D6-0i; Mon, 01 Aug 2005 01:01:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzSQU-0004BI-Tf for l3vpn@megatron.ietf.org; Mon, 01 Aug 2005 01:01:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09289 for ; Mon, 1 Aug 2005 01:01:22 -0400 (EDT) Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzSwh-0002XX-4G for l3vpn@ietf.org; Mon, 01 Aug 2005 01:34:40 -0400 Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 06:01:06 +0100 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 06:01:06 +0100 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 1 Aug 2005 01:01:05 -0400 Received: from [172.23.8.119] ([172.23.8.119]) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 01:01:04 -0400 Message-ID: <42EDAC8E.7050208@juniper.net> Date: Mon, 01 Aug 2005 01:01:02 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Wainner References: <42EA8107.1010104@cisco.com> <42EA8FF9.6020708@cisco.com> <42EA94E7.30103@cisco.com> In-Reply-To: <42EA94E7.30103@cisco.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2005 05:01:04.0927 (UTC) FILETIME=[053E9AF0:01C59656] X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: 7bit Cc: raszuk@cisco.com, l3vpn@ietf.org Subject: Re: draft-ietf-l3vpn-gre-ip-2547-04.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Scott, Robert, Can we agree for now that draft-ietf-l3vpn-gre-ip-2547-04 is OK as is, and that we can save the discussion below for the day when we address automated signaling? Ron Scott Wainner wrote: > > > Robert Raszuk wrote: > >> Scott, >> >> The question is valid and the automated solution to the problem has >> been proposed many times :) >> >> Just for the reference please look at the below draft: >> >> http://community.roxen.com/developers/idocs/drafts/draft-raggarwa-ppvpn-tunnel-encap-sig-01.html > > > > > or alternatively .. > http://www.ietf.org/internet-drafts/draft-nalawade-kapoor-tunnel-safi-03.txt > > > Nevertheless, something must be signaled by the egress PE. > >> >> >> Before we finalize the automated way the provisioning tools are >> responsible for selecting the encapsulation of choice. > > > Certainly, a provisioning tool could specify the use of GRE, IP, or LSP > encap; however, it would have to be done on a per peer basis. > > In addition, a distinct tunnel end-point cannot be distinguished from > the Next Hop address without reverting back to statically configuring IP > tunnel end-points. > > Seems these requirements defeat the purpose of the draft. > > Scott > >> >> >> Cheers, >> R. >> >> >> >>> In reviewing draft-ietf-l3vpn-gre-ip-2547-04.txt, I noted the >>> following that requires some clarification: >>> >>>> 4.1 MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE >>>> >>>> The following description is not meant to specify an implementation >>>> strategy; any implementation procedure which produces the same result >>>> is acceptable. >>>> >>>> When an ingress PE router receives a packet from a CE router, it >>>> looks up the packet's destination IP address in a VRF that is >>>> associated with packet's ingress attachment circuit. This enables >>>> the (ingress) PE router to find a VPN-IP route. The VPN-IP route >>>> will have an associated VPN route label and an associated BGP Next >>>> Hop. The label is pushed on the packet. Then an IP (or IP+GRE) >>>> encapsulation header is prepended to the packet, creating an >>>> MPLS-in-IP (or MPLS-in-GRE) encapsulated packet. >>> >>> >>> >>> >>> It appears that the ingress PE can choose to use MPLS-in-IP or MPLS-in- >>> GRE implying that the egress MUST be able to perform both forms of >>> decapsulation. If the egress PE can only perform one form of >>> decapsulation, >>> how does the ingress PE determine which form of encapsulation is >>> preferred >>> or required? >>> >>> The IP source >>> >>>> address field of the encapsulation header will be an address of the >>>> ingress PE router itself. The IP destination address field of the >>>> encapsulation header will contain the value of the associated BGP >>>> Next Hop; this will be an IP address of the egress PE router. QoS >>>> information can be copied from the VPN packet to the GRE/IP tunnel >>>> header so that required forwarding behaviors can be maintained at >>>> each hop along the forwarding path. >>> >>> >>> >>> >>>> The effect is to dynamically create an IP (or GRE) tunnel between the >>>> ingress and egress PE routers. >>> >>> >>> >>> >>> Presumably, the ingress PE and/or egress PE are also capable of >>> forwarding >>> packets via label switched paths (either between themselves or to other >>> PE's or ASBR's). In a mixed environment, its conceivable that two PE's >>> could only communicate via GRE or IP while a third could use an LSP >>> to the >>> one or the other PE. What means does the ingress PE use to determine >>> that the LSP should be used verses the GRE or IP encap? >>> >>>> No apriori configuration of the >>>> remote tunnel endpoints is needed. Note that these tunnels SHOULD >>>> NOT be IGP-visible links, and routing adjacencies SHOULD NOT be >>>> supported across these tunnel. Note also that the set of remote >>>> tunnel endpoints is not known in advance, but is learned dynamically >>>> via the BGP distribution of VPN-IP routes. The IP address of the >>>> remote tunnel endpoints is carried in the Network Address of the Next >>>> Hop field of the MP_REACH_NLRI BGP attribute [4] >>> >>> >>> >>> >>> This model assumes that the Network Address of the Next Hop field is the >>> destination tunnel address. This may or may not be true. The provider >>> may in fact want the externally accessible tunnel address to be distinct >>> from the Next Hop address for a variety of reasons including security, >>> transitive tunnels, etc. How does the egress PE indicate to the ingress >>> PE that the tunnel should NOT be built to the Next Hop address, but to >>> a designated tunnel address assigned on the egress PE? Likewise, how >>> does an ASBR determine that traffic to prefixes to a peer ASBR should >>> not be tunneled while prefixes to a peer PE should be tunneled. >>> >>> Seems that some form of signaling is required which is not defined in >>> this >>> draft. >>> >>> Scott Wainner >>> >>> >>> >>> Message: 1 >>> Date: Fri, 22 Jul 2005 17:31:30 -0700 (PDT) >>> From: Rick Wilder >>> Subject: draft-ietf-l3vpn-gre-ip-2547-04.txt. >>> To: l3vpn@ietf.org >>> Message-ID: <20050723003130.30954.qmail@web308.biz.mail.mud.yahoo.com> >>> Content-Type: text/plain; charset="iso-8859-1" >>> >>> L3VPN participants, >>> >>> >>> This begins a two-week last call for comments on >>> draft-ietf-l3vpn-gre-ip-2547-04.txt. >>> >>> Rick >>> >>> >>> >> >> > From l3vpn-bounces@ietf.org Mon Aug 01 04:44:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzVud-00037l-72; Mon, 01 Aug 2005 04:44:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzVub-00037g-A0 for l3vpn@megatron.ietf.org; Mon, 01 Aug 2005 04:44:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05787 for ; Mon, 1 Aug 2005 04:44:39 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzWQq-0004gE-Al for l3vpn@ietf.org; Mon, 01 Aug 2005 05:18:00 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 01 Aug 2005 01:44:32 -0700 X-IronPort-AV: i="3.95,156,1120460400"; d="scan'208"; a="201823783:sNHT34023744" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j718iG73004550; Mon, 1 Aug 2005 01:44:29 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 01:43:49 -0700 Received: from [10.21.144.107] ([10.21.144.107]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 01:43:48 -0700 Message-ID: <42EDE0C1.6070902@cisco.com> Date: Mon, 01 Aug 2005 01:43:45 -0700 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ron Bonica References: <42EA8107.1010104@cisco.com> <42EA8FF9.6020708@cisco.com> <42EA94E7.30103@cisco.com> <42EDAC8E.7050208@juniper.net> In-Reply-To: <42EDAC8E.7050208@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2005 08:43:48.0798 (UTC) FILETIME=[22BB7DE0:01C59675] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Content-Transfer-Encoding: 7bit Cc: l3vpn@ietf.org, Scott Wainner Subject: Re: draft-ietf-l3vpn-gre-ip-2547-04.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@cisco.com List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Hi Ron, Draft-ietf-l3vpn-gre-ip-2547-04 just specifies the encapsulation options assuming peers are manually configured. IMHO the day already came long time back (the moment we started to give ability for single side tunnel provisioning) to require automated way for peers to know what the other end is capable of decapsulating. In that light draft-ietf-l3vpn-gre-ip-2547-04 does not seems like easy to deploy in large scale today making it an incomplete spec. Cheers, R. > Scott, Robert, > > Can we agree for now that draft-ietf-l3vpn-gre-ip-2547-04 is OK as is, > and that we can save the discussion below for the day when we address > automated signaling? > > Ron > > > Scott Wainner wrote: > >> >> >> Robert Raszuk wrote: >> >>> Scott, >>> >>> The question is valid and the automated solution to the problem has >>> been proposed many times :) >>> >>> Just for the reference please look at the below draft: >>> >>> http://community.roxen.com/developers/idocs/drafts/draft-raggarwa-ppvpn-tunnel-encap-sig-01.html >> >> >> >> >> >> >> or alternatively .. >> http://www.ietf.org/internet-drafts/draft-nalawade-kapoor-tunnel-safi-03.txt >> >> >> Nevertheless, something must be signaled by the egress PE. >> >>> >>> >>> Before we finalize the automated way the provisioning tools are >>> responsible for selecting the encapsulation of choice. >> >> >> >> Certainly, a provisioning tool could specify the use of GRE, IP, or >> LSP encap; however, it would have to be done on a per peer basis. >> >> In addition, a distinct tunnel end-point cannot be distinguished from >> the Next Hop address without reverting back to statically configuring >> IP tunnel end-points. >> >> Seems these requirements defeat the purpose of the draft. >> >> Scott >> >>> >>> >>> Cheers, >>> R. >>> >>> >>> >>>> In reviewing draft-ietf-l3vpn-gre-ip-2547-04.txt, I noted the >>>> following that requires some clarification: >>>> >>>>> 4.1 MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE >>>>> >>>>> The following description is not meant to specify an implementation >>>>> strategy; any implementation procedure which produces the same >>>>> result >>>>> is acceptable. >>>>> >>>>> When an ingress PE router receives a packet from a CE router, it >>>>> looks up the packet's destination IP address in a VRF that is >>>>> associated with packet's ingress attachment circuit. This enables >>>>> the (ingress) PE router to find a VPN-IP route. The VPN-IP route >>>>> will have an associated VPN route label and an associated BGP Next >>>>> Hop. The label is pushed on the packet. Then an IP (or IP+GRE) >>>>> encapsulation header is prepended to the packet, creating an >>>>> MPLS-in-IP (or MPLS-in-GRE) encapsulated packet. >>>> >>>> >>>> >>>> >>>> >>>> It appears that the ingress PE can choose to use MPLS-in-IP or MPLS-in- >>>> GRE implying that the egress MUST be able to perform both forms of >>>> decapsulation. If the egress PE can only perform one form of >>>> decapsulation, >>>> how does the ingress PE determine which form of encapsulation is >>>> preferred >>>> or required? >>>> >>>> The IP source >>>> >>>>> address field of the encapsulation header will be an address of the >>>>> ingress PE router itself. The IP destination address field of the >>>>> encapsulation header will contain the value of the associated BGP >>>>> Next Hop; this will be an IP address of the egress PE router. QoS >>>>> information can be copied from the VPN packet to the GRE/IP tunnel >>>>> header so that required forwarding behaviors can be maintained at >>>>> each hop along the forwarding path. >>>> >>>> >>>> >>>> >>>> >>>>> The effect is to dynamically create an IP (or GRE) tunnel between >>>>> the >>>>> ingress and egress PE routers. >>>> >>>> >>>> >>>> >>>> >>>> Presumably, the ingress PE and/or egress PE are also capable of >>>> forwarding >>>> packets via label switched paths (either between themselves or to other >>>> PE's or ASBR's). In a mixed environment, its conceivable that two PE's >>>> could only communicate via GRE or IP while a third could use an LSP >>>> to the >>>> one or the other PE. What means does the ingress PE use to determine >>>> that the LSP should be used verses the GRE or IP encap? >>>> >>>>> No apriori configuration of the >>>>> remote tunnel endpoints is needed. Note that these tunnels SHOULD >>>>> NOT be IGP-visible links, and routing adjacencies SHOULD NOT be >>>>> supported across these tunnel. Note also that the set of remote >>>>> tunnel endpoints is not known in advance, but is learned dynamically >>>>> via the BGP distribution of VPN-IP routes. The IP address of the >>>>> remote tunnel endpoints is carried in the Network Address of the >>>>> Next >>>>> Hop field of the MP_REACH_NLRI BGP attribute [4] >>>> >>>> >>>> >>>> >>>> >>>> This model assumes that the Network Address of the Next Hop field is >>>> the >>>> destination tunnel address. This may or may not be true. The provider >>>> may in fact want the externally accessible tunnel address to be >>>> distinct >>>> from the Next Hop address for a variety of reasons including security, >>>> transitive tunnels, etc. How does the egress PE indicate to the >>>> ingress >>>> PE that the tunnel should NOT be built to the Next Hop address, but to >>>> a designated tunnel address assigned on the egress PE? Likewise, how >>>> does an ASBR determine that traffic to prefixes to a peer ASBR should >>>> not be tunneled while prefixes to a peer PE should be tunneled. >>>> >>>> Seems that some form of signaling is required which is not defined >>>> in this >>>> draft. >>>> >>>> Scott Wainner >>>> >>>> >>>> >>>> Message: 1 >>>> Date: Fri, 22 Jul 2005 17:31:30 -0700 (PDT) >>>> From: Rick Wilder >>>> Subject: draft-ietf-l3vpn-gre-ip-2547-04.txt. >>>> To: l3vpn@ietf.org >>>> Message-ID: <20050723003130.30954.qmail@web308.biz.mail.mud.yahoo.com> >>>> Content-Type: text/plain; charset="iso-8859-1" >>>> >>>> L3VPN participants, >>>> >>>> >>>> This begins a two-week last call for comments on >>>> draft-ietf-l3vpn-gre-ip-2547-04.txt. >>>> >>>> Rick >>>> >>>> >>>> >>> >>> >> > From l3vpn-bounces@ietf.org Mon Aug 01 09:07:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dza0m-0001jY-M1; Mon, 01 Aug 2005 09:07:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dza0j-0001io-30 for l3vpn@megatron.ietf.org; Mon, 01 Aug 2005 09:07:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07310 for ; Mon, 1 Aug 2005 09:07:13 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzaX0-0008CP-Eh for l3vpn@ietf.org; Mon, 01 Aug 2005 09:40:39 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 01 Aug 2005 06:07:07 -0700 X-IronPort-AV: i="3.95,156,1120460400"; d="scan'208"; a="201854247:sNHT33437332" Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j71D73ul014767; Mon, 1 Aug 2005 06:07:03 -0700 (PDT) Received: from cisco.com (sjc-vpn2-535.cisco.com [10.21.114.23]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA20810; Mon, 1 Aug 2005 06:07:01 -0700 (PDT) Message-ID: <42EE1E73.7020101@cisco.com> Date: Mon, 01 Aug 2005 09:06:59 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ron Bonica References: <42EA8107.1010104@cisco.com> <42EA8FF9.6020708@cisco.com> <42EA94E7.30103@cisco.com> <42EDAC8E.7050208@juniper.net> In-Reply-To: <42EDAC8E.7050208@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Content-Transfer-Encoding: 7bit Cc: raszuk@cisco.com, l3vpn@ietf.org Subject: Re: draft-ietf-l3vpn-gre-ip-2547-04.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org I think that the following paragraph needs to be modified: The effect is to dynamically create an IP (or GRE) tunnel between the ingress and egress PE routers. No apriori configuration of the remote tunnel endpoints is needed. Note that these tunnels SHOULD NOT be IGP-visible links, and routing adjacencies SHOULD NOT be supported across these tunnel. Note also that the set of remote tunnel endpoints is not known in advance, but is learned dynamically via the BGP distribution of VPN-IP routes. The IP address of the remote tunnel endpoints is carried in the Network Address of the Next Hop field of the MP_REACH_NLRI BGP attribute [4] to: The IP address of the remote tunnel endpoints MAY be inferred from the Network Address of the Next Hop field of the MP_REACH_NLRI BGP attribute [4]. Note that the set of Next Hop Network Addresses is not known in advance, but is learned dynamically via the BGP distribution of VPN-IP routes. Assuming a consistent set of tunnel capabilities exist between all the PE's and ASBR's, no apriori configuration of the remote tunnel endpoints is needed. The entire set of PE and ASBR routers MUST have the same tunnel capabilities if the dynamic creation of IP (or GRE) tunnels is desired. The preference to use an IP (or GRE) tunnel MUST be configured. A set of PE's using two or more tunnel mechanisms (i.e. LSP, GRE, IP, etc.) MUST determine the tunnel type on a per peer basis. The automatic association of tunnel capabilities on a per peer basis is for future study. Note that these tunnels SHOULD NOT be IGP-visible links and routing adjacencies SHOULD NOT be supported across these tunnel. Scott Wainner Ron Bonica wrote: > Scott, Robert, > > Can we agree for now that draft-ietf-l3vpn-gre-ip-2547-04 is OK as is, > and that we can save the discussion below for the day when we address > automated signaling? > > Ron > > > Scott Wainner wrote: > >> >> >> Robert Raszuk wrote: >> >>> Scott, >>> >>> The question is valid and the automated solution to the problem has >>> been proposed many times :) >>> >>> Just for the reference please look at the below draft: >>> >>> http://community.roxen.com/developers/idocs/drafts/draft-raggarwa-ppvpn-tunnel-encap-sig-01.html >> >> >> >> >> >> >> or alternatively .. >> http://www.ietf.org/internet-drafts/draft-nalawade-kapoor-tunnel-safi-03.txt >> >> >> Nevertheless, something must be signaled by the egress PE. >> >>> >>> >>> Before we finalize the automated way the provisioning tools are >>> responsible for selecting the encapsulation of choice. >> >> >> >> Certainly, a provisioning tool could specify the use of GRE, IP, or >> LSP encap; however, it would have to be done on a per peer basis. >> >> In addition, a distinct tunnel end-point cannot be distinguished >> from the Next Hop address without reverting back to statically >> configuring IP tunnel end-points. >> >> Seems these requirements defeat the purpose of the draft. >> >> Scott >> >>> >>> >>> Cheers, >>> R. >>> >>> >>> >>>> In reviewing draft-ietf-l3vpn-gre-ip-2547-04.txt, I noted the >>>> following that requires some clarification: >>>> >>>>> 4.1 MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE >>>>> >>>>> The following description is not meant to specify an implementation >>>>> strategy; any implementation procedure which produces the same >>>>> result >>>>> is acceptable. >>>>> >>>>> When an ingress PE router receives a packet from a CE router, it >>>>> looks up the packet's destination IP address in a VRF that is >>>>> associated with packet's ingress attachment circuit. This enables >>>>> the (ingress) PE router to find a VPN-IP route. The VPN-IP route >>>>> will have an associated VPN route label and an associated BGP Next >>>>> Hop. The label is pushed on the packet. Then an IP (or IP+GRE) >>>>> encapsulation header is prepended to the packet, creating an >>>>> MPLS-in-IP (or MPLS-in-GRE) encapsulated packet. >>>> >>>> >>>> >>>> >>>> >>>> It appears that the ingress PE can choose to use MPLS-in-IP or >>>> MPLS-in- >>>> GRE implying that the egress MUST be able to perform both forms of >>>> decapsulation. If the egress PE can only perform one form of >>>> decapsulation, >>>> how does the ingress PE determine which form of encapsulation is >>>> preferred >>>> or required? >>>> >>>> The IP source >>>> >>>>> address field of the encapsulation header will be an address of the >>>>> ingress PE router itself. The IP destination address field of the >>>>> encapsulation header will contain the value of the associated BGP >>>>> Next Hop; this will be an IP address of the egress PE router. QoS >>>>> information can be copied from the VPN packet to the GRE/IP tunnel >>>>> header so that required forwarding behaviors can be maintained at >>>>> each hop along the forwarding path. >>>> >>>> >>>> >>>> >>>> >>>>> The effect is to dynamically create an IP (or GRE) tunnel >>>>> between the >>>>> ingress and egress PE routers. >>>> >>>> >>>> >>>> >>>> >>>> Presumably, the ingress PE and/or egress PE are also capable of >>>> forwarding >>>> packets via label switched paths (either between themselves or to >>>> other >>>> PE's or ASBR's). In a mixed environment, its conceivable that two >>>> PE's >>>> could only communicate via GRE or IP while a third could use an LSP >>>> to the >>>> one or the other PE. What means does the ingress PE use to determine >>>> that the LSP should be used verses the GRE or IP encap? >>>> >>>>> No apriori configuration of the >>>>> remote tunnel endpoints is needed. Note that these tunnels SHOULD >>>>> NOT be IGP-visible links, and routing adjacencies SHOULD NOT be >>>>> supported across these tunnel. Note also that the set of remote >>>>> tunnel endpoints is not known in advance, but is learned >>>>> dynamically >>>>> via the BGP distribution of VPN-IP routes. The IP address of the >>>>> remote tunnel endpoints is carried in the Network Address of the >>>>> Next >>>>> Hop field of the MP_REACH_NLRI BGP attribute [4] >>>> >>>> >>>> >>>> >>>> >>>> This model assumes that the Network Address of the Next Hop field >>>> is the >>>> destination tunnel address. This may or may not be true. The >>>> provider >>>> may in fact want the externally accessible tunnel address to be >>>> distinct >>>> from the Next Hop address for a variety of reasons including security, >>>> transitive tunnels, etc. How does the egress PE indicate to the >>>> ingress >>>> PE that the tunnel should NOT be built to the Next Hop address, but to >>>> a designated tunnel address assigned on the egress PE? Likewise, how >>>> does an ASBR determine that traffic to prefixes to a peer ASBR should >>>> not be tunneled while prefixes to a peer PE should be tunneled. >>>> >>>> Seems that some form of signaling is required which is not defined >>>> in this >>>> draft. >>>> >>>> Scott Wainner >>>> >>>> >>>> >>>> Message: 1 >>>> Date: Fri, 22 Jul 2005 17:31:30 -0700 (PDT) >>>> From: Rick Wilder >>>> Subject: draft-ietf-l3vpn-gre-ip-2547-04.txt. >>>> To: l3vpn@ietf.org >>>> Message-ID: <20050723003130.30954.qmail@web308.biz.mail.mud.yahoo.com> >>>> Content-Type: text/plain; charset="iso-8859-1" >>>> >>>> L3VPN participants, >>>> >>>> >>>> This begins a two-week last call for comments on >>>> draft-ietf-l3vpn-gre-ip-2547-04.txt. >>>> >>>> Rick >>>> >>>> >>>> >>> >>> >> > From l3vpn-bounces@ietf.org Mon Aug 01 15:50:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzgIu-00042g-CH; Mon, 01 Aug 2005 15:50:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzgIV-0003rz-Kh; Mon, 01 Aug 2005 15:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05070; Mon, 1 Aug 2005 15:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzgop-0001kD-6s; Mon, 01 Aug 2005 16:23:27 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DzgIT-0004Za-Ad; Mon, 01 Aug 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 01 Aug 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-vr-mib-04.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : Virtual Router Management Information Base Using SMIv2 Author(s) : E. Stelzer, et al. Filename : draft-ietf-l3vpn-vr-mib-04.txt Pages : 24 Date : 2005-8-1 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing networks using Virtual Routers (VR). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-vr-mib-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l3vpn-vr-mib-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l3vpn-vr-mib-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-1123523.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-vr-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-vr-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-1123523.I-D@ietf.org> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Mon Aug 01 15:50:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzgJM-0004GO-8a; Mon, 01 Aug 2005 15:50:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzgIY-0003uZ-UJ; Mon, 01 Aug 2005 15:50:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05119; Mon, 1 Aug 2005 15:50:05 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzgop-0001kd-Ul; Mon, 01 Aug 2005 16:23:29 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DzgIT-0004bE-UR; Mon, 01 Aug 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 01 Aug 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-bgp-ipv6-07.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : BGP-MPLS IP VPN extension for IPv6 VPN Author(s) : J. De Clercq, et al. Filename : draft-ietf-l3vpn-bgp-ipv6-07.txt Pages : 18 Date : 2005-8-1 This document describes a method by which a Service Provider may use its packet switched backbone to provide Virtual Private Network services for its IPv6 customers. This method reuses, and extends where necessary, the "BGP/MPLS IP VPN" method [2547bis] for support of IPv6. In BGP/MPLS IP VPN, "Multiprotocol BGP" is used for distributing IPv4 VPN routes over the service provider backbone and MPLS is used to forward IPv4 VPN packets over the backbone. This document defines an IPv6 VPN address family and describes the corresponding IPv6 VPN route distribution in "Multiprotocol BGP". This document defines support of the IPv6 VPN service over both an IPv4 and an IPv6 backbone, and using various tunneling techniques over the core including MPLS, IP-in-IP, GRE and IPsec protected tunnels. The inter-working between an IPv4 site and an IPv6 site is outside the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgp-ipv6-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l3vpn-bgp-ipv6-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l3vpn-bgp-ipv6-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-1141234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-bgp-ipv6-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-bgp-ipv6-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-1141234.I-D@ietf.org> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Tue Aug 02 03:59:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzrge-0003Oa-25; Tue, 02 Aug 2005 03:59:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzrga-0003OM-Tw for l3vpn@megatron.ietf.org; Tue, 02 Aug 2005 03:59:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28112 for ; Tue, 2 Aug 2005 03:59:38 -0400 (EDT) Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzsD2-0000uH-5l for l3vpn@ietf.org; Tue, 02 Aug 2005 04:33:12 -0400 Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Aug 2005 08:59:20 +0100 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Aug 2005 08:59:19 +0100 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 2 Aug 2005 03:59:17 -0400 Received: from [172.23.1.32] ([172.23.1.32]) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Aug 2005 03:59:16 -0400 Message-ID: <42EF27D1.3060001@juniper.net> Date: Tue, 02 Aug 2005 03:59:13 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Wainner References: <42EA8107.1010104@cisco.com> <42EA8FF9.6020708@cisco.com> <42EA94E7.30103@cisco.com> <42EDAC8E.7050208@juniper.net> <42EE1E73.7020101@cisco.com> In-Reply-To: <42EE1E73.7020101@cisco.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Aug 2005 07:59:17.0139 (UTC) FILETIME=[14B66E30:01C59738] X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Content-Transfer-Encoding: 7bit Cc: raszuk@cisco.com, l3vpn@ietf.org Subject: Re: draft-ietf-l3vpn-gre-ip-2547-04.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Agreed. I will make this change in the next version of the draft. -r Scott Wainner wrote: > I think that the following paragraph needs to be modified: > > The effect is to dynamically create an IP (or GRE) tunnel between the > ingress and egress PE routers. No apriori configuration of the > remote tunnel endpoints is needed. Note that these tunnels SHOULD > NOT be IGP-visible links, and routing adjacencies SHOULD NOT be > supported across these tunnel. Note also that the set of remote > tunnel endpoints is not known in advance, but is learned dynamically > via the BGP distribution of VPN-IP routes. The IP address of the > remote tunnel endpoints is carried in the Network Address of the Next > Hop field of the MP_REACH_NLRI BGP attribute [4] > > to: > > The IP address of the remote tunnel endpoints MAY be inferred from the > Network Address of the Next Hop field of the MP_REACH_NLRI BGP attribute > [4]. Note that the set of Next Hop Network Addresses is not known in > advance, but is learned dynamically via the BGP distribution of VPN-IP > routes. Assuming a consistent set of tunnel capabilities exist between > all the PE's and ASBR's, no apriori configuration of the remote tunnel > endpoints is needed. The entire set of PE and ASBR routers MUST have > the same tunnel capabilities if the dynamic creation of IP (or GRE) > tunnels is desired. The preference to use an IP (or GRE) tunnel MUST be > configured. A set of PE's using two or more tunnel mechanisms (i.e. > LSP, GRE, IP, etc.) MUST determine the tunnel type on a per peer basis. > The automatic association of tunnel capabilities on a per peer basis is > for future study. Note that these tunnels SHOULD NOT be IGP-visible > links and routing adjacencies SHOULD NOT be supported across these tunnel. > > Scott Wainner > > > Ron Bonica wrote: > >> Scott, Robert, >> >> Can we agree for now that draft-ietf-l3vpn-gre-ip-2547-04 is OK as is, >> and that we can save the discussion below for the day when we address >> automated signaling? >> >> Ron >> >> >> Scott Wainner wrote: >> >>> >>> >>> Robert Raszuk wrote: >>> >>>> Scott, >>>> >>>> The question is valid and the automated solution to the problem has >>>> been proposed many times :) >>>> >>>> Just for the reference please look at the below draft: >>>> >>>> http://community.roxen.com/developers/idocs/drafts/draft-raggarwa-ppvpn-tunnel-encap-sig-01.html >>> >>> >>> >>> >>> >>> >>> >>> >>> or alternatively .. >>> http://www.ietf.org/internet-drafts/draft-nalawade-kapoor-tunnel-safi-03.txt >>> >>> >>> Nevertheless, something must be signaled by the egress PE. >>> >>>> >>>> >>>> Before we finalize the automated way the provisioning tools are >>>> responsible for selecting the encapsulation of choice. >>> >>> >>> >>> >>> Certainly, a provisioning tool could specify the use of GRE, IP, or >>> LSP encap; however, it would have to be done on a per peer basis. >>> >>> In addition, a distinct tunnel end-point cannot be distinguished >>> from the Next Hop address without reverting back to statically >>> configuring IP tunnel end-points. >>> >>> Seems these requirements defeat the purpose of the draft. >>> >>> Scott >>> >>>> >>>> >>>> Cheers, >>>> R. >>>> >>>> >>>> >>>>> In reviewing draft-ietf-l3vpn-gre-ip-2547-04.txt, I noted the >>>>> following that requires some clarification: >>>>> >>>>>> 4.1 MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE >>>>>> >>>>>> The following description is not meant to specify an implementation >>>>>> strategy; any implementation procedure which produces the same >>>>>> result >>>>>> is acceptable. >>>>>> >>>>>> When an ingress PE router receives a packet from a CE router, it >>>>>> looks up the packet's destination IP address in a VRF that is >>>>>> associated with packet's ingress attachment circuit. This enables >>>>>> the (ingress) PE router to find a VPN-IP route. The VPN-IP route >>>>>> will have an associated VPN route label and an associated BGP Next >>>>>> Hop. The label is pushed on the packet. Then an IP (or IP+GRE) >>>>>> encapsulation header is prepended to the packet, creating an >>>>>> MPLS-in-IP (or MPLS-in-GRE) encapsulated packet. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> It appears that the ingress PE can choose to use MPLS-in-IP or >>>>> MPLS-in- >>>>> GRE implying that the egress MUST be able to perform both forms of >>>>> decapsulation. If the egress PE can only perform one form of >>>>> decapsulation, >>>>> how does the ingress PE determine which form of encapsulation is >>>>> preferred >>>>> or required? >>>>> >>>>> The IP source >>>>> >>>>>> address field of the encapsulation header will be an address of the >>>>>> ingress PE router itself. The IP destination address field of the >>>>>> encapsulation header will contain the value of the associated BGP >>>>>> Next Hop; this will be an IP address of the egress PE router. QoS >>>>>> information can be copied from the VPN packet to the GRE/IP tunnel >>>>>> header so that required forwarding behaviors can be maintained at >>>>>> each hop along the forwarding path. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> The effect is to dynamically create an IP (or GRE) tunnel >>>>>> between the >>>>>> ingress and egress PE routers. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Presumably, the ingress PE and/or egress PE are also capable of >>>>> forwarding >>>>> packets via label switched paths (either between themselves or to >>>>> other >>>>> PE's or ASBR's). In a mixed environment, its conceivable that two >>>>> PE's >>>>> could only communicate via GRE or IP while a third could use an LSP >>>>> to the >>>>> one or the other PE. What means does the ingress PE use to determine >>>>> that the LSP should be used verses the GRE or IP encap? >>>>> >>>>>> No apriori configuration of the >>>>>> remote tunnel endpoints is needed. Note that these tunnels SHOULD >>>>>> NOT be IGP-visible links, and routing adjacencies SHOULD NOT be >>>>>> supported across these tunnel. Note also that the set of remote >>>>>> tunnel endpoints is not known in advance, but is learned >>>>>> dynamically >>>>>> via the BGP distribution of VPN-IP routes. The IP address of the >>>>>> remote tunnel endpoints is carried in the Network Address of the >>>>>> Next >>>>>> Hop field of the MP_REACH_NLRI BGP attribute [4] >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This model assumes that the Network Address of the Next Hop field >>>>> is the >>>>> destination tunnel address. This may or may not be true. The >>>>> provider >>>>> may in fact want the externally accessible tunnel address to be >>>>> distinct >>>>> from the Next Hop address for a variety of reasons including security, >>>>> transitive tunnels, etc. How does the egress PE indicate to the >>>>> ingress >>>>> PE that the tunnel should NOT be built to the Next Hop address, but to >>>>> a designated tunnel address assigned on the egress PE? Likewise, how >>>>> does an ASBR determine that traffic to prefixes to a peer ASBR should >>>>> not be tunneled while prefixes to a peer PE should be tunneled. >>>>> >>>>> Seems that some form of signaling is required which is not defined >>>>> in this >>>>> draft. >>>>> >>>>> Scott Wainner >>>>> >>>>> >>>>> >>>>> Message: 1 >>>>> Date: Fri, 22 Jul 2005 17:31:30 -0700 (PDT) >>>>> From: Rick Wilder >>>>> Subject: draft-ietf-l3vpn-gre-ip-2547-04.txt. >>>>> To: l3vpn@ietf.org >>>>> Message-ID: <20050723003130.30954.qmail@web308.biz.mail.mud.yahoo.com> >>>>> Content-Type: text/plain; charset="iso-8859-1" >>>>> >>>>> L3VPN participants, >>>>> >>>>> >>>>> This begins a two-week last call for comments on >>>>> draft-ietf-l3vpn-gre-ip-2547-04.txt. >>>>> >>>>> Rick >>>>> >>>>> >>>>> >>>> >>>> >>> >> > From l3vpn-bounces@ietf.org Wed Aug 03 11:30:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0LCf-0000yg-0y; Wed, 03 Aug 2005 11:30:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0LCd-0000yT-5j for l3vpn@megatron.ietf.org; Wed, 03 Aug 2005 11:30:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25811 for ; Wed, 3 Aug 2005 11:30:41 -0400 (EDT) Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0LjK-0006mf-CT for l3vpn@ietf.org; Wed, 03 Aug 2005 12:04:31 -0400 Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 16:30:22 +0100 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 16:30:21 +0100 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Aug 2005 11:30:19 -0400 Received: from [172.23.1.32] ([172.23.1.32]) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 11:30:18 -0400 Message-ID: <42F0E308.9060300@juniper.net> Date: Wed, 03 Aug 2005 11:30:16 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l3vpn@ietf.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Aug 2005 15:30:18.0804 (UTC) FILETIME=[41228F40:01C59840] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: IETF 63 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Folks, If you presented to the L3VPN WG at IETF63, please send me your slides so that I can include them in the minutes. Ron From l3vpn-bounces@ietf.org Thu Aug 04 10:43:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0gwv-0000Bq-AQ; Thu, 04 Aug 2005 10:43:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0gwt-0000Bl-Ma for l3vpn@megatron.ietf.org; Thu, 04 Aug 2005 10:43:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16342 for ; Thu, 4 Aug 2005 10:43:53 -0400 (EDT) Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0hTl-0005ln-88 for l3vpn@ietf.org; Thu, 04 Aug 2005 11:17:56 -0400 Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 15:43:43 +0100 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 15:43:43 +0100 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Aug 2005 10:43:42 -0400 Received: from [172.23.1.32] ([172.23.1.32]) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 10:43:40 -0400 Message-ID: <42F22997.3040805@juniper.net> Date: Thu, 04 Aug 2005 10:43:35 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l3vpn@ietf.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------000406080004060802000609" X-OriginalArrivalTime: 04 Aug 2005 14:43:41.0181 (UTC) FILETIME=[E808EAD0:01C59902] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4f8b2857a7a1a95c927652b5e03785d Subject: draft-ietf-l3vpn-gre-ip-2547-05 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org This is a multi-part message in MIME format. --------------000406080004060802000609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Rick, Ross, I have just posted the attached draft to address comments that were received in wg last call. Assuming that no further comments are posted until the end of the last call (tomorrow) the attached draft version should be ready to go to the iesg. -r --------------000406080004060802000609 Content-Type: text/plain; name="draft-ietf-l3vpn-gre-ip-2547-05.txt" Content-Disposition: inline; filename="draft-ietf-l3vpn-gre-ip-2547-05.txt" Content-Transfer-Encoding: 7bit L3VPN Working Group Y. Rekhter Internet-Draft R. Bonica Expires: February 5, 2006 Juniper Networks E. Rosen Cisco Systems, Inc. August 4, 2005 Use of PE-PE GRE or IP in BGP/MPLS IP Virtual Private Networks draft-ietf-l3vpn-gre-ip-2547-05 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 5, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This draft describes an implementation strategy for BGP/MPLS IP Virtual Private Networks (VPNs) in which the outermost MPLS label (i.e., the tunnel label) is replaced with either an IP header or an IP header with Generic Routing Encapsulation (GRE). The implementation strategy described herein enables the deployment Rekhter, et al. Expires February 5, 2006 [Page 1] Internet-Draft L3VPN GRE August 2005 of BGP/MPLS IP VPN technology in networks whose edge devices are MPLS and VPN aware, but whose interior devices are not. Table of Contents 1. Conventions Used In This Document . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1 MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE . . . . 7 4.2 MPLS-in-IP/MPLS-in-GRE Decapsulation by Egress PE . . . . 8 5. Implications On Packet Spoofing . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . 14 Rekhter, et al. Expires February 5, 2006 [Page 2] Internet-Draft L3VPN GRE August 2005 1. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [1]. Rekhter, et al. Expires February 5, 2006 [Page 3] Internet-Draft L3VPN GRE August 2005 2. Introduction A "conventional" BGP/MPLS IP VPN [2] is characterized as follows: Each Provider Edge (PE) router maintains one or more Virtual Routing and Forwarding (VRF) instances. A VRF instances is a VPN specific forwarding table. PE routers exchange reachability information with one another using BGP [3] with multi-protocol extensions [4]. MPLS Label Switching Paths (LSPs) [5] connect PE routers one another. In simple configurations, the VPN service is offered by a single Autonomous System (AS). All service provider routers are contained by a single AS and all VPN sites attach to that AS. When an ingress PE router receives a packet from a VPN site, it looks up the packet's destination IP address in a VRF that is associated with packet's ingress attachment circuit. As a result of this lookup, the ingress PE router determines an MPLS label stack, a data link header, and an output interface. The label stack is prepended to the packet, the data link header is prepended to that, and the resulting frame is queued for the output interface. The innermost label in the MPLS label stack is called the VPN route label. The VPN route label is significant and visible to the egress PE router only. It controls forwarding of the packet by the egress PE router. The outermost label in the MPLS label stack is called the tunnel label. The tunnel label causes the packet to be delivered to the egress PE router which understands the VPN route label. Specifically, the tunnel label identifies an MPLS LSP that connects the ingress PE router to the egress PE router. In the context of BGP/MPLS IP VPNs, this LSP is called a tunnel LSP. The tunnel LSP provides a forwarding path between the ingress and egress PE routers. QoS information can be mapped from the VPN packet to the tunnel LSP header so that required forwarding behaviors can be maintained at each hop along the forwarding path. Sections 9 and 10 of reference [2] define more complex configurations (i.e., carriers' carrier and multi-AS backbones) in which service providers offer L3VPN services across multiple automous systems. In these configurations, VPN route labels can be stitched together across AS boundares. Within each AS, tunnel LSPs carry VPN packets from network edge to network edge. Rekhter, et al. Expires February 5, 2006 [Page 4] Internet-Draft L3VPN GRE August 2005 In most configurations, tunnel LSPs never traverse AS boundaries. The tunnel LSP is always contained within a single AS. In one particular configuration (i.e., Inter-provider Option C), tunnel LSPs may traverse AS boundaries. This memo describes procedures for creating an MPLS packet which carries the VPN route label, but does not carry the tunnel label. Then, using either GRE or IP encapsulation, the ingress PE router sends the MPLS packet across the network to the egress PE router. That is, a GRE or IP tunnel replaces the tunnel LSP that was present in "conventional" BGP/MPLS IP VPNs. Like the tunnel LSP, the GRE/IP tunnel provides a forwarding path between the ingress and egress PE routers. QoS information can be copied from the VPN packet to the GRE/IP tunnel header so that required forwarding behaviors can be maintained at each hop along the forwarding path. However, because the GRE/IP tunnel lacks traffic engineering capabilities, any traffic engineering features provided by the tunnel LSP are lost. Rekhter, et al. Expires February 5, 2006 [Page 5] Internet-Draft L3VPN GRE August 2005 3. Motivation "Conventional" BGP/MPLS IP VPNs require an MPLS Label Switched Path (LSP) between a packet's ingress PE router and its egress PE router. This means that a BGP/MPLS IP VPN cannot be implemented if there is a part of the path between the ingress and egress PE routers which does not support MPLS. In order to enable BGP/MPLS IP VPNs to be deployed even when there are non-MPLS routers along the path between the ingress and egress PE routers, it is desirable to have an alternative which allows the tunnel label to be replaced with either IP or (IP + GRE) header. The encapsulation header would have the address of the egress PE router in its destination IP address field, and this would cause the packet to be delivered to the egress PE router. In this procedure, the ingress and egress PE routers themselves must support MPLS, but that is not an issue, as those routers must necessarily have BGP/MPLS IP VPN support, whereas the transit routers need not support MPLS or BGP/MPLS VPNs. Rekhter, et al. Expires February 5, 2006 [Page 6] Internet-Draft L3VPN GRE August 2005 4. Specification In short, the technical approach specified here is: 1. Continue to use MPLS to identify a VPN route, by continuing to add an MPLS label stack to the VPN packets. Between the ingress and egress PE router, the outermost member of the label stack will represent the VPN route label. 2. An MPLS-in-GRE or MPLS-in-IP [6] encapsulation will be used to turn the MPLS packet, described above, back into an IP packet. This in effect creates a GRE or an IP tunnel between the ingress PE router and the egress PE router. The net effect is that an MPLS packet gets sent through a GRE or an IP tunnel. Service providers must protect the above mentioned IP or GRE tunnel as recommended in Section 8.2 of reference [6]. As stated in that document, "If the tunnel lies entirely within a single administrative domain, address filtering at the boundaries can be used to ensure that no packet with the IP source address of a tunnel endpoint or with the IP destination address of a tunnel endpoint can enter the domain from outside. However, when the tunnel head and the tunnel tail are not in the same administrative domain, this may become difficult, and filtering based on the destination address can even become impossible if the packets must traverse the public Internet. Sometimes only source address filtering (but not destination address filtering) is done at the boundaries of an administrative domain. If this is the case, the filtering does not provide effective protection at all unless the decapsulator of an MPLS-in-IP or MPLS-in-GRE validates the IP source address of the packet. This document does not require that the decapsulator validate the IP source address of the tunneled packets, but it should be understood that failure to do so presupposes that there is effective destination-based (or a combination of source-based and destination-based) filtering at the boundaries." 4.1 MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE The following description is not meant to specify an implementation strategy; any implementation procedure which produces the same result Rekhter, et al. Expires February 5, 2006 [Page 7] Internet-Draft L3VPN GRE August 2005 is acceptable. When an ingress PE router receives a packet from a CE router, it looks up the packet's destination IP address in a VRF that is associated with packet's ingress attachment circuit. This enables the (ingress) PE router to find a VPN-IP route. The VPN-IP route will have an associated VPN route label and an associated BGP Next Hop. The label is pushed on the packet. Then an IP (or IP+GRE) encapsulation header is prepended to the packet, creating an MPLS-in-IP (or MPLS-in-GRE) encapsulated packet. The IP source address field of the encapsulation header will be an address of the ingress PE router itself. The IP destination address field of the encapsulation header will contain the value of the associated BGP Next Hop; this will be an IP address of the egress PE router. QoS information can be copied from the VPN packet to the GRE/IP tunnel header so that required forwarding behaviors can be maintained at each hop along the forwarding path. The IP address of the remote tunnel endpoints MAY be inferred from the Network Address of the Next Hop field of the MP_REACH_NLRI BGP attribute [4]. Note that the set of Next Hop Network Addresses is not known in advance, but is learned dynamically via the BGP distribution of VPN-IP routes. Assuming a consistent set of tunnel capabilities exist between all the PE's and ASBR's, no apriori configuration of the remote tunnel endpoints is needed. The entire set of PE and ASBR routers MUST have the same tunnel capabilities if the dynamic creation of IP (or GRE) tunnels is desired. The preference to use an IP (or GRE) tunnel MUST be configured. A set of PE's using two or more tunnel mechanisms (i.e. LSP, GRE, IP, etc.) MUST determine the tunnel type on a per peer basis. The automatic association of tunnel capabilities on a per peer basis is for future study. Note that these tunnels SHOULD NOT be IGP-visible links and routing adjacencies SHOULD NOT be supported across these tunnel. 4.2 MPLS-in-IP/MPLS-in-GRE Decapsulation by Egress PE Every egress PE is also an ingress PE, and hence has the ability to decapsulate MPLS-in-IP (or MPLS-in-GRE) packets. After decapsulation, the packets SHOULD be delivered to the routing function for ordinary MPLS switching. As stated above, if the service provider deploys source-based filtering at network edges to protect the IP/GRE tunnel (instead of destination-based filtering), the decapsulator must validate the IP source address of the tunneled packets. Rekhter, et al. Expires February 5, 2006 [Page 8] Internet-Draft L3VPN GRE August 2005 5. Implications On Packet Spoofing It should be noted that if the tunnel MPLS labels are replaced with an unsecured IP encapsulation, like GRE or IP, it becomes more difficult to protect the VPNs against spoofed packets. This is because a Service Provider (SP) can protect against spoofed MPLS packets by the simple expedient of not accepting MPLS packets from outside its own boundaries (or more generally by keeping track of which labels are validly received over which interfaces, and discarding packets which arrive with labels that are not valid for their incoming interfaces). By contrast, protection against spoofed IP packets requires all SP boundary routers to perform filtering; either (a) filtering packets from "outside" of the SP which are addressed to PE routers, or (b) filtering packets from "outside" of the SP which have source addresses that belong "inside" and, in addition, filtering on each PE all packets which have source addresses that belong "outside" of the SP. The maintenance of these filter lists can be management intensive. Furthermore, depending upon implementation, these filter lists can be performance affecting. However, such filters may be required for reasons other than protection against spoofed VPN packets, in which case the additional maintenance overhead of these filters to protect (among other things) against spoofing of VPN packets may be of no practical significance. Note that allocating IP addresses used for GRE or IP tunnels out of a single (or a small number of) IP block could simplify maintenance of the filters. Rekhter, et al. Expires February 5, 2006 [Page 9] Internet-Draft L3VPN GRE August 2005 6. Security Considerations Security considerations in reference [6] apply here as well. Additional security issues are discussed in the section "Implications on packet spoofing" above. Rekhter, et al. Expires February 5, 2006 [Page 10] Internet-Draft L3VPN GRE August 2005 7. IANA Considerations No actions for IANA required. Rekhter, et al. Expires February 5, 2006 [Page 11] Internet-Draft L3VPN GRE August 2005 8. Acknowledgments Thanks to Robert Raszuk and Scott Wainner for their contributions to this document. 9. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosen, E., "BGP/MPLS IP VPNs", draft-ietf-l3vpn-rfc2547bis-03 (work in progress), October 2004. [3] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [4] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. [5] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [6] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005. Authors' Addresses Yakov Rekhter Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US Email: yakov@juniper.net Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 US Email: rbonica@juniper.net Rekhter, et al. Expires February 5, 2006 [Page 12] Internet-Draft L3VPN GRE August 2005 Eric C. Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 US Email: erosen@cisco.com Rekhter, et al. Expires February 5, 2006 [Page 13] Internet-Draft L3VPN GRE August 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Rekhter, et al. Expires February 5, 2006 [Page 14] --------------000406080004060802000609-- From l3vpn-bounces@ietf.org Thu Aug 04 15:50:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ljH-0001sK-AR; Thu, 04 Aug 2005 15:50:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0lj9-0001p7-0S; Thu, 04 Aug 2005 15:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04575; Thu, 4 Aug 2005 15:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0mG5-0005UF-Qb; Thu, 04 Aug 2005 16:24:06 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E0lj7-0006Fa-SL; Thu, 04 Aug 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 04 Aug 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-gre-ip-2547-05.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : Use of PE-PE GRE or IP in BGP/MPLS IP Virtual Private Networks Author(s) : Y. Rekhter, et al. Filename : draft-ietf-l3vpn-gre-ip-2547-05.txt Pages : 14 Date : 2005-8-4 This draft describes an implementation strategy for BGP/MPLS IP Virtual Private Networks (VPNs) in which the outermost MPLS label (i.e., the tunnel label) is replaced with either an IP header or an IP header with Generic Routing Encapsulation (GRE). The implementation strategy described herein enables the deployment of BGP/MPLS IP VPN technology in networks whose edge devices are MPLS and VPN aware, but whose interior devices are not. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-gre-ip-2547-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l3vpn-gre-ip-2547-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l3vpn-gre-ip-2547-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-4143434.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-gre-ip-2547-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-gre-ip-2547-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-4143434.I-D@ietf.org> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Mon Aug 08 11:21:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E29RU-0003FF-Oj; Mon, 08 Aug 2005 11:21:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E29RS-0003FA-5i for l3vpn@megatron.ietf.org; Mon, 08 Aug 2005 11:21:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27971 for ; Mon, 8 Aug 2005 11:21:27 -0400 (EDT) Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E29zA-0002pa-VP for l3vpn@ietf.org; Mon, 08 Aug 2005 11:56:21 -0400 Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 16:21:13 +0100 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 16:21:13 +0100 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Aug 2005 11:21:12 -0400 Received: from [172.25.42.155] ([172.25.42.155]) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 11:21:12 -0400 Message-ID: <42F77868.9060203@juniper.net> Date: Mon, 08 Aug 2005 11:21:12 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l3vpn@ietf.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2005 15:21:12.0212 (UTC) FILETIME=[CF67FD40:01C59C2C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Content-Transfer-Encoding: 7bit Subject: IETF 63 L3VPN Minutes X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Folks, Thanks to Hamid, Spencer and Scott for taking minutes. If I hear no objections by Friday, I will post these minutes plus all slides that were presented. Ron =================================================================== Layer 3 Virtual Private Networks (Internet Area) Monday, August 1 at 16:30-18:00 ============================== Chairs: Ross Callon Rick Wilder Ron Bonica Agenda: 16:30-16:40 Document Status Review - Ross Callon Ross presented the status review. - Made good progress. Ross mentioned the new RFCs published. - bgp/mpls vpn specification initially waiting for addressing the BGP extended communities within the idr wg. Recently it was approved to progress and bgp/mpls vpn can progress now. - iesg evaluation for pe-pe gre or ip in bgp/mpls, revised text in wg last call. - ospf for PE-CE protocol (revised in may) waiting for iesg. - bgp auto-discovery revised given the feedback received, back to AD. - Waiting for write-up: - Constrained VPN route distrib updated, waiting on chairs - BGP-MPLS IP VPN for IPv6 updated, recently provided to IESG. - Revised id needed: Virtual Router Architecture and its associated applicability statement. Comments sent to authors. - Under AD evaluation: An architecture for PP CE-based VPNs using IPsec and associated AS needs review and update. - Architecture for PE-PE IPSec tunnel for bgp/mpls ip vpns recently updated based on last call comments - Current work: o Requirement for multicast o Multicast solution in bgp ip vpn o CE-CE member verification o l3vpn import export verification (no activity on the above 2 docs). o appl stat, framework o definition textual convention mib for bgp/mpls ip vpn. Multicast VPN Requirements - Thomas Morin draft-ietf-l3vpn-ppvpn-mcast-reqts-01 ========================================= Thomas Morin presented the draft-id. - A new update posted 2 weeks ago. - in this presentation will go through the changes, the multicast vpn survey, and we talk about next work. - On the changes 2 new sections in the draft have been added. o Carrier's carrier requirements and o New section on QoS (ability to offer different QoS level to different customers. - Updated sections: QoS (5.1.3) maintain join and leave delay requirement (refer to RFC2432)and minimum MTU. - Tunneling technologies need to mention P2MP LSP as much possible. - Compatibility and migration issues solution should state a migration policy. - Trouble shooting provide the operator with means LSP ping - inter-as section (should provide inter-as mechanism requiring least.... - Big changes on section 4 (Uses cases) illustrated deployment requirements. - describe use cases scenarios - provide order of magnitude for scalability requirement, - waiting for survey. - finally some edits changes... - For multicast vpn survey (proposed at last ietf) - survey overview (to be answered mainly by ISPs) - focus on future expected deployments. - typical questions Quantitative and qualitative (type of multicast deployed, etc). - Survey launched last week posted on different WG lists please answer it and send completed survey to Daniel King Dan (dnni.com) - answers expected by Sept 15 05. Tom described the Next items for the draft such as: o complete section 4 with the help of the survey and o refine the requirements (PE-Ce protocols, inter-AS, carrier's carrier, extranet tunneling protocols, etc) o Address some open questions relevance of MTU-related sections. - Conclusion: requirement is mostly mature except section 4. Tom asked the audience to provide comments on the draft on the mailing list and answer and disseminate the survey. - Questions on the draft: no questions. Multicast VPN Solution - Rahul Aggarwal draft-ietf-l3vpn-2547bis-mcast-00 ======================================== Rahul presented the draft: This is an update on multicast draft, this is Wg document. Rahul shows the co-authors/contributors, fully committed to move this work forward, This presentation for discussion open options. Reduce options if possible, outline the issues and specify required and optional procedures, looking at MVPN routing information exchange service provider technologies - need to look at scalability of entire network. consider rate of churn C-joins/Prunes number of protocol sessions require frequent periodic changes - how does it fit with 2547 operational model unicast Rahul shows a table for MVPN routing exchange not exhaustive list. Periodic refresh, session per PE UI-PMSI,. etc. for BGP, PIM UNicast, PIM multicast... - Do we really need PIM-SM with GRE? Discovery can be done using BGP, shared trees can be built with PIM-SSM. Conclusion Goal to address these issues and produce 01 version. Ross: is you proposal is to propose this options to the WG list. Make Wg aware of the options: - Ross Callon: is your proposal to ask these questions on the WG mailing list? Rahul: Yes. Want to capture these questions in the minutes. Send email on the list and initiate the discussion. -Question on BGP encoding to be published. They are already published encodings for BGP to carry MVPN information Rahul: Existing proposal may or may not be used. - Question (person from Cisco): Wants backward compatibility with what has been deployed for years and the Rosen draft. Rahul: Certain options have been deployed, some not. Point well taken. Need WG input. - Question: Deprecate PIM-SM? Some providers already use it. Rahul: Point taken. OK. - Question: need periodic refreshment. There is are WG items that try to reduce periodic refreshes. Need to consider these approaches other that may reduce the overhead. - Albert, Redback: PIM needs periodic refresh? There's some work in PIM WG to reduce periodic refreshes. Need to consider these approaches. Rahul: Yes, need to look at pragmatic options, point taken. - Question (from Cisco): What is a service? The only difference to the MVPN service is whether using SSM or ASM. The protocol you use to implement it should be a separate issue. Rahul: draft should talk about applicability of protocols. Draft has told about tunneling technologies Yakov Rekhter: I disagree. Need to specify which protocol for interoperability reasons. Toerless: same with IS-IS and OSPF. Yakov: yes. Toerless: what does rfc2547 say about IS-IS? Dan Alvarez: At least why do we think BGP is suitable. For example there is no information on dynamic building of OSPF trees etc. Comment (Person): this is the wrong level of detail. Why this need to be specified. Yakov: I disagree because of interoperability reasons need to specify which protocol to use. Question (Albert from Cisco): last comment: how well bgp is suitable for multicast bgp is not used for intra multicast operation, why BGP is suitable. no information on dynamic multicast tree and how it related to scalability. why use BGP as replacement for all existing multicast protocols... Rahul: Not talking of building trees with BGP, just transporting with BGP. one item for consideration Alcatel: The one thing for BGP helps is to provide a reliable transport. Rahul: Note that BGP does have filtering mechanism...and is applicable in this case. Ross: some of discussion can go to the text... Multicast VPN MIB - Tom Nadeau draft-svaidya-mcast-vpn-mib-02 ================================ Tom presented the draft. Propose this document to manage rosen-multicast doc. interacts well with MPLS MIBS. draft need to use the combined approach will be published soon after meeting. - Ross: Have you got input? - Tom: Yes. Will be published soon. - Tom: Can we publish it directly as Wg doc. - Ross: The MIB managed the combined draft. When the MIB will be updated to reflect combined drafts then we have two choices: either submit as individual contribution and request WG to ask for WGs, or just make it wg doc. Ross: My personal option if the authors of both sides agree this is the agreed way forward then I don't see objections to adopt it as WG doc. Ross: Does anybody has any objection to that? No objection from audience... Virtual Router Multicast Solution - Hong-Ke Zhang draft-zhang-l3vpn-vr-mcast-01.txt. ================================================= Presenter: Spencer Dawkins. Spencer mentioned Zhang couldn't make the meeting. There were some scalability questions on the mailing list such as the number of trees in SP core will not exceed the number of VRs, and does all multicast traffic in a VR share the same tree, answer yes. Does this approach require PIM-DM mode answer no, next version will say this more clearly. Questions: - Ross: whose read the draft: - Ross: few hand for those who read the document. Obvious question out of 10 would that be any objection for those become WGs. Not quite enough need to take it to the WG list and ask the question. - Ross: if anybody is interested in deploying multicast for vr please bring those to the mailing list. From l3vpn-bounces@ietf.org Mon Aug 08 15:50:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Ddj-00043w-7B; Mon, 08 Aug 2005 15:50:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2DdM-0003tK-Bl; Mon, 08 Aug 2005 15:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13734; Mon, 8 Aug 2005 15:50:02 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2EB6-00029Z-3H; Mon, 08 Aug 2005 16:24:56 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E2DdJ-0003mx-Pk; Mon, 08 Aug 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 08 Aug 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-ipsec-2547-05.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs Author(s) : E. Rosen, et al. Filename : draft-ietf-l3vpn-ipsec-2547-05.txt Pages : 18 Date : 2005-8-8 In BGP/MPLS IP Virtual Private Networks (VPNs), VPN data packets traveling from one Provider Edge (PE) router to another generally carry two MPLS labels, an "inner" label that corresponds to a VPN- specific route, and an "outer" label that corresponds to a Label Switched Path (LSP) between the PE routers. In some circumstances, it is desirable to support the same type of VPN architecture, but using an IPsec Security Association in place of that LSP. The "outer" MPLS label would thus be replaced by an IP/IPsec header. This enables the VPN packets to be carried securely over non-MPLS networks, using standard IPsec authentication and/or encryption functions to protect them. This draft specifies the procedures which are specific to support of BGP/MPLS IP VPNs using the IPsec encapsulation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-ipsec-2547-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l3vpn-ipsec-2547-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l3vpn-ipsec-2547-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-8140123.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-ipsec-2547-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-ipsec-2547-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-8140123.I-D@ietf.org> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Mon Aug 08 19:09:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2GkU-0000BG-9t; Mon, 08 Aug 2005 19:09:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2GkT-0000B3-0b for l3vpn@megatron.ietf.org; Mon, 08 Aug 2005 19:09:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00972 for ; Mon, 8 Aug 2005 19:09:33 -0400 (EDT) Received: from rwcrmhc12.comcast.net ([204.127.198.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2HIF-0001Fw-2m for l3vpn@ietf.org; Mon, 08 Aug 2005 19:44:32 -0400 Received: from [127.0.0.1] (unknown[65.104.224.98]) by comcast.net (rwcrmhc12) with ESMTP id <2005080823092201400ppfrme>; Mon, 8 Aug 2005 23:09:24 +0000 Message-ID: <42F7E60B.7030405@mcsr-labs.org> Date: Mon, 08 Aug 2005 18:08:59 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: l3vpn@ietf.org References: <42F77868.9060203@juniper.net> In-Reply-To: <42F77868.9060203@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Subject: Re: IETF 63 L3VPN Minutes X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: spencer@mcsr-labs.org List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org My apologies, because my meeting notes ran out while I was presenting :-) I remember about three questions from the working group meeting at the end of my presentation on draft-zhang-l3vpn-vr-mcast-01.txt, and was hoping that the meeting minutes would contain them - I know one was a request that we explicitly reference specific requirements from the multicast requirements document - does anyone remember what the other two questions were? Thanks! Spencer Ron Bonica wrote: > Folks, > > Thanks to Hamid, Spencer and Scott for taking minutes. If I hear no > objections by Friday, I will post these minutes plus all slides that > were presented. > > Ron > > Virtual Router Multicast Solution - Hong-Ke Zhang > draft-zhang-l3vpn-vr-mcast-01.txt. > ================================================= > deleted down to > > Questions: > > - Ross: whose read the draft: > > - Ross: few hand for those who read the document. Obvious question > out of 10 would that be any objection for those become WGs. Not quite > enough need to take it to the WG list and ask the question. > > > - Ross: if anybody is interested in deploying multicast for > vr please bring those to the mailing list. From l3vpn-bounces@ietf.org Tue Aug 09 17:36:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2blS-0007cd-GY; Tue, 09 Aug 2005 17:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2blQ-0007Yy-C6 for l3vpn@megatron.ietf.org; Tue, 09 Aug 2005 17:36:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16204 for ; Tue, 9 Aug 2005 17:35:57 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2cJO-00088X-TW for l3vpn@ietf.org; Tue, 09 Aug 2005 18:11:07 -0400 Received: from [147.28.0.62] (helo=usmovnazinin.alcatel.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2blO-000Jse-DF; Tue, 09 Aug 2005 21:35:58 +0000 Date: Tue, 9 Aug 2005 14:35:45 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1292446966.20050809143545@psg.com> To: Ron Bonica In-Reply-To: <42F77868.9060203@juniper.net> References: <42F77868.9060203@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 Content-Transfer-Encoding: 7bit Cc: l3vpn@ietf.org Subject: Re: IETF 63 L3VPN Minutes X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Ron, In many places below "Cisco" or "Alcatel" have been used instead of names. Can we please fix this? -- Alex http://www.psg.com/~zinin Monday, August 8, 2005, 8:21:12 AM, Ron Bonica wrote: > Folks, > Thanks to Hamid, Spencer and Scott for taking minutes. If I hear no > objections by Friday, I will post these minutes plus all slides that > were presented. > Ron > =================================================================== > Layer 3 Virtual Private Networks (Internet Area) > Monday, August 1 at 16:30-18:00 > ============================== > Chairs: > Ross Callon > Rick Wilder > Ron Bonica > Agenda: > 16:30-16:40 Document Status Review - Ross Callon > Ross presented the status review. > - Made good progress. Ross mentioned the new RFCs > published. > - bgp/mpls vpn specification initially waiting for addressing > the BGP extended communities within the idr wg. Recently it > was approved to progress and bgp/mpls vpn can progress now. > - iesg evaluation for pe-pe gre or ip in bgp/mpls, revised text > in wg last call. > - ospf for PE-CE protocol (revised in may) waiting for iesg. > - bgp auto-discovery revised given the feedback received, back > to AD. > - Waiting for write-up: > - Constrained VPN route distrib updated, waiting on chairs > - BGP-MPLS IP VPN for IPv6 updated, recently provided to IESG. > - Revised id needed: > Virtual Router Architecture and its associated applicability > statement. Comments sent to authors. > - Under AD evaluation: > An architecture for PP CE-based VPNs using IPsec and associated > AS needs review and update. > - Architecture for PE-PE IPSec tunnel for bgp/mpls ip vpns > recently updated based on last call comments > - Current work: > o Requirement for multicast > o Multicast solution in bgp ip vpn > o CE-CE member verification > o l3vpn import export verification (no activity on the above 2 docs). > o appl stat, framework > o definition textual convention mib for bgp/mpls ip vpn. > Multicast VPN Requirements - Thomas Morin > draft-ietf-l3vpn-ppvpn-mcast-reqts-01 > ========================================= > Thomas Morin presented the draft-id. > - A new update posted 2 weeks ago. > - in this presentation will go through the changes, > the multicast vpn survey, and we talk about next work. > - On the changes 2 new sections in the draft have been added. > o Carrier's carrier requirements and > o New section on QoS (ability to offer different QoS level to > different customers. > - Updated sections: QoS (5.1.3) maintain join and leave delay > requirement > (refer to RFC2432)and minimum MTU. > - Tunneling technologies need to mention P2MP LSP as much possible. > - Compatibility and migration issues solution should state > a migration policy. > - Trouble shooting provide the operator with > means LSP ping > - inter-as section (should provide inter-as mechanism requiring > least.... > - Big changes on section 4 (Uses cases) illustrated deployment > requirements. > - describe use cases scenarios > - provide order of magnitude for scalability requirement, > - waiting for survey. > - finally some edits changes... > - For multicast vpn survey (proposed at last ietf) > - survey overview (to be answered mainly by ISPs) > - focus on future expected deployments. > - typical questions Quantitative and qualitative (type of multicast > deployed, etc). > - Survey launched last week posted on different WG lists > please answer it and send completed survey to Daniel King Dan > (dnni.com) > - answers expected by Sept 15 05. > Tom described the Next items for the draft such as: > o complete section 4 with the help of the survey and > o refine the requirements (PE-Ce protocols, inter-AS, > carrier's carrier, extranet tunneling protocols, etc) > o Address some open questions relevance of MTU-related sections. > - Conclusion: requirement is mostly mature except section 4. > Tom asked the audience to provide comments on the draft > on the mailing list and answer and disseminate the survey. > - Questions on the draft: no questions. > Multicast VPN Solution - Rahul Aggarwal > draft-ietf-l3vpn-2547bis-mcast-00 > ======================================== > Rahul presented the draft: > This is an update on multicast draft, this is Wg document. > Rahul shows the co-authors/contributors, > fully committed to move this work forward, > This presentation for discussion open options. > Reduce options if possible, outline the issues and > specify required and optional procedures, > looking at MVPN routing information exchange > service provider technologies > - need to look at scalability of entire network. > consider rate of churn C-joins/Prunes > number of protocol sessions require frequent periodic > changes > - how does it fit with 2547 operational model unicast > Rahul shows a table for MVPN routing exchange > not exhaustive list. Periodic refresh, session per PE UI-PMSI,. etc. > for BGP, PIM UNicast, PIM multicast... > - Do we really need PIM-SM with GRE? Discovery can be done using > BGP, shared trees can be built with PIM-SSM. > Conclusion > Goal to address these issues and produce 01 version. > Ross: is you proposal is to propose this options to > the WG list. Make Wg aware of the options: > - Ross Callon: is your proposal to ask these questions on the WG > mailing list? > Rahul: Yes. Want to capture these questions in the > minutes. Send email on the list and initiate the > discussion. > -Question on BGP encoding to be published. They are already published > encodings for BGP to carry MVPN information > Rahul: Existing proposal may or may not be used. > - Question (person from Cisco): Wants backward compatibility with what > has been > deployed for years and the Rosen draft. > Rahul: Certain options have been deployed, some not. Point well taken. > Need WG input. > - Question: Deprecate PIM-SM? Some providers already use > it. > Rahul: Point taken. OK. > - Question: need periodic refreshment. There is are WG items that try > to reduce periodic refreshes. Need to consider these approaches other > that may reduce the overhead. > - Albert, Redback: PIM needs periodic refresh? There's some work in > PIM WG to reduce periodic refreshes. Need to consider these > approaches. > Rahul: Yes, need to look at pragmatic options, point taken. > - Question (from Cisco): What is a service? The only difference to the > MVPN service is whether using SSM or ASM. The protocol you use to > implement it should be a separate issue. > Rahul: draft should talk about applicability of protocols. > Draft has told about tunneling technologies > Yakov Rekhter: I disagree. Need to specify which protocol for > interoperability reasons. > Toerless: same with IS-IS and OSPF. > Yakov: yes. > Toerless: what does rfc2547 say about IS-IS? > Dan Alvarez: At least why do we think BGP is suitable. For > example there is no information on dynamic building of OSPF trees > etc. > Comment (Person): this is the wrong level of detail. Why this need to be > specified. > Yakov: I disagree because of interoperability reasons need to specify > which protocol > to use. > Question (Albert from Cisco): last comment: how well bgp is suitable for > multicast > bgp is not used for intra multicast operation, why BGP is suitable. > no information on dynamic multicast tree and how it related to > scalability. > why use BGP as replacement for all existing multicast protocols... > Rahul: Not talking of building trees with BGP, > just transporting with BGP. one item for consideration > Alcatel: The one thing for BGP helps is to provide a reliable transport. > Rahul: Note that BGP does have filtering mechanism...and is applicable > in this case. > Ross: some of discussion can go to the text... > Multicast VPN MIB - Tom Nadeau > draft-svaidya-mcast-vpn-mib-02 > ================================ > Tom presented the draft. > Propose this document to manage rosen-multicast doc. interacts > well with MPLS MIBS. > draft need to use the combined approach will be published soon > after meeting. > - Ross: Have you got input? > - Tom: Yes. Will be published soon. > - Tom: Can we publish it directly as Wg doc. > - Ross: The MIB managed the combined draft. When the MIB will be > updated to reflect combined drafts then we have two choices: > either submit as individual contribution and request WG to > ask for WGs, or just make it wg doc. > Ross: My personal option if the authors of both sides agree this is > the agreed way forward then I don't see objections to adopt it > as WG doc. > Ross: Does anybody has any objection to that? > No objection from audience... > Virtual Router Multicast Solution - Hong-Ke Zhang > draft-zhang-l3vpn-vr-mcast-01.txt. > ================================================= > Presenter: Spencer Dawkins. Spencer mentioned Zhang couldn't make the > meeting. > There were some scalability questions on the mailing list such > as the number of trees in SP core will not exceed the number of > VRs, and does all multicast traffic in a VR share the same tree, > answer yes. > Does this approach require PIM-DM mode > answer no, next version will say this more clearly. > Questions: > - Ross: whose read the draft: > - Ross: few hand for those who read the document. Obvious question > out of 10 would that be any objection for those become WGs. Not quite > enough need to take it to the WG list and ask the question. > - Ross: if anybody is interested in deploying multicast for > vr please bring those to the mailing list. From l3vpn-bounces@ietf.org Tue Aug 09 19:33:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2dan-00041Y-MB; Tue, 09 Aug 2005 19:33:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2dam-00041K-16 for l3vpn@megatron.ietf.org; Tue, 09 Aug 2005 19:33:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23428 for ; Tue, 9 Aug 2005 19:33:04 -0400 (EDT) Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2e8l-0002SJ-2t for l3vpn@ietf.org; Tue, 09 Aug 2005 20:08:16 -0400 Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Aug 2005 00:32:48 +0100 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Aug 2005 00:32:48 +0100 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Aug 2005 19:32:47 -0400 Received: from [172.23.1.4] ([172.23.1.4]) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Aug 2005 19:32:46 -0400 Message-ID: <42F93D1C.6070005@juniper.net> Date: Tue, 09 Aug 2005 19:32:44 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin References: <42F77868.9060203@juniper.net> <1292446966.20050809143545@psg.com> In-Reply-To: <1292446966.20050809143545@psg.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2005 23:32:46.0568 (UTC) FILETIME=[A5D34E80:01C59D3A] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: l3vpn@ietf.org Subject: Re: IETF 63 L3VPN Minutes X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Alex, Sure thing. All, Please review the minutes. If you are "the person from Cisco" or "the person from Alcatel", please send me a private email so that I can include your name in the minutes. Ron Alex Zinin wrote: > Ron, > > In many places below "Cisco" or "Alcatel" have been used instead of > names. Can we please fix this? > From l3vpn-bounces@ietf.org Thu Aug 11 17:34:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Kh1-0001X3-3N; Thu, 11 Aug 2005 17:34:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Kgz-0001Wq-6F for l3vpn@megatron.ietf.org; Thu, 11 Aug 2005 17:34:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28615 for ; Thu, 11 Aug 2005 17:34:22 -0400 (EDT) Received: from web306.biz.mail.mud.yahoo.com ([68.142.199.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E3LFH-00013o-18 for l3vpn@ietf.org; Thu, 11 Aug 2005 18:09:54 -0400 Received: (qmail 75306 invoked by uid 60001); 11 Aug 2005 21:34:02 -0000 Message-ID: <20050811213402.75304.qmail@web306.biz.mail.mud.yahoo.com> Received: from [192.160.6.253] by web306.biz.mail.mud.yahoo.com via HTTP; Thu, 11 Aug 2005 14:34:01 PDT Date: Thu, 11 Aug 2005 14:34:01 -0700 (PDT) From: Rick Wilder To: l3vpn@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-787390693-1123796041=:74936" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: last call on draft-ietf-l3vpn-gre-ip-2547-04 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org --0-787390693-1123796041=:74936 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit The L3VPN last call on draft-ietf-l3vpn-gre-ip-2547-04 is now closed. The comments that were received have been incorporated into the newly submitted draft-ietf-l3vpn-gre-ip-2547-05. Rick --0-787390693-1123796041=:74936 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
 
 
The L3VPN last call on draft-ietf-l3vpn-gre-ip-2547-04 is now closed.
 
The comments that were received have been incorporated into the newly submitted draft-ietf-l3vpn-gre-ip-2547-05.
 
Rick
 
 
--0-787390693-1123796041=:74936-- From l3vpn-bounces@ietf.org Tue Aug 16 19:27:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5AqR-00012T-S2; Tue, 16 Aug 2005 19:27:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5AqQ-00012M-1R for l3vpn@megatron.ietf.org; Tue, 16 Aug 2005 19:27:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20370 for ; Tue, 16 Aug 2005 19:27:42 -0400 (EDT) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5BPq-0002A9-Hf for l3vpn@ietf.org; Tue, 16 Aug 2005 20:04:23 -0400 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id 55798E0000A9 for ; Wed, 17 Aug 2005 00:27:36 +0100 (BST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 17 Aug 2005 00:27:14 +0100 Message-ID: Thread-Topic: Reminder: Multicast VPN Survey Thread-Index: AcWSxQbkYH/ThfzHRJmc+oCs9qzRVQPus7dwAA2YoOAAAK95wA== From: "Daniel King" To: X-Spam-Score: 1.2 (+) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Content-Transfer-Encoding: quoted-printable Subject: Reminder: Multicast VPN Survey X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Hi Folks, We have had a good response since we sent out the original email. I wanted to just remind everyone, that there is still time to submit your completed survey before we publish the results in September.=20 Kind Regards, Dan -----Original Message----- Date: Wed, 27 Jul 2005 10:18:56 +0200 From: Thomas Morin Subject: Multicast VPN Survey To: L3VPN Message-ID: <1122452337.19757.23.camel@wintermute> Content-Type: text/plain; charset=3D"us-ascii" Hello, Here is the Multicast VPN survey that we prepared to complement draft-ietf-l3vpn-ppvpn-mcast-reqts with relevant informations about scalability expectations and priorities. Please broadcast this survey to organizations and/or people that you know may be interested in the deployments of such solutions. Completed surveys sould be send, before September 15th, to Daniel King , who will anonymise the answers. Thank you very much, -Thomas Morin -------------- next part -------------- Multicast VPN Survey - July 2005 1. Presentation 1.1 Context and goal Current work in the l3vpn IETF Working group include the definition=20 of requirements for Multicast in L3VPNs and the specifications of=20 multicast VPN solutions. In this perspective, the authors of the requirement draft [draft-ietf-l3vpn-ppvpn-mcast-reqts] are=20 initiating a survey to better detail requirements, and especially scalability requirements. A summary of the results of this survey will be included in the requirements document which should serve as guidelines for solution design. The scope of this survey is multicast in L3VPNs: the mechanisms setup by a VPN provider to carry customer multicast traffic of customers. 1.2 Answering this survey This survey will hopefuly be answered by ISPs planing to offer a multicast VPN service, and possibly by VPN customers having a need for such a service (not all questions of this survey will be relevant in that later case). If your are an ISP, the answers should relate not to what you'd expect today, but more to what you see as a longer term target=20 for such a service. For scalability figures, please answer what you think you would need to support in the longer term. If you expect many significantly different deployments, it is=20 possible to answer the survey multiple times. Please answer as much questions as possible, but feel free to ommit answers if the question aren't relevant for you. 1.3 Sending the results Once completed, we'd appreciate that you send the document to Daniel King , who will anonymize the survey=20 results before forwarding them to the L3VPN WG multicast VPN requirement drafts authors. Please have completed surveys sent before September 15th, 2005. Thank you very much ! 2. Questions This survey is divided into three parts. The first one relates to quantitative questions that can be quickly answered by a simple figure (numbers of multicast PEs, of multicast VPNs,...), and the second one is made of qualitative questions regarding the expected use of the service (features, dynamicity, client application use case patterns...). In the last part you can express more in detail considerations you may have about multicast VPN deployments, including for instance specific use cases you think may highlight specific important points. 2.1 Quantitative questions Here, we are just expecting rough figures and orders of magnitude, such as: 20k, tens of thousands, hundreds, ~7500, O(10^2), etc. 2.1.1 Deployment and offer 1. Number of VPNs for which multicast is made available * total: ....... * per PE: ....... If inter-AS and/or inter-provider context is relevant for you: * per AS : ...... * per provider : ...... 2. CEs per VPN per PE, for which multicast is enabled: .......... 3. number of PEs per VPN with multicast enabled (source or receiver): .......... 4. number of PEs with multicast service enabled: .......... 2.1.2 Parameters related to customer applications and usage patterns 1. Number of PEs connected to multicast receivers: .......... 2. Number of PEs connected to multicast sources: .......... 3. Number of multicast (*,G) or (S,G) sourced ... * ...per VPN: .......... * ...per PE: .......... * ...per CE: .......... 2.2 Qualitative questions 2.2.1 Expected VPN customer applications 1. Type of multicast applications Mutlicast applications deployed over a multicast VPN can be differentiated depending on many criterias, such as, for instance: real-time or not, bandwidth, receiver-source structure (one-to-many, many-to-many, many-to-few...), sensitivity to packet loss, number of streams... Please give examples of some possible applications, in the following form : realtime or not / number of sources / number of receivers / bandwidth / packet-loss sensitive / streams per application For instance:=20 real-time / few and known / many in unknown locations=20 / tens of Mbps / loss sensitive / hundreds of streams a) ........ b) ........ c) ......... ... 2. Dynamics * Do you expect customer applications that are sensitive to multicast join/latency (time to receive/leave a stream) ? ........ * What kind of frequency do you expect for mcast routing=20 changes, at the PE level ? (eg. "not more than XX leave and joins per hour") ........ * Predictability of sources and receivers locations: do you expect to be able, for each said multicast VPN customer, to have an a priori on the location of customer sources and/or receivers ? ........ 3. Customer side protocols: among the following, please chose which you'd expect to support at the CE-PE level (y/n) ? * PIM-SM: * PIM-SSM: * Bidir PIM:=20 * IGMP(v2/v3): * MLDv2:=20 * PIM-DM: 4. Would you plan to support multicast in a carrier's carrier context ? ........ 2.2.1 Network Considerations 1. Do you have PE for which reachability is less good than others (costly or scarce bandwidth) ? ........ 2. Do you think some VPNs of your customers may have same or close sets of PEs, and may thus possibly benefit from using the same PE-to-PE point to multipoint tunnels ? ........ 3. Do you plan to deploy multicast VPNs in a multi-AS context ? ........ 4. Do you plan to deploy multicast VPNs in a multi-provider context ? ........ 2.2.1 Relative Importance on different aspects Please rate the following items according to their relative importance - from 1 (Unimportant) to 5 (Important). * Seamless interoperability with the current unicast model: ... * Multicast VPN must not impose additional requirements on CE devices: ... * Re-use of existing multicast protocols for multcast traffic transport over the provider core network: ... * Support of TE features such as bandwidth reservation and admission control: ... * Provide the same level of security for both the customer and the SP as available with unicast VPNs: ... * Support for global Internet multicast (emission/reception): ... * Support for Extranet (having a VRF in more than one=20 multicast VPN): ... 3. Specific considerations you may want to express ........... ------------------------------ _______________________________________________ L3vpn mailing list L3vpn@ietf.org https://www1.ietf.org/mailman/listinfo/l3vpn End of L3vpn Digest, Vol 15, Issue 16 ************************************* From l3vpn-bounces@ietf.org Wed Aug 17 11:11:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5PZc-00084O-MI; Wed, 17 Aug 2005 11:11:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5PZb-00083t-33 for l3vpn@megatron.ietf.org; Wed, 17 Aug 2005 11:11:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06574 for ; Wed, 17 Aug 2005 11:11:20 -0400 (EDT) From: kkhanna@isocore.com Received: from ns1.cpanel.btnaccess.com ([205.177.121.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Q9A-0002O8-9V for l3vpn@ietf.org; Wed, 17 Aug 2005 11:48:08 -0400 Received: from cpanel by ns1.cpanel.btnaccess.com with local (Exim 4.52) id 1E5PZZ-0007cf-FJ for l3vpn@ietf.org; Wed, 17 Aug 2005 11:11:21 -0400 Received: from 65.213.193.37 ([65.213.193.37]) by www.isocore.com (Horde MIME library) with HTTP; Wed, 17 Aug 2005 11:11:21 -0400 Message-ID: <20050817111121.aqup3kuexi3kkscw@www.isocore.com> Date: Wed, 17 Aug 2005 11:11:21 -0400 To: l3vpn@ietf.org References: <20050815114930.im8ojyqh1aggocss@www.isocore.com> In-Reply-To: <20050815114930.im8ojyqh1aggocss@www.isocore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32001 502] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Subject: Important Info: MPLS 2005 (October 16-19; Washington DC) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Greetings, You are invited to participate in the premier event on MPLS and related technologies at the MPLS 2005 International Conference () to be held from October 16-19, 2005 in Washington DC. PROGRAM: ---------- The conference includes presentations by leading exterts on hot topics in MPLS and GMPLS, tutorials, exhibits by key vendors, a panel discussion by Service Providers on Advanced Services using MPLS, and a panel discussion by industry vendors on LDP versus RSVP-TE. Program details are available at: REGISTRATION: -------------- Registration is underway - to register, go to: HOTEL RESERVATIONS: -------------------- The designated Hotel for the MPLS 2005 International Conference is the Omni Shoreham Hotel in Washington, D.C. (Tel: 202-234-0700 or 800-843-6664). A limited number of rooms are available at special rates for conference attendees. We suggest you make your reservation as soon as possible, since October is typically a busy period for hotels in Washington DC. To make reservations please call the Hotel Reservation Desk directly. You must identify yourself as MPLS 2005 conference attendees for discounted rates. We look forward to your participation in this event. Regards, Kavita From l3vpn-bounces@ietf.org Wed Aug 24 05:14:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7rLX-0003OG-6t; Wed, 24 Aug 2005 05:14:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7rLU-0003O1-Me for l3vpn@megatron.ietf.org; Wed, 24 Aug 2005 05:14:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08647 for ; Wed, 24 Aug 2005 05:14:54 -0400 (EDT) Received: from web52013.mail.yahoo.com ([206.190.48.96]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E7rLg-0000ZB-M5 for l3vpn@ietf.org; Wed, 24 Aug 2005 05:15:15 -0400 Received: (qmail 65356 invoked by uid 60001); 24 Aug 2005 09:14:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=uhebnfwqo091IkGNlUI63vHN1AsCdxmTZEyNXZOJsbDGVPXsmR4KsTeCLS56F7z+qIIh+RTZj0pnRBypfz/NKTJ1vwliIcJUhmrORf8kcjgzGT4EsLM1yX559wBrjhvTc4pesnINUgNGGg3Ect/vdmnnIY0g69QfMTdgIpsi9FU= ; Message-ID: <20050824091439.65354.qmail@web52013.mail.yahoo.com> Received: from [212.175.65.58] by web52013.mail.yahoo.com via HTTP; Wed, 24 Aug 2005 02:14:39 PDT Date: Wed, 24 Aug 2005 02:14:39 -0700 (PDT) From: mehmet ozdem To: l3vpn@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-102919738-1124874879=:62643" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: (no subject) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org --0-102919738-1124874879=:62643 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit --------------------------------- Yahoo! Mail Stay connected, organized, and protected. Take the tour --0-102919738-1124874879=:62643 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Yahoo! Mail
Stay connected, organized, and protected. Take the tour --0-102919738-1124874879=:62643-- From l3vpn-bounces@ietf.org Thu Aug 25 00:48:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E89fC-0002Pb-MN; Thu, 25 Aug 2005 00:48:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E89fA-0002P6-4T for l3vpn@megatron.ietf.org; Thu, 25 Aug 2005 00:48:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14857 for ; Thu, 25 Aug 2005 00:48:25 -0400 (EDT) Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E89fZ-0005OM-Iw for l3vpn@ietf.org; Thu, 25 Aug 2005 00:48:56 -0400 Received: from unknown (HELO alpha.jnpr.net) (172.24.18.126) by kremlin.juniper.net with ESMTP; 24 Aug 2005 21:48:12 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,139,1122879600"; d="scan'208"; a="479169249:sNHT19266752" Received: from [127.0.0.1] ([207.17.136.44]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Aug 2005 21:48:11 -0700 Message-ID: <430D4D8A.9040602@juniper.net> Date: Wed, 24 Aug 2005 21:48:10 -0700 From: Pedro Roque Marques User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l3vpn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Aug 2005 04:48:11.0345 (UTC) FILETIME=[32115C10:01C5A930] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: draft-marques-l3vpn-ibgp X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org I've submitted a new version of this document: http://www.ietf.org/internet-drafts/draft-marques-l3vpn-ibgp-01.txt I'd like to ask the WG if there is interest in taking this as a working group document. o It is similar in scope to other work that is currently in the WG plate (e.g. ospf as pe-ce). o There is one implementation, there are deployments in several networks. Both myself and other co-authors have had interest expressed by other SP in having this document go through the standardization process. It would be nice to hear from SPs on the list if they are indeed interested. thanks, Pedro. From l3vpn-bounces@ietf.org Mon Aug 29 11:46:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9lqE-0003lQ-HG; Mon, 29 Aug 2005 11:46:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9lqD-0003lL-FJ for l3vpn@megatron.ietf.org; Mon, 29 Aug 2005 11:46:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17499 for ; Mon, 29 Aug 2005 11:46:31 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9lrY-0003w3-B1 for l3vpn@ietf.org; Mon, 29 Aug 2005 11:47:58 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 29 Aug 2005 08:45:53 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,150,1122879600"; d="scan'208"; a="7679907:sNHT19647252" Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7TFjpQl000639; Mon, 29 Aug 2005 11:45:51 -0400 (EDT) Message-Id: <200508291545.j7TFjpQl000639@rtp-core-2.cisco.com> To: l3vpn@ietf.org MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 29 Aug 2005 11:45:51 -0400 From: Eric Rosen X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: draft-ietf-l3vpn-ospf-2547-04 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org As a result of AD review, significant changes have been made to the specification draft-ietf-l3vpn-ospf-2547. These changes can be seen in the latest version, draft -04. It is believed that the draft now corresponds to the implementations. The following issues were addressed as a result of the AD review. The spec was written so as to allow a single VRF to correspond to multiple OSPF domains. However, it did not make clear just which parameters and procedures are relative to a domain, and which are relative to a VRF. This has now been cleared up. However, doing so required extensive textual changes. There are cases where BGP decides to put a route into the VRF for a particular address prefix, and OSPF also decides to put a route into the VRF for that same address prefix. Of course, only one of these can actually be used for forwarding. The original spec did not make it adequately clear just how a choice between two such routes would be made. This has been clarified. In some cases, the results will be different than they would have been if the VPN were really a pure OSPF network. These differences are now explained and their potential consequences pointed out. The procedures for forwarding data traffic on a sham link have been clarified. The procedures for sending OSPF control traffic on a sham link have been clarified. The role of the optional "sham link endpoint address" has been clarified. The procedures for translating BGP-distributed VPN-IPv4 routes into OSPF routes have been clarified. A discussion of NSSA routes has been added. Alex says it is not detailed enough; any feedback in this area would be welcome. Due to the large number of changes, Alex has asked for a new last call, and I expect the WG chairs to formally issue the last call shortly. From l3vpn-bounces@ietf.org Wed Aug 31 11:16:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAUKd-0000q8-AK; Wed, 31 Aug 2005 11:16:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAUKa-0000pF-PO for l3vpn@megatron.ietf.org; Wed, 31 Aug 2005 11:16:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26125 for ; Wed, 31 Aug 2005 11:16:50 -0400 (EDT) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAUMJ-00007E-Do for l3vpn@ietf.org; Wed, 31 Aug 2005 11:18:42 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j7VFGJ955491; Wed, 31 Aug 2005 08:16:19 -0700 (PDT) (envelope-from rcallon@juniper.net) Received: from rcallon-lt1.juniper.net ([172.28.5.193]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j7VFGEG67389; Wed, 31 Aug 2005 08:16:14 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20050831111344.02718af8@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 31 Aug 2005 11:16:10 -0400 To: l3vpn@ietf.org From: Ross Callon In-Reply-To: <200508291545.j7TFjpQl000639@rtp-core-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: erosen@cisco.com Subject: Last call on draft-ietf-l3vpn-ospf-2547-04 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org This begins working group last call on draft-ietf-l3vpn-ospf-2547-04. This last call is limited to the changes that Eric has made to the document (which are outlined in Eric's email below). The last call will end in two weeks (September 14th). Please send any comments to the working group mailing list. Thanks, Ross At 11:45 AM 8/29/2005 -0400, Eric Rosen wrote: >As a result of AD review, significant changes have been made to the >specification draft-ietf-l3vpn-ospf-2547. These changes can be seen in the >latest version, draft -04. It is believed that the draft now corresponds to >the implementations. > >The following issues were addressed as a result of the AD review. > >The spec was written so as to allow a single VRF to correspond to multiple >OSPF domains. However, it did not make clear just which parameters and >procedures are relative to a domain, and which are relative to a VRF. This >has now been cleared up. However, doing so required extensive textual >changes. > >There are cases where BGP decides to put a route into the VRF for a >particular address prefix, and OSPF also decides to put a route into the VRF >for that same address prefix. Of course, only one of these can actually be >used for forwarding. The original spec did not make it adequately clear >just how a choice between two such routes would be made. This has been >clarified. In some cases, the results will be different than they would >have been if the VPN were really a pure OSPF network. These differences are >now explained and their potential consequences pointed out. > >The procedures for forwarding data traffic on a sham link have been >clarified. The procedures for sending OSPF control traffic on a sham link >have been clarified. The role of the optional "sham link endpoint address" >has been clarified. > >The procedures for translating BGP-distributed VPN-IPv4 routes into OSPF >routes have been clarified. > >A discussion of NSSA routes has been added. Alex says it is not detailed >enough; any feedback in this area would be welcome. > >Due to the large number of changes, Alex has asked for a new last call, and >I expect the WG chairs to formally issue the last call shortly. From l3vpn-bounces@ietf.org Wed Aug 31 15:16:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAY4J-0006AI-I6; Wed, 31 Aug 2005 15:16:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAUqm-0003LC-RA for l3vpn@megatron.ietf.org; Wed, 31 Aug 2005 11:50:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27729 for ; Wed, 31 Aug 2005 11:50:06 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAUsV-00014P-P7 for l3vpn@ietf.org; Wed, 31 Aug 2005 11:51:59 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 31 Aug 2005 11:49:56 -0400 X-IronPort-AV: i="3.96,158,1122868800"; d="scan'208"; a="68504619:sNHT31361788" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7VFnqT6021283; Wed, 31 Aug 2005 11:49:53 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 11:49:39 -0400 Received: from [64.102.194.234] ([64.102.194.234]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 11:49:39 -0400 Message-ID: <4315D193.50205@cisco.com> Date: Wed, 31 Aug 2005 11:49:39 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OSPF List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2005 15:49:39.0597 (UTC) FILETIME=[989683D0:01C5AE43] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 31 Aug 2005 15:16:17 -0400 Cc: l3vpn@ietf.org Subject: draft-ietf-l3vpn-ospf-2547-04 L3VPN/OSPF WG Last Call X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org This begins working group last call on draft-ietf-l3vpn-ospf-2547-04. This last call is limited to the changes that Eric has made to the document (which are outlined in Eric's email below). The last call will end in two weeks (September 14th). Please send any comments to the l3vpn (l3vpn@ietf.org) and OSPF WG mailing lists. The document is an l3vpn WG document but it reflects OSPF operation/interaction with BGP/MPLS in a PE/CE environment. Thanks, Acee At 11:45 AM 8/29/2005 -0400, Eric Rosen wrote: > As a result of AD review, significant changes have been made > to the > specification draft-ietf-l3vpn-ospf-2547. These changes can be seen > in the > latest version, draft -04. It is believed that the draft now > corresponds to > the implementations. > > The following issues were addressed as a result of the AD review. > > The spec was written so as to allow a single VRF to correspond to > multiple > OSPF domains. However, it did not make clear just which > parameters and > procedures are relative to a domain, and which are relative to a > VRF. This > has now been cleared up. However, doing so required extensive > textual > changes. > > There are cases where BGP decides to put a route into the VRF > for a > particular address prefix, and OSPF also decides to put a route into > the VRF > for that same address prefix. Of course, only one of these can > actually be > used for forwarding. The original spec did not make it adequately > clear > just how a choice between two such routes would be made. This > has been > clarified. In some cases, the results will be different than they > would > have been if the VPN were really a pure OSPF network. These > differences are > now explained and their potential consequences pointed out. > > The procedures for forwarding data traffic on a sham link > have been > clarified. The procedures for sending OSPF control traffic on a > sham link > have been clarified. The role of the optional "sham link endpoint > address" > has been clarified. > > The procedures for translating BGP-distributed VPN-IPv4 routes > into OSPF > routes have been clarified. > > A discussion of NSSA routes has been added. Alex says it is not > detailed > enough; any feedback in this area would be welcome. > > Due to the large number of changes, Alex has asked for a new last > call, and > I expect the WG chairs to formally issue the last call shortly.