Stephane,
Sure you can send two NHs next to each other. But my main question is what
should the receiver of such "thing" do ? Which next hop is more important
to be actually used in forwarding ? Based on what elements such decision is
made ...
If you know some history and can share it here iI
Hi Robert,
There are implementations which set two NHs, here is a capture:
Update Message (2), length: 150
Multi-Protocol Reach NLRI (14), length: 100, Flags [O]:
AFI: IPv6 (2), SAFI: labeled VPN Unicast (128)
nexthop: RD: 0:0 (= 0.0.0.0), 2000::162RD: 0:0 (=
Hi all,
For L3VPN features, there are some differences:
Per RFC4634, the IPv4-VPN routes shall carry the V4 Next-hop, beginning with an
8-octet RD and ending with a 4-octet IPv4 address.
Per RFC4659, the IPv6-VPN routes shall carry the V6 Next-hop, beginning with an
8-octet RD and ending with
Hi Robert:
I was convinced. All of your points:
(1) No need to relax the check of nexthop as my previous suggestion.
(2) No need to update 5549/6515, and the nexthops defined in
section 3.1 to 3.4 are all right to me now.
(3) if we would be defining new SAFI we can write anything
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:
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
Please reject this erratum.
RFC6515 is mandatory to require 4/16 bytes nexthop, and mandatory to reject
12/24 bytes nexthop.
Thanks.
Jingrong.
-Original Message-
From: Vigoureux, Martin (Nokia - FR/Paris-Saclay)
[mailto:martin.vigour...@nokia.com]
Sent: Thursday, June 27, 2019 6:37
> Back to my suggestion: implementation should interpret nexthop RD+IPv4
and nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6
the same.
When elements of BGP UPDATE message are being parsed code must know what to
expect. Note that we are dealing here with deployed SAFI 128 for
Thanks for the RFC historical lessons.
--there was historically some assumption that next hop must be of the same AF
as prefix.
--RFC 2858 says that Next Hop field should match AFI. On the other hand, RFC
4760 says that Next Hop Field should match combination of AFI/SAFI.
--authors of RFC 4364
And just to self complete the last sentence ...
The same leading zeros were also added to SAFI 128 in the next hop field
as to match the length of RD:IP prefix of the L3VPN NLRI. Original 2547 or
subsequent 4364 did not define explicitly that the size of the next hop
could be inferred from the
10 matches
Mail list logo
