Authors,
Any risk of progressing this document?
Attached are four emails that you need to attend to with a new revision. The
comments from Benson developed into a longish thread that seemed to go quiet at
the start of December. The IANA discussion seems to have been resolved around
mid December.
Thanks,
Adrian
--- Begin Message ---
Hi Adrian,
This makes it clear whether or not that assignment needs to be updated when this
draft is approved for publication as RFC:
[[[
I think that might be valuable. So the IANA section should read...
IANA has previously made an allocation from the "BGP Tunnel Encapsulation
Attribute Tunnel Types" registry that reads:
Value | Name | Reference
--------+---------------------------+-------------------------------
13 | MPLS in UDP Encapsulation | [draft-ietf-l3vpn-end-system]
IANA is requested to change the reference to point to the RFC number
of this document when it is published.
]]]
The current text "This document has no IANA actions." provides no
instructions and incorrectly tell people there is no actions requested.
Thanks
~pl
On Tue Dec 09 13:20:57 2014, [email protected] wrote:
> Hi,
>
> Replying to myself and keeping the same IANA tracking number.
>
> > > IESG/Authors/WG Chairs:
> > >
> > > IANA has reviewed draft-ietf-l3vpn-end-system-04. Authors should
> review
> > > the comments and/or questions below. Please report any
> inaccuracies and
> > > respond to any questions as soon as possible.
> > >
> > > IANA's reviewer has the following comments/questions:
> > >
> > > IANA has a question about the IANA Considerations section of this
> document.
> > >
> > > Previously, an early assignment has been made to support this
> draft. The
> > > original request for an assignment is below:
> > >
> > >> <begin request="">
> > >> Contact Name:
> > >> Thomas Morin
> > >>
> > >> Contact Email:
> > >> [email protected]
> > >>
> > >> Type of Assignment:
> > >> Assignement of a BGP parameter in a FCFS registry.
> > >>
> > >> Registry:
> > >> BGP Tunnel Encapsulation Attribute Tunnel Types
> > >>
> > >> See: https://www.iana.org/assignments/bgp-parameters
> > >>
> > >> Description:
> > >> Needed for draft-ietf-l3vpn-end-system, to allow the use of an
> > >> MPLS-over-UDP encapsulation as specified in draft-ietf-mpls-in-
> udp .
> > >>
> > >> No value has been proposed yet, next available value 13 would be
> fine.
> > >>
> > >> Additional Info:
> > >> draft-ietf-l3vpn-end-system
> > >> </end>
> > >
> > > IANA Question --> The IANA Considerations section said "This
> document has
> > > no IANA actions." and, as a result, the assignment made through
> the request
> > > above would not be made permanent. Is this the author's intent? If
> not,
> could
> > > the draft be revised to indicate that the assignment made based on
> the
> request
> > > above be changed from an initial assignment to a permanent
> assignment.
>
> How do you mean?
> The registry is FCFS for which *any* document is sufficient.
> The assignment has been made and is as permanent as any FCFS
> assignment ever is.
>
> > > Please note that IANA cannot reserve specific values. However,
> early
> > > allocation is available for some types of registrations. For more
> information,
> > > please see RFC 7120.
>
> Yes, but this is a FCFS registry to which 7120 does not apply, and nor
> does
> "reservation of values".
> With FCFS the value is assigned when requested and that's it.
>
> Now, it is a different question whether this document should ask for
> the
> registry to be updated to point to the consequent RFC instead of the
> I-D.
>
> I think that might be valuable. So the IANA section should read...
>
> IANA has previously made an allocation from the "BGP Tunnel
> Encapsulation
> Attribute Tunnel Types" registry that reads:
>
> Value | Name | Reference
> --------+---------------------------
> +-------------------------------
> 13 | MPLS in UDP Encapsulation | [draft-ietf-l3vpn-end-system]
>
> IANA is requested to change the reference to point to the RFC
> number
> of this document when it is published.
>
> Cheers,
> Adrian
--- End Message ---
--- Begin Message ---
Thanks Brian,
Authors: please develop updates or a response.
Thanks,
Adrian
> -----Original Message-----
> From: iesg [mailto:[email protected]] On Behalf Of Brian Weis (bew)
> Sent: 09 December 2014 03:19
> To: [email protected]; The IESG
> Cc: [email protected]
> Subject: Secdir review of draft-ietf-l3vpn-end-system-04
>
> I have reviewed this document as part of the security directorate's ongoing
effort
> to review all IETF documents being processed by the IESG. These comments
> were written primarily for the benefit of the security area directors.
Document
> editors and WG chairs should treat these comments just like any other last
call
> comments.
>
> This subject of this document is "BGP-signaled end-system IP/VPNs", which
> defines a system where an L3VPN system is supported on "end systems", which
> means servers sitting in a data center. It describes how the L2VPN control
plane
> and forwarding plane can be implemented in a network virtualization
> environment. Three actors are described, which together implement the L3VPN
> PE role.
>
> The security goal of the L3VPN is to maintain isolation between sets of users
> (e.g., customers of a provider). A new XMPP-based signaling protocol is
> described in order for two of the actors ("End System" and "End System Route
> Server") to pass IP reachability information for each set of users.
>
> The Security Considerations section is fairly light. It should be a bit more
verbose
> in describing the new threats that this system have over and above a
traditional
> L3VPN. The following comments try to tease out what those threats might be.
>
> 1. The first paragraph of Security Considerations says "It is important to
secure
> the end-system access to End-System Route Servers and the BGP infrastructure
> itself." I'm not sure if this is intended to mean that the end-system (and
it's
> virtual machines) aren't trusted and should be isolated from the RSs and BGP
> infrastructure, or if this a preamble to the next paragraph stating that the
XMPP
> session needs to be secured.
>
> But in either case since the L3VPN PE functionality is now no longer
physically
> isolated form the customer images, it is important to describe what new
threats
> this approach adds to the PE role. Maybe the last paragraph in the section is
> trying to make the point that there are new threats, but if so should say more
> about the need for separation of virtual and infrastructure traffic. E.g.,
this
> mitigates traffic from a virtual machine attacking the infrastructure traffic
or
> creating a denial of service by clogging up the infrastructure with frames.
>
> 2. The second paragraph of Security Considerations mentions that the XMPP
> session needs to be secured. It describes the use of certificates, but this
isn't
> enough. Certificates need to be used with a protocol that uses certificates
for
> peer authentication. I think it's common to protect XMPP with TLS, for example
> so you might want to look into that. Once a peer is authenticated with its
> certificate, then the router server can perform authorization. It is important
to
> give at least one complete example of a method to secure the session.
>
> 3. The third paragraph of Security Considerations mentions a couple of
> conventional methods for securing BGP. Is this more than what is typically
> recommended within an L3VPN BGP (as opposed to a BGP speaker connected to
> another provider)? If so, it would be good to say what are the additional
threats
> that require more security.
>
> 4. Section 6 mentions external Forwarders, and says that in this case "VPN
routing
> information received from the Route Server(s) SHOULD NOT be propagated to
> the end-system." Is there a security consideration here?
>
> Brian
>
--- End Message ---
--- Begin Message ---
Thanks for the nits, Peter.
We'll be sure to look at them if the document is open again before being passed
to the RFC editor.
Adrian
> -----Original Message-----
> From: ietf [mailto:[email protected]] On Behalf Of Peter Yee
> Sent: 09 December 2014 08:09
> To: [email protected]
> Cc: [email protected]; [email protected]
> Subject: Gen-ART LC review for draft-ietf-l3vpn-end-system-04
>
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
> please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
>
> Please resolve these comments along with any other Last Call comments you may
> receive.
>
> Document: draft-ietf-l3vpn-end-system-04
> Reviewer: Peter Yee
> Review Date: Dec-8-2014
> IETF LC End Date: Dec-8-2014
> IESG Telechat date: TBD
>
> Summary: This draft is basically ready for publication as a Standards Track
> RFC, but
> has some nits that should be fixed before publication. [Ready with nits.]
>
> This draft documents a novel means of using XMPP to signal VPN route
> information between VPN Forwarders and End-System Route Servers for use
> with BGP IP VPNs. It discussed the requirements on each entity using the
> scheme.
>
> Major issues:
>
> Minor issues:
>
> Nits:
>
> General: Use a comma after i.e. and e.g.
>
> General: Data center doesn't require a hyphen. Neither does virtual machine.
> Wi-Fi does, however.
>
> Page 3, definition of End-System, 1st sentence: change "which" to "whose".
>
> Page 4, 4th paragraph, last sentence: replace "recur to" with "rely upon".
>
> Page 6, 3rd paragraph, 1st sentence: delete "then".
>
> Page 10, 1st paragraph, 1st sentence: delete redundant "the".
>
> Page 10, 1st paragraph, 2nd sentence: change "mac-" to "MAC ". Change "a
> IEEE"
> to "an IEEE".
>
> Page 11, figure: this figure needs a caption with a figure number. That will
> force
> an increment of all of the following figure numbers as well.
>
> Page 16, 1st paragraph after XML, last sentence: change "convinience" to
> "convenience".
>
> Page 16, 2nd paragraph, 3rd sentence: replace the period with a comma and
> change the following "Even" to lower case to join the following clause to the
> sentence.
>
> Page 17, 4th paragraph, 2nd sentence: replace "detemined" with "determined".
> Replace "an" with "a".
>
> Page 17, 5th paragraph, 2nd sentence: replace "mapps" with "maps".
>
> Page 18, Section 8, 4th paragraph, 1st sentence: change "a XMPP" to "an XMPP".
>
> Page 19, 1st paragraph, 2nd sentence: change "attachement" to "attachment".
>
> Page 20, 1st full paragraph, 1st sentence: I'm not certain, but would
> inserting
> "the" before "host" help? Or how about a host number after "host"?
>
> Page 20, 7th paragraph, 2nd sentence: change "Assuming" to "Assume".
>
--- End Message ---
--- Begin Message ---
Hi, Adrian -
Of course it's possible that I'm wrong - in fact, it would be great if that
turns out to be the case. But my suspicion is that it will take material updates
(not just editorial) to fix at least one of the issues that I described in my
review. And, in-line with some of the feedback that I heard during the plenary
at IETF-91, I am biased toward having WGs review material changes, etc.
Here are my views of the severity of changes for each of the three topics that I
raised:
Simple: I agree that it should be relatively straight-forward to fix the
namespace issue. While I'm not intimately familiar with it, I think that RFC
3688 describes how the appropriate namespace can be assigned. I'm comfortable
describing this as editorial rather than material.
Somewhat more material: It may also be straight-forward to fix the VXLAN
encapsulation issue, either by removing the VXLAN option from the schema, or by
making reference to another document that describes the procedure. I can imagine
at least a couple ways that such encapsulation might be done. However I'm not
aware of the existence of such a document, which means it probably needs to be
developed. And it seems to me that the 'label' element in the end-system schema
might be inadequate information for such an encapsulation procedure.
Probably very material: The draft really needs some kind of text around the
various issues I included in the "Second" issue paragraph, in my previous
message. Specifically, there needs to be some text about assignment of
route-server JIDs. This should include some explanation about how route-server
JIDs relate to the redundancy scheme that's sketched out in the draft. This
should also include some kind of error handling discussion around incorrect JIDs
being used in messages, etc. Much of the preceding also applies to pubsub 'node'
values, with an emphasis on the error handling issues. It is possible that the
authors have an editorial solution to this, which would avoid material changes
to the draft text, but my limited imagination can't picture what that might look
like.
As I said above, I would be happy to be wrong about the severity of these
changes. But my suspicion is that they are somewhat material additions / changes
to the draft text.
Cheers,
-Benson
Adrian Farrel <mailto:[email protected]>
November 25, 2014 at 3:00 AM
Hi Benson,
Thanks for reviewing and commenting. I'm sure the authors will address your
points.
I'd just like to pick up on the last one...
> Otherwise, I'm not sure that this draft is ready for Proposed Standard
> publication. I suspect that it may need further review and development
> in BESS.
The draft went through WG process in L3VPN and was subject to WG last call.
There is nothing intrinsically different between processing in BESS and
processing in L3VPN.
So I read you as saying that the three points you have raised are evidence that
more review and development are needed. But it seems to me that the three points
you have raised are relatively small and easily addressed (perhaps I will be
proven wrong) so can you clarify why you think this work should be sent back to
the working group.
Thanks,
Adrian
From: Benson Schliesser [mailto:[email protected]]
Sent: 24 November 2014 23:36
To: [email protected]; [email protected]
Cc: [email protected]
Subject: Re: Last Call Comment draft-ietf-l3vpn-end-system-04.txt
In addition to Adrian's comment, I'm confused by a number of things in
draft-ietf-l3vpn-end-system-04. Just picking on the big ones:
First, I think there might be a mistake in the XML examples and/or XSD. The
schema in section 11 defines a target namespace of
http://www.ietf.org/bgp-l3vpn-unicast.xsd but the examples use
http://ietf.org/protocol/bgpvpn.
Second, the document doesn't seem to provide adequate operational guidance on
how to determine the route server JID, how to determine the correct pubsub node
values, etc. I assume that the server JID is a configurable option. And I assume
that the pubsub node is equivalent to the 128 octet VPN ID. But neither seems to
be spelled out clearly (unless I'm overlooking it) and in any case there don't
seem to be any discussions of error handling. (In fact, the only comment I can
find on the 'node' value suggests vaguely that perhaps all values are implicitly
correct, in which case there needs to be some additional text about
troubleshooting.)
Third, the schema offers three different encap types including GRE, UDP, and
VXLAN. I believe that the GRE and UDP options are meant to be MPLS in {GRE, UDP}
in which cases I think the 'label' element provides adequate information for the
encapsulation. However I can't find text about how to construct the VXLAN
encapsulation. Is it also MPLS over VXLAN, or is the label supposed to map to
the VNI? In either case I suspect that you need a reference to something that
defines the VXLAN usage of link layer addresses, or the use of the GPE
extensions, etc.
Perhaps I'm overlooking something in the text, or (even more likely) maybe I'm
just too ignorant of XMPP standards etc. If that's the case then I hope the
authors will help me understand.
Otherwise, I'm not sure that this draft is ready for Proposed Standard
publication. I suspect that it may need further review and development in BESS.
Cheers,
-Benson
<mailto:[email protected]> Adrian Farrel
November 24, 2014 at 2:27 PM
This document contains a worked example using IP addresses from the 10/8 and
192.168/16 Private Use spaces.
It would be far better if the document used addresses from the three
documentation/test spaces 192.0.2/24 198.51.100/24 and 203.0.113/24
Unless you can provide a strong reason not to make this change (which looks to
me like it would be a simple matter), please do so in a new revision after IETF
last call.
Thanks,
Adrian
Benson Schliesser <mailto:[email protected]>
November 24, 2014 at 6:36 PM
In addition to Adrian's comment, I'm confused by a number of things in
draft-ietf-l3vpn-end-system-04. Just picking on the big ones:
First, I think there might be a mistake in the XML examples and/or XSD. The
schema in section 11 defines a target namespace of
http://www.ietf.org/bgp-l3vpn-unicast.xsd but the examples use
http://ietf.org/protocol/bgpvpn.
Second, the document doesn't seem to provide adequate operational guidance on
how to determine the route server JID, how to determine the correct pubsub node
values, etc. I assume that the server JID is a configurable option. And I assume
that the pubsub node is equivalent to the 128 octet VPN ID. But neither seems to
be spelled out clearly (unless I'm overlooking it) and in any case there don't
seem to be any discussions of error handling. (In fact, the only comment I can
find on the 'node' value suggests vaguely that perhaps all values are implicitly
correct, in which case there needs to be some additional text about
troubleshooting.)
Third, the schema offers three different encap types including GRE, UDP, and
VXLAN. I believe that the GRE and UDP options are meant to be MPLS in {GRE, UDP}
in which cases I think the 'label' element provides adequate information for the
encapsulation. However I can't find text about how to construct the VXLAN
encapsulation. Is it also MPLS over VXLAN, or is the label supposed to map to
the VNI? In either case I suspect that you need a reference to something that
defines the VXLAN usage of link layer addresses, or the use of the GPE
extensions, etc.
Perhaps I'm overlooking something in the text, or (even more likely) maybe I'm
just too ignorant of XMPP standards etc. If that's the case then I hope the
authors will help me understand.
Otherwise, I'm not sure that this draft is ready for Proposed Standard
publication. I suspect that it may need further review and development in BESS.
Cheers,
-Benson
Adrian Farrel <mailto:[email protected]>
November 24, 2014 at 2:27 PM
This document contains a worked example using IP addresses from the 10/8 and
192.168/16 Private Use spaces.
It would be far better if the document used addresses from the three
documentation/test spaces 192.0.2/24 198.51.100/24 and 203.0.113/24
Unless you can provide a strong reason not to make this change (which looks to
me like it would be a simple matter), please do so in a new revision after IETF
last call.
Thanks,
Adrian
--- End Message ---
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
