Re: [art] [bess] APPDIR Review of draft-ietf-l3vpn-end-system-05

[Matt Miller <[e-mail]>]

Thanks for the update, Stuart.  I'll take a read through and let you know.


- m&m

Matt Miller
Cisco Systems, Inc.

On 2016-12-15 15:13, Stuart Mackie wrote:
> Matt,
> 
>  
> 
> As you have probably realized from the lack of activity on this draft,
> Pedro Marques has moved on and is no longer active in this area. I have
> been asked to take ownership and move the draft through the IETF process.
> 
>  
> 
> I just posted a new version of the draft which addresses the concerns
> raised in your email.
> 
>  
> 
> I have made quite a few changes for clarity in the draft, so I have
> described the changes that specifically address your issues in this note.
> 
>  
> 
> Please let me know if you have any further concerns.
> 
>  
> 
> Thanks
> 
>  
> 
> Stuart
> 
> ---------------------------------------
> 
>  
> 
> I have been selected as the Applications in ART Directorate reviewer for
> 
> this draft (for background on appsdir, please see
> 
> ​
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).
> 
>  
> 
> Please resolve these comments along with any other Last Call comments
> 
> you may receive. Please wait for direction from your document shepherd
> 
> or AD before posting a new version of the draft.
> 
>  
> 
>  
> 
> Document: draft-ietf-l3vpn-end-system-05
> 
> Title: BGP-signaled end-system IP/VPNs
> 
> Reviewer: Matt Miller
> 
> Review Date: 2016-01-18
> 
> IETF Last Call Date: N/A
> 
> IESG Telechat Date: N/A
> 
>  
> 
> Summary: This draft is not ready for publication as a Proposed
> 
> Standard.
> 
>  
> 
> Comments:
> 
>  
> 
> This draft is making assumptions and design decisions that are not really
> 
> compatible with XMPP, and these should be resolved before publishing.
> 
>  
> 
> It's important to note XMPP is an end-to-end application routing
> 
> protocol. Clients are capable of sending data to other clients,
> 
> possibly crossing multiple server boundaries.  For example:
> 
>  
> 
> 1) [e-mail] -->
> 
> 2) server-1.example -->
> 
> 3) muc.example -->
> 
> 4) server-2.example -->
> 
> 5) [e-mail]
> 
>  
> 
> This document seems to make the assumption that routing is purely
> 
> between a client and its sever, which I believe has lead to design
> 
> decisions that are very problematic.
> 
>  
> 
> Major Issues: (All of which apply to Section 6. XMPP Signaling
> 
> Protocol)
> 
>  
> 
> * The addressing scheme for End Systems connecting to the external VPN
> 
> Forwarder is not explicitly documented anywhere -- the only instance I
> 
> can deduce is from the external VPN forwarded subscription example,
> 
> which seems to use a domain JID for the End System.  Without a clear
> 
> XMPP addressing scheme, properly routing stanzas across the XMPP
> 
> network and mutually authenticating TLS according to RFC 6125 (and
> 
> possibly [XEP-0178]) seem problematic to me.
> 
>  
> 
> /SM>  Modified as follows:/
> 
> /The VPN Forwarder SHOULD use its hostname as JID, when available, or a
> unique IP address within the infrastructure network using its string
> representation. The same naming convention SHOULD be used for an End
> System which has an XMPP session with an external VPN Forwarder./
> 
>  
> 
> If End Systems are expected to communicate directly with the Route
> 
> Server (e.g., End System addresses stanzas to the Route Server, which
> 
> the VPN Forwarder is expected to relay), the addressing scheme for all
> 
> components needs to be better defined.  For instance, the VPN Forwarder
> 
> address in XMPP could be a domain JID as it is, while the End System
> 
> address could be a bare JID derived from that VPN Forwarder's JID
> 
> (e.g., "[e-mail]").  This would disambiguate the
> 
> XMPP routing across the XMPP network.
> 
>  
> 
> /SM> It is not, in fact, intended that End Systems communicate with the
> Route Server directly. There were some typos that indicated to the
> contrary. Figure 1 in the -05 draft was misleading since it indicated
> that End Systems have an XMPP session with Route Servers. The diagram
> has been updated as follows/
> 
>  
> 
>                         +---------+        +--------+
> 
>                         |    RS   |--------|  BGP   |
> 
>                         +---------+        +--------+
> 
>                         /         \        /
> 
>                       XMPP         \      /
> 
>                       /             \    /
> 
>    +--------------------+            \  /
> 
>    |  End   |   VPN     |             \/
> 
>    | System | Forwarder |             /\
> 
>    +--------------------+            /  \
> 
>                       \             /    \
> 
>                       XMPP         /      \
> 
>                         \         /        \
> 
>                         +---------+        +--------+
> 
>                         |    RS   |--------|  BGP   |
> 
>                         +---------+        +--------+
> 
>  
> 
>  
> 
>  
> 
> However, if VPN Forwarders are to act as proxies for End Systems, then
> 
> it should act as a proxy in all cases -- End Systems subscribe to
> 
> pubsub nodes on the external VPN Forwarder (which could in turn trigger
> 
> a subscribe of the VPN forwarder to the Route Server), and receive
> 
> notifications from the VPN Forwarder (which in turn are first received
> 
> by the VPN Forwarder from the Route Server).
> 
>  
> 
> /SM> The text now reads:/
> 
> /   When an external Forwarder is used, its control software MAY operate/
> 
> /   as an XMPP server which processes requests from end-systems and SHALL/
> 
> /   operate as a client of one or more End-System Route Servers.  The/
> 
> /   control software relays to the End-System Route Server(s) VPN/
> 
> /   membership stanzas it receives from the end-system.  VPN routing/
> 
> /   information received from the Route Server(s) SHOULD NOT be/
> 
> /   propagated to the end-system unless it specifically requests such/
> 
> /   information.  End systems MAY have sessions directly with the End-/
> 
> /   System Route Servers, and in this case no XMPP sessions are required/
> 
> /   with VPN Forwarders./
> 
>  
> 
> * Using a hard-coded JID for the Route Server can be a serious problem if
> 
> there is ever a case where individual Route Servers oversee different
> 
> routing information.  If this is never the case, then a single JID for
> 
> all Route Servers is probably OK, but I think there could be problems
> 
> with properly authenticating the TLS session.  Using a different JID
> 
> for each Route Server can introduce some difficulties for End Systems
> 
> utilizing external VPN Forwarders, but I think only in the case where
> 
> the End System is expected to subscribe to the Route Server directly --
> 
> if the End System actually subscribes to the VPN Forwarder, then the
> 
> End System already knows the VPN Forwarder's JID and would not need to
> 
> determine the Route Server' JID.
> 
>  
> 
> /SM> It is assumed that Route Servers contain identical routing
> information, /
> 
> /or that Routing Servers contain just the routing information required
> for the /
> 
> /VPN Forwarders that connect to them. In this second case, a Routing
> Server /
> 
> /can subscribe for routing information managed in a higher-order
> management /
> 
> /system that manages all the routing information for a domain of VPN /
> 
> /Forwarders. The protocol between Route Servers and such a higher-level /
> 
> /management could be XMPP or another convenient protocol that supports a /
> 
> /publish and subscribe capability./
> 
>  
> 
>  
> 
> Minor Issues: (all apply to Section 6. XMPP Signaling Protocol)
> 
>  
> 
> * The XEP-0060 PubSub subscription and unsubscription examples are
> 
> incorrect.  Specifically, the 'jid' attribute of the <subscribe/>
> 
> element is the subscriber's JID not the pubsub service, and
> 
> subscription options are encoded using Data Forms [XEP-0004].
> 
>  
> 
> The co-located example then is:
> 
>  
> 
> <iq type='set'
> 
>     from='forwarder.example'
> 
>     to='route-server'
> 
>     id='sub1'>
> 
>   <pubsub xmlns='http://jabber.org/protocol/pubsub'>
> 
>     <subscribe node='vpn-customer-name' jid='forwarder.example'/>
> 
>     <options node='vpn-customer-name' jid='forwarder.example'>
> 
>       <x xmlns='jabber:x:data' type='submit'>
> 
>         <field var='vpn#instance-id'>
> 
>           <value>1</value>
> 
>         </field>
> 
>       </x>
> 
>     </options>
> 
>   </pubsub>
> 
> </iq>
> 
>  
> 
> /SM> This has been corrected/
> 
>  
> 
> The external example could be the following (if there is a single
> 
> addressing scheme):
> 
>  
> 
> <iq type='set'
> 
>     from='[e-mail]'
> 
>     to='route-server'
> 
>     id='sub1'>
> 
>   <pubsub xmlns='http://jabber.org/protocol/pubsub'>
> 
>     <subscribe node='vpn-customer-name' jid='[e-mail]'/>
> 
>     <options node='vpn-customer-name' jid='[e-mail]'>
> 
>       <x xmlns='jabber:x:data' type='submit'>
> 
>         <field var='vpn#vlan_id'><value>100</value></field>
> 
>       </x>
> 
>     </options>
> 
>   </pubsub>
> 
> </iq>
> 
>  
> 
>  
> 
> The unsubscribe example is then:
> 
>  
> 
> <iq type='set'
> 
>     from='forwarder.example'
> 
>     to='route-server'
> 
>     id='unsub1'>
> 
>   <pubsub xmlns='http://jabber.org/protocol/pubsub'>
> 
>     <unsubscribe node='vpn-customer-name'
> 
>                  jid='forwarder.example' />
> 
>   </pubsub>
> 
> </iq>
> 
>  
> 
> /SM>  In the external case, the VPN Forwarder has the session with the
> Route Server, not /
> 
> /the End-System, and the text has been changed to reflect this. /
> 
> / /
> 
>  
> 
> * Requiring pubsub notifications to always go from the Route Server to
> 
> the VPN Forwarder regardless of what entity subscribed to the pubsub
> 
> node is counter to how XEP-0060 works.  The pubsub subscribe request
> 
> specifies where the notifications are supposed to go, and the pubsub
> 
> service is expected to honor that.  See above in the addressing
> 
> discussion for some ideas of how to deal with this.
> 
>  
> 
> /SM> Within the context of this document, only VPN Forwarders are
> subscribing /
> 
> /to Route Servers./
> 
>  
> 
>  
> 
> Nits:
> 
>  
> 
> * (Mostly in Section 6. XMPP Signaling Protocol) The document often
> 
> uses the term "message" when discussing XMPP communications. The XMPP
> 
> term of art is "stanza" not "message"; "message" has a specific
> 
> meaning in XMPP that is not in use here, and can lead to confusion
> 
> for readers of this document once they follow the references to
> 
> RFC 6120 and the various XEPs.
> 
> /SM> Changed “message” to “stanza”, except in the section that deals with /
> 
> /notifications/
> 
>  
> 
> * In Section 1. Introduction, the use of the term XMPP should be
> 
> followed by a reference to RFC 6120.
> 
>  
> 
> /SM> Change made/
> 
>  
> 
> * In Section 6. XMPP Signaling Protocol, the seventh paragraph
> 
> (immediately preceding Figure 1) has an extraneous period (.) at the
> 
> end of the last sentence.
> 
>  
> 
> SM> Fixed
> 
>  
> 
> * In Section 6. XMPP Signaling Protocol, I understood the meaning of
> 
> the following sentence:
> 
>  
> 
>     The VPN Forwarder SHOULD use as JID its hostname, when available,
> 
>     or an unique IP address within the infrastructure network win its
> 
>     string representation.
> 
>  
> 
> Regardless of how my XMPP addressing concerns are finally resolved,
> 
> please revisit this sentence.
> 
>  
> 
> /SM> Changed to:/
> 
> /The VPN Forwarder SHOULD use as JID its hostname, when available, or a
> unique /
> 
> /IP address within the infrastructure network using it string
> representation./
> 
>  
> 
>  
> 
>  
> 
> References:
> 
>  
> 
> [XEP-0004]: Data Forms < http://xmpp.org/extensions/xep-0004.html >
> 
> [XEP-0030]: Service Discovery < http://xmpp.org/extensions/xep-0030.html >
> 
> [XEP-0178]: Best Practices for Use of SASL EXTERNAL with Certificates <
> http://xmpp.org/extensions/xep-0178.html >
> 
>  
> 
>  
> 
> --
> 
> - m&m
> 
>  
> 
> Matt Miller
> 
> Cisco Systems, Inc.
> 
>  
> 
>  
> 
> *…………………………..*
> 
>  
> 
> *Stuart Mackie*
> 
> /SDN/NFV Architect/
> 
> / /
> 
> [phone]
> 
>  
> 
> cid:image001.png@01D23914.C41AB720
>