[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-morin-l3vpn-mvpn-considerations
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
>-----Original Message-----
>From: NAPIERALA, MARIA H, ATTLABS [mailto:mnapierala at att.com]
>Sent: Wednesday, December 19, 2007 8:46 AM
>To: Thomas Morin
>Cc: l3vpn at ietf.org
>Subject: FW: draft-morin-l3vpn-mvpn-considerations
>
>Hi Thomas,
>Please see in-line..
>
>Maria
>
>-----Original Message-----
>From: Thomas Morin [mailto:thomas.morin at orange-ftgroup.com]
>Sent: Wednesday, December 19, 2007 4:36 AM
>To: NAPIERALA, MARIA H, ATTLABS
>Cc: l3vpn at ietf.org
>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 <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
>> > -)
>> >
>> >
>>
>
>
>