On Tue, Mar 27, 2018 at 7:30 PM, Sri Gundavelli (sgundave) <[email protected]> wrote: > Hi Tom, > > I realize there have been some discussions, but I think its time to reopen > those discussion in 6MAN or wherever and find a way-forward. There is a > strong use-case now for such capability. I am not convinced that we cannot > find a work around. May be its about documentation on the potential issues > and with an IESG note on the considerations before enabling such mode. It > will be unfortunate, if we loose this basic capability of SRH insertion by > an on-path node. > Sri,
Personally, I don't think the justification was all that strong. AFAICT the only reason to do this is to save bytes of header. But the savings aren't all that impressive. As pointed out previously, if you use encapsulation for SR then the destination address eliminates the need for one sid so the savings is at most 24 bytes. But in the case there is only one sid (I belives that's 'traditional mode') the need for the EH overhead is eliminated with encapsulation, so the savings is only 16 bytes. Given that SR is pretty verbose to begin with (each sid is 16 bytes), it's not clear to me at least that saving a some bytes of encapsulation header is worth the effort of changing a protocol that's now a full Internet standard. Perhaps there's some other reason why header insertion is critically needed? Tom _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
