draft-ietf-l3vpn-ospf-2547-04 L3VPN/OSPF WG Last Call

Acee Lindem <acee@CISCO.COM> Wed, 31 August 2005 15:50 UTC

User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID: <4315D193.50205@cisco.com>
Date: Wed, 31 Aug 2005 11:49:39 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
Subject: draft-ietf-l3vpn-ospf-2547-04 L3VPN/OSPF WG Last Call
Comments: cc: l3vpn@ietf.org
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

This begins working group last call on draft-ietf-l3vpn-ospf-2547-04.
This last call is limited to the changes that Eric has made to the
document (which are outlined in Eric's email below). The last call
will end in two weeks (September 14th).

Please send any comments to the l3vpn (l3vpn@ietf.org) and
OSPF WG mailing lists. The document is an l3vpn WG document but
it reflects OSPF operation/interaction with BGP/MPLS in a
PE/CE environment.

Thanks,
Acee

At 11:45 AM 8/29/2005 -0400, Eric Rosen wrote:

> As  a  result of  AD  review,  significant changes  have  been  made 
> to  the
> specification draft-ietf-l3vpn-ospf-2547.  These changes  can be seen 
> in the
> latest version, draft -04.  It is believed that the draft now 
> corresponds to
> the implementations.
>
> The following issues were addressed as a result of the AD review.
>
> The spec was  written so as to  allow a single VRF to  correspond to 
> multiple
> OSPF  domains.  However, it  did not  make clear  just which  
> parameters and
> procedures are relative to a domain,  and which are relative to a 
> VRF.  This
> has  now been  cleared up.   However,  doing so  required extensive  
> textual
> changes.
>
> There  are cases  where  BGP decides  to  put a  route into  the  VRF 
> for  a
> particular address prefix, and OSPF also decides to put a route into 
> the VRF
> for that same address prefix.  Of  course, only one of these can 
> actually be
> used for  forwarding.  The  original spec did  not make it  adequately 
> clear
> just how  a choice  between two such  routes would  be made.  This  
> has been
> clarified.  In  some cases,  the results will  be different than  they 
> would
> have been if the VPN were really a pure OSPF network.  These 
> differences are
> now explained and their potential consequences pointed out.
>
> The  procedures  for  forwarding data  traffic  on  a  sham link  
> have  been
> clarified.  The procedures  for sending OSPF control traffic  on a 
> sham link
> have been clarified.  The role of the optional  "sham link endpoint 
> address"
> has been clarified.
>
> The  procedures for  translating BGP-distributed  VPN-IPv4 routes  
> into OSPF
> routes have been clarified.
>
> A discussion  of NSSA routes has been  added.  Alex says it  is not 
> detailed
> enough; any feedback in this area would be welcome.
>
> Due to the large number of changes,  Alex has asked for a new last 
> call, and
> I expect the WG chairs to formally issue the last call shortly.

draft-ietf-l3vpn-ospf-2547-04 L3VPN/OSPF WG Last … Acee Lindem