Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt PaulB thread

From: "Elzur, Uri" <[email-masked]>
Date: Sat, 16 Apr 2016 01:30:17 +0000

Some comments below [UE]

Thx

Uri ("Oo-Ree")
C: 949-378-7568

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Bottorff, Paul
Sent: Friday, April 15, 2016 2:36 PM
To: Paul Quinn (paulq) <[email-masked]>; Elzur, Uri <[email-masked]>
Cc: Thomas Narten <[email-masked]>; [email-masked]
Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt

Hi Paul Q.

Some responses to comments.

Cheers,

Paul

-----Original Message-----
From: Paul Quinn (paulq) [mailto:[email-masked]] 
Sent: Thursday, April 14, 2016 10:21 AM
To: Bottorff, Paul <[email-masked]>
Cc: Thomas Narten <[email-masked]>; [email-masked]
Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt

Paul B.

Some comments inline.

> On Apr 13, 2016, at 6:05 PM, Bottorff, Paul <[email-masked]> wrote:
> 
> Hi Thomas:
> 
> I do not support last call on draft-eitf-sfc-nsh-04. The risk of rushing to close a format before we have clear agreement on the forwarding principles and features is just too high.
> 
> The major problems with the current draft are: 
> 1)the service address formed by the combined SPI+SI appears to have a number of deficiencies which lead to transport dependencies and to layer violations,

PQ>  You draw this broad stoke, however, it is relatively unsubstantiated with technical facts.  The WG discussed the representation of the SPI/SI prior to NSH adoption.  The SPI/SI are not transport values -- and please don't conflate transport (and the associated requirements) with address family.  
PB> I have never asserted that SPI+SI for a "transport" address. Please don't confuse what I've said. The modeling of SPI+SI as a service layer address is very soundly rooted in classic network layer modeling. It is the assertion that that the service layer is independent from the "transport" layer below that indicates the SPI+SI form the address used by the service layer dialog. This address is mapped into the "transport" by mapping the SPI+SI into a transport tunnel and destination address.

[UE] the WG has long recognized the need and advantages of the "service" as a sort of an overlay on top of whatever transport is deployed underneath, to enable e2e and seamless stitching over various transports. I'm not sure I see why the "Service" amounts to a full transport on top of an underlying transport - this seems like duplication. To me SFC/NSH is more of a specialized form of an overlay. If we look into overlays, we find no QoS, no loop detection, just an identifier unique to that overlay...

> 2)there is no resolution to forward/reverse addressing necessary for support of many L4-high service functions,

PQ> That is factually incorrect and I think derives from your opinion that SPI/SI == address family: in general, you can create two unidirectional chains and use them for forward and reverse traffic.  This has been reviewed with /by  L4+ vendors/experts.
PB>We have a lot of work on both L4-higher SFs and proxy forwarders for L4-higher SFs for MAC Chaining and understand this problem in a lot of detail. Having two unidirectional chains don't solve the forward/reverse traffic problem because the reverse path SPI/SI are not included in the NSH header and therefore not available at the time we need to reverse the forwarding direction. Are you mandating every SF and Proxy be provisioned with the forward and reverse SPI/SI? If so the solution is unacceptable to me.  

> 3)there is no resolution to encoding hierarchies which are of importance to SFC applications in NFV environments,

PQ> Encoding hierarchies is an optimization of the base protocol to support scaling in a large deployment; in any case such optimization does not require changes to the base SFC encapsulation.
PB> A general stacking solution will require some type of support which I believe should be in the base header so the context words are kept clear for pure meta-data.

> 4)the draft needs a transport service interface and a description of the mappings used for the service layer onto the transport layer,

PQ> I am not sure what you mean by "transport service interface" - it is true that the SPI/SI need to map to a transport layer forwarding entry but I don't know what you are implying.
PB>You are trying to specify a "transport" independent layer, however have not specified what services the transport must provide to support the SFC layer. A service interface is one of the formalized ways to specify the feature requirements of the underlying layer.

[UE] like in other cases, it implies one can choose the most appropriate transport for the app needs. In absence of underlying transport, I see this as a valid concern, but as mentioned above NSH is not a transport

> 5)the draft specifies two independent formats for encoding the NSH header which is likely to divide the market slowing the deployment of NSH.

PQ>  The draft actually specifies two metadata formats for flexibility and the market will decide which is most appropriate based on specific use cases.  The evidence is clear: a wide-range of _implementations_ already exist. In fact, the real impediment to deployment is esoteric opinion.
PB> This is always the last resort dodge we use in standards, however it always comes at the price of some market confusion and delay. Even though I can accept this if no middle ground is possible, I don't think we have pushed the parties hard enough toward a converged solution to give it up on it yet.

