Subject: [Gen-art] Gen-ART Review of draft-ietf-l2vpn-requirements-06.txt

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 13 Jan 2006 09:39:06 -0600

Just to let Brian know - the authors have addressed all the comments I 
raised in my review of -05. Ready for publication as an Informational RFC, 
in my opinion.

Thanks!

Spencer

>I was selected as General Area Review Team reviewer for this
> specification (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Summary: This document is on the right track for publication as an 
> Informational RFC, but some work remains. Most of the comments I list 
> below are nits, but the comments on 3.4, 4.6, and 6.10 are probably worth 
> some attention after Last Call.
>
> Thanks, and good luck with your document!
>
> Spencer Dawkins
>
> 2.1 Scope of this document
>
>   The technical specifications to provide L2VPN services are outside
>   the scope of this document.  The framework document [L2VPN_FR] and
>   several documents, which explain technical approaches providing L2VPN
>   services, are available to cover this aspect.
>
> Spencer: "and several documents" without citations seems hand-waveish...
>
> 3.2 Taxonomy of L2VPN Types
>
>   The following diagram shows a L2VPN reference model.
>
> Spencer: citation for this "reference model" would be nice. It would also 
> be nice to say "L2VPN A in this diagram shows VPLS, L2VPN B shows VPWS" - 
> "In Figure 1, L2VPN B represents a VPWS case" does appear later in the 
> document, but it's buried at the end of a paragraph, and I can't find 
> "L2VPN A represents a VPLS" anywhere in the document.
>
> 3.4 VPLS
>
>   In a VPLS, a customer site receives Layer 2 service from the SP.  The
>   PE is attached via an access connection to one or more CEs.  The PE
>   performs forwarding of user data packets based on information in the
>   Layer 2 header, such as a MAC destination address.  The CE sees a
>   bridge.
>
> Spencer: "sees a bridge" doesn't seem particularly clear here. Section 
> 4.7.2 is a good example of what I'm hoping for - calling out specific 
> specifications for the interface that are required. At the very least, 
> Figure 3 shows "backdoor links" - so do all L2VPN solutions need to 
> provide 802.1D-2004 spanning tree support? I should also note that I'm 
> currently involved in some pretty detailed discussion about "bridging" in 
> TRILL, and lack of precision about what a "bridge" actually does is making 
> our work difficult there, so I'm more sensitive than usual on this topic.
>
> 4.1 Scope of emulation
>
>   Some possibly salient differences between VPLS and a real LAN are:
>     - VPLS frames can get duplicated if the PW sequencing option isn't
>     turned on.  The data frames on the PWs are sent in IP datagrams,
>     and under certain failure scenarios, IP networks can duplicate
>     packets.  If the PW data transmission protocol does not ensure
>     sequence of data packets, frames can be duplicated or received out
>     of sequence.  If the customer's Bridge Protocol Data Unit (BPDU)
>     frames are sent as data packets, then BPDU frames can be duplicated
>     or mis-sequenced.
>
> Spencer: it may be worth mentioning that some of the prohibitions against 
> out-of-order delivery, etc. during spanning tree recalculation were 
> relaxed when IEEE defined RTSP, so VPLSes that duplicate or mis-sequence 
> frames during spanning tree recalculation may not be all that different 
> from real LANs.
>
>   - Since the IPLS solution aims at transporting encapsulated traffic
>     (rather than Layer 2 frames themselves), the IPLS solution is NOT
>     REQUIRED to preserve the Layer 2 Header transparently from CE to
>     CE.  For example, Source MAC address may not be preserved by the
>     IPLS solution.
>
> Spencer: s/may not be/will probably not be/? "may not be" seems to say 
> that the lack of transparency is the exception in IPLS, but I would expect 
> it to be the rule.
>
> 4.6 Addressing
>   A L2VPN solution MUST support overlapping addresses of different
>   L2VPNs.  For instance, customers MUST NOT be prevented from using the
>   same MAC addresses and/or the same VLAN Ids when used with different
>   L2VPNs.  Actually, for VLANs, there are two cases.  First, a L2VPN is
>   oblivious to customer VLANs.  In this case, customers can have
>   overlapping VLAN Ids.  Second, VLAN Ids MAY be used as service
>   delimiters, in which case it depends on whether the SP assigns the
>   VLANs or not.  If it does, then there is no overlap.  If it doesn't,
>   then overlapping VLAN Ids can occur and the SP has to put safeguards
>   in place to avoid this situation.
>
> Spencer: this is a MUST requirement, but it's fairly confusing to me - is 
> it saying, "L2VPN solutions MUST allow multiple customers to use 
> overlapping MAC addresses and VLAN ID ranges, whether or not the SP 
> assigns VLAN ID ranges"?
>
> 4.9 Protection and Restoration
>   The L2VPN service infrastructure SHOULD provide redundant paths to
>   assure high availability.  The reaction to failures SHOULD result in
>   an attempt to restore the service using alternative paths.
>
> Spencer: well, at least this isn't a MUST... My impression is that 
> customers who care about redundant paths usually care about spreading the 
> paths across SPs as well - but I guess SPs in this situation don't have to 
> provide redundant paths, if customers are prepared to switch SPs on 
> failure detection anyway. Mumble. Forget I said anything...
>
>   The intention is to keep the restoration time small.  The restoration
>   time MUST be less than the time it takes the CE devices, or customer
>   Layer 2 control protocols as well as Layer 3 routing protocols, to
>   detect a failure in the L2VPN.
>
> 5.2 Layer 3 Support
>
>   IPLS MUST allow transport of customer's IPv4 and IPv6 traffic
>   encapsulated within Layer 2 frames.  IPLS SHOULD also allow CEs to
>   run ISIS and MPLS protocols transparently among them when those are
>   used in conjunction with IP.
>
> Spencer: not sure I understood why ISIS and MPLS are called out, while 
> OSPF (and, I guess, BGP and even RIPv2) are not.
>
> 5.3 Quality of Service and Traffic Parameters
>
>   A customer application SHOULD experience consistent QoS independent
>   of the access network technology used at different sites connected to
>   the same L2VPN.
>
> Spencer: umm, given that 802.3 supports various access link speeds, is QoS 
> really technology-independent? 5.6.1 seems more realistic on this topic.
>
> 5.6.1  Physical/Link Layer Technology
>   L2VPNs SHOULD support a broad range of physical and link layer access
>   technologies, such as PSTN, ISDN, xDSL, cable modem, leased line,
>   Ethernet, Ethernet VLAN, ATM, Frame Relay, Wireless local loop,
>   mobile radio access, etc.  The capacity and QoS achievable MAY be
>   dependent on the specific access technology in use.
>
> Spencer: s/L2VPNs SHOULD/L2VPN solutions SHOULD/?
>
> 5.6.2  Access Connectivity
>   In case of VPLS, multi-link access for CE devices SHOULD be supported.
>
> Spencer: Got a specific "multi-link" technology in mind? IEEE 802.3ad-2000 
> link aggregation, or something else?
>
> 5.7.1  Unicast, Unknown Unicast, Multicast, and Broadcast forwarding
>   A VPLS MUST deliver every packet at least to its intended
>   destination(s) within the scope of the VPLS, subject to the ingress
>   policing and security policies.
>
> Spencer: "intended" probably needs to be qualified - something like, "at 
> least to the same destinations within the scope of the VPLS that the 
> packet would have been delivered to, if the VPLS were replaced by a real 
> LAN"?
>
> 5.7.2  Packet Re-ordering
>   The queuing and forwarding policies SHOULD preserve packet order for
>   packets with the same QoS parameters.
>
> Spencer: Is this "in normal operation", or "even during protection 
> events"?
>
> 5.7.3  Minimum MTU
>
>   A VPLS MAY fragment packets as long as it is transparent to the
>   customer.
>
> Spencer: is this really talking about "IP fragmentation", or something 
> more like SAR (segmentation and reassembly)?
>
> 5.7.4  End-point VLAN tag translation
>   On the
>   other hand, it SHOULD be noted that VLAN tag translation affects the
>   support for multiple spanning trees (i.e., 802.1s [IEEE_802.1s]) and
>   can break the proper operation.
>
> Spencer: this is not a 2119 SHOULD, I think...
>
> 6.3 Discovering L2VPN Related Information
>
>   A L2VPN solution SHOULD support the means for attached CEs to
>   authenticate each other and verify that the SP L2VPN is correctly
>   configured.
>
> Spencer: Is this talking about "correctly connected" (which I can see CEs 
> verifying), or something more (which seems harder to visualize)?
>
> 6.4 SLS Support
>   Typically, a SP offering a L2VPN service commits to specific SLS as
>   part of a contract with the customer.  Such a SLA drives the specific
>   SP requirements for measuring specific SLSs for quality,
>   availability, response time, and configuration intervals.
>
> Spencer: unclear what is actually being required in 6.4 (I agree with the 
> paragraph, I just don't see a requirement being stated).
>
> 6.7 Security
>
>   In addition, a SP network MUST be immune to malformed or maliciously
>   constructed customer traffic.
>
> Spencer: I don't know what "immune" means in an SP network context.
>
> 6.10 Tunneling Requirements
>   Connectivity between CE sites or PE devices in the backbone SHOULD be
>   able to use a range of tunneling technologies, such as L2TP, GRE, IP-
>   in-IP, MPLS, etc.
>
> Spencer: is there a mandatory-to-implement technology? this seems required 
> for interworking...
>
> 6.11 Support for Access Technologies
>   The connectivity between PE and CE devices is referred to as an AC.
>   ACs MAY span networks of other providers or public networks.
>
> Spencer: "AC" has been used previously without definition, and is not 
> expanded in this definition.
>
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/gen-art 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art