[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
> > >>
> >
> >
> >
>