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

[Acee Lindem <[e-mail]>]

Hi Michael,
Thanks - sounds good. See one comment below. 

On Feb 10, 2010, at 1:04 PM, Michael Lundberg wrote:

> Hi Acee,
> 
> Please find responses to your questions below.
> 
> Thanks,
> Michael
> 
> On Sun, Jan 31, 2010 at 2:28 PM, Acee Lindem <[e-mail]> wrote:
>> 
>> Hi Padma, et al,
>> Somehow my response quoting was lost. I've prefixed my responses with "ACEE:" just to make sure.
>> 
>> On Jan 30, 2010, at 12:47 AM, Padma Pillay-Esnault wrote:
>> 
>> 
>> Thanks to everyone for their thorough review.
>> 
>> Assessing the different review comments on the flexibility of
>> assigning domain ID on a per-OSPF-Instance or a per-VRF basis,
>> the authors think offering a single approach will greatly improve the document's
>> clarity. The sections 4.1, 4.1.1, 4.1.2, 4.3, 4.3.1, 4.3.2.1, 4.3.2.3
>> will be modified to reflect assigning Domain ID per OSPF-instance only.
>> 
>> ACEE: Great. Just to be clear, you will remove the instance-id from the OSPFv3 route extended communities attributes as well - right?
>> 
> 
> Yes
> 
>> 
>> See below for other proposed changes and suggestions from reviews of the wg.
>> 
>> Section 3.1 OSPFv3 Specificities
>> 
>> "For an IPv6 MPLS/VPN architecture where customers interface to
>> providers through OSPFv3, traditional BGP/OSPF interactions
>> specify that VPN-IPv6 reachability information redistributed into
>> OSPFv3 will be expressed as an AS-External OSPFv3 LSAs.  Instead,
>> it may be desirable to view these LSAs as AS-internal (inter-area-prefix,
>> and intra-area-prefix) LSAs."
>> 
>> 
>> Proposed change
>> 
>> "For an IPv6 MPLS/VPN architecture where customers interface to
>> providers through OSPFv3, traditional BGP/OSPF interactions
>> specify that VPN-IPv6 reachability information redistributed into
>> OSPFv3 will be expressed as an AS-External OSPFv3 LSAs.  Instead,
>> it may be desirable to view these LSAs as inter-area-prefix LSAs."
>> 
>> ACEE: Replace "as an AS-External LSAs" with "as AS-External LSAs".
>> 
> 
> Agree
> 
>> 
>> 
>> Remove paragraph,
>> 
>> "To distinguish between routes originated from different
>>  OSPFv3 instances, an Instance ID field is carried in a
>> newly-defined OSPFv3 Route Extended Community attribute."
>> 
>> Section 4.3.2.2.  OSPF Intra-Area Route
>> 
>> "A route is advertised from a PE to a CE as an intra-area route using
>> an Intra-Area-Prefix (type 0x2009) LSA only when sham links are used,
>> as described in Section 5.  Otherwise routes are advertised as either
>> inter-area (Section 4.3.2.1) or external (Sections 4.3.2.3) routes."
>> 
>> Proposed Changes
>> 
>> "A route is advertised as an intra-area route using
>> an Intra-Area-Prefix (type 0x2009) LSA only when sham links are used,
>> as described in Section 5.  Otherwise routes are advertised as either
>> inter-area (Section 4.3.2.1) or external (Sections 4.3.2.3) routes."
>> 
>> ACEE: You could replace "external" with "external/NSSA" to be more precise.
>> 
> 
> Agree
> 
>> 
>> Section 4.4 OSPFv3 Route Extended Communities Attribute
>> 
>> "  0x50     External           0x2005   AS-external-LSA"
>> 
>> Proposed change
>> 
>> "  0x50     External           0x4005   AS-external-LSA"
>> 
>> Section 4.5.1.  OSPFv3 Down Bit
>> 
>>   "  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.  "
>> 
>> Proposed change
>> 
>>  " 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.  "
>> 
>> Section 5 OSPFv3 Sham Links
>> 
>> "Sham link endpoint addresses MUST be distributed by BGP as routeable
>> VPN IPv6 addresses whose IPv6 address prefix is 128 bits long.  As
>> specified in [rfc4577], these endpoint addresses MUST NOT be
>> advertised by OSPFv3."
>> 
>> changed to
>> 
>> "Sham link endpoint addresses MUST be distributed by BGP as routeable
>>  VPN IPv6 addresses whose IPv6 address prefix is 128 bits long.  As
>> specified in section 4.2.7.1 of [rfc4577], these endpoint
>> addresses MUST NOT be advertised by OSPFv3; if there is no BGP route
>> to the Sham Link Endpoint Address, that address is to appear unreachable,
>> so that the sham link appears to be down."
>> 
>> Section 5.1 Creating A Sham link
>> 
>> Remove the paragraph.
>> 
>> "One difference from Section 4.2.7.3 of [rfc4577] is the addition of
>> Type 0x2009 intra-area-prefix LSAs, and the flooding of these LSAs
>> across the sham link.  Furthermore, where prefixes associated with
>> OSPFv2 sham links are advertised in Type-1 LSAs, prefixes associated
>> with OSPFv3 sham links are advertised as OSPFv3 Type 0x2009 LSAs.
>> This change is required based on [rfc5340], which states that
>> loopback interfaces are advertised in intra-area-prefix LSAs."
>> 
>> ACEE: Will 0x90 remain as a assigned value for the OSPFv3 Route extended community route-type?
>> 
> 
> Yes, Intra-area-prefix-LSAs can still be advertised via bgp. Section
> 4.3.2.1.  describes how they will be handled.

I believe you mean 4.3.2.2 and 5.1. It would be good to explicitly spell out the use of the 0x90 route-type for the host (/128) address used as a Sham Link endpoint in section 5.1 since this is not exactly the same as RFC 4577.  

Thanks,
Acee


> 
>> 
>> 
>> Suggestions
>> 
>>      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.
>> PPE : 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.
>> 
>> #### 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)
>> 
>> PPE: 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.
>> 
>> ACEE: I'd agree.
>> 
>> Thanks,
>> Acee
>> 
>> 
>> 
>> 
>> Regards,
>> 
>> The authors
>> 
>> _______________________________________________
>> OSPF mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ospf