Subject: Re: Comments on draft-ietf-l3vpn-ospfv3-pece-07

From: Michael Lundberg <[email-masked]>
Date: Wed, 4 May 2011 10:22:16 -0400

Hi Nick,

We will make both updates, as well as the update suggested by Acee in
the next version.  Thanks for both of your comments.

Thanks,
Michael

On Thu, Apr 28, 2011 at 9:15 AM, Nick Weeds <[email-masked]> wrote:
> Hi Michael,
>
> Thanks for getting back to me.
>
> You suggest removing the  "No OSPFv3 route to the same prefix exists in the VRF" and specifying that the route will be redistributed into OSPF based on local policy.  Yes, that would address my concerns.  Obviously for the VPN function to work we need routes to be redistributed to OSPF, but network administrators might want greater control to restrict VPN routing in some cases.
>
> My email of 31st March also raised a separate point about section 4.3.2.3 text on comparing OSPFv3 Domain Ids, and your reply of 8th April said you'd update the text.  If you're batching up the updates then please remember this earlier point.
>
>        Nick.
>
>> -----Original Message-----
>> From: Michael Lundberg [mailto:[email-masked]]
>> Sent: 27 April 2011 17:16
>> To: Nick Weeds
>> Cc: Acee Lindem; [email-masked];
>> [email-masked]
>> Subject: Re: Comments on draft-ietf-l3vpn-ospfv3-pece-07
>>
>> Hi Nick,
>>
>> Sorry i didn't get to your comment earlier. I agree with the behavior
>> you are describing and the problem with saying the OSPF route will
>> always be preferred. Given the routes within the VRF are from
>> different protocols, I believe the only way to chose the route you
>> want is through local policy (e.g., admin distance, route preference).
>>
>> We can remove the  "No OSPFv3 route to the same prefix exists in the
>> VRF," and specify that the route will be redistributed into OSPF based
>> on local policy.  Will this address your concerns?
>>
>> Acee - we can also update the word "distance" and change it to
>> "metric", good comment.
>>
>> Regards,
>> Michael
>>
>> On Fri, Apr 15, 2011 at 12:19 PM, Nick Weeds
>> <[email-masked]> wrote:
>> > Hi Acee,
>> >
>> > We don't seem to be thinking of the same use case - please see below
>> ...
>> >
>> >> -----Original Message-----
>> >> From: Acee Lindem [mailto:[email-masked]]
>> >> Sent: 15 April 2011 16:51
>> >> To: Nick Weeds
>> >> Cc: Michael Lundberg; [email-masked];
>> >> [email-masked]
>> >> Subject: Re: Comments on draft-ietf-l3vpn-ospfv3-pece-07
>> >>
>> >> Hi Nick,
>> >> See inline.
>> >> On Apr 11, 2011, at 8:50 AM, Nick Weeds wrote:
>> >>
>> >> > Hi Michael,
>> >> >
>> >> > Thanks for your reply - please see further comments below.
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Michael Lundberg [mailto:[email-masked]]
>> >> >> Sent: 08 April 2011 20:44
>> >> >> To: Nick Weeds
>> >> >> Cc: [email-masked]; [email-masked]
>> >> >> Subject: Re: Comments on draft-ietf-l3vpn-ospfv3-pece-07
>> >> >>
>> >> >> Hi Nick,
>> >> >>
>> >> >> Thanks for your review and comments. Please see below for my
>> >> comments.
>> >> >>
>> >> >> On Thu, Mar 31, 2011 at 6:47 AM, Nick Weeds
>> >> <[email-masked]>
>> >> >> wrote:
>> >> >>> Hi,
>> >> >>>
>> >> >>> The changes in the new draft-ietf-l3vpn-ospfv3-07.txt draft look
>> >> >> good, but I
>> >> >>> do have a couple of specific comments.
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> Section 4.3.2 / top of p10
>> >> >>>
>> >> >>> The text says that a PE advertises the IPv6 route learned from
>> MP-
>> >> BGP
>> >> >> to
>> >> >>> attached CEs via OSPFv3 if various conditions hold, including:
>> >> >>>
>> >> >>>         "No OSPFv3 route to the same prefix exists in the VRF."
>> >> >>>
>> >> >>> I think this is too restrictive.  The aim is to allow a choice
>> >> >> between
>> >> >>> routing over the VPN and routing over an OSPF backdoor link.
>>  The
>> >> >> condition
>> >> >>> above would prevent routing over the VPN if there was already a
>> >> route
>> >> >> over
>> >> >>> an OSPF backdoor link.
>> >> >>>
>> >> >>> I believe the correct condition would be that the OSPFv3
>> decision
>> >> >> process
>> >> >>> selects the VPN route as the preferred route.
>> >> >>
>> >> >> I believe our text is consistent with 4577, which says "If a VRF
>> >> >> contains both an OSPF-distributed route and a VPN-IPv4 route for
>> the
>> >> >> same IPv4 prefix, then the OSPF-distributed route is preferred."
>> >> >> Therefore, as described in the text above, if an OSPFv3 route is
>> >> >> installed in the VRF for the same prefix as the IPv6 route
>> learned
>> >> via
>> >> >> MP-BGP, the OSPFv3 route will be preferred, and the MP-BGP route
>> >> will
>> >> >> not be redistributed into OSPF.
>> >> >>
>> >> >> To get the behavior you are describing, where you want the OSPF
>> >> >> decision process to prefer either the backbone or the backdoor
>> link,
>> >> >> requires sham links.  In this case, the OSPF routes from one PE
>> are
>> >> >> 'tunneled' via MPLS to the other PE and do not appear in the VRF
>> as
>> >> >> MP-BGP routes.  Therefore, the rules above do not hold as you are
>> >> only
>> >> >> comparing OSPF routes, not MP-BGP to OSPF.
>> >> >>
>> >> >
>> >> >
>> >> > Unfortunately the text you refer to in RFC 4577 also seems to
>> gloss
>> >> over the complexities involved...
>> >> >
>> >> > Stepping back, the main function of RFC 4577 and draft-ietf-l3vpn-
>> >> ospfv3-pece is to allow a choice between VPN routes and OSPF
>> backdoor
>> >> routes rather than force traffic onto OSPF backdoor routes.
>> >> >
>> >> > There are two cases: (1) when the backdoor route is an inter-area
>> >> route (2) when the backdoor route is an intra-area route.
>> >> >
>> >> > In the inter-area case (1) the solution is to map VPN routes to
>> OSPF
>> >> inter-area prefix LSAs rather than AS-external LSAs according to the
>> >> OSPF Domain ID configuration (as described in RFC 4577 section
>> 4.2.8).
>> >> This allows the OSPF decision process to choose between the VPN
>> route
>> >> (viewed as an OSPF inter-area route) and any inter-area OSPF
>> backdoor
>> >> route.  If the OSPF decision process selects the mapped VPN route
>> then
>> >> the intent is for the VRF to use the VPN route (complete with
>> BGP/MPLS
>> >> VPN labels) rather than the OSPF backdoor route.  As they stand the
>> >> statements in RFC 4577 and draft-ietf-l3vpn-ospfv3-pece both seem to
>> >> contradict this - taken at face value they both seem to say that the
>> PE
>> >> router should always use the OSPF (backdoor) route rather than BGP
>> >> (VPN) route.
>> >> >
>> >> > In the intra-area case (2) the solution is to use a sham link.
>>  This
>> >> is more complicated but less subject to ambiguity about VPN routes
>> >> mapped to OSPF inter-area prefix routes.
>> >> >
>> >> > If OSPF (backdoor) routes are always preferred to BGP (VPN) routes
>> >> except in the sham link case, how can the inter-area case possibly
>> >> allow a choice between the two on the PE router?
>> >> > (And if it doesn't allow a choice, what is the point of specifying
>> >> OSPF Domain ID configuration and mapping of VPN routes to OSPF
>> inter-
>> >> area prefix LSAs?)
>> >>
>> >> I agree that this is possible but it would be strange area topology
>> >> indeed. Since the metric is not carried in BGP, it is a matter of
>> local
>> >> policy in the PE and one could have some subset of the site using
>> the
>> >> inter-area path over the backdoor link and another using the VPN
>> path.
>> >> But again, I don't believe this is a common use case.
>> >>
>> >> Thanks,
>> >> Acee
>> >
>> > A couple of points:
>> >
>> > (1) The metric is carried in the BGP Multi-Exit Descriminator, as
>> specified at the end of draft section 4.3.1 (and also in RFC 4577).  I
>> believe the point of RFC 4577 and of the draft is that extra
>> information carried on the VPN route allows the BGP (VPN) route to be
>> mapped to an OSPF route, so that the VPN route can be preferred to the
>> OSPF backdoor route.  This function would be broken if the OSPF
>> backdoor route is always preferred to the BGP (VPN) route.
>> >
>> > (2) I don't understand why you say the area topology is strange.  As
>> far as I can see it's the only area topology where mapping of BGP
>> routes to OSPF inter-area routes has any effect on routing, and
>> therefore it is the mainline case for much of the draft.
>> >
>> >        Nick.
>> >
>> >>
>> >>
>> >>
>> >> >
>> >> > Hopefully if we can answer that then we'll understand how to make
>> the
>> >> draft-ietf-l3vpn-ospfv3-pece text clearer.
>> >> >
>> >> >     Nick.
>> >> >
>> >> >>> Section 4.3.2.3 / p11
>> >> >>>
>> >> >>> The rules 1 and 2 for comparing OSPFv3 Domain IDs state how to
>> >> >> compare the 6
>> >> >>> value bytes but not how to compare the 2 type bytes.  I believe
>> the
>> >> >> rules
>> >> >>> should match RFC 4577 section 4.2.8.1 rules 1 and 3.  In other
>> >> words,
>> >> >> either
>> >> >>> (1) all 8 (not 6) bytes match, or (2) the 6 byte value fields of
>> >> both
>> >> >>> attributes are all zeroes and the type bytes are ignored.  Note
>> >> that
>> >> >> in the
>> >> >>> first case the 2 type bytes must match and in the latter case
>> they
>> >> >> are
>> >> >>> ignored.
>> >> >>
>> >> >> This is a good point.  We will update the text. This text should
>> >> have
>> >> >> been updated when we removed the use of the single BGP extended
>> >> >> community and reverted back to the OSPF Domain ID extended
>> community
>> >> >> attribute.
>> >> >>
>> >> >> Thanks,
>> >> >> Michael
>> >> >>
>> >> >>>
>> >> >>>         Nick.
>> >> >>>
>> >> >>> Nick Weeds
>> >> >>> Software Engineer, Network Technologies Division
>> >> >>> Metaswitch Networks
>> >> >>>
>> >> >>> [email-masked]
>> >> >>> +44 (0) 20 8366 1177
>> >> >>> www.metaswitch.com
>> >
>> >
>