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

[Stuart Mackie <[e-mail]>]

Matt

Did you get a chance to look at the updates?

Thanks

Stuart
-914 886 2534

On 12/16/16, 3:34 PM, "Matt Miller" <[e-mail]> wrote:

    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
    >