Using BGP as an Auto-Discovery Mechanism for VR-based Layer-3 VPNs
draft-ietf-l3vpn-bgpvpn-auto-09

IANA Comments for new version

Upon approval of this document, the IANA will take four
actions.

First, IANA will make three new registrations in the BGP
Extended Communities Types registry located at:
http://www.iana.org/assignments/bgp-extended-communities

In the BGP Extended Communities Types registry for extended
and transitive types three new entries will be made for:

Name Value
VPN Topology Type Hub tbd
VPN Topology Type Spoke tbd
VPN Topology Type Mesh tbd

Second, IANA will make a single new registration in the BGP
Extended Communities Types registry located at:
http://www.iana.org/assignments/bgp-extended-communities

In the BGP Extended Communities Types registry for regular
and transitive types a new entry will be made for:

Name Value
VPN-ID Extended Community tbd

Third, IANA will add one SAFI numbers to the registry located at
http://www.iana.org/assignments/safi-namespace

Value Description
======== ====================================================
tbd Information for VR for labeled prefixes

Fourth, IANA will change the existing description for the SAFI
value "140" from "VPN auto-discovery" to "information for VR for non-labeled
prefixes"

IANA understands that these are the only actions required upon
publication of the document.

IANA Last Call Comments:

IANA is NOT OKAY.

Upon approval of this document, the IANA will take four actions.

IANA will add two SAFI numbers to the registry located at
http://www.iana.org/assignments/safi-namespace

The current draft requests that two SAFI numbers be added to
the registry: value "129" for indicating that the NLRI is
carrying information for  VR-based solution and value "140"
for indicating that the NLRI is carrying information for
VR fornon-labeled prefixes.

However, the IANA notes that RFC 2858 says that SAFI values
in the range 128 through 255 are not to be assigned by IANA.
SAFI values "4" through "634" are assigned by IANA via
IETF Consensus and values "64" through "127" are assigned
on a first-come, first-served basis.

It appears to IANA that the values "129" and "140" SHOULD
NOT be assigned in the way that this draft suggests.
Could the authors resolve this concern?

The other two IANA Actions involve BGP Extended Communities.

The first of these is the first registration in the BGP
Extended Communities

Types registry located at:
http://www.iana.org/assignments/bgp-extended-communities

In the BGP Extended Communities Types registry for regular
and transitive types a new entry will be made for:

Name Type Value
VPN-ID Extended Community tbd

The second of these is also a registration in the BGP
Extended Communities Types registry located at:

http://www.iana.org/assignments/bgp-extended-communities

In the BGP Extended Communities Types registry for extended
and transitive types a new entry will be made for:

Name Type Value
VPN Topology tbd

IANA understands that, once the conflict surrounding the
SAFI values is resolved, these four actions are the only
ones IANA needs to implement upon approval of the draft.

State Change Notice email list have been change to l3vpn-chairs@tools.ietf.org, hbrahim@nortelnetworks.com, erosen@cisco.com, yakov@juniper.net from rick@rhwilder.net, rcallon@juniper.net, rbonica@juniper.net, hbrahim@nortelnetworks.com, erosen@cisco.com, yakov@juniper.net

[Note]: '4/18/2006: Chairs say author has agreed to focus document to VR case only, and proceed with other document on Informational track.' added by Mark Townsley

[Note]: '2/20/06: Waiting for questionairre from chairs
3/16/06: Needs revising based on feedback that this draft is not necessary for implementing RFC4364 L3VPNs or L2VPNs. Likely focus on VR aspect, and move to informational along with other VR specs.

Going ahead and moving to informational for now, though still waiting final word from chairs/authors.' added by Mark Townsley

Changes from -05 to -06


-------- Original Message --------
Subject: RE: draft-ietf-l3vpn-bgpvpn-auto-06.txt
Date: Mon, 25 Jul 2005 10:55:47 -0400
From: Hamid Ould-Brahim
To: Hamid Ould-Brahim , Ross Callon , ,
CC: Mark Townsley , Rick Wilder , Ronald Bonica ,


