Subject: RE: Last call, draft-ietf-l3vpn-bgpvpn-auto-03.txt

From: "Schliesser, Benson" <[email-masked]>
Date: Wed, 5 May 2004 12:34:11 -0500

Just a couple comments, for wg-last-call, regarding
draft-ietf-l3vpn-bgpvpn-auto-03.

Section 4.2.2 introduces a new extended community for signaling a VR's
role in the VPN topology. It should be stated more clearly (assuming
I've inferred correctly) that spokes connect to hubs and vice versa, and
meshes connect to each other. Further, the draft should address the
situation where hub, spoke, and mesh VRs all coexist in the same VPN.
One might argue that this is a misconfiguration, but I'd propose that
mesh sites should connect to each other and to hubs while spokes only
connect to hubs, etc.

Section 6 addresses tunnel discovery, and recommends tunneling
mechanisms with demultiplexing capabilities. The draft should either
discuss or point to discussion of how the multiplex keys get
distributed/determined. (it's clear for MPLS, but less so for other
protocols; i.e., IKE, NLRI-encoded, ext community, etc? I know of
implementations that exist, but not necessarily specifications...)

Thanks,
-Benson

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ross Callon
> Sent: Thursday, April 22, 2004 4:43 PM
> To: [email-masked]
> Subject: Last call, draft-ietf-l3vpn-bgpvpn-auto-03.txt
> 
> This begins working group last call on 
> draft-ietf-l3vpn-bgpvpn-auto-03.txt.
> The last call will terminate two weeks from tomorrow (Friday May 7th).
> 
> Comments to the list please.
> 
> thanks, Ross
> 
> 
> >X-JNPR-Received-From: outside
> >To: [email-masked]
> >Cc: [email-masked]
> >From: [email-masked]
> >Subject: I-D ACTION:draft-ietf-l3vpn-bgpvpn-auto-03.txt
> >Date: Thu, 22 Apr 2004 15:41:33 -0400
> >Sender: [email-masked]
> >X-BeenThere: [email-masked]
> >X-Mailman-Version: 2.0.12
> >List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
> >         <mailto:[email-masked]?subject=unsubscribe>
> >List-Id: <l3vpn.ietf.org>
> >List-Post: <mailto:[email-masked]>
> >List-Help: <mailto:[email-masked]?subject=help>
> >List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
> >         <mailto:[email-masked]?subject=subscribe>
> >X-Not-Spam: Spam Score: 4.681 -
> >JNPR_BAD_RECV1,MIME_BOUND_NEXTPART,NO_REAL_NAME
> >X-Scanned-By: MIMEDefang 2.39
> >
> >A New Internet-Draft is available from the on-line Internet-Drafts 
> >directories.
> >This draft is a work item of the Layer 3 Virtual Private Networks 
> >Working Group of the IETF.
> >
> >         Title           : Using BGP as an Auto-Discovery 
> Mechanism for
> >                           Provider-provisioned VPNs
> >         Author(s)       : H. Ould-Brahim, et al.
> >         Filename        : draft-ietf-l3vpn-bgpvpn-auto-03.txt
> >         Pages           : 13
> >         Date            : 2004-4-22
> >
> >In any Provider Provisioned-Based VPN (PPVPN) scheme, the Provider
> >    Edge (PE) devices attached to a common VPN must exchange certain
> >    information as a prerequisite to establish VPN-specific
> >    connectivity. The purpose of this draft is to define a BGP based
> >    auto-discovery mechanism for both layer-2 VPN architectures and
> >    layer-3 VPNs (Virtual Routers ?VR [VPN-VR]). This 
> mechanism is based
> >    on the approach used by BGP/MPLS-IP-VPN [BGP/MPLS-IP-VPN] for
> >    distributing VPN routing information within the service 
> provider(s).
> >    Each VPN scheme uses the mechanism to automatically discover the
> >    information needed by that particular scheme.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgpvpn-a
> uto-03.txt
> >
> >To remove yourself from the I-D Announcement list, send a message to 
> >[email-masked] with the word unsubscribe in 
> the body of 
> >the message.
> >You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> >to change your subscription settings.
> >
> >
> >Internet-Drafts are also available by anonymous FTP. Login with the 
> >username "anonymous" and a password of your e-mail address. After 
> >logging in, type "cd internet-drafts" and then
> >         "get draft-ietf-l3vpn-bgpvpn-auto-03.txt".
> >
> >A list of Internet-Drafts directories can be found in 
> >http://www.ietf.org/shadow.html or 
> >ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> >Internet-Drafts can also be obtained by e-mail.
> >
> >Send a message to:
> >         [email-masked].
> >In the body type:
> >         "FILE /internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-03.txt".
> >
> >NOTE:   The mail server at ietf.org can return the document in
> >         MIME-encoded form by using the "mpack" utility.  To use this
> >         feature, insert the command "ENCODING mime" before 
> the "FILE"
> >         command.  To decode the response(s), you will need 
> "munpack" or
> >         a MIME-compliant mail reader.  Different 
> MIME-compliant mail readers
> >         exhibit different behavior, especially when dealing with
> >         "multipart" MIME messages (i.e. documents which 
> have been split
> >         up into multiple messages), so check your local 
> documentation on
> >         how to manipulate these messages.
> >
> >
> >Below is the data which will enable a MIME compliant mail reader 
> >implementation to automatically retrieve the ASCII version of the 
> >Internet-Draft.
> >Content-Type: text/plain
> >Content-ID:     <[email-masked]>
> >
> >ENCODING mime
> >FILE /internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-03.txt
> >
> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-l3vpn-bgpvpn-a
> uto-03.txt
> >>
> 
> 
>

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Fri, 7 May 2004 15:06:54 -0400

Benson,

Thanks for the feedback.

> Section 4.2.2 introduces a new extended community for 
> signaling a VR's role in the VPN topology. It should be 
> stated more clearly (assuming I've inferred correctly) that 
> spokes connect to hubs and vice versa, and meshes connect to 
> each other. Further, the draft should address the situation 
> where hub, spoke, and mesh VRs all coexist in the same VPN. 
> One might argue that this is a misconfiguration, but I'd 
> propose that mesh sites should connect to each other and to 
> hubs while spokes only connect to hubs, etc.
> 

Sure. I will make this clarification.

> Section 6 addresses tunnel discovery, and recommends 
> tunneling mechanisms with demultiplexing capabilities. The 
> draft should either discuss or point to discussion of how the 
> multiplex keys get distributed/determined. (it's clear for 
> MPLS, but less so for other protocols; i.e., IKE, 
> NLRI-encoded, ext community, etc? I know of implementations 
> that exist, but not necessarily specifications...)
> 

Indeed, multiple implementations may have different ways to
distribute/determine the demultiplexing capabilities and what
is needed for the discovery process to convey. In fact,
the draft is just trying to focus on the discovery process and
the minimum information such as PE address, VR- private address 
(that may or may not be used), membership information and not 
to describe how each tunnel protocol will use it. 
However, we can elaborate and clarify that the demultiplexing scheme 
needs to be determined as part of the discovery process or as part 
of the signaling protocol.

How about we add a text along these lines:

"The auto-discovery mechanism should convey minimum information 
for the tunnels to be setup. The means of distributing multiplexors 
must be defined either via some sort of  tunnel-protocol-specific 
signaling mechanism, or via additional information carried by the  
auto-discovery protocol. That information may or may not be 
used directly within the specific signaling protocol. 
On one end of the spectrum, the combination of IP address 
(such as BGP next hop and IP address carried within the NLRI) 
and the label and/or VPN-ID provides sufficient information for a 
PE to setup per VPN or per set of VPNs tunnels. On another end of the 
spectrum additional specific tunnel related information can be carried
within the discovery process if needed."

Thanks again.

Hamid.

> > >         "FILE 
> /internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-03.txt".
> > >

---

From: "Schliesser, Benson" <[email-masked]>
Date: Fri, 7 May 2004 20:36:27 -0500

Hamid-
I think your proposed changes (quoted below) are fine.
Thanks,
-Benson

> From: Hamid Ould-Brahim [mailto:[email-masked]] 
> Sent: Friday, May 07, 2004 2:07 PM
> To: Schliesser, Benson; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: Last call, draft-ietf-l3vpn-bgpvpn-auto-03.txt
> 
> Benson,
> 
> Thanks for the feedback.
> 
> > 
> signaling a VR's 
> > I've inferred correctly) that spokes connect to hubs and 
> vice versa, 
> > and meshes connect to each other. Further, the draft should address 
> > the situation where hub, spoke, and mesh VRs all coexist in 
> the same 
> > VPN.
> propose that