Hey Adrian, > Well for one let's observe that interface can be both physical and logical > > > entity and as such especially being a logical one can be tight with a > > > service switching vector in any network element. So even based on all > > > IPv6 related RFCs you have quoted it does not violate any. > > > > This is certainly one way around the concern. If we define “interfaces to > functions” (such as an interface to a VRF) then we may be done. That would > be relatively easy to achieve with a simple section in the network > programming draft. >
So it seems we have a solution to your concern. If WG decides to augement the WG doc with such defintion it seems to be done deal. Just to repeat (since it has apparently been repeatedly missed in reading > my emails on this topic, and was even the cause of some heat in a > face-to-face conversation I had in Prague) I am not seeking to block > anything. What I want to do is get everything aligned. I want to be sure > that we have agreement early rather than having a “fight” late in the day > when pressures will be more severe. > > I simply don’t understand any reluctance to bring this discussion into > the open and make sure we understand how the architectures and terminology > line up. > Well as an observer I see the interesting coincidence of such comments popping up in the same time as alternative proposals to define yet one more new mapping scheme of IDs to service functions and to not embed them as part of 128 bits. So the conclusions are coming out pretty automatically about overall strategy :) Cheers, R.
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
