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

[Padma Pillay-Esnault <[e-mail]>]

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.

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

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

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

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.

Regards,

The authors