[bess] Opsdir last call review of draft-ietf-bess-evpn-inter-subnet-forwarding-09

[Joel Jaeggli via Datatracker]

Reviewer: Joel Jaeggli
Review result: Ready

greetings,

I have reviewed draft-ietf-bess-evpn-inter-subnet-forwarding on behalf of the
ops directorate.

as a datacenter operator something of a conflict appears for me in this work in
that  I struggle with the state explosion that IRBs each host / subnet
represent on the PE switches. As the document says:

   In other words, each PE participating in
   asymmetric IRB MUST maintain ARP entries for remote hosts (hosts
   connected to other PEs) as well as maintain MAC-VRFs/BTs and IRB
   interfaces for ALL subnets in an IP VRF including subnets that may
   not be locally attached.

We designed ourselves into  a corner where we need this document.

it would be helpful if section 4 would be more explicit for non-implementors on
when symetric or asymetric modules would be chosen, as it stands the variation
basically reads like the enumeration of the features of various implementations.

I think this document is ready to proceed and it clearly addresses needs in
these implementations.

joel


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [GROW] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard

[joel jaeggli]

On 5/6/17 10:53 AM, Warren Kumari wrote:
> [ + authors ]
> 
> On Sat, May 6, 2017 at 3:16 AM, Robert Raszuk  wrote:
>> Hi Warren,
>>
>>> This is clearly not unanimous/ not everyone is happy, but (in my view)
>>> there is *rough* consensus for this to progress.
>>
>>
>> The group of users of BGP which this update impacts the most are members
>> of BESS WG (cc-ed) and not IDR WG due to the fact that this proposal applies
>> to all AFI/SAFIs.

I think this statement elides that the largest impact here is on
operators, which might be participants of either working group but are
by in large not at the ietf.

As an operator the ability to make recommendations based on practice
that has proven to be problematic is ought to be something others in the
ietf would be interested in. e.g. default accept policies have been
shooting operators in the foot with v4 and v6 unicast AFI's since
literally the dawn of time.

> I'll happily admit that I have not been following BESS at all, and so
> know very little of what y'all do ("Hi Bess!"). Alvaro, please advise
> if BESS is affected to the level that they should have been explicitly
> invited to comment?
> 
>> IMO before you progress anywhere with this IETF LC BESS WG should express
>> their formal opinion on it.
>>
>> Example of in or out eBGP policy where you are sending MAC addresses in
>> EVPN AF needs to be provided and explained why it makes sense. Likewise
>> examples of RTC AF for L3VPN Inter-as needs to be discussed.
>>
>> Otherwise the group of people which defined a lot of non ISP uses of BGP may
>> be
>> suddenly surprised down the read for keeping them out of the loop and have
>> customers loosing reachability upon compliant non sequential router OS
>> upgrade.
> 
> The authors are busy incorporating some final edits (including some
> suggested by Alvaro). I would have hoped that all affected parties
> would have seen the discussions on GROW / IDR / the IETF LC.
> 
> I ask people to please withhold judgment until the new version is released.
> 
> 
> I'm about to board a plane (to Budapest), and will be out of email for
> many hours...
> W
> 
>  >
>> Cheers,
>> Robert.
> 
>>
>> REF: https://tools.ietf.org/html/draft-ietf-grow-bgp-reject-06
>>
>>
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[joel jaeggli]

On 3/1/16 2:43 PM, Alvaro Retana (aretana) wrote:
> On 2/28/16, 5:37 PM, "Joel Jaeggli" <joe...@bogus.com> 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 requireme

Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT)

[joel jaeggli]

On 2/25/16 1:25 PM, Eric C Rosen wrote:
> On 2/24/2016 6:14 PM, joel jaeggli wrote:
>> Providing
>> operational advice isn't in scope? Section 1.3 goes into detail to the
>> point where it is hard to parse the application of route  distinguishers.
> Anyone who understands the normative references will know what a Route
> Distinguisher is and what a VRF is.  The fundamental part of
> provisioning any RFC4364 VPN is to create the VRFs, and to provision
> each VRF with Route Distinguishers.

Yeah, I'm not convinced of that, 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.

