RE: draft-morin-l3vpn-mvpn-considerations

[Thomas Morin <thomas.morin at orange-ftgroup.com>]

Hi Maria,

NAPIERALA, MARIA H, ATTLABS :
>
> > > - what is still missing in this draft as well as in RFC4834 is the
> > > requirement to support PIM Bidir on CE-PE links. This requirement
> > > is coming, e.g., from large financial firms for which using PIM-SM
> > > for certain business critical applications does not scale. Not to
> > > mention the SP :-))
> > > - support of "PIM-like" Anycast-RP by allowing multiple RP's to
> > > send traffic in parallel 
> > 
> > The two points above would look to me as belonging to the mvpn
> > requirement document (RFC4834). 
> > [...]
>
> <maria>
> that's true but RFC4834 only "recommends" PIM-Bidir support on 
> interfaces. The draft-mnapierala-mvpn-part-req makes it a
> requirement. We have many large VPN customers requiring it.

If you have the need to drive new or different requirement than the ones
defined in RFC4834, after a quite long process and a survey aiming at,
among other things, identifying the different levels of requirements for
CE-PE PIM variants, then this is a different matter than what
draft-mvpn-considerations proposes to do.



> > The way of supporting bidir-PIM is definitely distinct in the
> > BGP approach and in the Full PIM peering approach, but it seems to
> > me that both should be able to support it. Do you think that
> > mvpn-consideration should discuss the relative advantage of the
> > different proposals for bidir-PIM support ?
> 
> <maria> Definitely.

Well, then please contribute by detailing what differences between the
different proposals for bidir-PIM support make one of these
better/worse, from the VPN customer perspective and/or provider
perspective.


> > For the other requirement, the better is probably to explain to
> > solution draft authors, what would be the need. Do you think that it
> > could help distinguish one of the proposed approaches ?
> 
> <maria> surely. 
> Some of the argumentation from a service provider point of view is in
> draft-mnapierala-mvpn-part-reqt.

After reading draft-mnapierala-mvpn-part-reqt, nothing makes it obvious
that your requirement would be easily met nor by the BGP-based approach
or the Full PIM peering approach for C-multicast routing.

It will really be helpful if you can detail your idea that this new
requirement would be differently addressed/not-addressed by the BGP or
the PIM approach, or by different ways of signaling S-PMSI.


> > > - the recommended approach for a source PE to decide when to start
> > > transmitting customer multicast traffic on a S-PMSI (namely, the
> > > source PE waits for a pre-configured period of time) is not
> > > satisfactory in my opinion. A different approach is proposed in
> > > draft-mnapierala-mvpn-rev-03
> > 
> > Is this something mvpn-consideration should talk about to help
> > distinguish a better approach among the proposed ones ?
> 
> <maria> I think so. There are multiple approaches and they should be
> compared in this aspect. 

It would really be nice if you can expand more...

As far as I know "waiting for some pre-configured period of time before
transmitting traffic" is _common_ to both the BGP-based S-PMSI signaling
and to the UDP-based S-PMSI signaling, just because some signaling has
to reach all PEs before the PE signaling the S-PMSI can use it.  How
would your specific need/proposal help the working group elect one of
the proposed approach ?


> > > Also, I would suggest that "co-located RP" recommendation is
> > > removed from the document. Co-locating C-RP on PE should not be
> > > positioned as a
> > > mandatory mechanism in MVPN, which this draft is addressing.
> > 
> > As I said earlier, mvpn-considerations does not at all push this
> > feature as mandatory at all.
> 
> <maria>  What confused me is, quoting from the draft section 1: 
> "The aim of this document is to leverage the already expressed
> requirements [RFC4834] to identify the mechanisms that the authors
> believe are good candidates for being part of a core set of MANDATORY
> mechanisms which can be used to provide a base for interoperable
> solutions." (my underline of "mandatory").
> 
> I also think that in a "big scheme of things" co-locating C-RP with PE
> is an insignificant recommendation... This is already supported by
> vendors and if a service provider wants to use it, it is free to do so
> :-)
 
Ok, so I see there was indeed some confusion.
I think that it is now clarified that providing the RP-colocation
feature was never recommended as a mandatory mechanism.
We will further clarify that point in next revision.

Cheers,

-Thomas




> > > -) ---------- Forwarded message ----------
> > > -) Date: Mon, 10 Dec 2007 16:11:28 -0500
> > > -) From: Ron Bonica <rbonica at juniper.net>
> > > -) To: l3vpn at ietf.org
> > > -) Subject: draft-morin-l3vpn-mvpn-considerations
> > > -) 
> > > -) Folks,
> > > -) 
> > > -) Unless I hear an objection before COB Friday, this document will
> > > become
> > > -) a WG draft.
> > > -) 
> > > -)                                       Ron
> > > -) 
> > > 
> > > 
> > 
>
> Hi Maria,
> 
> NAPIERALA, MARIA H, ATTLABS wrote:
> > The draft is a very good start but there are still some outstanding
> > mandatory design aspects that need to be addressed: 
> > - support of non-static RP solutions like BSR. There are current large
> > MVPNs in SP network that use BSR
> 
> I agree (see reply to Eric) that our draft can mention BSR support.
> There is only one currently proposed approach for BSR support, applying
> to both the Full PIM peering approach and the BGP approach, so there
> isn't that much to "compare", but the current requirement for MI-PMSI
> for BSR support, even in the case where BGP is used for C-multicast
> routing, has to be mentioned.
> 
> <maria> yes, I agree. The need for MI-PMSI should be stated as the only
> currently available solution for BSR. Since there are existing MVPN
> deployments that use BSR, it needs to be supported.
> 
> > - what is still missing in this draft as well as in RFC4834 is the
> > requirement to support PIM Bidir on CE-PE links. This requirement is
> > coming, e.g., from large financial firms for which using PIM-SM for
> > certain business critical applications does not scale. Not to mention
> > the SP :-))
> > - support of "PIM-like" Anycast-RP by allowing multiple RP's to send
> > traffic in parallel 
> 
> The two points above would look to me as belonging to the mvpn
> requirement document (RFC4834). 
> 
> <maria> actually, those requirements are already stated in
> draft-mnapierala-mvpn-part-reqt-00.
> 
> The requirement for CE-PE bidir-PIM is actually already in that
> document. 
> 
> <maria> that's true but RFC4834 only "recommends" PIM-Bidir support on
> PE-CE interfaces. The draft-mnapierala-mvpn-part-req makes it a
> requirement. We have many large VPN customers requiring it.
> 
> The way of supporting bidir-PIM is definitely distinct in the
> BGP approach and in the Full PIM peering approach, but it seems to me
> that both should be able to support it. Do you think that
> mvpn-consideration should discuss the relative advantage of the
> different proposals for bidir-PIM support ?
> 
> <maria> Definitely.
> 
> For the other requirement, the better is probably to explain to solution
> draft authors, what would be the need. Do you think that it could help
> distinguish one of the proposed approaches ?
> 
> <maria> surely. Some of the argumentation from a service provider point
> of view is in draft-mnapierala-mvpn-part-reqt.
> 
> > - the recommended approach for a source PE to decide when to start
> > transmitting customer multicast traffic on a S-PMSI (namely, the
> source
> > PE waits for a pre-configured period of time) is not satisfactory in
> my
> > opinion. A different approach is proposed in
> > draft-mnapierala-mvpn-rev-03
> 
> Is this something mvpn-consideration should talk about to help
> distinguish a better approach among the proposed ones ?
> 
> <maria> I think so. There are multiple approaches and they should be
> compared in this aspect. 
> 
> > Also, I would suggest that "co-located RP" recommendation is removed
> > from the document. Co-locating C-RP on PE should not be positioned as
> a
> > mandatory mechanism in MVPN, which this draft is addressing.
> 
> As I said earlier, mvpn-considerations does not at all push this feature
> as mandatory at all.
> 
> <maria>  What confused me is, quoting from the draft section 1: 
> "The aim of this document is to leverage the already expressed
> requirements [RFC4834] to identify the mechanisms that the authors
> believe are good candidates for being part of a core set of MANDATORY
> mechanisms which can be used to provide a base for interoperable
> solutions." (my underline of "mandatory").
> I also think that in a "big scheme of things" co-locating C-RP with PE
> is an insignificant recommendation... This is already supported by
> vendors and if a service provider wants to use it, it is free to do so
> :-)
>  
> 
> > I might have comments but wanted to send those COB today. 
> 
> As I told you in Prague, your comments and contributions to this draft
> are always welcome. 
> 
> <maria> surely!
> 
> Thanks,
> 
> -Thomas
> 
> 
> 
> > -) ---------- Forwarded message ----------
> > -) Date: Mon, 10 Dec 2007 16:11:28 -0500
> > -) From: Ron Bonica <rbonica at juniper.net>
> > -) To: l3vpn at ietf.org
> > -) Subject: draft-morin-l3vpn-mvpn-considerations
> > -) 
> > -) Folks,
> > -) 
> > -) Unless I hear an objection before COB Friday, this document will
> > become
> > -) a WG draft.
> > -) 
> > -)                                       Ron
> > -) 
> > 
> > 
>