Hi Sami,
Please see in-line {iftekhar2]
From: Sami Boutros [mailto:[email protected]]
Sent: Sunday, February 05, 2017 11:59 AM
To: Iftekhar Hussain
Cc: Alvaro Retana (aretana); Jeffrey Zhang; [email protected];
[email protected]; [email protected]
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07
[Attached is the draft updated with the VPWS Service instance (control plane
managed entity) definition in the terminology section and with the general VPWS
reference to RFC4664]
Hi Iftekhar,
Please see inline
Hi Authors,
I support this work. However, I do have few comments that I would like to add
to the list from the AD:
· Section 1: The terms ES and ACs are used interchangeably (e.g., see
“….Ethernet Virtual Private Line (EVPL) service as p2p service between a pair
of ACs” and “…Ethernet Private Line (EPL) service … a single pair of ESes” .
This is confusing. What is the reason for not considering a port as an AC?
Suggestion: Please include a complete service entity reference mode in this
draft. Clearly indicate what entities are involved to provision a VPWS (for
example, ES-AC - LSP etc.). This will also be extremely useful for data
modeling of the service.
Sami: I am not sure I get this, we spend a lot of time on this on the list to
conclude to the text in Place for ES and AC. I am not sure changing any of that
will clarify or confuse.
Iftekhar: I am not saying you didn’t spend enough time. What I am saying is at
least to me the equivalence of AC and ES is not clear. Are you saying AC == ES?
As I understand, these two constructs are not equivalent. AC is a data plane
construct while ES appears to be purely a control plane construct. Okay for the
sake of argument, say ES and AC are equivalent. Then why do you need AC?
Moreover, what will be the data plane entity representation of VPWS-EVPN for
EVPL and EPL look like? Would it be AC- (xconnect) label – LSP or ES-
(xconnect) – LSP?
If you have a look at the terminology section it clarifies what exactly we mean
by ES in the doc it refers to the link/port attached to the PE and we refer to
AC as the VLAN like port. Like Pwe3 the evpn p2p lsp can be looked at as a Pw
construct. By the way AC is both a data and control plane construct. We are not
redefining what EVPL or EPL means but on a given PE we are cross connecting a
port or a VLAN like service to an evpn signaled p2p bidir lsp using evpn-vpws.
[Iftekhar2] “….refer to AC as the VLAN like port”. My question is why a port is
not an AC? In my understanding an AC can be a single VLAN, multiple (list or
range of VLANs) including the entire port (all VLANs). My suggestion is even
for the EPL (port-based service) – you should use the term AC (as opposed to
ES). In addition, if you need the notion of ES to define the service that is
okay. My earlier question was if you could provide an example of all the
management entities involved for configuring a EVPL and a EPL service using the
VPWS-EVPN solution that would be helpful.
Having said that I don’t want to hold your doc back, if other folks, are happy
with the current state of the doc and want to proceed to the next step that is
fine.
· Section 1: “…whereas, for more general VPWS,…” What is a more
general VPWS?
Sami: Please refer to
https://tools.ietf.org/html/rfc4664<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4664&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=arr8Ec2cKeCgz5UeHU7m9StAzmZwpiDEjN_kojOLZro&s=SwLT4zos2yLfooM7WUvRf7cB2C3LYHoDtltS7alnmKs&e=>
for the general VPWS definition. I will add a reference to it in the doc.
Iftekhar: Okay.
· Section 1: It is hard to keep track of what enhancements are being
proposed and what functionalities defined in RFC7432 applies or don’t apply to
VPWS.
Sami: The only change is making the Ethernet tag ID setting to a non zero value
a MUST, this is explicitly mentioned in section 1
"Unlike EVPN where Ethernet Tag ID in EVPN routes are set to zero for
Port-based, vlan-based, and vlan-bundle interface mode and it is set to
non-zero Ethernet tag ID for vlan-aware bundle mode, in EVPN-VPWS, for all the
four interface modes, Ethernet tag ID in the Ethernet A-D route MUST be set to
a non-zero value in all the service interface types."
Iftekhar: Let me give couple of examples. Does (a) MAC/IP route (type2) or
Inclusive Multicast Ethernet Tag route (type 3) (b) MAC Mobility Extended
Community or Default Gateway Extended Community defined in RFC7432 apply to
EVPN-VPWS? If not, it would be useful that this document clarifies it.
The document clearly mention that there is no Mac related routes, or bridge
like service related routes not sure what more clarifications we need.
Enumerating route types and extended communities not supported doesn't make
sense given that EVPN is still adding more route types and more extended
communities in several drafts not only the base.
[Iftekhar2] Not sure, I agree with that. However, I will leave it up to you to
decide. If you prefer not to summarize the deltas – fine.
Suggestion: Add a summary table which captures what Route Types apply (or don’t
apply) to VPWS
Sami: The only route that applies is the ethernet A-D route and we need segment
route for multihoming. None of the other routes apply!
· Section 5: What is equivalent of PW in EVPN-VPW case? In the service
model, is there any entity that need to be modeled? I see that in the
https://tools.ietf.org/html/draft-sajassi-bess-evpn-vpws-fxc-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dsajassi-2Dbess-2Devpn-2Dvpws-2Dfxc-2D01&d=DwMGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=HcUojq-BETlXVyoybL6fXvPLI8qFDvFHnbLsuHVNeew&s=S9UX7kIkRIvJs6_-bWMXPlhhP-3rSRpJYb8DSuaUdJo&e=>
you are introducing a new entity on the PSN side called “VPWS Service Tunnel …
a pair of EVPN service labels associated with a pair of endpoints”. What is
difference between labels associated with a pair of VPWS endpoints in this
draft vs vpws-fxc draft?
Sami: I don;t think we can explain the fxc draft in this draft, however in the
fxc the label is not sufficient to identify the service.
Iftekhar: Let me ask a very simple question. Suppose I am interested in
statistic counters on packet received or transmitted toward PSN/from PSN for a
VPWS-EVPN. In the VPWS (RFC4664) there is PW entity. Could you kindly identify
an entity against which such counters can be shown and retrieved? All
VPWS-EVPN draft has is a “label”.
The PW entity is as well identified by 2 labels for imposition and disposition,
the same way an evpn p2p lsp for vpws is identified.
[Iftekhar2] What I am asking is could you introduce a name for the equivalent
entity for the VPWS-EVPN solution? My earlier suggestion is just call it a
“service tunnel” or something of your choice. I don’t think it will change your
control plane mechanism however it will make your model very clear. Note a LSP
can carry multiple services. I am talking about per service statistic counters.
I understand fxc is a different draft. My point is folks are thinking of
extending the architecture of VPWS-EVPN and they probably realized the need for
an entity. I believe these is a need for such an entity – we have an
opportunity to fix the VPWS-EVPN model right now before it becomes a standard.
Why not fix it now?
The management entity you are looking for is the evpn VPWS service instance,
fxc can map more than one AC to this. I will add a definition in the doc to
this evpn VPWS instance and mention that only one AC can be xconnected to it.
Will that be ok?
[Iftekhar2] An issue pointed earlier that I see with the current solution is
that there is no per service level entity for statistic counters on the PSN
side. The LSP provides aggregate counters for all the services carried on that
LSP. A LSP could be carrying multiple VPWS-EVPN services. My suggestion is that
it would be better to sort this out. Again, if other folks are happy with the
current state of the doc, I don’t want to hold your doc.
Thanks,
Iftekhar
Thanks,
Sami
Thanks,
Iftekhar
Thanks,
Sami
Suggestion: Clearly identify entity that needs to be modeled on the PSN side.
If it is service tunnel, please indicate so. If this aspect is not addressed
properly, IMHO, this will cause lot of confusion.
Thanks,
Iftekhar
From: Alvaro Retana (aretana) [mailto:[email protected]]
Sent: Wednesday, January 25, 2017 8:39 PM
To:
[email protected]<mailto:[email protected]>
Cc: Jeffrey Zhang; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: [bess] AD Review of draft-ietf-bess-evpn-vpws-07
Dear authors:
Hi!
I just finished reading this document. Please take a look at my comments below
– I think they should be easy to resolve. I will start the IETF Last Call when
the comments have been addressed and a new revision has been published.
Thanks!
Alvaro.
Major:
M1. There are 8 authors listed on the front page. Following the guidelines in
the RFC Style Guide [RFC7322], we want the list to be at most 5. Please work
among yourselves to reduce the number of authors. Alternatively, you can just
list an Editor or two.
M2. From the Introduction: “Unlike EVPN where Ethernet Tag ID in EVPN routes
are set to zero…in EVPN-VPWS, Ethernet tag ID in the Ethernet A-D route MUST be
set to a valid value in all the service interface types.” Zero is a valid
value for the Ethernet Tag ID. Section 3. (BGP Extensions) says that “the
Ethernet Tag ID 32-bit field is set to the 24-bit VPWS service instance
identifier”, but I couldn’t find a place where the document told me what a
valid value is. IOW, how can the “MUST” be enforced if there’s no clear
indication of what is valid? OTOH, any specification wants the fields to
contain valid values, obviously! What happens if the value is not valid?
BTW, all this is to say that without a proper explanation (which probably
doesn’t belong in the Introduction), the whole paragraph is superfluous.
M3. The Introduction says that “For EVPL service, the Ethernet frames
transported over an MPLS/IP network SHOULD remain tagged with the originating
VID and any VID translation is performed at the disposition PE.”, later the
same (or at least something similar) is mentioned in Section 2.1. (VLAN-Based
Service Interface): “the Ethernet frames transported over an MPLS/IP network
SHOULD remain tagged with the originating VID, and a VID translation MUST be
supported in the data path and MUST be performed on the disposition PE.”
Please keep the normative language in one place – I am not fond of normative
language in the Introduction; note that even though the result should be the
same, the text is different (the “MUSTs” are used in 2.1).
M3.1. [minor] It is not clear in the text that EVPL service corresponds to
VLAN-based service. Please clarify that. In fact, some of the flow of the
document feel disjoint because slightly different terminology is used and no
hint of how it all ties together is presented; mapping EPL/EVPL to the Service
Interfaces, which are only mentioned in Section 2 (and very briefly in the
Introduction – see M2).
M4. Section 1.2 is titled Requirements. However, the list seems to include a
combination of statements of fact (“EPL service access circuit maps to the
whole Ethernet port”: this is pretty much the definition of EPL),
solution-sounding lines (“Each VLAN individually (or <S-VLAN,C-VLAN>
combination) will be considered to be an endpoint for an EVPL service”: not
only does it sound like what the solution will do, but it is also the
definition of EVPL), and statements that talk to the configuration and not what
the technical solution described later can do (“A given PE could have thousands
of EVPLs configured. It must be possible to configure multiple EVPL services
within the same EVI.”: is there an actual scalability requirement?). I
would have expected actual requirements (for example: “EPL service access
circuits MUST map to the whole Ethernet port”; normative language is not
required) that I can then check against the solution – but it all sounds like a
rehash of what was explained before. ☹
M5. Section 3. (BGP Extensions) says that “This document proposes the use of
the per EVI Ethernet A-D route to signal VPWS services. The Ethernet Segment
Identifier field is set to the customer ES and the Ethernet Tag ID 32-bit field
is set to the 24-bit VPWS service instance identifier.” First of all [this is
minor/a nit], if this document intends to be in the Standards Track then it is
past the “proposing” phase, it is *specifying*. As a specification, it is
rather weak in some places; for example, RFC7432 says (as an example) that the
“Ethernet Tag ID in all EVPN routes MUST be set to 0”: that is a strong
statement of what is expected. On the other hand, this document is modifying
the behavior, but no Normative language is used. [In general I don’t advocate
for the use of Normative language everywhere, but in cases like this where the
behavior is being changed from the base spec when using this extension, it
seems necessary.]
M5.1. Section 3: “Ethernet Tag ID 32-bit field is set to the 24-bit VPWS
service instance identifier” How should this be aligned into the larger field?
M6. Section 3.1 (EVPN Layer 2 attributes extended community).
M6.1. For the P flag – “SHOULD be set to 1 for multihoming all-active
scenarios”: in a multihoming all-active scenario, when would this flag not be
set? IOW, why is the “SHOULD” not a “MUST”. A couple of paragraphs later:
“…the PEs in the ES that are active and ready to forward traffic to/from the CE
will set the P bit to 1”. In the all-active scenario, is there a case where a
PE would not be “active and ready”? What does that mean? Clarifying may
justify the “SHOULD”.
M6.2. How should the other flags in the Control Flags field be assigned?
Please define a new registry and include the details in the IANA Considerations
section.
M6.3. What should a remote PE do if it receives both the P and B flags set (or
both unset)? I know that in a single-active scenario they should not be on at
the same time…but what should the receiver do?
M6.4. What happens if the B flag is set in the all-active scenario? I know
there was some discussion about this on the list – the document needs to
explicitly talk about it.
M6.5. What units is the MTU in? How is it encoded?
M6.6. “non-zero MTU SHOULD be checked against local MTU” When is it ok not to
check? I’m wondering why this “SHOULD” is not a “MUST”, specially because the
result of that check is a “MUST NOT”.
M6.7. “As per [RFC6790]…the control word (C bit set) SHOULD NOT be used…”
Where in RFC6790 does it say that? I searched for “control word”, but found
nothing? Also, this “SHOULD NOT” is in conflict with the definition of the C
flag: “If set to 1, a Control word [RFC4448] MUST be present…”
Minor:
P1. Please add a reference for VPWS.
P2. The [MEF] reference didn’t work for me; on all tries the connection timed
out. Is it possible to find a more stable reference?
P3. There are several acronyms that won’t be familiar to the average reader and
that need to be expanded on first use: ES, AD (A-D), EVI, VID, VNI, EP-LAN,
EVP-LAN. I know that some of these are expanded in the Terminology Section, but
in some cases that comes later in the text.
P4. The EVPN-VPWS term is introduced for the first time in the text at the
bottom of page 3. I take it that it refers to the solution presented in this
document. Please include a sentence at the top of the introduction to clarify
– note that this tag could be useful in other places as well.
P5. “Ethernet tag field” (and not “Ethernet Tag ID”, which I’m assuming is the
same thing) is used in several parts of the text. Please be consistent.
P6. “VxLAN encap” is mentioned in the Introduction, and potential things about
handling it…but there are no references and no additional mention anywhere else
in the document.
P7. “mass withdraw” is mentioned in the Introduction (“…can be used for
flow-based load-balancing and mass withdraw functions”), in Section 4 (“…can
be used for mass withdraw”), and finally Section 6.2 (the last section in the
draft!) has a reference… Please move it earlier in the document.
P8. S-VLAN, C-VLAN: expand and put a reference for them.
P9. There is no Reference to any of the Extended Communities RFCs: 4360, 7153,
etc…
P10. Please add Figure numbers/names.
P11. Section 3.1 (EVPN Layer 2 attributes extended community) defines 3 control
*flags*, but they are referred to later in the text as “bits”. Please be
consistent.
P12. Section 4 (Operation): s/with Next Hop attribute set/with the NEXT_HOP
attribute set Also, include an Informative reference to RFC4271.
P13. Section 6 (Failure Scenarios): “…the PE must withdraw all the associated
Ethernet AD routes…” Should that be a “MUST”?
P14. A reference to “[ietf-evpn-overlay]” appears in the Security
Considerations, but there’s no Reference later on.
Nits:
N1. “Both services are supported by using…I.e., for both EPL and EVPL
services…” The second part of that explanation is a lot clearer, you might
want to simplify by just leaving that part in.
N2. The introduction reads like a rushed summary of the solution, which results
in potentially confusing text. Suggestion: focus the Introduction on setting
the stage/background – if you want to provide a summary of the solution (good
idea!), then do it after the requirements.
N3. s/Ethernet Segment on a PE refer to/Ethernet Segment on a PE refers to
N4. s/multi home…single home/multi homed…single homed
N5. The text in Section 9 is misaligned.
_______________________________________________
BESS mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/bess<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=arr8Ec2cKeCgz5UeHU7m9StAzmZwpiDEjN_kojOLZro&s=KGkV-85RhWJnZPcuzM-GhaOfNb4s-XYBH5rHBnEDjEw&e=>
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
