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, 

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 

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

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

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 


[Orange logo]<http://www.orange.com/>

Stephane Litkowski
Network Architect
Orange Expert Future Networks
phone: +33 2 23 06 49 83 
  NEW !
mobile: +33 6 71 63 27 50 
  NEW !


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

Reply via email to