Subject: Re: [sfc] FW: New Version Notification for draft-kumar-sfc-nsh-forwarding-00.txt

From: "Bottorff, Paul" <[email-masked]>
Date: Tue, 15 Mar 2016 17:51:52 +0000

Hi Surendra:

This is a great improvement over the previous NSH forwarding methods which solving many of the issues I've had with NSH forwarding.

A few questions.

1)Is it really necessary prevent SI increments for Service Infrastructure forwarding? An alternative to suppressing SI incrementing for infrastructure forwarding with the I bit is to simply increment SI for every hop.
2)The use of increments for SI becomes inconvenient when adding or deleting a new SF to a chain since it requires updating the addressing for every SF in the chain. It does not seem necessary to limit the updates to incrementing. We could just swap the SI to any new value which then is sequenced at the SFF into a chain.
3)The use of the C/B bits for reverse services is a bit of a wart. We did the same thing for MAC Chaining by using the BT bit, however I've wondered if it would not be a better trade-off to use the Source Address at the SFF to decode reversals. The SA model for SF reversals uses a dual armed configuration. The SF simply sends in the intended direction. The SFF then decodes the forwarding based on <SPI,SI,SA>. The SF can then use the same mechanism to perform general branching by creating many arms and simply sending to these arms, so providing a very natural and general model for the SF. Even though the source address model has the down side that it makes the SFF forwarding aware of SF instances it also has the advantage that the forwarding model at the SF is simplified and does not require any modification to the NSH header. 

Cheers,

Paul

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Surendra Kumar (smkumar)
Sent: Monday, February 15, 2016 9:51 PM
To: [email-masked]
Subject: [sfc] FW: New Version Notification for draft-kumar-sfc-nsh-forwarding-00.txt

Hello All,

This is a new draft to separate service forwarding from service delivery function in NSH.
It contains the service path header updates to SFFs and enables integrity checks on it.

Thanks,
Surendra.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 15, 2016 3:25 PM
To: Dongkee Lee <[email-masked]>; Peter Bosch (pbosch) <[email-masked]>; Rajeev Manur <[email-masked]>; Joel M. Halpern <[email-masked]>; Sumandra Majee <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; Joel Halpern <[email-masked]>; Kent Leung (kleung) <[email-masked]>
Subject: New Version Notification for draft-kumar-sfc-nsh-forwarding-00.txt

A new version of I-D, draft-kumar-sfc-nsh-forwarding-00.txt
has been successfully submitted by Surendra Kumar and posted to the IETF repository.

Name:		draft-kumar-sfc-nsh-forwarding
Revision:	00
Title:		Infrastructure Service Forwarding For NSH
Document date:	2016-02-15
Group:		Individual Submission
Pages:		17
URL:            https://www.ietf.org/internet-drafts/draft-kumar-sfc-nsh-forwarding-00.txt
Status:         https://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-forwarding/
Htmlized:       https://tools.ietf.org/html/draft-kumar-sfc-nsh-forwarding-00

Abstract:
   This draft describes the separation of service forwarding function
   and service delivery function abstractions, along with the mechanics
   of NSH encapsulated packet forwarding with such separation, in SFC
   deployments.

   This separation frees the service functions from making forwarding
   decisions and the necessary control plane integration, thereby
   keeping the service functions simple and focused on service delivery.
   Further, this separation fully contains the forwarding decisions in
   forwarding functions, thereby allowing implementations to enforce
   integrity of the forwarding state carried in NSH which in turn is
   required for correctly forwarding NSH encapsulated packets.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Wed, 16 Mar 2016 00:55:48 +0000

Thanks for taking the time to read it and for the comments. Responses inline.

Thanks,
Surendra.

-----Original Message-----
From: Bottorff, Paul [mailto:[email-masked]] 
Sent: Tuesday, March 15, 2016 10:52 AM
To: Dongkee Lee <[email-masked]>; Peter Bosch (pbosch) <[email-masked]>; Rajeev Manur <[email-masked]>; Joel M. Halpern <[email-masked]>; Sumandra Majee <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; Joel Halpern <[email-masked]>; Kent Leung (kleung) <[email-masked]>
Cc: Fedyk, Don <[email-masked]>; [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-kumar-sfc-nsh-forwarding-00.txt

Hi Surendra:

A few questions.

1) Is it really necessary prevent SI increments for Service Infrastructure forwarding? An alternative to suppressing SI incrementing for infrastructure forwarding with the I bit is to simply increment SI for every hop.
SK> I guess you are then changing the definition of the SI, it will no longer mean SF location but the next hop (SF/SFF) in the forwarding graph. Also, in this method, I'm not sure if you still anchor the SFs to SFFs. IOW, traffic is directly forwarded by one SF to another without SFF in the middle.
SK> this draft simply makes the {SPI,SI} service header opaque to SFs without changing SI definition.

