Subject: Last Call: <draft-ietf-l3vpn-ospfv3-pece-09.txt> (OSPFv3 as a PE-CE routing protocol) to Proposed Standard

From: The IESG <[email-masked]>
Date: Sat, 12 Nov 2011 15:42:23 -0800

The IESG has received a request from the Layer 3 Virtual Private Networks
WG (l3vpn) to consider the following document:
- 'OSPFv3 as a PE-CE routing protocol'
  <draft-ietf-l3vpn-ospfv3-pece-09.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2011-12-04. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   Many Service Providers (SPs) offer Virtual Private Network (VPN)
   services to their customers using a technique in which Customer Edge
   (CE) routers are routing peers of Provider Edge (PE) routers.  The
   Border Gateway Protocol (BGP) is used to distribute the customer's
   routes across the provider's IP backbone network, and Multiprotocol
   Label Switching (MPLS) is used to tunnel customer packets across the
   provider's backbone.  This is known as a "BGP/MPLS IP VPN".
   Originally only IPv4 was supported and it was later extended to
   support IPv6 VPNs as well.  Extensions were later added for the
   support of the Open Shortest Path First protocol version 2 (OSPFv2)
   as a PE-CE routing protocol for the IPv4 VPNs.  This document extends
   those specifications to support OSPF version 3 (OSPFv3) as a PE-CE
   routing protocol.  The OSPFv3 PE-CE functionality is identical to
   that of OSPFv2 except for the differences described in this document.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-l3vpn-ospfv3-pece/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-l3vpn-ospfv3-pece/

No IPR declarations have been submitted directly on this I-D.

---

From: "Daniel Cohn" <[email-masked]>
Date: Wed, 16 Nov 2011 12:38:37 +0200

Hi,

(Belated) question to the authors:

Doesn't the following statement in the draft:

"However, since a PE interface can be associated with only one VRF, all
OSPFv3 instances running on the same interface MUST be associated with
the same VRF."

contradict the following statement in RFC 4364, section 3.2?

" In some cases, a particular site may be divided by the customer into
several "virtual sites"... Another way to accomplish this is to use IP
source addresses.  In this case, the PE uses the IP source address in a
packet received from the CE, along with the interface over which the
packet is received, to assign the packet to a particular VRF"

In other words, RFC 4364 allows assigning a single PE interface to
several VRFs. So shouldn't the statement in the draft at least be
qualified?

Regards,

Daniel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of The IESG
Sent: Sunday, November 13, 2011 1:42 AM
To: IETF-Announce
Cc: [email-masked]
Subject: Last Call: <draft-ietf-l3vpn-ospfv3-pece-09.txt> (OSPFv3 as a
PE-CErouting protocol) to Proposed Standard

The IESG has received a request from the Layer 3 Virtual Private
Networks WG (l3vpn) to consider the following document:
- 'OSPFv3 as a PE-CE routing protocol'
  <draft-ietf-l3vpn-ospfv3-pece-09.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2011-12-04. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

---

From: Acee Lindem <[email-masked]>
Date: Wed, 16 Nov 2011 09:58:40 -0500

Hi Daniel,
I'm not an author but I'll comment. 

> packet is received, to assign the packet to a particular VRF"

To the best of my knowledge, nobody has implemented the ability to put different subnets on the same interface in different VRFs. The way this problem is typically solved is with some layer 2 encapsulation, e.g., different VLANs in different VRFs. 
To complicate things, OSPFv3 runs on a link as opposed to a subnet.  Hence the demuxing described in RFC 4364 would not work. Conceivably, one could use the OSPFv3 interface instance ID for this demuxing but I don't think it makes any sense to try and solve this problem when no one is putting a single interface in multiple VRFs. 

Thanks,
Acee

---

From: "Daniel Cohn" <[email-masked]>
Date: Thu, 17 Nov 2011 09:29:36 +0200

Hi Acee, thanks for your reply. 
I don't agree with your comment regarding lack of implementations
associating a single interface to multiple VRFs. By way of example, the
following links show major vendor implementation of this feature:

http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/vrfselec.html
http://www.juniper.net/techpubs/software/junos/junos95/swconfig-vpns/id-
11185557.html

But this is not of the essence - the main issue IMO is that RFC 4364
framework does allow this configuration, so the draft statement is
factually incorrect.

Now, I do agree that we lack clear definitions on how OSPF (or any other
PE-CE protocol) should be used in this scenario. That's why I wrote that
the statement should be qualified, not deleted. Something like
"Configurations where a PE interface is associated with multiple VRFs
are out of the scope of this document".

What do you think?

Regards,

Daniel

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2011 4:59 PM
To: Daniel Cohn
Cc: [email-masked]
Subject: Re: Last Call: <draft-ietf-l3vpn-ospfv3-pece-09.txt> (OSPFv3 as
aPE-CErouting protocol) to Proposed Standard

Hi Daniel,

> packet is received, to assign the packet to a particular VRF"

To the best of my knowledge, nobody has implemented the ability to put
different subnets on the same interface in different VRFs. The way this
problem is typically solved is with some layer 2 encapsulation, e.g.,
different VLANs in different VRFs. 
To complicate things, OSPFv3 runs on a link as opposed to a subnet.
Hence the demuxing described in RFC 4364 would not work. Conceivably,
one could use the OSPFv3 interface instance ID for this demuxing but I
don't think it makes any sense to try and solve this problem when no one
is putting a single interface in multiple VRFs. 

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Thu, 17 Nov 2011 06:09:59 -0500

Hi Daniel, 

> http://www.juniper.net/techpubs/software/junos/junos95/swconfig-vpns/id-

This is interesting - I didn't know this capability existed. I see the two approaches have some differences and both are limited to static routing. 

> are out of the scope of this document".

I'd be fine with this statement. 

Thanks,
Acee

---

From: Michael Lundberg <[email-masked]>
Date: Thu, 17 Nov 2011 10:26:45 -0500

Daniel,

Thanks for the comment, and Acee thanks for providing your input as
well!  Given that there are implementations that allow selection of
the VRF based on IP address, I agree we need to add and/or modify the
text Dan pointed out below.

I am ok with adding the suggested text, and also removing the words
"However, since" to the beginning of the sentence, so it reads...

"A PE interface can be associated with only one VRF, and all OSPFv3
instances running on the same interface MUST be associated with the
same VRF. Configurations where a PE interface is associated with
multiple VRFs are out of scope for this document"

Let us know if this works.

Regards,
Michael

---

From: "Daniel Cohn" <[email-masked]>
Date: Sun, 20 Nov 2011 09:50:51 +0200

That’s fine with me, thanks,

DC

-----Original Message-----
From: Michael Lundberg [mailto:[email-masked]] 
Sent: Thursday, November 17, 2011 5:27 PM
To: Acee Lindem; Daniel Cohn
Cc: [email-masked]
Subject: Re: Last Call: <draft-ietf-l3vpn-ospfv3-pece-09.txt> (OSPFv3 as aPE-CErouting protocol) to Proposed Standard

Daniel,

Regards,
Michael