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:bensons(_at_)queuefull(_dot_)net]
Sent: 24 November 2014 23:36
To: ietf(_at_)ietf(_dot_)org; bess(_at_)ietf(_dot_)org
Cc: adrian(_at_)olddog(_dot_)co(_dot_)uk
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:adrian(_at_)olddog(_dot_)co(_dot_)uk> 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
