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

[Srinivasan K L <[e-mail]>]

Hi,

 

I have a question about section 4.3.2.2 of
draft-ietf-l3vpn-ospfv3-pece-05.txt. The section reads:

 

4.3.2.2.  OSPF Intra-Area Route

 

   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/NSSA (Sections 4.3.2.3) routes

 

My question is: Are there any new Intra-Area prefix LSAs advertised beyond
those that existed before the sham links were used ?  I understand that the
sham links allows the Intra-Area Prefix to flow into this site from other
sites, and these prefixes result in intra-area routes. 

 

Regards,

Srini.

****************************************************************************
***********
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

  _____  

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Padma Pillay-Esnault
Sent: Saturday, January 30, 2010 11:17 AM
To: Ross Callon; Adrian Farrel; [e-mail]; Abhay Roy (akr);
Peter Psenak (ppsenak)
Cc: [e-mail]; 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