[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Last call, draft-ietf-l3vpn-bgpvpn-auto-03.txt
Hamid-
I think your proposed changes (quoted below) are fine.
Thanks,
-Benson
> -----Original Message-----
> From: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com]
> Sent: Friday, May 07, 2004 2:07 PM
> To: Schliesser, Benson; l3vpn@ietf.org; erosen@cisco.com;
> yakov@juniper.net
> Subject: RE: Last call, draft-ietf-l3vpn-bgpvpn-auto-03.txt
>
> Benson,
>
> Thanks for the feedback.
>
> >
> > 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.
> >
>
> 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.
>
> > Thanks,
> > -Benson
> >
> >
> > > -----Original Message-----
> > > From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org] On
> > > Behalf Of Ross Callon
> > > Sent: Thursday, April 22, 2004 4:43 PM
> > > To: l3vpn@ietf.org
> > > 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: i-d-announce@ietf.org
> > > >Cc: l3vpn@ietf.org
> > > >From: Internet-Drafts@ietf.org
> > > >Subject: I-D ACTION:draft-ietf-l3vpn-bgpvpn-auto-03.txt
> > > >Date: Thu, 22 Apr 2004 15:41:33 -0400
> > > >Sender: l3vpn-admin@ietf.org
> > > >X-BeenThere: l3vpn@ietf.org
> > > >X-Mailman-Version: 2.0.12
> > > >List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
> > > > <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
> > > >List-Id: <l3vpn.ietf.org>
> > > >List-Post: <mailto:l3vpn@ietf.org>
> > > >List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
> > > >List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
> > > > <mailto:l3vpn-request@ietf.org?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
> > > >i-d-announce-request@ietf.org 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:
> > > > mailserv@ietf.org.
> > > >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: <2004-4-22154050.I-D@ietf.org>
> > > >
> > > >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
> > > >>
> > >
> > >
> > >
> >
>