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

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Tue, 18 Dec 2007 11:34:14 -0600

Hi Thomas,
thanks for the reply. See my responses in-line.

Maria 

-----Original Message-----
From: Thomas Morin [mailto:[email-masked]] 
Sent: Monday, December 17, 2007 5:01 PM
To: NAPIERALA, MARIA H, ATTLABS
Cc: Ron Bonica; [email-masked]
Subject: RE: draft-morin-l3vpn-mvpn-considerations

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: Yakov Rekhter <[email-masked]>
Date: Tue, 18 Dec 2007 12:00:17 -0800

Maria,

> thanks for the reply. See my responses in-line.

see in-line...

> currently available solution for BSR. 

There is a way to support BSR without using MI-PMSI. As I mentioned
in my reply to Eric's original e-mail, supporting BSR without MI-PMSI
has been explained in the presentation at the L3VPN WG meeting. The
authors of 

> Since there are existing MVPN

I agree that BSR certainly has to be supported. But that does not 
mean that supporting BSR requires MI-PMSI.

> requirement. We have many large VPN customers requiring it.

Changing "recommends" to something else has to do with changing
rfc4834, not with draft-morin-l3vpn-mvpn-considerations.
  
Yakov.

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Tue, 18 Dec 2007 14:10:44 -0600

Yakov,

>mean that supporting BSR requires MI-PMSI.

OK. Is there more information about the specifics of this BSR support? 

Maria

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Tuesday, December 18, 2007 3:00 PM
To: NAPIERALA, MARIA H, ATTLABS
Cc: Thomas Morin; [email-masked]
Subject: Re: draft-morin-l3vpn-mvpn-considerations 

Maria,

see in-line...

  
Yakov.

---

From: Thomas Morin <[email-masked]>
Date: Wed, 19 Dec 2007 10:36:04 +0100

Hi Maria,

NAPIERALA, MARIA H, ATTLABS :
> > > 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 
> > 
> > [...]
> <maria>
> that's true but RFC4834 only "recommends" PIM-Bidir support on 
> interfaces. The draft-mnapierala-mvpn-part-req makes it a

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.

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

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.

> > > source PE waits for a pre-configured period of time) is not
> > > satisfactory in my opinion. A different approach is proposed in

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
> > As I said earlier, mvpn-considerations does not at all push this
> > feature as mandatory at all.
> 
 
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

---

From: Thomas Morin <[email-masked]>
Date: Wed, 19 Dec 2007 10:47:02 +0100

Yakov Rekhter :
> maria> yes, I agree. The need for MI-PMSI should be stated as the only
> maria> currently available solution for BSR. 
> 
> has been explained in the presentation at the L3VPN WG meeting. 

Yakov, mvpn-considerations cannot definitely not take into account stuff
that is not fully described yet.

Until a mechanism like the one is proposed, it is logical to state that
"current proposed approaches require an MI-PMSI for BSR support" and
update the section of mvpn-consideration talking about MI-PMSI in this
respect.  That can (and will) obviously be updated later if proposal to
do BSR without an MI-PMSI are made.

Thanks,

-Thomas