Hi Robert,
Thinking about future, I’m not sure that using only length of NH is a good thing. Of course, with IPv4 vs IPv6, it works. But what happens if in the future we have different NH types using a common size ? How do you ensure that the NH is correctly encoded ? If you want to be 100% clean, you need a field telling how is encoded your NH. This is purely theoretical, but nothing can prevent this to happen. This discussion has wider implications. If we just brainstorm, we can even wonder if the NH field is really needed when tunnels are used and tunnel-encaps may be a solution to replace the NH for some AFI/SAFIs. That’s a different discussion 😊. > The main reason is that as SAFIs are being defined every now and then and > there is still no clear document if next hop should match NLRI type or not. As already discussed offline, I would be happy to see guidelines written in IDR to make things better for any new AFI/SAFIs and possibly make all existing AFI/SAFIs working with the new guidelines through a capability or whatever solution. But again, this is orthogonal. Again the goal here is not to do a revolution, but just accommodating the standard to how the implementations of RFC5549 are working. Changing the solution is not the goal. You can’t force people to change their code just because we did things suboptimal from a standard point of view. Codes are working today and are deployed. Any new solution could be done in a separate document and then it will be up to each vendor to implement it or not and to customers to use it or not. Stephane From: Robert Raszuk <rob...@raszuk.net> Sent: jeudi 28 novembre 2019 17:57 To: slitkows.i...@gmail.com Cc: Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com>; bess@ietf.org; bess-cha...@ietf.org Subject: Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00 Stephane, Adding ability to recognize the length of the next hop to any code is purely incremental thing. When vendors were asked I do not even recall if there was a question if given implementation can infer next hop format from length or not - and that is the key problem/point here. Just asking if you are prepending zeros or not to NH in some SAFIs and stating that if so you do revise 5549 to reflect that is not what we should be doing. The main reason is that as SAFIs are being defined every now and then and there is still no clear document if next hop should match NLRI type or not. Moreover 4364 is still being developed in few vendors. Sure they want to be backwards compatible too, but with that let's also give them a chance to do the right thing vs just follow legacy. So yes if you are opening that box my suggestion is to define an additional capability indicating if receiver can process next hop without any additional nonsense zero padding. All it takes is one paragraph/section and one IANA codepoint. Stating that this should be new separate document again updating 5549 and now 5549revised is really not the best option. Best, Robert On Thu, Nov 28, 2019 at 5:40 PM <slitkows.i...@gmail.com <mailto:slitkows.i...@gmail.com> > wrote: Hi Robert, Please see some replies inline. Brgds, From: Robert Raszuk <rob...@raszuk.net <mailto:rob...@raszuk.net> > Sent: mercredi 27 novembre 2019 22:18 To: Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com <mailto:matthew.bo...@nokia.com> > Cc: bess@ietf.org <mailto:bess@ietf.org> ; bess-cha...@ietf.org <mailto:bess-cha...@ietf.org> Subject: Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00 I do not support this draft in the current form. This document instead of improving the original specification makes it actually worse. [SLI] Point 1 - Original RFC sec. 6.2: o Network Address of Next Hop = IPv6 address of Next Hop Proposed text: o Network Address of Next Hop = VPN-IPv6 address of Next Hop whose RD is set to zero As it has been explained when you negotiate in capability AFI2 as next hop it is just 16 octets - not 24. [SLI] AFI2 means that the nexthop is encoded with a format compliant with an AFI2, but does not tell anything about the SAFI. A VPN-IPv6 address is still AFI2. Next hop never has an RD. [SLI] We have already discussed about that. RD doesn’t make any sense for a nexthop address. No one disagrees on that point. However our legacy 2547bis introduced a nexthop encoded as a VPN-IP address, and all VPN unicast SAFIs are following this. As RD does not make sense, zeroes are just added to fit the size of the address format. In reality, it is just an IP address with 0es padded before. Of course, it would have been cleaner to use only a regular IP address instead of a VPN-IP address but again that’s our legacy. The fact that some implementations are matching length of NLRI with length of next hop no where should be made equal that next hop has 8 octet dummy Route Distinguisher. [SLI] Again this is coming from legacy. If revision is to be made would be to explicitly negotiate capability to infer next hop encoding from the length. [SLI] Are you talking about a new capability or the existing ENH cap ? ENH tells you what is the NH AFI, so the only length check required is for the case of one or two IPv6 addresses. A new cap means a new solution, and that’s not the goal here. Point 2 - Addition of section 6.3 and SAFI 129 is fine, but again next hop encoding is lightly stating suboptimal. Conclusion: As we have discussed on and off line if revision is to be made let's make it both backwards compatible, Let's make it applicable to both IPv4 and IPv6 next hop addresses and let's allow explicit capability where implementations could indicate that it can recognize next hop value from its length. After all we are talking about just 4 discrete possible values here. [SLI] The goal is not to create something new here, but just to reflect how RFC5549 has been implemented for the SAFI 128/129 cases. The goal is also to minimize running code changes too (and even avoid !). We have to deal with what has been shipped and deployed by vendors today. We can still create something completely new, with a new cap and new procedures, but I think this is orthogonal to “aligning RFC5549 with implementations” as RFC5549 is there anyway and we can’t blindly forget it due to the codes that are available. Cheers, Robert. On Wed, Nov 27, 2019 at 1:36 PM Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com <mailto:matthew.bo...@nokia.com> > wrote: Hello, This email begins a two-weeks WG adoption poll for draft-litkowski-bess-rfc5549revision-00 [1] . Please review the draft and post any comments to the BESS working group list. We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The document won't progress without answers from all the authors and contributors. Currently, there are no IPR disclosures against this document. If you are not listed as an author or a contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. This poll for adoption closes on Wednesday 11th December 2019. Regards, Matthew [1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/ _______________________________________________ BESS mailing list BESS@ietf.org <mailto:BESS@ietf.org> https://www.ietf.org/mailman/listinfo/bess
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