2) The use of increments for SI becomes inconvenient when adding or deleting a new SF to a chain since it requires updating the addressing for every SF in the chain. It does not seem necessary to limit the updates to incrementing. We could just swap the SI to any new value which then is sequenced at the SFF into a chain.
SK> I may not be fully following this. Even in this method with random/custom SI values, a) the receiving node in the hop needs to be updated if it is doing any kind of path validation, for add/del operations. b) all SFs must be programmed to participate in sfc forwarding.
So, if service-path header is opaque, and the SI definition is (hypothetically) relaxed then the value does not matter. However b) is better avoided simply to remove the forwarding burden on the SFs and control plane touch points.

3)The use of the C/B bits for reverse services is a bit of a wart. We did the same thing for MAC Chaining by using the BT bit, however I've wondered if it would not be a better trade-off to use the Source Address at the SFF to decode reversals. The SA model for SF reversals uses a dual armed configuration. The SF simply sends in the intended direction. The SFF then decodes the forwarding based on <SPI,SI,SA>. The SF can then use the same mechanism to perform general branching by creating many arms and simply sending to these arms, so providing a very natural and general model for the SF. Even though the source address model has the down side that it makes the SFF forwarding aware of SF instances it also has the advantage that the forwarding model at the SF is simplified and does not require any modification to the NSH header. 
SK>Yes, went through the same dilemma with a bit to signal vs SAs. I fear there are many single armed SFs in the virtual world, something to think about though.

Cheers,

Paul

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Surendra Kumar (smkumar)
Sent: Monday, February 15, 2016 9:51 PM
To: [email-masked]
Subject: [sfc] FW: New Version Notification for draft-kumar-sfc-nsh-forwarding-00.txt

Hello All,

Thanks,
Surendra.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 15, 2016 3:25 PM
To: Dongkee Lee <[email-masked]>; Peter Bosch (pbosch) <[email-masked]>; Rajeev Manur <[email-masked]>; Joel M. Halpern <[email-masked]>; Sumandra Majee <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; Joel Halpern <[email-masked]>; Kent Leung (kleung) <[email-masked]>
Subject: New Version Notification for draft-kumar-sfc-nsh-forwarding-00.txt

Abstract:

The IETF Secretariat

---

From: Joel Halpern <[email-masked]>
Date: Wed, 16 Mar 2016 07:35:00 +0000

I really don't think we can count on the source address to detect reversal.  The very meaning of "source address" is different in different transports.   While I am not happy with the bits driving "reverse" interpretation, for internally source reverse packets, it is really hard to see how else to handle it in a general fashion.

Yours,
Joel

-----Original Message-----
From: Bottorff, Paul [mailto:[email-masked]] 
Sent: Tuesday, March 15, 2016 6:52 PM
To: Dongkee Lee; Peter Bosch (pbosch; Rajeev Manur; Joel Halpern; Sumandra Majee; Surendra Kumar (smkumar; Surendra Kumar (smkumar; Joel Halpern; Kent Leung (kleung
Cc: Fedyk, Don; [email-masked]
Subject: RE: [sfc] FW: New Version Notification for draft-kumar-sfc-nsh-forwarding-00.txt

Hi Surendra:

A few questions.

Cheers,

Paul

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Surendra Kumar (smkumar)
Sent: Monday, February 15, 2016 9:51 PM
To: [email-masked]
Subject: [sfc] FW: New Version Notification for draft-kumar-sfc-nsh-forwarding-00.txt

Hello All,

Thanks,
Surendra.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 15, 2016 3:25 PM
To: Dongkee Lee <[email-masked]>; Peter Bosch (pbosch) <[email-masked]>; Rajeev Manur <[email-masked]>; Joel M. Halpern <[email-masked]>; Sumandra Majee <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; Joel Halpern <[email-masked]>; Kent Leung (kleung) <[email-masked]>
Subject: New Version Notification for draft-kumar-sfc-nsh-forwarding-00.txt

Abstract:

The IETF Secretariat