Hi,
Here is my review of the document.
Main feeling:
I don't think that the document is ready to be published, especially as
Standard Track is requested. The document clearly lacks of description of what
should be implemented (what is optional, mandatory...) and some
ambiguities/misinterpretation are possible. The description is fine for an
informational RFC but not for a standard track document.
General comments:
The document uses "service chains" or "service function chains". Wouldn't it be
good to have a single name used across the document ?
The document tells that a controller is not mandatory but always talks about
the controller job. It should be clear that the document is focusing on a
controller based approach as it does not provide a good view on how an
implementation should work without a controller.
While being Standard Track, the document does not rely on the associated
normative language.
The usual boilerplate template is missing.
Please make sure that all abbreviations are expanded on first use (VRF,VPN,
XMPP...)
Please provide references for XMPP, Netconf, YANG.
It would be good to replace "NC" by "Netconf"
Try to avoid as much as possible references using "above" or "below" for
sections and use clear reference pointers instead (just in case of paragraph
reshuffling).
Section 1.1:
* Some of the definitions you are providing are already present in
RFC7665 (like Network Service, Classification...).
* VRF definition is badly indented (it is within the Gateway definition)
Section 2.1:
"The forwarding table in the VRF in
R-A will direct traffic destined for Network-B into an encapsulation
tunnel with destination R-1 and a label that identifies the ingress
(left) interface of SF1 that R-1 should send the packets out on.
* Does this mean that the label can't be a VRF assigned label, so when
the label comes in, it causes an IP route lookup in the ingress VRF ?
* In the figure, it does not make sense to me for the SFC entry point
to be on R-A. I agree that it works but this sounds more a waste of resource as
you can attach directly Net-A to the Ingress VRF on R-1 which then acts as the
SFC entry point.
"The controller is responsible for configuring the VRFs in each
routing system, installing the routes in each of the VRFs to
implement the SFC, and, in the case of virtualized services, may
instantiate the service instances."
* In the text above, it would be good to add something telling who does
what when a controller is not used.
Section 2.4:
"SF instances can be deployed as software running on physical
appliances, or in virtual machines running on a hypervisor.
* In the text above, it would be good to enlarge the possibilities
rather than limiting to PNF or VMs (for example, what about containers...). It
would be good to have something generic and not limitative at the end. Giving
example is fine but you should not limit to these.
A single SF instance can be part of multiple service chains. In this
case, the SF instance will have dedicated interfaces (typically
logical) and forwarding contexts associated with each service chain.
* As this is a standard track document, IMO, you should use a word like
"SHOULD" or "MUST" in the sentence above.
Section 2.5:
You are using words like "may", but should you use "MAY" instead ?
Section 2.6:
Additionally, in the second
method, the controller also sends the route-policy containing the
service chain logical topology to each routing system.
What do you mean by route policy here ?
Section 2.6.1:
Controller creates a VRF in each routing system that is connected
to a service instance that will be used in the SFC
Using "a VRF" may be limiting, it could create one or multiple depending on the
architecture of the chain.
Controller configures each VRF to contain the logical interface
that connects to a SF instance.
Shouldn't it be "configures each logical interface, that connects to a SFI, to
be attached in the appropriate VRF"
Controller implements route target import and export policies in
the VRFs using the same route targets for the egress VRFs of a
service function and the ingress VRFs of the next logically
connected service function in the SFC.
This text is unclear, please state clearly if egress VRF and next logical
ingress use the same RT as import and export. Or if egress VRF just imports the
exported RT from the next logical ingress ?
In this section , you should use a normative language.
Section 2.6.2:
Using Figure 1 for reference, when the gateway R-B advertises a VPN
route to Network-B
I have an issue with this sentence, it makes me think that R-B advertise a
route to the B-side which is not the case. I think the sentence is correct but
it could be misinterpreted. We are advertising the routes learned from Network
B to the Service VPN.
In this section , you should use a normative language.
Section 2.7:
This can involve instantiation
of SF instances to implement each service function
I don't think that this is the role of the controller. However it is the role
of the VIM/VNF manager.
Section 2.8.1:
This section is unclear to me. Maybe because I have an idea on how we should be
done and it does not match.
The point I'm missing is the split of the SFC in two sections. Could you
elaborate ?
Here is my view.
Gateway A advertises a DR to Net-A to steer packets in the SFC. Each VRF
(Ingress and Egress) as a DR to the next SF interface or next VRF. The egress
VRF has the fine routes to Net-B.
Section 2.8.2:
In a variation of the SFC configuration method described above
It would be better to have a reference to the previous section rather than
using "above".
I'm also missing the use case here... could you elaborate more ? (same for
2.8.3)
What I personally see is that using a DR is fine as long as you don't have a
per flow SFC (HTTP using SFC1, MAIL using SFC2), and this requires that Net-A
and Net-B does not already use a DR for another purpose like Internet breakout.
Section 2.8.5:
This can be achieved if a new BGP Extended Community
[RFC4360] is implemented to control re-origination.
Again here, you need to use normative language to state that the RT-record ext
ct must be used and the associated procedure.
Section 2.8.6:
"In this case,
the ingress and egress VRFs are combined into one"
Why ?
Section 2.9:
When such a SF is present in
the SFC, the procedures at the routing system are modified slightly.
The L3 routes are the same as the L3 SF case, but now an L2 header
has to be supplied for each packet passing through an SF.
I don't understand that, there is always a layer 2 header... even when using L3
fwding.
Section 2.10
Replacing or not the advertisement is a matter of use case.
You could have some cases where only a subset of the traffic to Net-B is NAT'ed
while the rest is using the existing source address. In such a case, you need
to advertise both the NAT pool and the existing address pool.
Section 3.1
Hence, each VRF in a distributed, SFC
environment should have a unique route distinguisher.
Please use normative language
Section 3.3
I don't understand the two level loadbalancing scheme for ingress.
The ingress VRF of SFI13 will advertise a VPN route RD1:X/Y with label A
pointing to SFI13.
The ingress VRF of SFI11/12 will advertise two VPN routes: RD2:X/Y label B
pointing to SFI11 and RD3:X/Y label C pointing to SFI12
In such case each SFI will get 33% of traffic (approx).
Or in your case does your ingress VRF (the top one) advertise a single route
and not one per SFI ?
Section 3.4.2
It seems that this section assumes that all implementations are using the same
hash function, salt... but is it realistic as you pointed previously that this
is purely implementation dependent ?
In addition, the draft says that addresses and ports should be swapped in the
reverse direction but how the system knows that this is the reverse direction
especially if the system is packet based and not flow based.
This section also tells that the controller could install the LB function in
VRFs, how ? there are a lot of HW/SW dependencies behind, it's not just a
signaling problem, you have to know if the resource is able to handle the
programmed function.
Should this section be normative or purely informative ? It talks about a BGP
ext ct to be used but there is no normative language used.
Section 3.4.3
- Same comment about normative language.
- Point 1) talks about egress VRF, but shouldn't it be applicable also
to the Ingress VRF ?
- Point 3): a VRF cannot create anything. The text should be changed
to something like "a new flow entry is created (or SHOULD be created) in the
egress VRF context".
- Point 5): how do you do that ? RPF check ? Do you assume that your
Ingress VRF is used as Egress VRF for the reverse flow ?
- Point 6): the tunnels (overlays) are usually unidirectional, so you
can't use the tunnel on which the traffic arrived. There is usually no source
information (especially in MPLS world).
- Point 7): do you assume that an IP route lookup is done in the
Ingress VRF ? That's not always the case, as you could get a direct forwarding
to the SFI.
Section 3.4.4
Why can you assume that you will not get any implementation
difference in the virtual forwarders ? Do you mandate to have the same ?
Section 4.1:
IMO, it's only a matter of policy routing in the SF. We have to
deal with multiple topologies like N->N or 1->N, N->1. So the multisubnet
approach is a bit limiting.
Section 4.2:
Why limiting to VLANs ? an SF may just have multiple physical
interfaces, or multiple tap interfaces (in case of VM) without VLAN. Again it's
a matter of policy routing/switching. The SF may implement multiple bridging
domains to segregate some traffic.
Section 5:
There is a paging issue. "A chain <next paragraph> entry VRF would
loadbalance..."
While I agree that it could be a valid use case to have an external classifier,
it is not IMO the natural one which would be to have a classifier being able to
set the traffic on the appropriate overlay to enter the SFC. It would be good
to add this example as well. I don't think it will be practical to configure
one logical if per SFC on the classifier...
Section 10.1:
s/(RT-Record)is/(RT-Record) is/
s/an Route-Target/a Route-Target/
Please use normative language
Section 10.3:
The beginning of the section does not make sense (copy/paste issue from the
previous one ?)
What about using MAC src/dst when using L2 SFCs ?
Section 12:
I think that this section should be enhanced, there are some attack vectors
especially with the flow based approach for ECMPs...
Section 13:
Please rewrite the IANA section appropriately with the numbers allocated.
References:
Please update the references.
Tunnel-encaps may be a normative reference IMO.
You are also missing the basic RFCs referenced in the boilerplate of standard
docs.
Brgds,
[Orange logo]<http://www.orange.com/>
Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83
<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
NEW !
mobile: +33 6 71 63 27 50
<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
NEW !
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
