Subject: [bess] Last Call Comment draft-ietf-l3vpn-end-system-04.txt

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 24 Nov 2014 19:27:10 -0000

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

> -----Original Message-----
> From: IETF-Announce [mailto:[email-masked]] On Behalf Of The
> IESG
> Sent: 24 November 2014 15:57
> To: IETF-Announce
> Cc: [email-masked]
> Subject: Last Call: <draft-ietf-l3vpn-end-system-04.txt> (BGP-signaled end-
> system IP/VPNs.) to Proposed Standard
> 
> 
> The IESG has received a request from the BGP Enabled Services WG (bess)
> to consider the following document:
> - 'BGP-signaled end-system IP/VPNs.'
>   <draft-ietf-l3vpn-end-system-04.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2014-12-08. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> This document contains a normative Downref to RFC 1027
> 
> Abstract
> 
>    This document describes a solution in which the control plane
>    protocol specified in BGP/MPLS IP VPNs is used to provide a Virtual
>    Network service to end-systems.  These end-systems may be used to
>    provide network services or may directly host end-to-end
>    applications.
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-l3vpn-end-system/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-l3vpn-end-system/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.

---

From: Benson Schliesser <[email-masked]>
Date: Mon, 24 Nov 2014 18:36:13 -0500

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-masked]>
> November 24, 2014 at 2:27 PM

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 25 Nov 2014 08:00:27 -0000

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...
 
> publication. I suspect that it may need further review and development
 
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-masked]] 
Sent: 24 November 2014 23:36
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: Last Call Comment draft-ietf-l3vpn-end-system-04.txt

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-masked]> 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.

Thanks,
Adrian

---

From: Benson Schliesser <[email-masked]>
Date: Tue, 25 Nov 2014 13:25:58 -0500

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

> November 25, 2014 at 3:00 AM
>
> Hi Benson,
>
> Thanks for reviewing and commenting. I'm sure the authors will address 
> your points.
>
> 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-masked]]
> *Sent:* 24 November 2014 23:36
> *To:* [email-masked]; [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: Last Call Comment draft-ietf-l3vpn-end-system-04.txt
>
> 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 
> 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 
> 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 
> *Adrian Farrel* <mailto:[email-masked]>
>
> Benson Schliesser <mailto:[email-masked]>
> November 24, 2014 at 6:36 PM
> 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 
> 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 
> 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