Re: [bess] Joel Jaeggli's Discuss on draft-ietf-bess-mvpn-extranet-06: (with DISCUSS and COMMENT)

[joel jaeggli <[e-mail]>]

On 3/1/16 2:43 PM, Alvaro Retana (aretana) wrote:
> On 2/28/16, 5:37 PM, "Joel Jaeggli" <[e-mail]> wrote:
> 
> Joel:
> 
> Hi!  How are you?

good

> ...
>> ----------------------------------------------------------------------
>>
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>>
>> After further discussion related to the ops dir review, I'm going to have
>> to echo Benoit and the Opsdir reviewers concern.
> 
> I have to say that, as Eric, I am at a loss as to what specifically
> you want to see in the document.  Please see my comments below
> related to the OpsDir review text.
> 
> 
>> ----------------------------------------------------------------------
>>
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>>
>> Sue Hares performed the opsdir review. benoit holds the discuss for the
>> points she raised.
>> 
>> Status: Not ready,  three major concerns and two editorial nits:
>> 
>> Major concerns:
>> 
>> 1)      Specification of the Extranet Source Extended Community and
>> Extra Source extended Community
> 
> I think the authors took care of this already by making sure that
> 4.4 includes the text that Sue had proposed [1].
> 
> ...
>> 2)      Why is there no Deployment considerations section?
> 
> This seems to be the sticking point.  What exactly are you looking
> for?

I think the question comes down to, is this document adequately
proscriptive when it comes to implementation in a network. This question
might be easier to discuss cogently if in fact the document were easier
to read. It is not, so you find your CO-ADs relying on the reviews of
domain experts, and previous discussion on the list. I have implmented
mvpns, I am not a protocol developer.

> Please take a look at Sections 1.2. (Scope) and 1.3. (Clarification
> on Use of Route Distinguishers) -- these are maybe not the best named
> sections, but in them the authors lay out when this spec is useful:
> SSM and ASM deployments (not Dense mode), calls out potential
> problems with BSR, applicable to both PIM and BGP signaling,
> justified the use of a unique VRF per RD.

unique RD per VRF, yes it discusses this, then brings in the extranet RD
leakage. calling this spongy is maybe an understatement.

> Section 1.4. (Overview) gives some examples of potential deployments 
> ("only some of its multicast C-sources be treated as extranet
> C-sources", or "some of its extranet C-sources can transmit only to a
> certain set of VPNs"), and it talks about the need for the SP to
> coordinate with the customer during the provisioning process.
> 
> It seems to me that there's already a pretty good summary in those 
> sections, but they are not called "operational considerations"Š  What
> is missing?  Do you want the above to be in a specific titled
> section, or maybe there are other details you'd like to see -- if so,
> what are they?

It's also not a summary.

You see to be asking us to write the words. I don't intend to take up
the pen on the document nor should we be expected to.

I'd reference Sue's message from 12/22 to the working group accordingly

> 
> 2) On the deployment section:  I given text and examples – but I
> think you still misunderstand what I am looking for.
> 
> Since you are an author of academic papers,  consider I am looking
> for an operator-based “abstract” that focuses the reader on the key
> points.  I am sure you can create one for this document, but I not
> clear why you object to it the concept.
> 
> The “security consideration ” in section 10 in  the text use
> “security consideration” as a euphemism for the traffic being sent to
> the wrong place.  This is deployment and security issue – not just a
> security consideration.   The third paragraph of your text in section
> 10 starting with “In general, different VPNs are allowed to have
> overlapping IP address” needs to clearly state what you stated to me
> in this last email.  (see the text below).
> 
> To limit the email back-forth, will you please let me know that you
> have read my suggested text insertions on both these topics.  I will
> email Benoit/Joel offline regarding #2 deployment to see if he
> believes it is not a DISCUSS criteria.
> 
> Cheerily,
> 
> Sue

I'm not actually married to any particular structure which conveys this
information. just that there is one. the result of that should be that
as an implmentor of the extranet vpn you can also read this document.

> 
> A couple of days ago you raised a specific point [2]:
> 
> "... there is eleborate discussion of the requirement for one RD per
> VRF and then extranet seperation adds a twist that.
> 
> However, when Extranet Separation is used, some of the local-RD
> routes exported from the VRF will contain the extranet RD.  Details
> concerning the exported routes that contain the extranet RD can be
> found in Sections 4.1 and 7.3. "
> 
> It sounds like you may want more clarity/details on parts of that.
> What?
> 
> 
> 
> ...
>> 3)      Is security section really a security section? It seems
>> more like ³do this policy² or this will fail.  It should get a
>> stronger review from the security directorate
> 
> I am in fact not able to find a SecDir review.  However, the SEC AD
> did put a DISCUSS on this document [3] and later cleared it [4] based
> on added text.
> 
> Are there specific security concerns?
> 
> Thanks!
> 
> Alvaro.
> 
> 
> 
> [1]
> https://mailarchive.ietf.org/arch/msg/bess/h3H9joH90g2B1XplYi_H9QJaf6k
>
> 
[2] https://mailarchive.ietf.org/arch/msg/bess/Gg4e8CvN5TpvhqmvUOCB4vRvlug
> [3]
> https://mailarchive.ietf.org/arch/msg/bess/DBdwMh2Z3WE80NJxhA5qDsmlQwI
>
> 
[4] https://mailarchive.ietf.org/arch/msg/bess/sjxLrpyGCCarO86xd5n617Q3fIk
> 
>