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

From: Pedro Marques <[email-masked]>
Date: Mon, 1 Dec 2014 12:04:01 -0800

Benson,

> On Nov 25, 2014, at 10:25 AM, Benson Schliesser <[email-masked]> wrote:
> 
> 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.

RFC 3688 provides a way to ask IANA to assign a URN for a schema. It doesn’t include guidelines on how that URN should look like. From the point of view of the draft in question it is simple to modify the examples to use TBD as a URN. However IANA would probably want guidance as to what name to assign. Does it make sense to include a suggestion in the IANA section ?

> 
> Somewhat more material: It may also be straight-forward to fix the VXLAN encapsulation issue, either by removing the VXLAN option from the schema

I’ll remove it.

> , 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.

The reference to the “jid” value in the RD assignment procedure is incorrect; This procedure uses the IP identifier of the compute node. Earlier versions of the document assume the JID to be the IP identifier… this is no longer the case.
Thank you for highlighting this… I’ll update the document.

> 
> 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-masked]>	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-masked] <mailto:[email-masked]>] 
>> Sent: 24 November 2014 23:36
>> To: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>> Cc: [email-masked] <mailto:[email-masked]>
>> 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 <http://www.ietf.org/bgp-l3vpn-unicast.xsd> but the examples use http://ietf.org/protocol/bgpvpn <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
>> 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-masked]>	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 <http://www.ietf.org/bgp-l3vpn-unicast.xsd> but the examples use http://ietf.org/protocol/bgpvpn <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
>> 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-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/bess <https://www.ietf.org/mailman/listinfo/bess>

---

From: Benson Schliesser <[email-masked]>
Date: Wed, 03 Dec 2014 10:38:44 -0800

Hi, Pedro -

>> 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.
>
> RFC 3688 provides a way to ask IANA to assign a URN for a schema. It 
> doesn’t include guidelines on how that URN should look like. From the 
> point of view of the draft in question it is simple to modify the 
> examples to use TBD as a URN. However IANA would probably want 
> guidance as to what name to assign. Does it make sense to include a 
> suggestion in the IANA section ?
>

That makes sense to me. Maybe somebody else knows more about the 
process, and could give better feedback, but what you propose is exactly 
what I would do under the circumstances.

>> 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.
>
> The reference to the “jid” value in the RD assignment procedure is 
> incorrect; This procedure uses the IP identifier of the compute node. 
> Earlier versions of the document assume the JID to be the IP 
> identifier… this is no longer the case.

I look forward to seeing the updated text. I'm not sure that your 
proposal covers all the issues that I've identified, but I'll wait to 
see the text before I leap to any conclusions. :)

Cheers,
-Benson