Subject: Re: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol'

From: Michael Lundberg <[email-masked]>
Date: Wed, 27 Jan 2010 16:37:50 -0500

Sending again; previous email wasn't posted to lists...

-----Original Message-----
From: Lundberg, Michael [USA]
Sent: Tuesday, January 26, 2010 11:36 PM
To: 'Acee Lindem'; Ross Callon; [email-masked]
Cc: [email-masked]; Adrian Farrel
Subject: RE: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3
as a PE-CE routing protocol'

Hi Acee,

Thanks for your review.  Please see below for responses to your comments.

> Here are my comments:
>
> There is a typo on page 14:
>
>    0x50 External 0x2005 AS-external-LSA
>
> Should be:
>
>
>  0x50     External           0x4005   AS-external-LSA
>

You are correct, this should be 0x4005

> Additionally, I don't think the addition of the instance ID to the
> OSPFv3 Route Extended Communities attribute accomplishes all the much.
> Assuming an IPv6 route is advertised once in BGP for a given VRF, how
> does one advertise it into multiple PE OSPFv3 instances associated with
> the VRF? Given that secondary routing domains can be configured for
> OSPFv3 PE instances (as described in 4.1.2), it would seem you'd need
> different routing domains for each instance and accomplish this.
> However, if you need to use different domain IDs and keep the instance
> ID common, what is the utility of the instance ID as an additional
> route demultiplexer? There whole discussion of instance ID in sections
> 4.1 and 4.1.1 doesn't make sense to me. The OSPFv3 instance ID is used
> in OSPFv3 packets in order to allow multiple instances to share a link.
> Hence, the only place it maps directly to this draft is for the sham
> link as described in section 5. In order to advertise a route into
> multiple instances
>  in the same VRF, one would need to associate multiple OSPFv3 Route
> Extended Communities with the route. If this is the indent, the draft
> should should state as such. However, there is no reason why OSPFv2 PE-
> CE, as described in RFC 4577, couldn't also take advantage of such of
> mechanism.
>

The motivation for using an Instance ID was not to advertise a route into
multiple OSPFv3 instances.  This can be done through redistribution policies
configured on the router (even for RFC 4577 implementations).

Rather, the motivation was to leave implementers the room for flexibility,
where Domain IDs can be assigned on a per-VRF or a per-OSPF-instance basis.
In the per-VRF case, the Instance ID is used to demultiplex routes across
different OSPFv3 instances.

Regards,

Michael S. Lundberg
Associate
Booz | Allen | Hamilton
22 Batterymarch Street
Boston, MA  02109
Office: 617-428-4476

> Thanks,
> Acee
>
> On Jan 22, 2010, at 3:16 PM, Ross Callon wrote:
>
> draft-ietf-l3vpn-ospfv3-pece was recently approved by the IESG for
> publication, and is currently in the RFC editor's queue. While this
> document passed WG last call in the L3VPN working group, and also
> passed IETF last call, we forgot to either do an last call in the OSPF
> working group, or to specifically flag the IETF last call to the OSPF
> working group.
>
> With this in mind, we would like to solicit comments on this draft from
> the OSPF working group. If there are minor comments we can fix this
> during AUTH48. If there are major concerns then we will need to figure
> out what to do (which in the most extreme situation might require un-
> approving the document).
>
> Thus, please review this document and reply to the OSPF working group
> email list by the end of next Friday, January 29th, if you have any
> comments or concerns.
>
> Thanks, Ross
> (acting in my role as the AD who goofed in this case).
> _______________________________________________
> OSPF mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ospf
>
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf