Hi, I am not that naive to think that you can do something else here ;)
But can you at least send a pointer to formal implementation report before proceeding ? Thx a lot, R. On Tue, Dec 3, 2019, 13:17 Acee Lindem (acee) <a...@cisco.com> wrote: > Hi Robert, > > My point is that your proposal to save the 8 bytes of RD can be > independent of correcting RFC 5449. It is pretty much a no-brainer that > revising the specification to match the de facto standard of all extant > implementations is preferable to a non-trivial upgrade and migration. > > > > Anyway, I don’t wish to engage in a protracted debate and I don’t believe > the WG wishes to delay publication of this draft. Your lone objection can > be noted in the shepherds report. > > > > Thanks, > Acee > > > > > > *From: *Robert Raszuk <rob...@raszuk.net> > *Date: *Monday, December 2, 2019 at 6:37 PM > *To: *Acee Lindem <a...@cisco.com> > *Cc: *"slitkows.i...@gmail.com" <slitkows.i...@gmail.com>, "Bocci, > Matthew (Nokia - GB)" <matthew.bo...@nokia.com>, "bess-cha...@ietf.org" < > bess-cha...@ietf.org>, "bess@ietf.org" <bess@ietf.org> > *Subject: *Re: [bess] WG Adoption and IPR Poll for > draft-litkowski-bess-rfc5549revision-00 > > > > Hi Acee, > > > > Please observe that this draft defines encoding for SAFI 129 with IPv6 as > next hop. > > > > If we are prepend it with zero pls do not forget to also submit the errata > to RFC 6514 which says > > clearly in section 9.2.3.2 that next hop *field* must be set to a routable > IP address. Not part of the > > Next Hop field but the entire *field*. > > > > When re-advertising an Inter-AS I-PMSI A-D route, the ASBR MUST set > > the Next Hop field of the MP_REACH_NLRI attribute to a routable IP > > address of the ASBR. > > > > And the above is just the tip of the iceberg :) > > > > Bottom line is that instead of publishing the spec which in backwards > compatible fashion allows > > gradually to fix the implementation errors of the past it is just blessing > them. And we all agree > > that pushing to each MP_REACH NH field 64 zeros is completely unnecessary.. > Not a good thing > > in my measures. > > > > Best, > > R. > > > > PS. And what happens if those 8 octets is not zeros but zero and ones ? > Should it be accepted and > > ignored or is this an invalid attribute ? > > > > > > > > On Mon, Dec 2, 2019 at 11:21 PM Acee Lindem (acee) <a...@cisco.com> wrote: > > Robert, > > > > What you’re suggesting doesn’t really solve the problem that all the > currently deployed routers that do not follow RFC 5549. No known > implementations follow RFC 5549. Were you on the meetecho when this was > presented in the BESS meeting at IETF 106? There was clear consensus in the > meeting. > > > > Anyway, you can put your ideas in a new draft and let them stand on their > own merit. That way, if there were consensus, we could save those 8 bytes > of RD. However, we shouldn’t mix this with the draft revising RFC 5549 to > reflect the current implementations and deployments. > > > > Thanks, > > Acee > > > > *From: *BESS <bess-boun...@ietf.org> on behalf of Robert Raszuk < > rob...@raszuk.net> > *Date: *Thursday, November 28, 2019 at 11:58 AM > *To: *"slitkows.i...@gmail.com" <slitkows.i...@gmail.com> > *Cc: *"Bocci, Matthew (Nokia - GB)" <matthew.bo...@nokia.com>, " > bess-cha...@ietf.org" <bess-cha...@ietf.org>, "bess@ietf.org" < > bess@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> wrote: > > Hi Robert, > > > > Please see some replies inline. > > > > Brgds, > > > > *From:* Robert Raszuk <rob...@raszuk.net> > *Sent:* mercredi 27 novembre 2019 22:18 > *To:* Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com > <matthew..bo...@nokia.com>> > *Cc:* bess@ietf.org; 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> 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/ > <https://datatracker.ietf..org/doc/draft-litkowski-bess-rfc5549revision/> > > > > > > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
