Hi Brian, > Each SR node (Segment Endpoint) is effectively applying new IPv6 encap so > is already doing an insertion of new SRH > > That isn't "insertion" in the sense of draft-voyer.
Correct. But we are not discussing draft-voyer here. I think recent mail threads prove that it is much better to discuss one topic at a time rather then mix three different and pretty orthogonal "issues" interchangeably. > . It's prepending an extra layer of encapsulation, which is indeed just > fine and I don't think anyone here is objecting to it. The spring draft > currently uses (IMHO) imprecise language, even in its pseudo-code, but if > all it's doing is describing successive layers of encapsulation that's fine > too. Wasted bytes perhaps, but that isn't an IETF problem. Great that we agree. > Whether prepending new headers, each with their own SRH, is the best way > of doing service-based traffic engineering is another question. Having just > reviewed draft-ietf-bess-nsh-bgp-control-plane for Gen-ART, I do believe > there's more than one possible approach. > 100% agreed. In fact as you may have seen I have another non data plane, but control plane proposal posted: https://tools.ietf.org/html/draft-raszuk-teas-ip-te-np-00 Kind regards, R.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