[UE] we have waited more than 2 years, we have multiple implementations. Like you, I'd love to see more convergence, but the drawback is larger. If we keep dragging standards on, for years, rather than recognizing the higher pace of innovation and technology shifts in the market, we end up as accomplices to the diminishing value of std in the industry. It is a delicate balance. Not sure it will be resloved in a short time to justify holding NSH back for this  
> 
>> From my point of view the SFC formed service plane layer network with a peer dialog between the SCF, SFF and SF.  The Service Path Header (SPI+SI) forms the address for this service plane. As it stands there is an attempt to overload the function of the SI as both the SF identifier with the Service Path and as a form of loop detection, however the coupling has resulted in two problems: 
> 1)Since every SF in a path must have a sequential SI, in the event we need to insert or delete a SF it is necessary to update the SFF forwarding entries for the entire chain. To fix this either the SI should be allowed to take non-sequential values along the chain or should not be used for SF addressing.

PQ> This is not a true statement; if an SF needs to be added or deleted then it is necessary to update the SFF forwarding entries for all SFFs downstream of where the change occurs. 
PB> Agreed, I stand corrected.

> 2)Since the SI is only decremented on SF hops it can't guard against a loop between SFFs or SCFs, hence SI is not a reliable method for loop squelching. If a TTL is needed it needs to be separated from SI. Given that there is no clear alternative to TTL for loop squelching at the service layer I believe we do need to include an effective TTL to go forward.

PQ> The SI can provide a simple loop check within the serivce plane but it's primary semantic value is one of location.  The transport itself can provide loop detection as well as SFF verification of SPI/SI + source.  
PB> I both disagree that SI is useful for loop squeltching or that "transport" TTL can stop service layer looping. To use the "transport" TTL  the field would need to be copied from one "transport" to the next "transport" over the SFC service layer. Disregarding the fact that this operation is building a dependency between the "transport" and service layers, which we expressly are trying to avoid, the TTL fields of the transports are not sized to allow for the expanded path lengths which could be created in chains. In addition, some of the transports like Ethernet only support TTL for in special cases (Ethernet only supports TTL when using F-Tag forwarding).

[UE] the SI role is - mapping and identification of the SF to be used.  Like the arguments above, there is no attempt to duplicate each and every transport service in an SFC/NSH "service" layer. An implementer can benefit from a smart allocation of the SI space to assist in loop detection, but it is the right choice of the underlying transport that is in charge of providing transport services e.g. loop detection/prevention.  If we take the above argument one step forward we will need to provide windowing, congestion control, etc. etc. I do not see this as the role of this form of an overlay...

> 3)Every other successful address space has needed to add a few bits to support QoS options. I would suggest taking 3-4 bits from the MD-type and to reserve for QoS handling.

PQ>  Again, this is blurring the lines: QoS is handled, as expected by the selection transport.  This is a feature, not a bug, architecturally speaking.  
PB> Just the opposite, failing to add QoS to the NSH header is blurring the lines between the service layer and the "transport" layer. Consider an a chain which uses both a best effort and an expedited service. Next consider building the chain where each hop uses a different type of "transport". As we map from one "transport" to the next we may over some hops have less QoS information than others. As we continue to the next "transport" we retain the integrity of the end-to-end communication by regenerating QoS from the original QoS contained at the service layer a driven down into the "transport". 

[UE] this suggest the "service" layer has a role of inter-transport or super-transport. I disagree. It is the NSH notion of "mapping from NSH to the transport", that gives the user the perfect control over these phenomenon. A user concerned about this, should pick homogenous transport or most suitable transports. The cost of providing such assurance in a "service" layer is duplicating the transport functionality (and even that will not solve the issue if the underlying transport is lagging...)

> 4)In may data centers we have multi-vendor deployments. In these environments we may have different managers assigning chains. There should to be some convention for splitting the address space between these vendors. The most desirable solution to this is to add an assigned organization ID to the address space. An alternative would be to separate the SPI into a 4 and 20 bit field designating the high 4 bits as a local manager ID.
> 

PQ>  You are conflating federation/configuration and frame format.  The multi-manager scenario is a control-plane/management-plane function.
PB> In a multi-manager situation I need a way to avoid collision in the allocation of the SPI/SI space which is being independently allocated by different managers.

[UE] same goes to a VXLAN....no such field is present there either. Agree w PaulQ - this is a Control Plane aspect
_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc