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

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 21 Dec 2005 16:19:09 -0600

Hi, Yetik,

A couple of items in the Gen-ART FAQ at 
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html are probably 
especially helpful:

Q: I have comments from a Gen-ART reviewer - do I revise the document
immediately?

A: Not unless your AD/document shepherd asks you to revise the document.
Some comments may be resolved with Notes to the RFC Editor, and the IESG may
choose to approve the document without requiring changes to address all
Gen-ART comments, since Gen-ART reviews are not a formal part of the
approval review cycle. The AD/document shepherd may also prefer to complete
the entire approval review cycle before requesting an updated version of the
document, in order to avoid confusion about exactly what version is being
last-called, reviewed and approved. In no case should you submit an updated
version of the document without consulting the AD/document shepherd.

Q: What if the Gen-ART reviewer is just flat wrong?

A: The General Area director understands that these are reviews by
generalists who are not experts in every protocol the IETF works on, plus
security and MIBs. If you disagree with comments, say so. The gen-art
reviewers *want* to hear feedback. They want to learn more about your area,
and appreciate feedback about how helpful their comments are. And always
remember that the IESG ballot position is called "DISCUSS", not "IMPERIAL
EDICT" or "BLACKMAIL".

:-)

Have a great holiday break!

Spencer

----- Original Message ----- 
From: "Serbest, Yetik" <[email-masked]>

Shane and Vach,

What is the procedure here? Do we reply to the list?

Everyone,
Happy Holidays,

Thanks,
yetik 

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

---

From: "Serbest, Yetik" <[email-masked]>
Date: Wed, 21 Dec 2005 16:10:50 -0600

Shane and Vach,

Everyone,
Happy Holidays,

Thanks,
yetik

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Monday, December 19, 2005 3:55 PM
To: General Area Review Team
Cc: Shane Amante; Vach Kompella; Mark Townsley; Russ Housley; Alex
Zinin; Waldemar Augustyn; Serbest, Yetik
Subject: Gen-ART Review of draft-ietf-l2vpn-requirements-05.txt 

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.

---

From: "Vach Kompella" <[email-masked]>
Date: Wed, 21 Dec 2005 14:19:17 -0800

Let's keep it between the editors, WG chairs and Spencer before we go to
the whole list.  A lot of the issues are fairly easily resolved, and I'm
sure Spencer can mediate with GenART.

-Vach 

> From: Serbest, Yetik [mailto:[email-masked]] 
> Sent: Wednesday, December 21, 2005 2:11 PM
> To: Spencer Dawkins; General Area Review Team
> Cc: Shane Amante; Vach Kompella; Mark Townsley; Russ Housley; 
> Alex Zinin; Waldemar Augustyn
> Subject: RE: Gen-ART Review of draft-ietf-l2vpn-requirements-05.txt
> 
> 
> Shane and Vach,
> 
> Cc: Shane Amante; Vach Kompella; Mark Townsley; Russ Housley; 
> Alex Zinin; Waldemar Augustyn; Serbest, Yetik
> Informational RFC, but some work remains. Most of the 
> comments I list below 
> 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, 
> Spencer: "sees a bridge" doesn't seem particularly clear 
> here. Section 4.7.2 
> Figure 3 shows "backdoor links" - so do all L2VPN solutions 
> need to provide 
> involved in some pretty detailed discussion about "bridging" 
> in TRILL, and 
> Spencer: it may be worth mentioning that some of the 
> prohibitions against 
> out-of-order delivery, etc. during spanning tree 
> recalculation were relaxed 
> during spanning tree recalculation may not be all that 
> different from real 
> LANs.
> 
> 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
> Spencer: this is a MUST requirement, but it's fairly 
> confusing to me - is it 
> 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 
> Spencer: not sure I understood why ISIS and MPLS are called 
> out, while OSPF 
> Spencer: umm, given that 802.3 supports various access link 
> speeds, is QoS 
>    In case of VPLS, multi-link access for CE devices SHOULD 
> be supported.
> 
> least to the same destinations within the scope of the VPLS 
> that the packet 
> Spencer: Is this "in normal operation", or "even during 
> protection events"?
> 
> 5.7.3  Minimum MTU
> 
> Spencer: is this really talking about "IP fragmentation", or 
> something more 
> Spencer: Is this talking about "correctly connected" (which I 
> can see CEs 
> Spencer: unclear what is actually being required in 6.4 (I 
> agree with the 
> Spencer: is there a mandatory-to-implement technology? this 
> seems required 
> for interworking...
>