Subject: Re: Last Call: <draft-ietf-l3vpn-ospfv3-pece-09.txt> (OSPFv3 asaPE-CErouting protocol) to Proposed Standard

From: "Daniel Cohn" <[email-masked]>
Date: Sat, 03 Dec 2011 22:29:54 +0200

Thank you for incorporating the feedback!

Thumb typed - please be tolerant

Padma Pillay-Esnault <[email-masked]> wrote:

Daniel, Acee

Thanks for review and comment.
The draft is updated and posted.

Padma

On 11/19/11 11:50 PM, Daniel Cohn wrote:
> 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,
>
> 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
>
> On Thu, Nov 17, 2011 at 6:09 AM, Acee Lindem<[email-masked]>  wrote:
>> Hi Daniel,
>>
>> On Nov 17, 2011, at 2:29 AM, Daniel Cohn wrote:
>>
>>> 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
>> 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.
>>
>>
>>> 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?
>> I'd be fine with this statement.
>>
>> Thanks,
>> Acee
>>
>>
>>
>>> 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,
>>> I'm not an author but I'll comment.
>>>
>>> On Nov 16, 2011, at 5:38 AM, Daniel Cohn wrote:
>>>
>>>> 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"
>>> 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
>>>
>>>
>>>> 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
>>>>
>>>>
>>>>   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.
>>>>
>>>>
>>