Subject: FW: draft-mnapierala-mvpn-part-reqt-02

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Fri, 18 Jul 2008 11:19:30 -0400

I would like to make a general statement about the comments, namely that
they confuse the specific requirements associated with allowing
different egress PEs/mVRFs choose different upstream PE for the same
C-stream, according to specified routing policies or SP criteria, with
more general requirements in RFC4834. 
In addition, there is no contradiction with RFC4834 (see detailed
replies to the comments).

Detailed responses in-line.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Rahul Aggarwal
Sent: Monday, July 14, 2008 2:20 PM
To: [email-masked]
Subject: Re: draft-mnapierala-mvpn-part-reqt-02 

WG,

Few high-level comments on draft-mnapierala-mvpn-part-reqt-02.txt:

 (1) some of the requirements stated in this document are already
   covered in rfc4834 (L3VPN Mcast Requirements)
 (2) some of the material on the document describes a solution, not
   a requirement
 (3) some of the requirements stated in this document contradict
   the requirements stated in rfc4834
 (4) some of the requirements stated in this document are new,
   and not covered in rfc4834.

We should not be accepting new requirements, nor should we change
the requirements already accepted by the WG (rfc4834) until we finish
working on the solution(s) that meet the requirements already
accepted by the WG.

Based on the above I object accepting this draft as an L3VPN WG
document.

P.S. Below are few detailed comments in-line...
------------------------------------------------------------------------
---
>    Network Working Group
>    Internet Draft                                       Maria
Napierala
>    Document: draft-mnapierala-mvpn-part-reqt-02.txt
AT&T
>    Expires: December 24 2008                               June 24
2008
>
>
>             Requirement for Multicast MPLS/BGP VPN Partitioning
>
>
> Status of this Memo
>
>    By submitting this Internet-Draft, each author represents that any
>    applicable patent or other IPR claims of which he or she is aware
>    have been or will be disclosed, and any of which he or she becomes
>    aware will be disclosed, in accordance with Section 6 of BCP 79.
>
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as Internet-
>    Drafts.
>
>    Internet-Drafts are draft documents valid for a maximum of six
months
>    and may be updated, replaced, or obsoleted by other documents at
any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    The list of current Internet-Drafts can be accessed at
>         http://www.ietf.org/ietf/1id-abstracts.txt
>    The list of Internet-Draft Shadow Directories can be accessed at
>         http://www.ietf.org/shadow.html.
>
>
> Abstract
>
>    This document describes a requirement for Multicast IP VPN
solutions
>    to allow the same multicast stream to flow simultaneously on
>    multiple inter-PE paths without duplicates being sent to receivers.
>    It is intended that existing and new solutions to MPLS/BGP
Multicast
>    IP VPN's will support this requirement.
>
>
> Conventions used in this document
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
this
>    document are to be interpreted as described in RFC-2119 [i].
>
>
> Napierala              Expires - December 2008               [Page 1]
>             Requirement for Multicast MPLS/BGP VPN Partitioning
>
>
>
>
>
>
>
> Table of Contents
>
>    1.   Introduction................................................2
>    2.   Terminology.................................................3
>    3.   General Requirements........................................3
>    4.   Multicast VPN Partitioning..................................4
>       4.1  Support of Anycast C-RP..................................5
>       4.2  Support of Redundant P-Tunnels...........................6
>    5.   Preserving Customer Multicast Traffic Patterns..............7
>       5.1  Support of Source-Specific Host Reports in PIM-SM........8
>    6.   Support of PIM-Bidir in MVPN................................8
>       6.1  Preventing Packet Loops..................................8
>       6.2  Support of Source-Only Branches..........................9
>    7.   IANA Considerations.........................................9
>    8.   Security Considerations....................................10
>    9.   References.................................................10
>    10.  Acknowledgments............................................10
>    11.  Author's Addresses.........................................10
>    12.  Intellectual Property Statement............................11
>    13.  Copyright Notice...........................................11
>
>
> 1. Introduction
>
>    Multicast VPN (cf.[ii]) extends MPLS/BGP VPN services (cf.[iii]) by
>    enabling customers to run native IP multicast within their IP
VPN's.
>    Multicast VPN's enabled customers to use applications that were
>    expensive or difficult, if not impossible, to operate in wide-area
>    network before (e.g., voice/video conferencing, stock quotes, large
>    file distribution). From VPN customer perspective there is no
change
>    in the multicast operational model. Multicast distribution trees
are
>    built in service provider network to carry VPN multicast traffic.
>    Those trees are essentially point-to-multipoint (P2MP) and
>    multipoint-to-multipoint (MP2MP) tunnels that encapsulate IP VPN
>    multicast packets for transport across provider's network.
Throughout
>    this document whenever we refer to a VPN we mean MPLS/BGP IP VPN
and
>    whenever we refer to an MVPN we mean MPLS/BGP Multicast IP VPN.
>
>    The generic requirements for IP multicast services within IP VPN's
>    are specified in [iv]. This document defines additional multicast
VPN
>    requirements beyond those in [iv]. More precisely, it specifies the
>    need of VPN customers to have multiple parallel paths to a
>    Rendezvous Point or a multicast source across a service provider
>
>
>
> Napierala              Expires - December 2008               [Page 2]
>             Requirement for Multicast MPLS/BGP VPN Partitioning
>
>
>
>    network. The document formulates the generic aspects of this
>    requirement and states its specific issues that should be addressed
>    by MVPN solution.
>
>    It is expected that solutions that specify procedures and protocol
>    extensions for multicast in IP VPN's should satisfy this
requirement.
>
>
> 2. Terminology
>
>    In this document when we use the "C-" prefix when we refer to the
VPN
>    customer multicast addresses and multicast trees. We will prefix
VPN
>    customer multicast trees, sources, groups, Rendezvous Points (RP),
>    and PIM routes with "C-", as in: C-tree, C-S, C-G, C-RP, (C-*,
C-G),
>    (C-S, C-G). When we use the "P-" prefix when we refer to provider's
>    multicast addresses and multicast trees/tunnels. We assume
>    familiarity with PIM protocol [v][vi][vii].
>
>
> 3. General Requirements
>
>    The MVPN solution MUST allow the same multicast traffic to flow
>    simultaneously on multiple trees across provider's network without
>    duplicate packets sent to customer receivers. The solution has to
>    allow for different downstream PE's to choose different upstream
>    PE's to customer RP or customer source. As a result, customer
>    multicast stream would be able to flow along multiple inter-PE
trees
>    and simultaneously utilize multiple paths in redundant topology.
>
>    The lack of support of parallel paths for multicast traffic would
>    prevent different multicast VRF's of the same VPN to have different
>    routing policies and choose different paths to reach C-RP or the C-
>    source. As a result it would break any kind of "anycast" sourcing
of
>    a multicast stream in IP VPN, including Anycast RP operation by not
>    allowing multiple RP's to send traffic in parallel to their closest
>    receivers.
>
>    The solution MUST NOT result in creating duplicates to customer
>    receivers, except during routing transients. The amount of
duplicates
>    during routing convergence should be minimized and should be
>    compatible to that of standard PIM operation. When preventing
>    duplicates to receivers, the solution MUST NOT waste provider's
>    network resources by discarding, at network egress, already
>    transmitted duplicate traffic. Only a single copy of any
C-multicast
>    stream should reach any egress mVRF in a converged network. This
>    includes PIM-SM C-streams that are either flowing on C-shared tree
>    or C-shortest-path tree. An egress PE should receive a PIM-SM C-
>
>
>
> Napierala              Expires - December 2008               [Page 3]
>             Requirement for Multicast MPLS/BGP VPN Partitioning
>
>
>
>    stream either from the C-RP or directly from the C-source but never
>    from both.
>    There are two exceptions to the requirement of not wasting
>    provider's network bandwidth and discarding duplicates at network
>    egress. One exception is when providing fast convergence for
certain
>    multicast VPN traffic on failures in access or in provider's
>    network. This requirement is described in section 4.2.

What is described in 4.2 is a solution, not a requirement. The above
exception assumes a particular solution (the solution described in 4.2).
Which means that this requirement presuppose a particular solution.

>                                                           The other
>    exception is in case of aggregation of different C-streams on to
the
>    same multicast distribution tree (i.e., P-tunnel) in provider's
>    network.

The "other exception" is already covered in 5.2.3.2 of rfc4834.

<mnapierala> This "other exception" is listed for completeness in
relation to the requirement of not wasting SP network bandwidth while
allowing parallel P-tunnels for the same C-stream. I can add to this
text that this is stated in RFC4834. 

>    These two exceptions should be implemented by MVPN solution
>    as optional behavior, based on provider's discretion.

Implementation by MVPN solution of the second "exception" as "optional
behavior" contradicts requirement of rfc4834 that states that
"proposed solutions SHOULD offer the possibility of sharing such
resources between different multicast streams (between different
VPNs, between different multicast streams of the same or of different
VPNs).  This means, for instance, if MDTunnels are trees, being
able to share an MDTunnel between several customers."

<mnapierala> The "optional behavior" is not equal to the "optional
requirement." The "optional" behavior means that whether the particular
feature or behavior (in this case MDT aggregation) is used should be
provided as an option to the SP.

>    In addition, these two exceptions apply only to traffic from
anycast
>    sources/RP's but not to PIM-SM C-streams flowing on C-shared tree
vs.
>    C-shortest-path tree. In other words, a PIM-SM C-stream should
never
>    be delivered to an egress PE from both, the C-RP and directly from
>    the C-source.
>
>    These requirements SHOULD be supported for all tunnel technologies
>    and SHOULD work with all protocols used for multicast signaling
among
>    PE's. However, it is desirable that the solution is "generic" i.e.,
>    it is independent of multicast tunnel technology used by the
service
>    provider. Independence from tunneling technology will allow
>    different transport methods to be used for different multicast
>    applications without overloading the transport technology itself.

What is stated in the above paragraph is already covered in section
5.2.4.1 of rfc4834.

<mnapierala> this statement is in the context of main requirement
(multiple P-tunnels for same C-stream) and is not covered in rfc4834.

>    This, in turn, will simplify provider's network maintenance
>    operations.
>
>    Moreover, the solution MUST NOT impose any restrictions on
>    customer's multicast routing or requirements on multicast service
>    offering. For example, it cannot require a customer to outsource
its
>    RP functionality to the service provider or a service provider to
>    participate in customer's RP protocol by running MSDP with the
>    customer.

This is covered in 5.1.10.1 of rfc4834 where it states that outsourcing
RP is "may".

<mnapierala> again, this statement is in the context of main requirement
(multiple P-tunnels for same C-stream) and is not covered in rfc4834.

>    These requirements SHOULD be supported for the following PIM modes
>    in customer domain: PIM-SM [v], PIM-SSM [vii], and PIM-Bidir [vi].

Most of the last sentence is already covered in 5.1.2 of rfc4834:
"the support of PIM-SM (which includes the SSM model) and either
IGMPv3 (for IPv4 solutions) and/or Multicast Listener Discovery
Version 2 (MLDv2) [RFC3810] (for IPv6 solutions) is REQUIRED.
Bidir-PIM support at the PE-CE interface is RECOMMENDED.  And
considering deployments, PIM-DM is considered OPTIONAL."

<mnapierala> again, this statement is in the context of main requirement
(multiple P-tunnels for same C-stream) and is not covered in rfc4834.

One part of the last sentence, making support for PIM-Bidir "SHOULD",
is a change to rfc4834 (which states that support for PIM-Bidir
is "RECOMMENDED".

<mnapierala> correct.

>    The MVPN procedures SHOULD support all Rendezvous Point solutions
>    currently used by VPN customers.

This is already covered in 5.1.10.2 of rfc4834 "different mechanisms
exist, such as BSR [PIM-BSR] or anycast-RP (Multicast Source Discovery
Protocol (MSDP)- based [RFC3446] or PIM-based [RFC4610]). These
protocols and procedures SHOULD work transparently through a multicast
VPN".

<mnapierala>  same as above plus the listed RP mechanisms are not the
only ones used by the MVPN customers.

> 4. Multicast VPN Partitioning
>
>    Service providers might allow VPN sites to have specific routing
>    intelligence, giving the customers more granular control of their
>    routing in the VPN.  Site specific routing intelligence may
include,
>    for example, route preference or denial of routes. A VPN customer
may
>    partition its sites into groups that share the same routing policy.
>    How these routing policies are defined and how the customers
control
>
>
> Napierala              Expires - December 2008               [Page 4]
>             Requirement for Multicast MPLS/BGP VPN Partitioning
>
>
>
>    their routing may differ among service providers and it is outside
>    the scope of this document.
>
>    An example where customers need more granular control of their
>    routing is in the selection of the Internet Gateway. Customers
might
>    access the Internet from their branch sites utilizing a default
route
>    or a summary route originating from their Internet Gateway site.  A
>    VPN might have multiple Internet Gateways. A customer may want to
>    control which sites can access each of the gateways based on delay,
>    application, security policy, etc.
>
>    More generally, enterprises and firms often want to segment their
>    VPN's by data center or hub locations in order to meet specific
>    performance, security, functionality, or application access
>    requirements.
>
>    Such partitioning of VPN's has been possible for unicast
>    transmission. It is a customer expectation that multicast traffic
in
>    a VPN can be subject to similar partitioning by multicast source or
>    Rendezvous Point location. The partitioning of multicast VPN by
>    multicast source or Rendezvous Point location is based on "anycast
>    souring". "Anycast" allows a group of destinations to be identified
>    with the same address so that data packets destined for that
address
>    can be delivered to any member of the group. Anycast routing is
>    implemented via announcements of the same address prefix from
>    multiple origins. IP VPN customers often inject into VPN the same
>    route(s) at different VPN sites. These could be default or summary
>    routes, or specific routes. If these routes are routes to C-RP's or
>    C-sources, they are examples of "anycast sourcing" of multicast
>    traffic in MVPN. Anycast sourcing includes multi-homed sites with
C-
>    sources or C-RP(A)'s, as well as Anycast C-RP's.
>
>    Lack of support for MVPN partitioning can deteriorate application's
>    performance, introduce latencies and variable delays that impact
>    users and applications. Typically, large enterprises have multiple
>    data centers and would like multicast applications to be
>    simultaneously sourced from each data center to serve different
sets
>    of branch locations. For example, real-time market data
distribution
>    requires timely and simultaneous delivery to users. The differences
>    in propagation delay might introduce unacceptable timing
differences
>    in the availability of data to users, and hence, unfairness in
>    business competition. Locating sources close to receivers and
>    partitioning of receivers by the source location is necessary in
such
>    business critical real-time data feeds.
>
>
>  4.1 Support of Anycast C-RP
>
>
>
> Napierala              Expires - December 2008               [Page 5]
>             Requirement for Multicast MPLS/BGP VPN Partitioning
>
>
>
>    In Anycast RP, two or more RP's are configured with the same IP
>    address on loopback interfaces. IP routing automatically selects
the
>    topologically closest RP for each source and receiver. Anycast RP
>    provides RP redundancy, fast RP failover, and load sharing of
>    registering sources. Anycast RP's are often used in large
enterprise
>    networks.
>
>    Typically, large enterprises have multiple data centers where
Anycast
>    RP's and sources of multicast traffic are located. Such customers
>    might require multicast applications to be simultaneously sourced
>    from each data center and delivered via corresponding Anycast RP's
to
>    different sets of branch locations. The expected anycast addressing
>    behavior is that different PE's could choose different upstream
PE's
>    as the next-hops to the customer RP or source.
>
>    The MVPN solution SHOULD support Anycast C-RP in the following two
>    ways: based on provider's network IGP/routing cost or based on VPN
>    customer routing. IGP cost-based next-hop selection provides
PIM-like
>    support of Anycast C-RP's, i.e., C-receivers join the closest
Anycast
>    C-RP across provider's network. The other option is to leave it up
to
>    the VPN routing policy to partition receivers by Anycast RP
location.
>    This allows multicast VPN customer to define its own Anycast C-RP
>    selection, based on other criterion than the closest distance.
>
>
>  4.2 Support of Redundant P-Tunnels

The title of this section, "Redundant P-Tunnels", presuppose a
solution, not a requirement. 

<mnapierala> I am not sure how this title presupposes any specific
solution. It only states the need for "redundant P-Tunnels" for the same
C-stream. But I am open to express it differently provided that the
intended requirement is covered adequately.

Moreover rfc4834 already covers the
issue of protection in 5.1.3: "The level of availability for the
multicast service SHOULD be on par with what exists for unicast
traffic.  For instance, comparable traffic protection mechanisms
SHOULD be available for customer multicast traffic when it is carried
over the service provider's network."

<mnapierala> what unicast protection scheme covers the multicast
requirement described in this section?

>    Certain multicast applications are not tolerant to packet loss.
>

The rest of this section describes a solution, not a requirement.

<mnapierala> I don't agree that this describes a solution. But I am open
to suggestions for restatement if it meets the intended requirement. 

>    To
>    minimize multicast traffic disruption during network or access
>    failures, the solution should provide a capability to pre-build
>    redundant P-tunnels in case of multi-homed C-RP's or C-sources. In
>    addition to "primary" tunnel, a "secondary" or redundant P-tunnel
>    could be triggered for C-Group or C-Source traffic. For example,
the
>    primary P-tunnel could be based on mVRF's best route to C-RP or C-
>    source, while the secondary P-tunnel could be based on the next
best
>    route (or another equal cost path) to C-RP or C-source. The
redundant
>    P-tunnel should function in a "warm-standby" or a "hot-standby"
mode.
>    In a "warm-standby" mode the redundant P-tunnel should be triggered
>    but the traffic should not be forwarded to it from the ingress PE,
>    the root of the tunnel. In a "hot-standby" mode the traffic should
be
>    carried on both primary and standby tunnels and allow duplicates to
>    be received at egress PE's. The egress PE's should accept the
traffic
>    only from either the primary tunnel or from the secondary tunnel.
>
>    Redundant tunnel capability should be implemented as a per-tunnel
>    configuration option to service provider.
>
>
>
>
> Napierala              Expires - December 2008               [Page 6]
>             Requirement for Multicast MPLS/BGP VPN Partitioning
>
>
>
> 5. Preserving Customer Multicast Traffic Patterns
>
>    PIM-SM has the capability for last-hop routers to switch to the
>    shortest-path tree if the traffic rate is above a configured SPT-
>    threshold. By switching to SPT, the optimal path is used to deliver
>    the multicast traffic. Depending on the location of the source in
>    relation to the RP, switching to the SPT can significantly reduce
>    network latency. However, in networks with large numbers of
senders,
>    SPT's can increase the amount of multicast state that must be kept
in
>    the routers. A VPN customer might set SPT-threshold to a value
higher
>    than zero in order to switch to SPT's only for sources that cross
>    certain traffic rate. This is done in order to alleviate Rendezvous
>    Point from carrying too much traffic while at the same time
>    controlling the number of (S,G) states created in the network. In
>    fact, last-hop CE's might never switch traffic to SPT's for certain
>    multicast groups if SPT-threshold of "infinity" is specified for
>    those groups. The MVPN solution should not affect this PIM-SM
>    behavior in customer's network.
>
>    In native PIM-SM mode the same multicast traffic does not
necessarily
>    flow over a single tree but it can simultaneously flow on both
shared
>    and shortest path trees, without duplicates being sent to
receivers.
>    The MVPN solution SHOULD allow egress PE's (i.e., PE's with
>    receivers) receive a specific PIM-SM C-stream either via the C-RP
or
>    directly from the C-source. As it was stated in section 3, a PIM-SM
>    C-stream should never be delivered to an egress PE from both the
C-RP
>    and directly from the C-source.
>
>    Moreover, the MVPN solution should not base multicast routing
>    decisions on provider's backbone internal infrastructure, like IP
>    addressing of PE routers. Rather the MVPN solution MUST preserve
the
>    multicast routing policies as defined in customer's VPN. More
>    precisely, a multicast VRF with receivers of (C-*, C-G) or (C-S,
C-G)
>    should receive multicast traffic from its best next-hop to C-RP or
C-
>    S, respectively. The only two exceptions to this requirement are:
(1)
>    the existence of multiple equal cost paths to customer source or
>    customer RP, which forces the provider's network to impose a tie-
>    breaker, and (2) the existence of a configuration knob that
provides
>    an optional multicast behavior, based on provider's discretion (for
>    example, Anycast C-RP selection based on provider's network routing
>    cost).
>
>    In summary, the MVPN procedures should not alter customer's
>    multicast traffic patterns as defined by customer's PIM
>    infrastructure as well as by MVPN routing policies. More precisely,
>    MVPN solution MUST:
>    - preserve PIM-SM shared trees in customer network if CE's do not
>      switch traffic to SPT's or if they prune previously triggered
(C-S,
>
>
> Napierala              Expires - December 2008               [Page 7]
>             Requirement for Multicast MPLS/BGP VPN Partitioning
>
>
>
>      C-G) states; i.e. MVPN solution MUST:
>          + not trigger unexpected (C-S, C-G) states in customer's
>            network
>          + not retain pruned (C-S, C-G) states in customer's network;
>    - support multi-homed C-receiver sites where shared tree and
>      shortest path tree diverge;
>    - preserve multicast routing policies of customer's VPN.
>
>
>  5.1 Support of Source-Specific Host Reports in PIM-SM
>
>    PIM-SM [v] permits "a receiver to join a group and specify that it
>    only wants to receive traffic for a group if that traffic comes
from
>    a particular source. If a receiver does this, and no other receiver
>    on the LAN requires all the traffic for the group, then the DR may
>    omit performing a (*,G) join to set up the shared tree, and instead
>    issue a source-specific (S,G) join only."
>
>    Such a behavior of PIM-SM means that any PE can receive Join (C-S,
C-
>    G) for a sparse mode group even if no PE has ever received Join
(C-*,
>    C-G) in an MVPN. It also means that (as in PIM-SSM) source trees
>    might be triggered even for sources that are not active. The MVPN
>    solution SHOULD support source-specific host requests but it SHOULD

