RE: Advancing the Protocol and Morin Drafts

["NAPIERALA, MARIA H, ATTLABS" <[e-mail]>]

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