> Section 1.3 states that, for the purposes of MVPN, two VRFs MUST NOT be
> configured with the same RD.
> 
> It further states that if the "extranet separation" feature is not
> required, every VRF MUST be configured with a single RD.  If the feature
> is required, every VRF MUST be configured with two RDs, one called the
> "default RD" and one called the "extranet RD".
> 
> In other words, that entire section specifies requirements that must be
> met by whatever process is used to provision the MVPN extranet. It also
> specifies reasons why these requirements are in place by mentioning some
> of the situations in which the protocols presuppose that these
> provisioning requirements are met.
> 
> I don't see what's missing.  I find it puzzling that a section whose
> whole purpose is to clarify the provisioning requirements (and the
> dependencies of the protocols on those requirements) would be held up as
> an example of how there are no operational considerations.
>
> It's true that the section is more focused on providing a precise
> description of the provisioning requirements than on providing a
> tutorial or guide or "advice".  But the former is within the scope of
> the document and the latter is not.  After all, the purpose of this
> document is to specify the protocols and procedures that need to be
> implemented.  The purpose is not to define a service model or
> provisioning system.
> 
>> extranets are by the nature set up by two independent entities. one
>> presumes both mutual cooridnation, and design efforts required to avoid
>> collisions.
> Extranet involves two VPNs, but the provisioning of the extranet is
> generally done by the single service provider that is providing both of
> those VPNs.  Thus the provisioning of an extranet generally does not
> require coordination between two independent entities.
> 
> It is possible that two independent providers will coordinate to provide
> an extranet, but it is also possible that two independent providers will
> coordinate to provide a single VPN, if that single VPN has sites
> attached to both providers.
> 
> For this reason, RFC4364 defines the Route Targets in such a way as to
> enable service providers to allocate globally unique Route Targets.  
> The need for uniqueness of the Route Targets is not specific to extranet
> or to multicast, and is covered in the normative references.
> 
>> the concerns in 2.3.2
>>
>> Section 3 of this document describes a procedure known as "extranet
>> separation".  When extranet separation is used, the ambiguity of
>> Section 2.1 is prevented.  However, the ambiguity of Section 2.2 is
>> not prevented by extranet separation.  Therefore, the use of extranet
>> separation is not a sufficient condition for avoiding the procedures
>> referenced in Section 2.3.1.  Extranet separation is, however,
>> implied by the policies discussed in this section (Section 2.3.2).
>>
>> so being prescriptive with respect to how these may be operated seems
>> like it would be helpful.
> The draft goes into excruciating detail about how to avoid address
> ambiguity when moving data between two VPNs that have overlapping
> address spaces.  It specifies a protocol-based mechanism ("discard from
> the wrong tunnel") allows you to determine which of two streams is the
> one you want, even if both streams use the same IP addresses.  It also
> specifies policies, for assigning multicast flows to tunnels, that can
> be used to avoid address ambiguity.
> 
> Again, I don't see what is lacking.
>> Note that there is no requirement to have a separate "operational
>> considerations" section.
>> nor would that I think be necessary to address the concern.
>>
> Perhaps someone could explain to me exactly what is necessary to address
> the concern.
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Joel Jaeggli]

Joel Jaeggli has entered the following ballot position for
draft-ietf-bess-mvpn-extranet-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-extranet/



--
DISCUSS:
--

After further discussion related to the ops dir review, I'm going to have
to echo Benoit and the Opsdir reviewers concern.


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

Please provide the type of detail as show in RFC 4360 sections 3.1, 3.2,
and 3.3.  

2)  Why is there no Deployment considerations section? 

The whole draft is a set of rules for handling policy, BGP A-D routes,
tunnel set-up, and PIM Join/leaves in the case of an intra net.  Unless
these rules are followed exactly, traffic may flow into a VPN it is not
suppose to.

If the customer and the SP must coordinate on setting up filters, the
procedure is outside the document.

An error in any of these set-ups is considered a “security violation”. 

Milo Medin stated “with enough trust” a rock can fly to the moon. 
However, the NASA flights were fragile and risky.  In the journey to the
moon, there was no other choice.  Instrumentation has 4-5 backups.