Support for source-specific host requests via IGMPv3 is already
REQUIRED in rfc4834 (Section 5.1.2)

<mnapierala> This requirement calls for not triggering P-tunnels for
non-active C-sources. Where is this stated in rfc4834? I don't see it in
section 5.1.2. 

>    prevent useless S-PMSI creation for C-sources which are not active.
>
>
> 6. Support of PIM-Bidir in MVPN
>
>    Many enterprises use multicast applications that scale or even
>    operate correctly only with PIM-Bidir [vi]. For example, financial
>    firms use a business critical "always on" VoIP conferencing (so
>    called "hoot-n-holler") to share market updates and trading orders.
>    PIM-Bidir is already deployed in many of these networks and its
>    support in MVPN context is REQUIRED. This is a change from MVPN
>    generic requirements document [iv] where PIM-Bidir support on PE-CE
>    interfaces is only recommended.
>

This is a change to rfc4834.

<mnapierala> yes.

>  6.1 Preventing Packet Loops
>
>    In PIM-Bidir, the packet forwarding rules have been improved over
>    PIM-SM, allowing traffic to be passed up the shared tree toward the
>    RP Address (RPA). To avoid multicast packet looping, PIM-Bidir uses
a
>    mechanism called the designated forwarder (DF) election, which
>    establishes a loop-free tree rooted at the RPA. Use of this method
>    ensures that only one copy of every packet will be sent to an RPA,
>    even if there are parallel equal cost paths to the RPA. To avoid
>    loops the DF election process enforces consistent view of the DF on
>
>
> Napierala              Expires - December 2008               [Page 8]
>             Requirement for Multicast MPLS/BGP VPN Partitioning
>
>
>
>    all routers on network segment, and during periods of ambiguity or
>    routing convergence the traffic forwarding is suspended.
>
>    The standard DF election procedure used in plain IP environments
>    would not yield the desired results in MVPN context. This is
because
>    the DF election in MVPN would have to be based on the provider's
>    internal IP addressing of PE routers instead of on routing policy
in
>    customer's VPN.
>
>    In MVPN context a Designated Forwarder for Bidir C-RPA is a PE
>    attached to C-RPA. Different mVRF's in a given MVPN might have
>    different best next-hop PE's to C-RPA due to different routing
>    policies or they might have temporarily different next-hop PE's to
C-
>    RPA due to routing transients. The MVPN solution for C-Bidir MUST
>    prevent multicast packet looping during routing convergence. The
MVPN
>    solution for C-Bidir SHOULD NOT rely on all mVRF's in a given MVPN
to
>    either have common routing view to C-RPA or to reach a common
routing
>    view to C-RPA in time to prevent packet looping. Rather, a VPN has
to
>    be treated as a collection of sets of multicast VRF's, each having
>    the same but distinct from other sets reachability information
>    towards C-RPA. Hence, resolving C-Bidir packet loops in MVPN
>    inevitably results in the ability to partition a VPN into disjoined
>    sets of VRF's, each having a distinct view of converged network.
>
>    As an option, the MVPN implementation of C-Bidir SHOULD allow to
>    ignore specific multicast routing policy in mVRF, and instead make
>    all PE's in a given MVPN choose the same next-hop PE to C-RPA.
Among
>    all candidate next-hop PE's, the single chosen upstream PE to C-RPA
>    could be the PE with the highest IP address. This approach to
C-Bidir
>    might be desirable to customers that do not want a permanent
>    splitting of their MVPN's into disjoined C-Bidir trees.
>
>
>  6.2 Support of Source-Only Branches
>
>    PIM-Bidir supports source-only branches i.e., branches that do not
>    lead to any receivers but that are used to forward packets
traversing
>    upstream from sources towards the RPA. In plain IP PIM-Bidir it is
up
>    to the implementation whether to maintain group state for
source-only
>    branches [vi]. The MVPN solutions MUST assure that PE's on source-
>    only branches of C-Bidir tree are able to send and receive inter-PE
>    MVPN traffic. In other words, PE's on source-only branches have to
>    be able to participate in P-tunnels triggered for C-Bidir trees.
>
>
> 7. IANA Considerations
>
>    None.
>
>
> Napierala              Expires - December 2008               [Page 9]
>             Requirement for Multicast MPLS/BGP VPN Partitioning
>
>
>
>
>
> 8. Security Considerations
>
>    None.
>
>
> 9. References
>
>
>       [i] Bradner, S., "The Internet Standards Process -- Revision 3",
>       BCP 9, RFC 2026, October 1996.
>
>       [ii] E. Rosen, R. Aggarwal, "Multicast in MPLS/BGP IP VPNs",
>       draft-ietf-l3vpn-2547bis-mcast. Work in progress.
>
>       [iii] E. Rosen, E., Rekhter, Y., "BGP/MPLS IP Virtual Private
>       Networks (VPNs)", RFC 4364, February 2006.
>
>       [iv] T. Morin, Ed., "Requirements for Multicast in Layer 3
>       Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC
>       4834, April 2007.
>
>       [v] B. Fenner et al., "Protocol Independent Multicast - Sparse
>       Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601,
>       August 2006.
>
>       [vi] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-
>       directional Protocol Independent Multicast (Bidir-PIM)", RFC
>       5015, October 2007.
>
>       [vii] H. Holbrook, B. Cain, "Source-Specific Multicast for IP",
>       RFC 4607, August 2006.
>
>
>
>
> 10.Acknowledgments
>
>    The author would like to thank Eric Rosen, Yakov Rekhter, and Ron
>    Bonica for their comments.
>
> 11.Author's Addresses
>
>    Maria Napierala
>    AT&T Labs
>    200 Laurel Avenue, Middletown, NJ 07748
>
>
>
> Napierala              Expires - December 2008              [Page 10]
>             Requirement for Multicast MPLS/BGP VPN Partitioning
>
>
>
>    Email: [email-masked]
>
>
> 12.  Intellectual Property Statement
>
>    The IETF takes no position regarding the validity or scope of any
>    Intellectual Property Rights or other rights that might be claimed
to
>    pertain to the implementation or use of the technology described in
>    this document or the extent to which any license under such rights
>    might or might not be available; nor does it represent that it has
>    made any independent effort to identify any such rights.
Information
>    on the procedures with respect to rights in RFC documents can be
>    found in BCP 78 and BCP 79.
>
>    Copies of IPR disclosures made to the IETF Secretariat and any
>    assurances of licenses to be made available, or the result of an
>    attempt made to obtain a general license or permission for the use
of
>    such proprietary rights by implementers or users of this
>    specification can be obtained from the IETF on-line IPR repository
at
>    http://www.ietf.org/ipr.
>
>    The IETF invites any interested party to bring to its attention any
>    copyrights, patents or patent applications, or other proprietary
>    rights that may cover technology that may be required to implement
>    this standard.  Please address the information to the IETF at ietf-
>    [email-masked].
>
>
> 13.  Copyright Notice
>
>    Copyright (C) The IETF Trust (2008).
>
>    This document is subject to the rights, licenses and restrictions
>    contained in BCP 78, and except as set forth therein, the authors
>    retain all their rights.
>
>    This document and the information contained herein are provided on
an
>    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS
>    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST
AND
>    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS
>    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF
>    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
>    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>
>
>
>
>
>
>
> Napierala              Expires - December 2008              [Page 11]
>
>

