On Tue, 17 Mar 2020, 04:39 Sander Steffann, <san...@steffann.nl> wrote:
> Hi, > > > How this relates to NETPGM > > - SRv6 SIDs are IPv6 addresses. > > - SRv6 SIDs are not necessarily interface addresses. > > This will need some work, because according to > https://tools.ietf.org/html/rfc4291#section-2.1: "IPv6 addresses of all > types are assigned to interfaces, not nodes.". I think at least defining a > pseudo-interface (like a loopback) is required to comply with RFC 4291. > > Speaking as an operator: this would also make SRv6 SIDs easier to > understand conceptually. It would also make it easier to debug because the > SID would be a "normal" IPv6 address on an interface, not something that > isn't visible in the RIB/FIB but is still handled in the local router. > Having a RIB/FIB entry and an interface (if only a pseudo one) would make > existing debugging practices easier to apply. > It is also becomes a high level handle or object to attach related configuration to, a policy point for applying packet filters/ACLs, and the interface counters become easy to access, although not specific, function counters. For example, an SR virtual interface's counters become basic counters of the SR traffic that has been received and sent, accessible via standard SNMP interface OIDs. Early Cisco and Linux kernel IPsec implementations didn't use virtual interfaces to represent tunnels. They both moved to doing so fairly quickly for the same sorts of reasons. > If NETPGM deviates from RFC 4291 I think that needs to be strongly > justified. Not deviating from existing standards should be the default :) A major benefit of compliance with existing standards is you get to take advantage of existing implementations, models, knowledge and experience. A lot of things come for free because they already exist. Regards, Mark. > Cheers, > Sander > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