In this set-up, one has to ask “is there another choice” to this whole
design that seem fragile addition of extranets to an intra-AS multicast
design.  If the design is not fragile, then there should be a deployment
section indicating how to manage the RTs, RDs, and policy set-up. 
Perhaps experience with the Intra-As has shown deployment tips that would
make this less fragile.  If so,  it would be good to include an
operations consideration section.

If a new class of tools provides monitoring or provisioning, mentioning
these would be useful.  If yang modules are being developed, that would
be useful.

Places that indicate issues with violated constraint:

p. 11, 12, 19 (2.3.2 – a priori knowledge, inability to detect), , p. 25
last paragraph (violation of constraints will cause things to not work. 
However, only policy can control), p. 27 4.2.2 (1st paragraph, Route
Reflector must not change), p. 31 (5.1, first paragraph),

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


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT)

[joel jaeggli]

Hi,  I've reviewed this again in light of our discussion during the IESG
review. From my vantage point discussion on this document is intended to
address corner cases, as is the document itself since inter-vpn exchange
of multicast traffic is itself (in particular for asm) a corner-case,
I'm not sure I suscribe to the rairty of asm vs ssm but for the
appication described, ok .

n 1/27/16 10:35 AM, Eric C Rosen wrote:
> On 1/27/2016 4:37 AM, Benoit Claise wrote:
>>
>> This document doesn't give an operator “so-what” for deployment in 60
>> pages.
> I'm afraid I don't understand this sentence.
> 
>> You know, a few summary paragraphs that indicates where this
>> specification is useful and where it is not for operators, and the
>> potential fragility of the solution (which could be in a new
>> operational consideration section or in the security considerations.
> As I've been trying to explain to Sue, I don't understand what is being
> asked for in these "few summary paragraphs".   An "operator's guide to
> provisioning extranets" would be useful, but not within the scope of
> this draft.

I'm having a little trouble parsing where you disagree. Providing
operational advice isn't in scope? Section 1.3 goes into detail to the
point where it is hard to parse the application of route  distinguishers.

> The security considerations section already points out that
> misconfiguration of the Route Targets may result in misdelivery of
> traffic; the above text is merely a paraphrase of material that is
> already present in the document.
> 
> Note that there is no requirement to have a separate "operational
> considerations" section.

nor would that I think be necessary to address the concern.

>> I don't think I've seen text around coordination to set up filter, for
>> example.
> Coordination to set up filters?  I don't know what you are referring to.

extranets are by the nature set up by too independant entities. one
presumes both mutual cooridnation, and design efforts required to avoid
collisions.

the concerns in 2.3.2

   Section 3 of this document describes a procedure known as "extranet
   separation".  When extranet separation is used, the ambiguity of
   Section 2.1 is prevented.  However, the ambiguity of Section 2.2 is
   not prevented by extranet separation.  Therefore, the use of extranet
   separation is not a sufficient condition for avoiding the procedures
   referenced in Section 2.3.1.  Extranet separation is, however,
   implied by the policies discussed in this section (Section 2.3.2).

so being prescriptive with respect to how these may be operated seems
like it would be helpful.

>>
>> Sue has been trying to be helpful and even proposed some text:
>>
>> Whenever a VPN is provisioned, there is a risk that provisioning
>> errors will result in an unintended cross-connection of VPNs,
>> which would create a security problem for the customers.  Extranet
>> can be particularly tricky, as it intentionally cross-connects
>> VPNs, but in a manner that is intended to be strictly limited by
>> policy.  If one is connecting two VPNs that have overlapping
>> address spaces, one has to be sure that the inter-VPN traffic
>> isn't to/from the part of the address space that is in the
>> overlap.  The draft discusses a lot of the corner cases, and a lot
>> of the scenarios in which things can go wrong. 
>>
> 
> Actually, I wrote that text in an email to Sue.  Although it too is just
> a paraphrase of existing materiaI, I could add it to the "overview"
> section as part of the description of what an extranet is.   Are you
> saying that you will lift the DISCUSS if I just add that paragraph? 
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess