Unfortunately I don’t have the history, we discovered this behavior when doing
some VPNv6 testings a couple of months ago between IOS and Junos. IOS XE does
advertise two nexthops.
From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Friday, June 28, 2019 11:11
To: LITKOWSKI Stephane OBS/OINIS
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
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
since we are discussing that topic,
maybe the WG would like to reach a conclusion on how to treat that erratum:
http://www.rfc-editor.org/errata/eid5738
Thanks
-m
Le 2019-06-27 à 11:15, Xiejingrong a écrit :
> Thanks for the RFC historical lessons.
>
> --there was historically some assumption
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
Hi Robert,
Sorry, I was not so precise :-) Of course, RD part in Next Hop is not copied
from RD of NLRI, but zeroed. I was trying to explain why Next Hop field in RFC
4364 and RFC 4659 has format RD:IP (VPNvX address) rather than just IP.
Thank you!
> 26 июня 2019 г., в 16:27, Robert Raszuk
Hi Alex,
> My understanding is follow: RD is encoded in Next Hop field
That is subtle misinterpretation of the 4364 :)
The text says:
"When a PE router distributes a VPN-IPv4 route via BGP, it uses its own
address as the "BGP next hop". This address is encoded as a VPN-IPv4
address with an
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
Hi,
My understanding is follow: RD is encoded in Next Hop field, because authors of
RFC 4364, while referring to RFC 2858, were trying to make it consistent with
RFC 4760 (obsoletes RFC 2858). RFC 2858 says that Next Hop field should match
AFI. On the other hand, RFC 4760 says that Next Hop
+1
From: Idr On Behalf Of Robert Raszuk
Sent: Wednesday, June 26, 2019 7:53 AM
To: Xiejingrong
Cc: i...@ietf.org; ian.far...@telekom.de; ianfar...@gmx.com;
softwi...@ietf.org; bess@ietf.org
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address
coding for IPv4 VPN over
14 matches
Mail list logo
