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

From: Ross Callon <[email-masked]>
Date: Fri, 5 Feb 2010 12:53:35 -0500

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:[email-masked]]
Sent: 30 January 2010 00:47
To: Ross Callon; Adrian Farrel; [email-masked]; Abhay Roy (akr); Peter Psenak (ppsenak)
Cc: Padma Pillay-Esnault; [email-masked]; Lundberg, Michael [USA]; Ertekin, Emre [USA]; [email-masked]; [email-masked]
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

---

From: Michael Lundberg <[email-masked]>
Date: Wed, 10 Feb 2010 13:04:07 -0500

Hi Acee,

Please find responses to your questions below.

Thanks,
Michael

On Sun, Jan 31, 2010 at 2:28 PM, Acee Lindem <[email-masked]> 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:
>
>
> ACEE: Great. Just to be clear, you will remove the instance-id from the OSPFv3 route extended communities attributes as well - right?
>

Yes

> ACEE: Replace "as an AS-External LSAs" with "as AS-External LSAs".
>

Agree

> ACEE: You could replace "external" with "external/NSSA" to be more precise.
>

Agree

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

> ACEE: I'd agree.
> Thanks,
> Acee
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

---

From: Acee Lindem <[email-masked]>
Date: Wed, 10 Feb 2010 17:37:45 -0500

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

> 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

---

From: Michael Lundberg <[email-masked]>
Date: Wed, 10 Feb 2010 20:53:36 -0500

Hi Acee,

Comments inline:

  <removed agreed-upon text>

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

The text in section 5.1 stating the sham link is advertised as a type
0x90 is being removed, as Padma indicated above.  The sham link will
be advertised in BGP, but it does not need an extended community, as
the sham link end point addresses are preconfigured at each PE.
Therefore, if PE2 learns a route to PE1's sham link endpoint address
via BGP, the sham link is considered up.

Section 4.3.2.2 talks about PE to CE advertisement of
Intra-Area-Prefix LSAs.  This would be an actual OSPF LSA, not the
extended community.

A type 0x90 encoding in the OSPFv3 route extended community attribute
would be used for cases such as PE1 advertising to PE2 the PE1-CE1
prefix. If the policy in 4.3.2.1 is true, PE2 will advertise this
route to CE2 as an inter-area route, otherwise it will be advertised
as an OSPF external route.

Thanks,
Michael

---

From: Acee Lindem <[email-masked]>
Date: Wed, 10 Feb 2010 22:03:12 -0500

Hi Michael,
Ok - that sounds good to me. I was recalling the sham link auto-discovery mechanism that was in the early RFC 4577 drafts but removed. 
Thanks,
Acee 

|-----Original Message-----
|From: Michael Lundberg [mailto:[email-masked]] 
|Sent: Wednesday, February 10, 2010 8:54 PM
|To: Acee Lindem
|Cc: Padma Pillay-Esnault; [email-masked]; Ertekin, 
|Emre [USA]; [email-masked]; Adrian Farrel; [email-masked]
|Subject: Re: [OSPF] OSPF WG review of 
|draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol'
|
|Hi Acee,
|
|Comments inline:
|
|  <removed agreed-upon text>
|
|
|>>> 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.
|
|The text in section 5.1 stating the sham link is advertised as 
|a type 0x90 is being removed, as Padma indicated above.  The 
|sham link will be advertised in BGP, but it does not need an 
|extended community, as the sham link end point addresses are 
|preconfigured at each PE.
|Therefore, if PE2 learns a route to PE1's sham link endpoint 
|address via BGP, the sham link is considered up.
|
|Section 4.3.2.2 talks about PE to CE advertisement of 
|Intra-Area-Prefix LSAs.  This would be an actual OSPF LSA, not 
|the extended community.
|
|A type 0x90 encoding in the OSPFv3 route extended community 
|attribute would be used for cases such as PE1 advertising to 
|PE2 the PE1-CE1 prefix. If the policy in 4.3.2.1 is true, PE2 
|will advertise this route to CE2 as an inter-area route, 
|otherwise it will be advertised as an OSPF external route.
|
|Thanks,
|Michael
|
|>
|> 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
|>>> [email-masked]
|>>> https://www.ietf.org/mailman/listinfo/ospf
|>
|>
|