Draft: draft-ietf-l2vpn-requirements-05.txt Reviewer: Spencer Dawkins [spencer@mcsr-labs.org] Review Date: Monday 12/19/2005 3:55 PM CST LC Date: 12/21/2005 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.