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

[Ross Callon <[e-mail]>]

I have changed the state back to "AD is Watching", and informed the appropriate folks (IESG, RFC Editor, secretariat). Thus you can feel free to update the document whenever is convenient for the authors.

Once the document is updated, we will need to repeat the WG last call (which I believe should be sent to both L3VPN and OSPF WGs).  Please let me know when this is complete.

Thanks, Ross

________________________________
From: Padma Pillay-Esnault [mailto:[e-mail]]
Sent: 30 January 2010 00:47
To: Ross Callon; Adrian Farrel; [e-mail]; Abhay Roy (akr); Peter Psenak (ppsenak)
Cc: Padma Pillay-Esnault; [e-mail]; Lundberg, Michael [USA]; Ertekin, Emre [USA]; [e-mail]; [e-mail]
Subject: RE: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol'


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