On Thu, 5 Sep 2019 at 13:02, Ron Bonica <rbonica=40juniper....@dmarc.ietf.org> wrote: > > Fernando, Zhenqiang, > > > > You both have valid points. Maybe I am becoming too tolerant of deviations > from the specification. > >
I think by definition RFCs are the authoritative definition of how protocols and their implementations are to behave. I expect to be able to use them to find out how implementations devices are to behave, or to be able to use them to report bugs to vendors when the vendors' devices aren't behaving per the RFC. An unofficial deviation from the spec makes troubleshooting harder, and could significantly increase the time to resolve a fault for a service critical to a paying customer. I've wondered if SPRING may be viewing MPLS and IPv6 are equivalent utility protocols in the SR context, and therefore are unconsciously thinking that re-purposing IPv6 fields or changing IPv6 processing and behaviour both can be done and can be done as easily as it is possible to do things like re-purpose the MPLS label field to carry SIDs. There's quite a lot of significant differences between MPLS and IPv6, even if both could be used for SR. IPv6 is an end-to-end protocol talked by hosts. It's obviously not an optional protocol for both hosts and network to have enabled if they want to use IPv6 services. It isn't a local network protocol, it's intended to operate end-to-end across the entire Internet, with all devices involved complying with RFC8200 or its ancestors. MPLS is optional in a network, usually limited to the network, is rarely talked by hosts, and isn't talked by hosts by default. There's much more scope to modify it and re-purpose it when it's a much more limited domain protocol than IPv6. These significant differences between MPLS and IPv6 are the reasons why I think it is important that the use of IPv6 with SR complies with the existing IPv6 standard RFC. Regards, Mark. > > > Ron > > > > > > > > Juniper Business Use Only > > From: li zhenqiang <li_zhenqi...@hotmail.com> > Sent: Wednesday, September 4, 2019 10:59 PM > To: Fernando Gont <fg...@si6networks.com>; Ron Bonica <rbon...@juniper.net>; > Ole Troan <otr...@employees.org>; Fernando Gont <ferna...@gont.com.ar> > Cc: draft-voyer-6man-extension-header-insertion > <draft-voyer-6man-extension-header-insert...@ietf.org>; 6...@ietf.org; Suresh > Krishnan <suresh.krish...@gmail.com>; spring@ietf.org; > draft-ietf-spring-srv6-network-programming > <draft-ietf-spring-srv6-network-programm...@ietf.org> > Subject: Re: Re: Spirit and Letter of the Law (was: Question about SRv6 > Insert function) > > > > Hello all, > > > > I don't think we can infer from RFC 8200 that something is mandated and > something is strongly suggested. If guys with different interests can infer > from an "Internet Standard" what they are interested, the standard is > ambiguous and deserves a bis. > > > > If the standard is clear, we MUST obey it, especially for the result after > intensive debates, do we need to repeat the discussion again? > > > > Best Regards, > > Zhenqiang Li > > ________________________________ > > li_zhenqi...@hotmail.com > > > > From: Fernando Gont > > Date: 2019-09-05 09:23 > > To: Ron Bonica; Ole Troan; Fernando Gont > > CC: draft-voyer-6man-extension-header-insertion; 6...@ietf.org; Suresh > Krishnan; spring@ietf.org; draft-ietf-spring-srv6-network-programming > > Subject: Re: Spirit and Letter of the Law (was: Question about SRv6 Insert > function) > > On 4/9/19 21:27, Ron Bonica wrote: > > > Ole, > > > > > > Yes, a deep breath and some introspection are always a good thing.. > > > > > > First, I think that we need to make a distinction between the "spirit" and > > "letter" of the law. Next, we need to make a statement regarding good > > engineering practice. > > > > > > RFC 8200 mandates some things. For example, In an IPv6 header, the source > > address must precede the destination address. Any attempt to reverse those > > two would violate the letter of the law. > > > > > > By contrast, RFC 8200 strongly suggests other things. For example, transit > > nodes should not insert or delete extension headers. > > > > I don't think it "suggests" this. It clearly forbids it. > > > > > > > > > In general, these suggestions should be heeded. But exemptions can be > > granted, on a case-by-case basis, > > > > An exception about this would be a major change regarding what IPv6 is > > and its operation. > > > > > > > > > For better or worse, RFC 8200 does not use RFC 2119 language. So it is > > difficult to distinguish between the spirit and letter of the law. > > > > I think you can talk about spirit when there's room for interpretation, > > or the text is not clear. > > > > I don't think there's any of that in RFC8200 regarding EH insertion > > being forbidden. > > > > In fact, we added the text we added to make it clear that it was forbidden. > > > > > > > > > Beyond that, we need to make a statement regarding good engineering > > practice. > > > > I would like to contribute one: if one is to get into publishing specs, > > new specs should comply with the specs they depend on (i.e. the > > normative references). That means: > > > > 1) Don't violate other specs, or, > > 2) If you strongly feel like it, you first update the target spec, so > > that you behave nicely (you eventually comply with it). > > > > > > > > > If a technology violates the spirit of RFC 8200 once, with good reason, > > that is fine. > > > > I tend to differ here. If a technology is violating an aspect of a spec > > on which we spend a long time and energy, that's not fine. > > > > If we (IETF) do it, that would seem to be an indication of issues in the > > standardization process -- we publishing specs that not even us comply > > with doesn't seem to look nice. > > > > > > Doing this kind of major surgery (EH insertion) after elevating IPv6 to > > "Internet Standard" would bring another set of uncomfortable questions. > > > > Thanks, > > -- > > Fernando Gont > > SI6 Networks > > e-mail: fg...@si6networks.com > > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > i...@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
