Here is my review of draft-ietf-bess-nsh-bgp-control-plane-06

General comment:

The document is globally well written with good examples that help the 
understanding. However it requires some refinements in the normative language 
used: some statement should be normative but are not using upper case words.

Detailed comments:


-          Please expand "BGP" on first use

-          Please give a reference associated to "Network Service Header"


-          When "classifier" is used as an example of SF, do you refer to the 
classifier used to steer the traffic onto an SFC ? If yes, I don't think it 
could be considered as an SF.

-          I think the "conventional" approach described in the intro is really 
old school and even before SFC, we had some means, like dynamic routing 
protocols and other mechanisms like separate routing tables, to steer the 
traffic through a set of services. I agree that there is also some drawback 
associated with such approaches like the operational complexity of provisioning.

Section 1.2:
It would be good to give a definition for the additional terms that are defined 
in this document.

Section 2.1:

·         As the section is focused on dataplane, it would be good to rename it 
as "Reminder on NSH dataplane" or something like that. It does not provide a 
functional overview of the controlplane which is what was expected based on the 

·         "A special Service Function, called a Classifier, is located at each
   ingress point to a service function overlay network.  It assigns the
   packets of a given packet flow to a specific Service Function Path.
Again, based on my understanding, the Classifier cannot really be considered as 
an SF , at least this is a component out of the SFC which steers the traffic 
onto an SFC.

·         "An unknown or invalid SPI SHALL be treated as an error and the SFF

   MUST drop the packet.  Such errors SHOULD be logged, and such logs

   MUST be subject to rate limits."

I found strange to have such statement in this document which is focused on the 
controlplane while this statement is a dataplane statement. Isn't it part of 
RFC8300 Section 3 : "3.  Update the NSH: SFs MUST decrement the service index 
by one.  If

       an SFF receives a packet with an SPI and SI that do not

       correspond to a valid next hop in a valid SFP, that packet MUST

       be dropped by the SFF."

The next paragraph deals also with normative dataplane statement which is IMO 
out of scope of this document.

Section 2.2

·         "The SFIR describes a particular instance of a

      particular Service Function". Would it be good to talk about "Service 
Function Instance" rather than instance of a Service Function ? That's 
understandable, of course, however I think it's good to reuse the exact 

·         I think the SFT definition is appearing a bit late in this section 
and in the document as it as been referenced already multiple times before.

·         "Service Function Type (SFT) that

   is the category of SF that is supported by an SFF". Don't you mean SFI 
rather than SFF ?

·         "Thus the SFF can be seen as a portal...". Would "gateway" be more 
suitable rather than "portal" ?

·         The Figure 1 is not really used in this section as part of the 
existing text. I would be better to have a companion text that explains the 

·         I don't like (personal opinion), the "grouping" of SFIs in the Figure 
1 as part of an SFT. What strikes me is that it could be confused with the 
usual representation of an SF composed of multiple SFIs. Again that's just a 
personal feeling.

Section 3:

·         "they must use BGP Capabilities": is it a normative MUST ?

Section 3.1:

·         s/a two byte Type field and a six byte/a two bytes Type field and a 
six bytes/

·         "Two SFIs of the same SFT must be associated". Is it a normative MUST 
? Same comment for next sentences in the paragraph (multiple occurences)

·         "The Service Function Type identifies a service function". I don't 
think we can really say that, it identifies the type of service the SF is 
providing but not the SF itself.

·         "Each node hosting an SFI

   must originate an SFIR for each type of SF that it hosts, and it may

   advertise an SFIR for each instance of each type of SF." Is it really "and" 
? I mean can we just summarize by using " Each node hosting an SFI MUST 
originate an SFIR for each instance of each type of SF" ?

·         "A BGP Update containing one or more SFIRs will also include". Is it 
a MUST or SHOULD "also include"?

·         How is the nexthop encoded in the NLRI ?

Section 3.1.1

·         s/"It can be included"/"It MAY be included"/ ?

·         That would be great to give more details about the usage of pools

·         The encoding in Figure 4 is not matching the text. Figure 4 has 
Type=0x80, Sub-type=TBD6, text says type=TBD6 and subtype=0x00

·         How is the pool ID managed ?

Section 3.1.2

·         Same comment about Figure 5 not matching the text.

Section 3.2:

·         s/a two byte Type field and a six byte/a two bytes Type field and a 
six bytes/

·         Same comment about normative language "must" vs "MUST"

·         How is the nexthop encoded in the NLRI ?

Section 3.2.1:

·         From a readability point of view, it would be good to tell in the 
second sentence that the requested attribute is Optional Transitive (we can see 
it in the description but it is also good to have it in the intro of the 

·         "The presence rules and meanings are as follows.". It would be good 
to use normative language in the following sentences.

·         I don't see the "error handling" behavior associated with this 
attribute (discard, treat-as-withdraw...)


·         "It may be present" or "It MAY be present" ?

Section 4.1

Having an SFF being part of a single overlay network is IMO a very limited use 
case, in such a case, I don't think that you need an RT at all. The SFF could 
be part of a L3VPN which will be used as an underlay.
An SFF being "multitenant" is more valid and defacto requires to maintain 
separate forwarding states (VRF like...). This is mandatory to maintain the 
tenant isolation and RTs are very useful here to know the appropriate context 
to put the routes in.

Section 7.1
While I understand that the node doing the classification can perform a deep 
packet inspection to get an entropy indicator, any intermediate node cannot set 
it again as the NSH header will be there.
Here is an example:

PacketsIn ---> Classifier ->SFF1 (SFI1) -> SFF2(SFI2) ->SFF3(SFI3)->PacketsOut 
to dest

Classifier pushes NSH header onto the packets as well as the underlay tunnel 
(using an entropy indicator in UDP or ELI/EL). Where the packets comes in at 
SFF1, IMO, it strips the underlay tunnels including the entropy indicator. 
Which means that when the packet with NSH header will go to SFF2, it will not 
have anymore entropy indicator and there is no way to build it again as the NSH 
header prevents a new deep packet inspection. Am I missing something ? 
Maintaing a per packet state is IMO not doable , especially if the SFI modifies 
the packet content.

Section 8
I would have been good to have two SFIs with the same SFT on the same SFF in 
the example.
I don't like the representation of RD using ",1" as the "," can be 
confusing with a regular separator. Why not using :"" notation which 
is well known ?

Section 8.9.1:
How does an SFF know that an attached SFI is stateful ? I don't think it can 
know that.
I don't think that the fact that SFF2 is used in both direction is safe from a 
loadbalancing perspective.
If the hashing algorithm used by SFF2 is sensible to the order of the keys 
(like source vs dest address, or source vs dest port), it may provide a 
different SFI as a result of the hashing between the forward and the reverse 

Section 8.9.2:
How can the controller instruct the classifier how to place traffic ?
In addition, this could involve multiple classifiers that need to be 
The ingress forward classifier and the ingress reverse classifier should use 
SFPs within the same assoc.

Section 9:
Do we have to set limits on receiving nodes in term of number of states 
received from the controller to mitigate some attack ?
The text talks about security of BGP, what kind of mechanism should be put in 
place ?
Do we have any interdomain considerations ?
This is a controller based approach, so the security of the controller itself 
is also important.

Shouldn't RFC7665 be normative ?
I think that the mpls-sfc and mpls-sfc-encaps should also be normative as you 
are defining a controlplane to use them.


[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