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
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
