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

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Thu, 31 Jul 2008 12:06:08 -0400

Hi Thomas, 

-----Original Message-----
From: Thomas Morin [mailto:[email-masked]] 
Sent: Thursday, July 31, 2008 11:32 AM
To: NAPIERALA, MARIA H, ATTLABS
Cc: L3VPN
Subject: RE: draft-mnapierala-mvpn-part-reqt-02

Hi Maria,

NAPIERALA, MARIA H, ATTLABS :
> Thomas, 
> 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... !  

>   - do currently described solutions fail to address them ? why ?
> 
> <MN> having multiple entry points for the same C-flows for PIM-SM is
not
> 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.

<mn> this is only the means to achieve the goal and not the entire
solution.

>   (  -> 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? )
> 
> <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. 

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

<mn> but this is not the only requirement in my document (even regarding
Bidir) so I am not sure that "errata" is an answer.

>   - or maybe how these new requirements could help distinguish between
> currently described solutions
> 
> <MN> precisely, I believe they do help, as Ice already also indicated
on
> 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 ?

<mn> This document has always been a requirement document and as such it
only states the requirements. I have never promised in the past to
explain in the document what you are suggesting, namely, how these
requirements could help distinguish between currently described
solutions. In fact, these requirements can be met/are independent of the
signaling protocol used for exchanging multicast routes.  But if it
necessary to state in document more regarding this I am willing to do
so. I am trying to cooperate.

Thank you,

-Thomas