Subject: RE: Advancing the Protocol and Morin Drafts

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Mon, 13 Oct 2008 19:12:05 -0400

Hi Thomas,

>        Anycast-RP is a requirement formulated in RFC4834 ("SHOULD work
>        transparently through a multicast VPN"). Is is true that the
>        type of anycast sourcing that you described is not specifically
>        covered.

It is not suffcient to say that Anycast-RP "SHOULD work transparently
through a multicast VPN". It is not clear what "transparently" means in
MVPN context since there is an SP backbone network and a layer 3 service
in the middle. Anycast RP support has to be spelled out into specific
requirement(s).

>        
>        Let's go to the most important point for an operator: both are
>        fully supported by draft-ietf-2547bis-mcast. A specific UMH
>        selection algorithm that is common to BGP-based and PIM-based
>        C-multicast routing, is defined as a "SHOULD" in section 5.1.3.

As I pointed out before, UHM selection is just a means to the goal. It
is not an entire solution. 
Putting this aside, a requirements document is not to specify solutions
but it has to state what requirements anycast sourcing should meet. And
again, there are specific requirements for anycast sourcing support. I
have specified those requirements but you (and others) opposed them. 

>        If there were to be, at some point in the future, multiple
>        proposals to support anycast schemes (pure hypothesis), we
could
>        certainly cover this in draft-morin-l3vpn-mvpn-considerations,
>        and try to define which one to privilege.
>        
>        (If you think that solution drafts are lacking in some way to
>        properly support anycast schemes, or do not have the proper
>        SHOULD/MUST/MAY level, then I think that you should make
>        comments  to amend draft-ietf-2547bis-mcast )

Requirements and considerations drafts should express the requirements
so that the proposed solutions can adequately address them. Otherwise,
the requirements/considerations drafts do not serve their intended
purpose.

>Bidir-PIM
>
>        Customer Bidir-PIM is already defined as a SHOULD in RFC4834.
It

Bidir-PIM support should be REQUIRED in MVPN context. 

>        is already supported by draft-ietf-2547bis-mcast, by both the
>        PIM-based and BGP-based C-multicast routing approaches.  There
>        happen to be two approaches defined to support Bidir-PIM
>        ("outsourced RPL" in section 11.1, and "partitioned 
>        sets of PEs" section 11.2).
>        
>        I note that no contribution what yet proposed by the working
>        group to implement in priority one of these approach, and since

Section 4 of draft-morin-l3vpn-mvpn-considerations-03 states:
"It is therefore the recommendation that implementations should
support a co-located RP model, but that support for a co-located RP
model within an implementation should not restrict deployments to
using a co-located RP model [..]".  
Clearly, "outsourced RPL" cannot be take priority.

>        you are interested in the subject, we will certainly welcome a
>        contribution on the matter from you.  This is totally 100% in
>        the scope of the document evolution that can be expected from
>        the document once adopted (obviously we would have welcome a
>        contribution before too).

I am definitely interested in the subject as I am one of those running
the MVPN service :-)
The draft-morin-l3vpn-mvpn-considerations-03 states: "The aim of this
document is to leverage the already expressed requirements [RFC4834]
[..]". 
But the requirements we discussed above are not addressed in RFC4834. 
If my contribution is welcome, I wish the requirements are defined were
also welcome...;-)

Thanks!

Maria

---

From: Thomas Morin <[email-masked]>
Date: Tue, 14 Oct 2008 11:13:09 +0200

Hello Maria,

As explained previously and below again, contributions will be welcome
to cover matters related to bidir-PIM (or any other issue for which
there is indecision in draft-ietf-2547bis-mcast about what is
mandatory). Nobody, except you, seem to believe that new requirements
are needed to address them in draft-morin-l3vpn-mvpn-considerations.

> Clearly, "outsourced RPL" cannot be take priority.

Nonsense: the section you quote is *not* about bidir-PIM, but about the
RP function in a PIM-SM context (like clearly stated in the first
paragraph).

If you have any thought (or "consideration") about which of the
alternative ways of doing Bidir-PIM can be favored, we will welcome such
a contribution.

> If my contribution is welcome, I wish the requirements are defined were

As far as I can tell, RFC4834 is one guidance, but not the only one (eg.
quantitative scalability comparison is another), to examine the
alternatives proposed in draft-ietf-2547bis-mcast.

If you want to artificially limit your contribution, I can't decide for
you, but I think it is completely in the scope of the document to
examine the different alternatives for bidir-PIM and say which one
should be part of the proposed mandatory set of options. 

Whether it is a SHOULD or a MUST, it is relevant to include bidir-PIM in
the scope of a standard set of procedures, right ?

> the requirements/considerations drafts do not serve their intended

I think that you are confusing things. "Considerations" is just a word
in the title, meaning in our case that the document examine questions
related to multicast VPN interoperability.  This document serves a well
defined purpose, which is not the same as a requirements document aiming
at exposing needs about features that a solution should be able to
cover.  

-Thomas