rahul

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 18 Jul 2008 14:36:13 -0700

Maria,

> more general requirements in RFC4834. 

The comments do not confuse the specific requirements with more
general requirements in rfc4834. The point made in the comments is
that the general requirements in rfc4834 apply to all the specific
cases.

> replies to the comments).

There is a contradiction/change, as making support for PIM-Bidir REQUIRED 
contradicts/changes rfc4834 which makes support for PIM-Bidir RECOMMENDED.

> Detailed responses in-line.

see in-line...

> >    Internet Draft                                       Maria Napierala
> >    Document: draft-mnapierala-mvpn-part-reqt-02.txt AT&T
> >    Expires: December 24 2008                               June 24 2008
> >
> >
> >    Internet-Drafts are draft documents valid for a maximum of six months
> >    and may be updated, replaced, or obsoleted by other documents at any
> >    This document describes a requirement for Multicast IP VPN solutions
> >    It is intended that existing and new solutions to MPLS/BGP Multicast
> >    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
> >    enabling customers to run native IP multicast within their IP VPN's.
> >    file distribution). From VPN customer perspective there is no change
> >    in the multicast operational model. Multicast distribution trees are
> >    multicast packets for transport across provider's network. Throughout
> >    this document whenever we refer to a VPN we mean MPLS/BGP IP VPN and
> >    are specified in [iv]. This document defines additional multicast VPN
> >    extensions for multicast in IP VPN's should satisfy this requirement.
> >
> >
> > 2. Terminology
> >
> >    In this document when we use the "C-" prefix when we refer to the VPN
> >    customer multicast addresses and multicast trees. We will prefix VPN
> >    and PIM routes with "C-", as in: C-tree, C-S, C-G, C-RP, (C-*, C-G),
> >    multicast stream would be able to flow along multiple inter-PE trees
> >    source. As a result it would break any kind of "anycast" sourcing of
> >    receivers, except during routing transients. The amount of duplicates
> >    transmitted duplicate traffic. Only a single copy of any C-multicast
> >    egress. One exception is when providing fast convergence for certain
> >    exception is in case of aggregation of different C-streams on to the

Or even better, just remove it.

> provided as an option to the SP.

Ok.

> >    In addition, these two exceptions apply only to traffic from anycast
> >    sources/RP's but not to PIM-SM C-streams flowing on C-shared tree vs.
> >    C-shortest-path tree. In other words, a PIM-SM C-stream should never
> >    and SHOULD work with all protocols used for multicast signaling among
> >    it is independent of multicast tunnel technology used by the service

Section 5.2.4.1 spells out *general* requirements, and as such
it is applicable to all the specific cases (including the case
of multiple P-tunnels for same C-stream).

> >    offering. For example, it cannot require a customer to outsource its

Again, 5.1.10.1 spells out *general* requirements, and as such it
is applicable to all the specific cases (including the case
of multiple P-tunnels for same C-stream).
  
> (multiple P-tunnels for same C-stream) and is not covered in rfc4834.

Ditto.