Ross,


Here is pretty much a summary of changes made from the last version.
Most of them were addressing the comments coming from the last iesg
review of the document.

- I added in the abstract and introduction couple of sentences
  further clarifying the role of an auto-discovery mechanism.

  "An auto-discovery mechanism allows a PE to dynamically
  discover the set of remote PEs having VPN members
  in common. The auto-discovery mechanism proceeds
  by having a PE advertises to other PEs, at a minimum,
  its own IP address and the list of VPN members configured
  on that PE. Once that information is received the remote
  PEs will then identify the list of VPN members they have
  in common with the advertising PE, and use the
  information carried within the discovery mechanism
  to either establish layer-2/3 VPN connectivity or
  to learn remote site VPN routes."

- fixed some id nits stuff (typos, updated reference section, etc)...

- Given the comment made by Thomas on the applicability
  section, added a sentence that l3 and l2vpn solutions that intend
  to use BGP as the auto-discovery mechanism must comply with the
  encoding proposed in this document.

- Added further clarification on what VR prefix represents in section
  3.1.

- Since sections 5.1 and 5.2 are already covered in l2vpn signaling
  draft and apply only to ldp-based solution, we removed these
  two sections and updated the IANA section accordingly.

- Added further clarification to section 5.3 on VPLS particularly
  on the use of RD and RT.


Let me know if you need more details on these changes. Thanks.

Hamid.

[Note]: '

-------- Original Message --------
Subject: Re: WG Chair writeups for L3VPN Docs
Date: Wed, 27 Apr 2005 14:18:54 -0700 (PDT)
From: Rick Wilder
To: W. Mark Townsley , rick@rhwilder.net,
rcallon@juniper.net, ronald.p.bonica@mci.com



Mark,

I just exchanged some email with the authors of
draft-ietf-l3vpn-bgpvpn-auto. They are preparing to submit a new version
to more completely address comments they have received, so I encourage
them to proceed.

Rick
' added by Mark Townsley

State Change Notice email list have been change to rick@rhwilder.net, rcallon@juniper.net, rbonica@juniper.net, hbrahim@nortelnetworks.com, erosen@cisco.com, yakov@juniper.net from rick@rhwilder.net, rcallon@juniper.net, ronald.p.bonica@mci.com, hbrahim@nortelnetworks.com, erosen@cisco.com, yakov@juniper.net

[Note]: '2004-10-08: Author indicates he will look at comments and followup. 2004-08-26: AD review leaves me uncomfortable that this document is
ready to go. See comments in log.
' added by Thomas Narten

[Note]: '2004-10-08: Author indicates he will look at comments and followup.

2004-08-26: AD review leaves me uncomfortable that this document is
ready to go. See comments in log.
' added by Thomas Narten

From: Thomas Narten
To: "Rick Wilder" , Ross Callon ,
    Ron Bonica
cc: Alex Zinin , hbrahim@nortelnetworks.com,
    erosen@cisco.com, yakov@juniper.net
Date: Thu, 26 Aug 2004 12:23:00 -0400
Subject: AD review of draft-ietf-l3vpn-bgpvpn-auto-04.txt

I've done my review of this document (see below), and I'm concerned
that it's too mushy in terms of what needs to be implemented to
achieve interoperability. Maybe this an be fixed by putting more
explicit references to other documents. Maybe some more words are
needed. Maybe both.

Thomas

2004-08-25: review of -04 (WG says advance)

General. I find this document hard to understand, in the sense that it
is not immediately clear exactly what must be implemented (for
interoperability) and exactly what goes in what fields and how they
are interpreted. As an example, Section 5 basically says that for l2
VPNs, go see some other (unspecified) document. Section 4.2.2 defines
a "VPN Topology value", but I don't understand how this is used. E.g.,
what does a recieiver do when it gets one of these?

Seems like for autodiscovery, what one needs is a way of having each
router say "I am part of VPN XXX". I gather that is what this document
is doing. But how exactly is this done? Is the point that any router
advertising a route that contains an RD with a particular VPN ID is to
be treated as such a router? There seems to be a lot of words in the
document to say just this.

Nits:

>    layer-3 VPNs (Virtual Routers –VR [VPN-VR]). This mechanism is based

non-ascii character...

References in abstract

>    [L2VPN-ROSEN] Rosen, E., Radoaca, V., "Provisioning Models and
>        Endpoint Identifiers in L2VPN Signaling", Work in Progress. 

For references, please include the draft name for ease of reference.

>    connectivity. The purpose of this draft is to define a BGP based
>    auto-discovery mechanism for both layer-2 VPN architectures (i.e.,
>    [L2VPN-KOMP], [L2VPN-ROSEN]) and layer-3 VPNs Virtual Router(VR
>    [VPN-VR]). This mechanism is based on the approach used by BGP/MPLS-

Are these the best references? I.e, are these the ones the WG(s) are
pushing forward on standards track?

>    Both the layer-2 and layer-3 vpns architectures are using a network
>    reference model as illustrated in figure 1.

s/vpns/vpn/??

applicability: Who uses this?

>    on the other hand, is in the service provider addressing space. In
>    L3VPNs, the NLRI contains an address prefix which is within the
>    VPN address space, and therefore must be unique within the VPN.   

what does the prefix indicate? isn't the problem "find the routers
that are part of VPN XXX?"

>    In the case of the virtual router, the NLRI address prefix is an
>    address of one of the virtual routers configured on the PE. Thus
>    this mechanism allows the virtual routers to discover each other, to

I don't understand.

>    The NLRI carries VPN layer-2 addressing information called VPN-L2
>    address. A VPN-L2 address is composed of a quantity beginning with
>    an 8 bytes Route Distinguisher (RD) field and a variable length
>    quantity encoded according to the layer-2 VPN architecture used.

defined here? Reference to document?

>    This is done as follows.  The NLRI is a VPN-IP address or a labeled
>    VPN-IP address. 

what are these?

>    address. A VPN-L2 address is composed of a quantity beginning with
>    an 8 bytes Route Distinguisher (RD) field and a variable length
>    quantity encoded according to the layer-2 VPN architecture used.

Need more specific references here. Are there at least some example
formats?

>    boundary. The value of the type field for extended type is assigned
>    by IANA. The first two bytes of the value field (of the remaining 6

needs a proper IANA considerations section.

>    Arbitrary values can also be used to allow specific topologies to be
>    constructed. In a hub and spoke topology, spoke sites connect only
>    to hub sites. Hub sites can connect to both hub and spoke sites. In
>    a mesh topology, mesh sites connect to each other. Furthermore, in
>    the presence of both hub and spoke and mesh topologies within the
>    same VPN, mesh sites can as well connect to hub sites (and vice
>    versa)

How is this  encoded in BGP attributes and how used? Doesn't seem very
automatic.

>    packets. A provider edge router may terminate multiple type of

s/type/types/

>    BGP can be used to carry tunnel endpoint addresses between edge
>    routers. For scalability purposes, this draft recommends the use of
>    tunneling mechanisms with demultiplexing capabilities such as IPSec,
>    MPLS, and GRE (with respect to using GRE -the key field, it is no
>    different than just MPLS over GRE, however there is no specification
>    on how to exchange the key field, while there is a specification and
>    implementations on how to exchange the label). Note that IP in IP
>    doesn't have demultiplexing capabilities. 

Don't follow. Demultiplex on what? What is the issue here?

>    prefixes), and a SAFI value of 140 is for non labeled addresses.

s/non labeled/non-labeled/

>    VPNs, and (d) ASBRs.

s/and//