Jim & Avinash, Please let's observe that Adrian removed any references to Segment Routing. What this means that the current proposal is based on vanilla MPLS labels which by base MPLS architecture have **local significance*. *
You can't assume that out of the sudden label has domain wide or global meaning with SR references removed any more. If so this draft in question is not required to dynamically signal a label bound by operator to given service in a control plane. Just like you advertise any other label which has local meaning by the node advertising it. As we pointed out draft-ietf-bess-service-chaining-04 is one option to signal this. They may be other options, but you either treat label as local or as domain wide. You can't pretend that under the umbrella of doing former you are effectively doing latter without admitting it. Best, Robert. On Tue, Mar 20, 2018 at 12:29 PM, UTTARO, JAMES <ju1...@att.com> wrote: > *I guess I am not being clear.* > > > > *The issue as I see it is that I do not require NSH to realize the > creation of simple chains. I simply need SR to realize the chain. Why is > the IETF forcing me to adopt technology that I do not need, while at the > same time reducing the number of vendors that I may use in my network as > this encap will have to be supported by traditional OEMs and others looking > to get into the business.* > > > > *TBC I am not against NSH it addresses use cases where dynamic complex > chains are required. The reality of my world is that I have lots of simpler > chains i.e FW, LB and do not need the additional OPEX and CAPEX costs > associated with deploying NSH. * > > > > *Jim Uttaro* >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
