Subject: Re: draft-mnapierala-mvpn-part-reqt-02

From: Eric Rosen <[email-masked]>
Date: Thu, 10 Jul 2008 09:40:21 -0400

Maria's  draft  specifies  several  requirements  that are  not  present  in
RFC4834.  I think the requirements  are all reasonable, and all reflect real
experience  on the part  of a  service provider  offering MVPN  solutions to
customers.

I think therefore that  the draft should be accepted as a  WG draft, and the
requirements posed therein should be added to the RFC4384 requirements.

In particular, I  believe the new requirements identified  in that draft are
the following:

- For a  given C-(S,G) or  C-(*,G), different egress  PEs should be  able to
  make  independent selections  of the  Upstream PE,  according  to criteria
  which  a SP  may establish.   This  means that  the C-flow  may travel  on
  several different P-tunnels, with each egress PE for that C-flow receiving
  traffic from only one of those P-tunnels.

  This feature  is necessary  for proper support  of anycast RP  and anycast
  sources.   It  also  supports  various  kinds  of  load  balancing  and/or
  multicast traffic engineering.

  The  draft makes  it  a SHOULD  that  a PE  be able  to  base upstream  PE
  selection upon the P-network's IGP distance to the upstream PE,

  I agree that the solution must provide a way to meet this requirement.

  The draft also  requires that there be a way to  meet this requirement for
  each control  protocol, and for each tunneling  technology (and presumably
  for each combination of  control protocol and tunneling technology), which
  also seems reasonable.

- Support  for  warm-standby and/or  hot-standby  P-tunnels,  to reduce  the
  probability  of  multicast  packet  loss  due  to  a  failure  within  the
  P-network.

  I don't think this is  incompatible with anything in the existing solution
  drafts, but it isn't explicitly called out anywhere.

- Preserving customer multicast traffic patterns.  This has several facets:

  * Don't force customers to the (S,G) trees when they prefer to stay on the
    shared tree.   (However, I think that  if one CE  expresses a preference
    for (S,G)  over (*,G), all CEs should  be switched to the  (S,G) tree --
    this may require some further discussion.)

  * Don't  create any  customer-visible  (S,G) or  (S,G,RPTbit) states  that
    would not exist in the C-network if MVPN were not being used.

  This seems very reasonable. I would also infer from this that there should
  be a  way to  assign (*,G) traffic  to an  S-PMSI without having  to first
  identify each source.

- Support of (S,G) C-Joins from a CE  in the case where G is a non-SSM group
  address but the CE in question has not previously submitted a (*,G) Join.

- Support for customers that use BIDIR-PIM.

  * Without requiring that the PEs attaching to a given MVPN run the baroque
    BIDIR DF election procedure that  was designed for a very different kind
    of environment  (viz., for a LAN).  Should  be able to force  all PEs to
    select the  same upstream PE for  a given BIDIR-PIM C-RPA,  but must not
    require that to be the case.

  * Allow for a PE to be a "source-only" branch of a BIDIR-PIM C-tree.

  * I would add that, to my mind, support for BIDIR-PIM requires the ability
    to assign BIDIR-PIM group  addresses to S-PMSIs.  Another consequence, I
    think, is that the ability to use bidirectional P-tunnels to instantiate
    S-PMSIs should be at least a SHOULD, if not a MUST.

- It must not be  required for a customer to "outsource the  RP", or to talk
  MSDP to a PE or to any other router.
 
I  wouldn't  necessarily say  that  these are  so  obvious  that no  further
discussion is required, but I  certainly think this draft should be accepted
as a WG draft.

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Tue, 15 Jul 2008 14:24:58 -0400

Support as WG draft-
Deborah 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ron Bonica
Sent: Thursday, June 26, 2008 2:20 PM
To: [email-masked]
Subject: draft-mnapierala-mvpn-part-reqt-02

Folks,

Maria Napierala has asked the WG to adopt 
draft-mnapierala-mvpn-part-reqt-02 as a WG item. If you have any opinion

  regarding whether it should be adopted, please post a message to the
list.

                                      Ron

---

From: "Yuji KAMITE" <[email-masked]>
Date: Wed, 23 Jul 2008 16:28:30 +0900

Regarding the content,  it's not clear what the
"partitioning"  exactly means (definition in VPN context)
and why it is needed.  Does this offer new benefit to high reliability
or new service to the customer?

To me the current text (Section 1 and 2) does not yet explain
this point very well.  So I'd like to see the motivation/background
and justification more.  

Yuji

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ron Bonica
> Sent: Friday, June 27, 2008 3:20 AM
> To: [email-masked]
>   regarding whether it should be adopted, please post a 
> message to the list.
> 
>                                       Ron
> 
>

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Wed, 23 Jul 2008 09:26:24 -0400

Yuji,
> this point very well.  So I'd like to see the motivation/background

Sure. This can be done.

Maria
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Yuji KAMITE
Sent: Wednesday, July 23, 2008 3:29 AM
To: [email-masked]
Subject: RE: draft-mnapierala-mvpn-part-reqt-02

Yuji

---

From: Thomas Morin <[email-masked]>
Date: Sun, 27 Jul 2008 01:34:20 +0200

Hi,

I would not dismiss this draft based on the timing of these newly
identified requirements ; Maria's certainly has good reasons to see such
requirements, even if that comes long after RFC4834.

The general arguments that requirements coming from the operational is
also certainly true.

But before adopting such a draft I think we should before have clearly
identified :
=> are they needed to define solutions ?
  
  - do currently described solutions fail to address them ? why ?

  (  -> e.g. isn't C-bidir already covered by draft-ietf-2547bis-mcast ?
   isn't the partitioning approach already possible with
draft-ietf-2547bis-mcast? )

  - or maybe how these new requirements could help distinguish between
currently described solutions

   ( -> you've stated earlier that they were, and that you would explain
why, but you didn't provide such an explanation yet)

=> supposing that they call for new solutions or evolutions of currently
described solutions, what would be the appropriate timing to cover these
requirements (how critical these new requirements are vs. progressing
the solutions covering RFC4834) ?

I've not seen solid arguments to answer the above and I'm thus against
adoption of the draft until the above can be identified.

Until the need/relevance of new work, requirements or solutions, is
clearly identified, I think we should focus on progressing current work
toward a state where it can become a standard.  If some people think
that they have some piece of work that is needed or that provides a
significant advantage, then they should convince the WG of the relevance
of these proposal, and then that work would progress as its own pace.

-Thomas

Ron Bonica :
>   regarding whether it should be adopted, please post a message to the list.
> 
>                                       Ron
> 
>

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Tue, 29 Jul 2008 13:59:57 -0400

Thomas, 
these are very good points and questions. I am glad you asked them.
Please see in-line.

Maria
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Thomas Morin
Sent: Saturday, July 26, 2008 7:34 PM
To: L3VPN
Subject: Re: draft-mnapierala-mvpn-part-reqt-02

Hi,

<MN> tx

<MN> having multiple entry points for the same C-flows for PIM-SM cannot
be just added after the fact. It has to be included in the MVPN inter-PE
procedures.

<MN> having multiple entry points for the same C-flows for PIM-SM is not
currently covered in the WG solution draft.

<MN> yes, the C-Bidir is covered so I am not sure why such opposition to
it as a requirement?  Bidir has to be supported because VPN customers
are using it. 

<MN> precisely, I believe they do help, as Ice already also indicated on
the mailing list. I can certainly explain it in the document.

<MN>  The only reason I have not done it because I did not think such
explanation should appear in a requirements document. So, if there is an
agreement that it should be included I would definitely do so. 

<MN> they are critical. We will not move to a new MVPN solution if those
requirements are not supported (especially the partitioning for PIM-SM).

<MN> As I explained above, the current WG document draft does not
address the main requirement for partitioning PIM-SM domain. 

-Thomas

list.

---

From: Thomas Morin <[email-masked]>
Date: Thu, 31 Jul 2008 16:32:07 +0100

Hi Maria,

> these are very good points and questions. I am glad you asked them.

I'm glad to see you say that you can answer my questions (below).
and I would also be glad if you could also answer them... !  

> currently covered in the WG solution draft.

It seems to me that it is, the UMH selection algorithm explicitly allows
the selection of a different upstream PE by two downstream PEs, and the
routing procedures do also support this.

> it as a requirement?  Bidir has to be supported because VPN customers

(another way of seeing that question : is it worth publishing an errata
RFC to a requirements document, to update a SHOULD into a MUST, knowing
that this won't change the solutions ?)

> the mailing list. I can certainly explain it in the document.

Maria, you said, in January (!) that you would answer this very
question. You are repeating today that you can answer it.  Can you
please, if you think this is important, do it on the list ?

Thank you,

-Thomas