I just submitted a new version of l2vpn-requirements draft. The new
version includes some updates based on AD comments. Below please find AD
comments, and the corresponding responses.

Thanks,
Yetik



>    covers point to point VPNs referred to as Virtual Private Wire

s/point to point/point-to-point/

Done.

>    Service (VPWS), as well as multipoint to multipoint VPNs also known

Ditto

Done.

>    This document provides requirements for provider provisioned
Layer-2
>    Virtual Private Networks (L2VPN).  It identifies requirements that

provider-provisioned

Done.

>    Virtual Private Networks (L2VPN).  It identifies requirements that
>    MAY apply to one or more individual approaches that a Service
>    Provider (SP) MAY use for the provisioning of a Layer-2 VPN
service.
>    The content of this document makes use of the terminology defined
in
>    [VPN_TERM] and common components for deploying L2VPNs described in
>    [L2VPN_FR].

Use of upper case MAY here seems off. how does this fit with the
defintion of MAY?

Done.

>    individual approach satisfies specific requirements.  The
>    applicability statement document for each individual approach
SHOULD
>    document the results of this evaluation.

lower case should? I.e., this document is mandating that other documents
do this?

Done.

>    Some possibly salient differences between VPLS and a real LAN are:
>      - The reliability MAY likely be less, i.e., the probability that
a
>      message broadcast over the VPLS is not seen by one of the bridge
>      modules in PEs is higher than in a true Ethernet.

Not sure use of upper-case MAY is appropriate here.

Done.

>      of sequence.  If the customer's BPDU frames are sent as data

undefined/unexpanded acronym.

Expanded.

>      CE to CE.  For example, Source MAC address MAY NOT be preserved
by
>      the IPLS solution.

Again, not sure about use of upper case terms here.

Done.

> 4.3 Topology
>    A SP network MAY be realized using one or more network tunnel
>    topologies to interconnect PEs, ranging from simple point-to-point
>    to distributed hierarchical arrangements.  The typical topologies
>    include:

s/MAY/may/?

Done.

> 4.5 Security

...

>    hazards.  There MUST be methods available to protect against the
>    following situations.
> 
>      - Protocol attacks
>        o Excessive protocol adjacency setup/teardown
>        o Excessive protocol signaling/withdrawal
>      - Resource Utilization
>        o Forwarding plane replication (VPLS)
>        o Looping (VPLS primarily)
>        o MAC learning table size limit (VPLS)

this itemization is really cryptic. For the second bullet, I have no
idea what needs to be protected against. Same comment applies to some of
the other items. 

The following text added. That bullet is about protecting network
resources (bandwidth, memory, CPU, FIB).

"A number of security concerns arise in the setup and operation of a
L2VPN, ranging from mis-configurations to attacks that can be launched
on a L2VPN and can strain network resources such as memory space,
forwarding information base table, bandwidth and CPU processing.
This section lists some potential security hazards that can result due
to mis-configurations and/or malicious attacks."

> 4.5.1  User data security
>    L2VPN solution MUST provide traffic separation between different
>    L2VPNs.

s/L2VPN/An L2VPN/

Done.

> 4.6 Addressing
>    A L2VPN solution MUST support overlapping addresses of different
>    L2VPNs.  For instance, customers SHOULD not be prevented from using
>    the same MAC addresses and/or the same VLAN Ids when used with

seems like a s/SHOULD not/MUST NOT/

Done.

>    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 overlapping.  If it
>    doesn't, then overlapping VLAN Ids can occur and the SP has to put
>    safeguards in place to avoid this situation.

last case seems odd. You will let customers pick the VPN IDs and hope
they aren't duplicated elsewhere? Seems like a pretty poor choice.

It is there just for completeness, to make sure VLAN-Ids are unique per
customer in such scenarios.

> 4.13 Inter-working
>    Inter-working scenarios among different solutions, providing L2VPN
>    services, are highly desirable.  Inter-working SHOULD be supported
>    in a scalable manner.
> 
>    Inter-working scenarios MUST consider at least traffic isolation,
>    security, QoS, access, and management aspects.  This requirement is
>    essential in the case of network migration, to ensure service
>    continuity among sites belonging to different portions of the
>    network.

this needs to be made more clear/detailed. The IETF does not do
interworking of l2 in general; so what exactly is meant here?

The following text is added. A possible example is inter-working between
VPLS-LDP and VPLS-BGP. Let's say an SP buys another SP (former deployed
VPLS-LDP, and latter deployed VPLS-BGP), how does the new combined Sp
provides VPLS?

"It is possible to have cases that require inter-working or
interconnection between customer sites, which span network domains with
different L2VPN solutions or different implementations of the same
approach."

> 5.7.2  Packet Re-ordering
>    The queuing and forwarding policies SHOULD preserve packet order
for
>    packets with the same QoS parameters.
> 

Seems like reordering should only be allowed where the service being
emulated alows for reordering. Otherwise, random things will break.

This is what we meant by this requirement: do not cause re-ordering.

> 5.7.4  End-point VLAN tag translation
>    The L2VPN service MAY support translation of customers' AC
>    identifiers (e.g., VLAN tags, if the customer VLANs are used as
>    service delimiters).  Such service simplifies connectivity of sites
>    that want to keep their AC assignments or sites that belong to
>    different administrative domains.  In the latter case, the
>    connectivity is sometimes referred to as Layer-2 extranet.  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.

not sure about this. Has tagging been adopted as a WG approach?

Tags here are VLAN tags, an AC can be a VLAN.

>    prevented.  This can be accomplished with a loop free topology or

s/loop free/loop-free/

Done.

>    A L2VPN solution SHOULD be scalable to support a wide range of
>    number of customer addresses (e.g., MAC) per VPLS.  The number of
>    customer addresses per VPLS MAY range from just a few (i.e., the
>    number of sites when the CE devices are routers or when the service
>    is IPLS) to a very large number such as 1,000 (i.e., when CE
devices
>    are switches).  The number of customer addresses would be on the
>    order of addresses supported in a typical native Layer-2 backbone.

this could be made more clear. does "number of customer addresses"
relate to the number of CE devices (only) or to the number of nodes the
custer has connected to the VPN? I assume the latter, but if that is the
case, the 1,000 figure seems low. Or maybe not. Where does the 1K figure
come from? Is that the max (reasonable) size for a bridged network?

I removed the examples in Scalability section, and just refer to RFC3809
(Generic requirements), which already has the examples. But to answer
your answers: the latter to first question, yes to the second one.

>    The number of users per VPLS is the combination of servers and
hosts
>    connected to the VPLS.  It needs to scale from a handful to high
>    numbers.  A VPLS MUST scale from 2 users to a few hundred.

Hmm. few hundred? How does this relate to the 1000 figure above?

Again, I removed the example. A 1000 is an upper limit for a few hundred
:-)

> 6.8.2  Bandwidth and QoS Brokering
>    When a L2VPN spans multiple AS's, there is a need for a brokering
>    mechanism that requests certain SLS parameters, such as bandwidth
>    and QoS, from the other domains and/or networks involved in
>    transferring traffic to various sites.  The essential requirement
is
>    that a solution MUST be able to determine whether a set of AS's can
>    establish and guarantee uniform QoS in support of a provider
>    provisioned VPN.

Is this MUST one that has to be met? and will be by the proposed
approaches?

Yes.

> 8.2.2  Responsiveness to Congestion
>    A L2VPN solution SHOULD utilize the congestion avoidance techniques
>    defined by PWE3 ([PWE3_ARCH]).
> 

more words needed. I think what you need to say is that VPLS services
will provide congestion control. E.g,. if they carry TDM... It may well
be that PWE3 provides those mechanisms, but they MUST be somewhere.

I really don't know what we can add here. L2VPN is not supposed to
create new protocols. We are utilizing what PWE3 is giving us. That is
what we mean here.