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>
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 <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