> is a change to rfc4834 (which states that support for PIM-Bidir

And that is precisely one of the objections for accepting this
draft at the present moment.

> only ones used by the MVPN customers.

What are the standards-based RP mechanisms that are not listed ?

> >    routing in the VPN.  Site specific routing intelligence may include,
> >    for example, route preference or denial of routes. A VPN customer may
> >    How these routing policies are defined and how the customers control
> >
> >
> >    routing is in the selection of the Internet Gateway. Customers might
> >    access the Internet from their branch sites utilizing a default route
> >    transmission. It is a customer expectation that multicast traffic in
> >    with the same address so that data packets destined for that address
> >    traffic in MVPN. Anycast sourcing includes multi-homed sites with C-
> >    simultaneously sourced from each data center to serve different sets
> >    of branch locations. For example, real-time market data distribution
> >    in propagation delay might introduce unacceptable timing differences
> >    partitioning of receivers by the source location is necessary in such
> >    address on loopback interfaces. IP routing automatically selects the
> >    registering sources. Anycast RP's are often used in large enterprise
> >    networks.
> >
> >    Typically, large enterprises have multiple data centers where Anycast
> >    from each data center and delivered via corresponding Anycast RP's to
> >    behavior is that different PE's could choose different upstream PE's
> >    customer routing. IGP cost-based next-hop selection provides PIM-like
> >    support of Anycast C-RP's, i.e., C-receivers join the closest Anycast
> >    C-RP across provider's network. The other option is to leave it up to
> >    the VPN routing policy to partition receivers by Anycast RP location.

rfc4834 does not say that unicast protection scheme cover the
multicast requirement. rfc4834 said that "comparable traffic
protection mechanisms SHOULD be available".

> to suggestions for restatement if it meets the intended requirement. 

Disagree - what described below is a solution. The requirement
is just to provide traffic protection mechanisms. That is it.

> >    could be triggered for C-Group or C-Source traffic. For example, the
> >    source, while the secondary P-tunnel could be based on the next best
> >    route (or another equal cost path) to C-RP or C-source. The redundant
> >    P-tunnel should function in a "warm-standby" or a "hot-standby" mode.
> >    the root of the tunnel. In a "hot-standby" mode the traffic should be
> >    be received at egress PE's. The egress PE's should accept the traffic
> >    network latency. However, in networks with large numbers of senders,
> >    SPT's can increase the amount of multicast state that must be kept in
> >    the routers. A VPN customer might set SPT-threshold to a value higher
> >    In native PIM-SM mode the same multicast traffic does not necessarily
> >    flow over a single tree but it can simultaneously flow on both shared
> >    and shortest path trees, without duplicates being sent to receivers.
> >    receivers) receive a specific PIM-SM C-stream either via the C-RP or
> >    C-stream should never be delivered to an egress PE from both the C-RP
> >    addressing of PE routers. Rather the MVPN solution MUST preserve the
> >    precisely, a multicast VRF with receivers of (C-*, C-G) or (C-S, C-G)
> >    should receive multicast traffic from its best next-hop to C-RP or C-S,
> >    respectively. The only two exceptions to this requirement are: (1)
> >    breaker, and (2) the existence of a configuration knob that provides
> >      switch traffic to SPT's or if they prune previously triggered (C-S,
> >
> >
> >    only wants to receive traffic for a group if that traffic comes from
> >    Such a behavior of PIM-SM means that any PE can receive Join (C-S, C-
> >    G) for a sparse mode group even if no PE has ever received Join (C-*,

Quoting from the text above "The MVPN solution SHOULD support
source-specific host requests". This is not about "not triggering
P-tunnels for non-active C-sources". This is about source-specific
host requests. And this is already covered in rfc4834.
  
> This is a change to rfc4834.

And that is precisely one of the reasons why I object to accepting
this draft.

Yakov.

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Fri, 18 Jul 2008 18:12:48 -0400

Yakov,

> And that is precisely one of the reasons why I object to accepting

Why this is interpreted as a contradiction to RFC4843 and not as
"strengthening" of the requirement? If this cannot be addressed (even in
a separate document) then PIM-Bidir will never be a required MVPN
standard while, in reality, it is required.

from
(C-*,

> host requests. And this is already covered in rfc4834.

"The MVPN solution SHOULD support source-specific host requests" is not
an entire sentence from my document but a part of the sentence. The
entire sentence/requirement reads as follows: "The MVPN solution SHOULD
support source-specific host requests BUT it SHOULD prevent useless
S-PMSI creation for C-sources which are not active."
This is not stated in rfc4834. 

Maria 

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Friday, July 18, 2008 5:36 PM
To: NAPIERALA, MARIA H, ATTLABS
Cc: [email-masked]
Subject: Re: FW: draft-mnapierala-mvpn-part-reqt-02 

Maria,

> replies to the comments).

There is a contradiction/change, as making support for PIM-Bidir
REQUIRED 
contradicts/changes rfc4834 which makes support for PIM-Bidir
RECOMMENDED.

see in-line...

Napierala
2008
months
any
solutions
Multicast
this
> >    1.
Introduction................................................2
> >    2.
Terminology.................................................3
> >    3.   General
Requirements........................................3
> >    4.   Multicast VPN
Partitioning..................................4
> >    7.   IANA
Considerations.........................................9
> >    8.   Security
Considerations....................................10
> >    9.
References.................................................10
> >    10.
Acknowledgments............................................10
> >    11.  Author's
Addresses.........................................10
> >    13.  Copyright
Notice...........................................11
VPN's.
change
are
Throughout
and
VPN
requirement.
VPN
VPN
C-G),
trees
of
duplicates
C-multicast
certain
the

Ok.

anycast
vs.
never
among
service

its

Ditto.

include,
may
control
might
route
in
address
C-
sets
distribution
differences
such
the
enterprise
Anycast
PE's
PIM-like
Anycast
location.

the
best
redundant
mode.
traffic
senders,
higher
necessarily
shared
receivers.
or
C-RP
the
C-G)
provides
(C-S,
from
(C-*,

Yakov.

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 21 Jul 2008 08:48:43 -0700

Hi,
 
I have reviewed rfcC4834, Maria's I-D, and the mailing list discussions,
and I think it's more than a little late to accept this I-D as a working
group draft.  Accepting new requirements and/or changing the current
requirements is not especially conducive to making progress on
developing a multicast solution.

I am reminded of 'Groundhog Day'.

Thanks,

John
>From: NAPIERALA, MARIA H, ATTLABS [mailto:[email-masked]] 
>Sent: Friday, July 18, 2008 3:13 PM
>To: Yakov Rekhter
>Cc: [email-masked]
>Subject: RE: FW: draft-mnapierala-mvpn-part-reqt-02 
>
>Yakov,
>
>Why this is interpreted as a contradiction to RFC4843 and not 
>as "strengthening" of the requirement? If this cannot be 
>addressed (even in a separate document) then PIM-Bidir will 
>never be a required MVPN standard while, in reality, it is required.
>
>
>> > >    PIM-SM [v] permits "a receiver to join a group and 
>specify that
>it
>"The MVPN solution SHOULD support source-specific host 
>requests" is not an entire sentence from my document but a 
>part of the sentence. The entire sentence/requirement reads as 
>follows: "The MVPN solution SHOULD support source-specific 
>host requests BUT it SHOULD prevent useless S-PMSI creation 
>for C-sources which are not active."
>The comments do not confuse the specific requirements with 
>more general requirements in rfc4834. The point made in the 
>comments is that the general requirements in rfc4834 apply to 
>all the specific cases.
>
>There is a contradiction/change, as making support for 
>PIM-Bidir REQUIRED contradicts/changes rfc4834 which makes 
>support for PIM-Bidir RECOMMENDED.
>
>> We should not be accepting new requirements, nor should we 
>change the 
>> requirements already accepted by the WG (rfc4834) until we finish 
>> working on the solution(s) that meet the requirements 
>already accepted 
>> by the WG.
>> 
>> > >            Requirement for Multicast MPLS/BGP VPN Partitioning
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Table of Contents
>> >
>> >    1.
>> > >            Requirement for Multicast MPLS/BGP VPN Partitioning
>> >
>> >
>> >
>> > >            Requirement for Multicast MPLS/BGP VPN Partitioning
>> >
>> >
>> >
>> resources between different multicast streams (between 
>different VPNs, 
>> between different multicast streams of the same or of 
>different VPNs).  
>> This means, for instance, if MDTunnels are trees, being able 
>to share 
>> an MDTunnel between several customers."
>> 
>Again, 5.1.10.1 spells out *general* requirements, and as such 
>> is a change to rfc4834 (which states that support for PIM-Bidir is 
>> "RECOMMENDED".
>> 
>> <mnapierala> correct.
>
>> > >            Requirement for Multicast MPLS/BGP VPN Partitioning
>> >
>> >
>> >
>> > >            Requirement for Multicast MPLS/BGP VPN Partitioning
>> >
>> >
>> >
>> > >            Requirement for Multicast MPLS/BGP VPN Partitioning
>> >
>> >
>> >
>> > >            Requirement for Multicast MPLS/BGP VPN Partitioning
>> >
>> >
>> >
>source-specific host requests". This is not about "not 
>triggering P-tunnels for non-active C-sources". This is about 
>source-specific host requests. And this is already covered in rfc4834.
>  
>And that is precisely one of the reasons why I object to 
>accepting this draft.
>
>Yakov.
>

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Mon, 21 Jul 2008 15:21:12 -0400

John,
my draft is not intended as a "change" to RFC4834. Rather, regarding
PIM-Bidir specifically, the document states what is required in order to
support PIM-Bidir in MVPN context. If there is some wording in the draft
that gives the impression of being in contradiction with RFC4834, it can
be easily removed.

I don't think that accepting my draft as WG document will delay progress
in standardizing the MVPN technology in any way.

Maria

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Drake, John E
Sent: Monday, July 21, 2008 11:49 AM
To: [email-masked]
Subject: RE: FW: draft-mnapierala-mvpn-part-reqt-02 

Hi,

Thanks,

John

---

From: Leonard Giuliano <[email-masked]>
Date: Tue, 22 Jul 2008 13:50:18 -0700 (PDT)

I agree.  RFC4834 solicited extensive WG input, including a survey from 
SPs on MVPN requirements.  Adding new requirements now just moves the 
goalposts even further.

As such, I do not support adoption of draft-mnapierala-mvpn-part-reqt-02 
as a WG doc.

On Mon, 21 Jul 2008, Drake, John E wrote:

-) Hi,
-)  
-) I have reviewed rfcC4834, Maria's I-D, and the mailing list discussions,
-) and I think it's more than a little late to accept this I-D as a working
-) group draft.  Accepting new requirements and/or changing the current
-) requirements is not especially conducive to making progress on
-) developing a multicast solution.
-) 
-) I am reminded of 'Groundhog Day'.
-) 
-) Thanks,
-) 
-) John

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Wed, 23 Jul 2008 14:44:01 -0400

Lenny,
the requirements in my document are derived from a (large) production
MVPN deployment and represent the actual needs of layer 3 VPN customers.
I would hope that addressing them would be considered important by the
WG.

Maria

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Leonard Giuliano
Sent: Tuesday, July 22, 2008 4:50 PM
To: Drake, John E
Cc: [email-masked]
Subject: RE: FW: draft-mnapierala-mvpn-part-reqt-02 

as a WG doc.

-) Hi,
-)  
-) I have reviewed rfcC4834, Maria's I-D, and the mailing list
discussions,
-) and I think it's more than a little late to accept this I-D as a
working
-) group draft.  Accepting new requirements and/or changing the current
-) requirements is not especially conducive to making progress on
-) developing a multicast solution.
-) 
-) I am reminded of 'Groundhog Day'.
-) 
-) Thanks,
-) 
-) John

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 23 Jul 2008 22:12:45 +0200

Hi,

> I would hope that addressing them would be considered important by the

This is a very important point.

We should not ignore customer requirements and discover in one year  
that we ended up with a solution that only solves part of the MVPN  
customers problem, and we have to start over again.

I support this draft..

Thx,

Ice.

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 23 Jul 2008 14:05:48 -0700

>From: IJsbrand Wijnands [mailto:[email-masked]] 
>Sent: Wednesday, July 23, 2008 1:13 PM
>We should not ignore customer requirements and discover in one 
>year that we ended up with a solution that only solves part of 
>the MVPN customers problem, and we have to start over again.

JD:  As Mark Townsley pointed out, the group is currently about 3 1/2
years behind schedule.  To reiterate what I said in my original e-mail,
if we continue to accept requirements we will never be done with a
solution, let alone be done with one in a year.  I also think the phrase
'start over again' is a little Chicken Little-ish.

>> I agree.  RFC4834 solicited extensive WG input, including a survey 
>> from SPs on MVPN requirements.  Adding new requirements now 
>just moves 
>> the goalposts even further.
>>

---

From: "John Mullooly (jmullool)" <[email-masked]>
Date: Wed, 23 Jul 2008 17:09:21 -0400

agreed, clearly the standards community should take seriously the
feedback and the needs
from a large SP deployment. Only recently has MVPN really become a
mainstream service
offering and only now are we beginning to learn these important
requirements.

I support the draft.

john

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of IJsbrand Wijnands
Sent: Wednesday, July 23, 2008 4:13 PM
To: NAPIERALA, MARIA H, ATTLABS
Cc: [email-masked]
Subject: Re: draft-mnapierala-mvpn-part-reqt-02 

Hi,

We should not ignore customer requirements and discover in one year that
we ended up with a solution that only solves part of the MVPN customers
problem, and we have to start over again.

I support this draft..

Thx,

Ice.

> from SPs on MVPN requirements.  Adding new requirements now just moves

---

From: IJsbrand Wijnands <[email-masked]>
Date: Thu, 24 Jul 2008 09:22:42 +0200

John,

> 'start over again' is a little Chicken Little-ish.

The reason that we are 3 1/2 years behind schedule is not because  
we've been adding requirements. It all about the continued  
discussions regarding the different solutions to satisfy the  
requirements. In this case I believe it is actually very good to add  
requirements because it may be a deciding factor in comparing  
different solutions.

Thx,

Ice.

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 24 Jul 2008 09:52:05 -0700

Maria,

> I would hope that addressing them would be considered important by the

Your list of requirements seems to be changing fairly rapidly.
E.g., just a year ago (July 2007) you listed the following requirement:

   The amount of customer multicast control messages carried across SP 
   network should be minimized. Inter-PE C-multicast traffic should not 
   be sent via shared tree (RPT's) before being switched to shortest 
   path tree (SPT). 

yet this requirement is no longer listed in draft-mnapierala-mvpn-part-reqt-02. 
Why ?

Here is another example:

   There should be an out-of-band mechanism that would allow constrained 
   distribution of tunnel information, constrained distribution of 
   information about active VPN sources, and constrained distribution of 
   customer multicast control messages. 

yet this requirement is no longer listed in draft-mnapierala-mvpn-part-reqt-02. 
Why ?

And there are not the only changes between your requirements a year ago
and today.

Given that rate of changes may be your (current) requirements will change 
in a year again...

Yakov.

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Thu, 24 Jul 2008 13:28:41 -0400

Yakov, 

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Thursday, July 24, 2008 12:52 PM
To: NAPIERALA, MARIA H, ATTLABS
Cc: Leonard Giuliano; [email-masked]
Subject: Re: draft-mnapierala-mvpn-part-reqt-02 

Maria,

yet this requirement is no longer listed in
draft-mnapierala-mvpn-part-reqt-02. 
Why ?

<maria> This is not a text from either -00 or -01 of
draft-mnapierala-mvpn-part-reqt.

Here is another example:

yet this requirement is no longer listed in
draft-mnapierala-mvpn-part-reqt-02. 
Why ?

<maria> This is also not a text from either -00 or -01 of
draft-mnapierala-mvpn-part-reqt.

Given that rate of changes may be your (current) requirements will
change 
in a year again...

<maria> There have been no essential changes to the document across -00,
-01, -02 versions. There have been some changes, mostly editorial and
organizational, based on the input I received from the WG. 

Yakov.

---

From: Eric Rosen <[email-masked]>
Date: Thu, 24 Jul 2008 15:02:02 -0400

> solution, let alone be done with one in a year

The rhetorical flourishes are getting a bit out of hand.

Ultimately,  to be successful,  we have  to meet  the real  service provider
requirements, not the requirements that  happen to have been captured in any
particular document.

That's not to say that we have to meet them all "in the first release."

At this point, we should think about advancing the solutions work we already
have, and any shortfall between that work and new (or old) requirements will
give rise to followon work.  I think the two WG documents that are available
now are  in reasonable  shape, but  they do reflect  an agreement  among the
authors to  do a  functional freeze on  a certain  date.  This results  in a
number of  things not  being included (i.e.,  being declared out  of scope).
You can see my own view on  what additional work needs to be done by reading
draft-rosen-l3vpn-mvpn- mspmsi-00.txt.   I also think there is  more work to
do on extranet and on inter-provider MVPNs.   We need as a WG to be thinking
about closing on what we have and on moving ahead with the followup work.

Frankly,  when you take  three years  to produce  a piece  of work,  you can
expect that there  will not only be new requirements, but  also new ideas on
how to better solve the problems.  We need to adapt to and incorporate these
instead of trying to suppress them.

Of course, I'm sure no one wants  to see a situation where some piece of the
necessary work  goes to  standards track,  while the rest  is blocked  by an
endless series of filibusters.  One way to keep the work going without quite
so much politics  is to move everything on the  Experimental track, and then
come back in a few years when we have more deployment experience to see what
caught  on  and what  didn't.   Another  way would  be  to  form some  clear
agreements up front about exactly what followup work is to be done.

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 24 Jul 2008 13:27:22 -0700

Comments inline 

>From: Eric Rosen [mailto:[email-masked]] 
>Sent: Thursday, July 24, 2008 12:02 PM
>To: Drake, John E
>Cc: IJsbrand Wijnands; NAPIERALA, MARIA H, ATTLABS; [email-masked]

JD:  Oh, now
>
>Ultimately,  to be successful,  we have  to meet  the real  
>service provider requirements,

JD:  Hard to disagree with

>not the requirements that  
>happen to have been captured in any particular document.

JD:  Then what is the purpose of producing this 'any particular
document'?

>At this point, we should think about advancing the solutions 
>work we already have, and any shortfall between that work and 
>new (or old) requirements will give rise to followon work.  I 
>think the two WG documents that are available now are  in 
>reasonable  shape, but  they do reflect  an agreement  among 
>the authors to  do a  functional freeze on  a certain  date.  
>This results  in a number of  things not  being included 
>(i.e.,  being declared out  of scope).

JD:  I would think that when the working group starts planning for
followup work, it would start gathering requirements for followup work.

>
>Frankly,  when you take  three years  to produce  a piece  of 
>work,  you can expect that there  will not only be new 
>requirements, but  also new ideas on how to better solve the 
>problems.  We need to adapt to and incorporate these instead 
>of trying to suppress them.

JD:  Why capture requirements now if there is no intention or working on
them now?

>
>Of course, I'm sure no one wants  to see a situation where 
>some piece of the necessary work  goes to  standards track,  
>while the rest  is blocked  by an endless series of 
>filibusters.

JD:  Glass houses...

>One way to keep the work going without quite so 
>much politics  is to move everything on the  Experimental 
>track, and then come back in a few years when we have more 
>deployment experience to see what

JD:  That would seem to be the correct point at which to start gathering
additional requirements.

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 24 Jul 2008 16:29:32 -0400

I guess the question would be are these requirements necessary to  
augment/fix those in place today that are being used to form the
solutions that the WG is building? I know Mariea's requirements were  
not invented in a vacuum and so it is advisable that the
WG take a close look at them before shooting them down based on what  
sounds to me like rhetorical and procedural reasons.

	--Tom

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 24 Jul 2008 16:40:56 -0700

Maria,

> draft-mnapierala-mvpn-part-reqt.

The text is from draft-mnapierala-mvpn-rev-02.txt (which you published
just a year ago). One problem with that document was that it was a
combination of requirements and solutions. To address this problem
you essentially extracted *some* of the requirements from that
document, and put them into draft-mnapierala-mvpn-part-reqt.  So,
my question to you is why did not you put *all* of the requirements
that were present in draft-mnapierala-mvpn-rev-02.txt into
draft-mnapierala-mvpn-part-reqt.

Ditto.

Yakov.

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Thu, 24 Jul 2008 20:50:06 -0400

Yakov, 

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Thursday, July 24, 2008 7:41 PM
To: NAPIERALA, MARIA H, ATTLABS
Cc: Leonard Giuliano; [email-masked]
Subject: Re: draft-mnapierala-mvpn-part-reqt-02 

Maria,

<maria>  Yes, my solution draft initially contained also the
requirements it was addressing, since those requirements were not
covered by any other document. As you know it was suggested to me that I
write a requirements document corresponding to the solution I proposed
(in order to allow other solutions to address those requirements), which
I did. I tried to keep the requirements in mnapierala-mvpn-part-reqt at
the level high enough that would not presuppose any solutions, while my
solution draft contained much more detailed requirements precisely
because it was a combination of both the requirements and the solution.
When I issued the requirements draft, in parallel I cleaned the solution
draft from sentences that were requirements. 
This discussion is about accepting the requirements draft
draft-mnapierala-mvpn-part-reqt-02 as a WG document, and not my solution
draft.

Ditto.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 24 Jul 2008 18:13:29 -0700

Maria,

> draft-mnapierala-mvpn-part-reqt-02 as a WG document, and not my solution

And as part of this discussion I'd like you to explain why some of 
the requirements that you had a year ago are not in draft-mnapierala-mvpn-rev.

Yakov.