[Idr] FW: 2 week Last call on draft-ietf-l3vpn-ospf-2547-04.txt

Resending to get around mailer limit on copies. 

________________________________

From: Susan Hares 
Sent: Wednesday, September 07, 2005 6:47 AM
To: 'idr@ietf.org'
Cc: 'yakov@juniper.net'; 'zinin@psg.com'; 'acee@cisco.com';
'rohit@utstar.com'; 'zinin@psg.com'; 'townsley@cisco.com';
'rick@rhwilder.net'; 'rbonica@juniper.net'; 'rcallon@juniper.net';
'erosen@cisco.com'
Subject: 2 week Last call on draft-ietf-l3vpn-ospf-2547-04.txt

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 21st).

Please send any comments to the working group mailing list.

Thank-you,

Susan Hares and Yakov Rekhter 

(co-chairs, IDR) 

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.