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

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 1 Mar 2016 22:43:31 +0000

On 2/28/16, 5:37 PM, "Joel Jaeggli" <[email-masked]> wrote:

Joel:

Hi!  How are you?

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

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.

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?

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

---

From: joel jaeggli <[email-masked]>
Date: Thu, 10 Mar 2016 07:34:03 -0800

> On 2/28/16, 5:37 PM, "Joel Jaeggli" <[email-masked]> wrote:

good

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

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.

> ("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.
> 
> 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.

> "... 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. "
> 
>> 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.
> 
> [1]
> https://mailarchive.ietf.org/arch/msg/bess/h3H9joH90g2B1XplYi_H9QJaf6k
>
> 
> [3]
> https://mailarchive.ietf.org/arch/msg/bess/DBdwMh2Z3WE80NJxhA5qDsmlQwI
>
>

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 14 Mar 2016 14:30:15 -0400

On 3/10/2016 10:34 AM, joel jaeggli wrote:
> prescriptive when it comes to implementation in a network.
As far as I can tell, no one has offered any reason to think that the 
document is not adequately prescriptive.

> You see to be asking us to write the words.

No, you are just being asked to state what you think is needed that 
isn't present.  This should be stated with enough precision to enable 
the authors to know what it would take to lift the DISCUSS.

The text you quote from Sue:

> I am looking for an operator-based “abstract” that focuses the reader on the key
> points.

does not help me understand what is claimed to be missing.  I do not 
know what an "operator-based abstract" would be, or where it is stated 
that such a thing is required.

> leakage. calling this spongy is maybe an understatement.

This statement is a good example of the way in which the DISCUSS is 
unsatisfactory.  There is in fact no such technical concept as "RD 
leakage", and it is impossible to understand from the above text just 
what objection is being made.

Procedures for the use of the extranet RD are defined in such a way that 
existing procedures using the default RD will still work.

> This question
> domain experts, and previous discussion on the list.

Lack of familiarity with the normative references seems to be a factor 
here.  However, I am not aware of any requirement to provide an 
"executive summary" for people who are not familiar with the normative 
references.

I would like to call your attention to 
http://www.ietf.org/iesg/statement/discuss-criteria.html.  In section 
3.2, "DISCUSS Non-Criteria", it says "None of the following are criteria 
for which the IESG should DISCUSS a document", and among "the following" 
it lists:

Unfiltered external party reviews. While an AD is welcome to consult 
with external parties, the AD is expected to evaluate, to understand and 
to concur with issues raised by external parties. Blindly 
cut-and-pasting an external party review into a DISCUSS is inappropriate 
if the AD is unable to defend or substantiate the issues raised in the 
review.

Also among the non-criteria is:

Stating "I think there's something wrong here, and I'll tell you what it 
is later" is not appropriate for a DISCUSS;

I think this would rule out a DISCUSS based on the feeling that "there 
might be some mistakes in the part of the document that I don't understand".

On that same page, it lists among the valid DISCUSS criteria:

It would present serious operational issues in widespread deployment, by 
for example neglecting network management or configuration entirely.

This seems to be the main criterion being used to support the DISCUSS, 
but given the number of provisioning rules and warnings contained in the 
document, and the extensive discussion of what has to be configured in 
the PEs, I don't see how one could claim that network management or 
configuration are neglected entirely.

Thus I think this DISCUSS violates the IETF process in the following ways:

- The DISCUSS is too vague to be actionable.

- It is not based on a valid DISCUSS criterion.

- It relies entirely on an "unfiltered external party review".