RE: Advancing the Protocol and Morin Drafts

[Thomas Morin <[e-mail]>]

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.


NAPIERALA, MARIA H, ATTLABS :
>
> >Bidir-PIM
> >
> > Customer Bidir-PIM is already defined as a SHOULD in RFC4834.
> 
> 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.

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.


> >        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...;-)

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 ?


> >        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.

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