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

[Michael Lundberg <[e-mail]>]

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.

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