I agree and sometimes flexibility becomes an unwanted necessity (as is the case
here with option (a)).
IMO, option (b) length based check for NH should be preferred, since it works
for all AFI/SAFIs with an assumption that NH could be one IPv4 or IPv6 prefix.
Very reasonable option.
Option (a
Hi all,
Can the WG reach a conclusion on how to treat that erratum related to RFC5549:
https://www.rfc-editor.org/errata/eid5253
Thanks,
Shunwan
-Original Message-
From: Softwires [mailto:softwires-boun...@ietf.org] On Behalf Of Vigoureux,
Martin (Nokia - FR/Paris-Saclay)
Sent: Thursda
My vote - Reject.
Justification:
Irrespective if we would reject or accept the erratum implementations must
be able to handle 10 years old RFC so must be able to properly recognize
the next hop to be either of length 16 or 24. (I am putting aside the 32/48
invention).
So that means that next hop
Hi,
(co-chair hat off)
I also vote to reject this erratum on the following grounds: The erratum text
was raised as:
Section 6.2 says:
Length of Next Hop Network Address = 16 (or 32)
It should say:
Length of Next Hop Network Address = 24 (or 48)
Notes:
The lengths should include the RD length al
...@ietf.org
Subject: Re: [bess] [Softwires] [Idr] Regarding the Next Hop Network Address
coding for IPv4 VPN over IPv6 Core in RFC5549
I agree and sometimes flexibility becomes an unwanted necessity (as is the case
here with option (a)).
IMO, option (b) length based check for NH should be preferred
