Subject: FW: draft-morin-l3vpn-mvpn-considerations

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Wed, 19 Dec 2007 10:46:29 -0600

Hi Thomas,
Please see in-line..

Maria

-----Original Message-----
From: Thomas Morin [mailto:[email-masked]] 
Sent: Wednesday, December 19, 2007 4:36 AM
To: NAPIERALA, MARIA H, ATTLABS
Cc: [email-masked]
Subject: RE: draft-morin-l3vpn-mvpn-considerations

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.

<maria> Thomas, I just want to make sure that PIM-Bidir is a requirement
for MVPN. If this is not part of RFC4843 then it has to stand on its own
in draft-mnapierala-mvpn-part-req. If draft-mvpn-considerations has no
intention to refer to draft-mnapierala-mvpn-part-req then it cannot
represent all SP's (at least not the one I work for).

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

<maria> I can definitely do that provided that my above comment is
addressed. Otherwise it would not make much sense to address it in
draft-mvpn-considerations.

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

<maria> My requirement for PIM Bidir (as well as any other PIM mode)
calls for independence from inter-PE multicast signaling protocol. Such
solution is specified in draft-mnapierala-mvpn-rev-03.

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.

<maria> I can do that. 

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

<maria> this requires more elaboration because it has to do with an
entire procedure defined in draft-mnapierala-mvpn-rev-03. The gist of it
is that a PE attached to C-S starts transmitting traffic on S-PMSI
announced for C-S once it received the 1st (C-S, C-G) join. The PE's
attached to receivers join the S-PMSI once the advertisement from the
ingress PE is received. 

> > > 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 <[email-masked]>
> > > -) To: [email-masked]
> > > -) 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 <[email-masked]>
> > -) To: [email-masked]
> > -) Subject: draft-morin-l3vpn-mvpn-considerations
> > -) 
> > -) Folks,
> > -) 
> > -) Unless I hear an objection before COB Friday, this document will
> > become
> > -) a WG draft.
> > -) 
> > -)                                       Ron
> > -) 
> > 
> > 
>

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 19 Dec 2007 11:40:32 -0800

Maria,

Your I-D is not yet even a working group draft.  Would you please stop
asserting that the requirements it contains are in any way binding?

Thanks,

John
>From: NAPIERALA, MARIA H, ATTLABS [mailto:[email-masked]] 
>Sent: Wednesday, December 19, 2007 8:46 AM
>To: Thomas Morin
>Cc: [email-masked]
>Subject: FW: draft-morin-l3vpn-mvpn-considerations
>
>Hi Thomas,
>Please see in-line..
>
>Maria
>
>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.
>
><maria> Thomas, I just want to make sure that PIM-Bidir is a 
>requirement for MVPN. If this is not part of RFC4843 then it 
>has to stand on its own in draft-mnapierala-mvpn-part-req. If 
>draft-mvpn-considerations has no intention to refer to 
>draft-mnapierala-mvpn-part-req then it cannot represent all 
>SP's (at least not the one I work for).
>
>
>> > 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 
>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.
>
><maria> I can definitely do that provided that my above 
>comment is addressed. Otherwise it would not make much sense 
>to address it in draft-mvpn-considerations.
>
>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.
>
><maria> My requirement for PIM Bidir (as well as any other PIM 
>mode) calls for independence from inter-PE multicast signaling 
>protocol. Such solution is specified in draft-mnapierala-mvpn-rev-03.
>
>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.
>
><maria> I can do that. 
>
>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 ?
>
><maria> this requires more elaboration because it has to do 
>with an entire procedure defined in 
>draft-mnapierala-mvpn-rev-03. The gist of it is that a PE 
>attached to C-S starts transmitting traffic on S-PMSI 
>announced for C-S once it received the 1st (C-S, C-G) join. 
>The PE's attached to receivers join the S-PMSI once the 
>advertisement from the ingress PE is received. 
>
>> > > positioned as a mandatory mechanism in MVPN, which this draft is 
>> > > addressing.
>> > 
>I think that it is now clarified that providing the 
>RP-colocation feature was never recommended as a mandatory mechanism.
>> 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