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

From: Ross Callon <[email-masked]>
Date: Fri, 22 Jan 2010 15:16:57 -0500

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).

---

From: Acee Lindem <[email-masked]>
Date: Mon, 25 Jan 2010 16:36:35 -0500

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

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.

Thanks,
Acee

On Jan 22, 2010, at 3:16 PM, Ross Callon wrote:

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

---

From: Abhay Roy <[email-masked]>
Date: Tue, 26 Jan 2010 13:20:29 -0800

I also looked at the latest version and have a few comments. Nothing 
significant, so these can possibly be done in RFC Ed..

       OSPFv3 Options : 1 byte

       The Options field indicates if the route carries a type-1 or
       type-2 metric.  Setting the least significant bit in the field
       indicates that the route carries a External type-2 metric.

#### When talking of bit positions, it's always better to show the 
bitfield, and name the bit(s) being allocated. For e.g. see section A.2 
of rfc5340.
#### We also need an IANA registry for:
####  - Option bits (allocate the one's we need here)
####  - Route Type (only a few values are currently permitted)

4.5.1.  OSPFv3 Down Bit

    Section 1 and Section 3 of [rfc4576] describe the usage of the DN-bit
    for OSPFv2 and are applicable for OSPFv3 for inter-area-prefix LSAs,
    NSSA LSAs and External LSAs.  Similarly, the DN-bit must be set in
    inter-area-prefix-LSAs, NSSA-LSAs and AS-External-LSAs, when these
    are originated from a PE to a CE, to prevent those prefixes from
    being re-advertised into BGP.  As in [rfc4577], any LSA with the DN
    bit set must not be used for route calculations.

#### Can we capitalize MUST in - "the DN-bit must be set .."
#### The last sentence is confusing because it doesn't clarify this 
restriction to be only on PE routers. We could use similar language as 
in rfc4576:

    When a PE router receives, from a CE router, any LSA with the DN bit
    [OSPF-DN] set, the information from that LSA MUST NOT be used by the
    route calculation.

Regards,
-Abhay

On 1/22/10 12: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
>
> [email-masked]

---

From: Acee Lindem <[email-masked]>
Date: Wed, 27 Jan 2010 18:06:27 -0500

Hi Michael, 

See inline. 

On Jan 26, 2010, at 11:35 PM, Lundberg, Michael [USA] wrote:

> Hi Acee, 
> 
> Thanks for your review.  Please see below for responses to your comments.
> 
>> Here are my comments:
>> 
> 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).

If that is the case, why do sections 3.1 and 4.1 imply a direct functional correlation between the OSPFv3 interface instance ID and the Route Extended Communities attribute? 

>From section 3.1:

To distinguish between routes originated from different OSPFv3 instances, an Instance ID field is carried in a newly-defined OSPFv3 Route Extended Community attribute.
>From section 4.1:

   Since multiple OSPFv3 instances can be associated with a single VRF,
   an additional mechanism is needed to demultiplex routes across these
   instances.  When a PE supports multiple OSPFv3 instances in a VRF, a
   local Instance ID is assigned to the "link" that spans over the MPLS
   VPN backbone (PE-PE).  As specified in [rfc5340], the Instance ID has
   link-local significance only.  Therefore, the Instance IDs assigned
   to the PE-PE "link" need not be the same as the Instance IDs assigned
   to the PE-CE links.  By default, this Instance ID is set to NULL.
   The OSPFv3 Domain ID and local Instance ID associated with the MPLS
   backbone may be used to demultiplex routes for multiple instances.
   Further details on Domain IDs and Instance IDs are provided in
   Section 4.1.2.
If you have multiple instances within a VRF,  the assumption above is that the subset of routes known to each instance are disjoint. This limitation does not exist with OSPFv3 instances in the  routing domain (or VRF)  using different Instance IDs to share links.

> 
> 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.

Right, but in the case where instance ID is specified that route may be only redistributed into an OSPFv3 instance configured with that instance ID (as specified in 4.1.2). 

Thanks,
Acee 

> Michael S. Lundberg
> Associate
> Booz | Allen | Hamilton
> 22 Batterymarch Street
> Boston, MA  02109
> Office: 617-428-4476
>> 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).
>>

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 27 Jan 2010 20:18:11 -0800

On 1/26/10 1:20 PM, Abhay Roy wrote:
> bitfield, and name the bit(s) being allocated. For e.g. see section 
> A.2 of rfc5340.
Only the least significant bit is set to indicate the presence of  a 
type-2 metric we felt this was sufficient. If you feel this would make 
things clearer, we can make the change.
> ####  - Route Type (only a few values are currently permitted)
While I feel it is not needed for the Options bit,  an IANA registry for 
the route types could be added.  I will defer to the ADs on this matter.

> #### Can we capitalize MUST in - "the DN-bit must be set .."
Agreed.
>     [OSPF-DN] set, the information from that LSA MUST NOT be used by the
Agree we can rephrase it.

Thanks for your review

Padma
>> 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.
>>
>> [email-masked]  <mailto:[email-masked]>