Hi Mo, et.al.,

So far my understanding was, that we do not require rfc8950-compliant for the Internet Peering use-case. That's why I omitted it in https://github.com/euro-ix/rfc8950-ixp/blob/main/examples/Juniper_JunOS.md
Comparing RFC5549 and RFC8950 suggests that next-hop encoding is only different in VPN-IPv4 use cases (SAFI 128/129). So maybe we rather need a warning not to enabe this on older JunOS versions?

Reading https://community.juniper.net/blogs/krzysztof-szarkowicz/2022/08/11/l3vpn-over-srv6 indicates some relationship to VPN use cases, but is not 100% clear:
Junos by default uses pre-standard (based on preliminary IETF draft before RFC 8950 was published) encoding scheme for IPv6 next hops for IPv4 address families. Therefore, if you omit ‘rfc8950-compliant’ keyword, the setup will work between Juniper routers, but with high probability will fail between Juniper and 3rd party routers.

Maybe you can forward this "question" to the Juniper SE?

Really helpful information:
I'll add this to the example doc.

Thanks,
André


On Tue, 17 Oct 2023 at 15:10, Moyaze Shivji <moyaze@linx.net> wrote:

 

Hi Guys

 

As agreed I would share what the LINX’s Juniper SE shared with me with regards to RFC8950.

 

Hope this is useful info.

 

Mo

 

 

 

 

Hi Mo,

Hope you’re well.
We support RFC5549 (predecessor to RFC8950) on MX since 17.3R1. Other platforms like QFX had support added later as per below:
https://apps.juniper.net/feature-explorer/feature-info.html?fKey=7931&fn=Redistribution+of+IPv4+routes+over+IPv6+routes+into+BGP+through+tunnels+%28RFC+5549%29

Below are some PRs that affected RFC8950 compliance:
PR1649332 : RFC 8950 Extended Nexthop Encoding Capability conformance issue
PR1716946 : BGP connection doesn't establish when it is configured with rfc8950-compliant under logical-systems on all Junos and Junos OS Evolved platforms


From the last PR, the fixes are available in:

22.4R2

22.4R3

23.1R2

23.2R1

23.3R1

Reference documentation:
https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic-map/multiprotocol-bgp.html#id-understanding-redistribution-of-ipv4-routes-with-ipv6-next-hop-into-bgp
For point to point BGP peering, the dynamic tunnels described in above doc are not required.

I tested on 23.1R2 and below is my simple topology and sample config:

 

LAN01(2.2.2.0/24) ------- ge-0/0/2 - R1 (AS65001) - ge-0/0/1---- v6 Peering ---- ge-0/0/1 R2 (AS65002) ge-0/0/2 ------- LAN02 (1.1.1.0/24)

 

root> show configuration protocols bgp

group TEST {

    type external;

    local-address 2001:db8::2;

    family inet {

        unicast {

            extended-nexthop;

        }

    }

    export EXPORT-BGP;

    peer-as 65001;

    neighbor 2001:db8::1;

}

rfc8950-compliant;

 

root> show configuration interfaces ge-0/0/1

unit 0 {

    family inet;

    family inet6 {

        address 2001:db8::2/64;

    }

}


root> show route table inet.0 1.1.1.0/24

 

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

1.1.1.0/24         *[BGP/170] 14:18:30, localpref 100

                      AS path: 65001 I, validation-state: unverified

                    >  to 2001:db8::1 via ge-0/0/1.0

 

 

Please let me know if you would like to have a quick call to go through.


Kind Regards,
Ashvin

 

 

Juniper Business Use Only

 

_______________________________________________
Rfc8950 mailing list -- rfc8950@lists.euro-ix.net
To unsubscribe send an email to rfc8950-leave@lists.euro-ix.net


--
André Grüneberg, Managing Director
andre.grueneberg@bcix.de
+49 30 2332195 42

BCIX Management GmbH
Albrechtstr. 110
12103 Berlin
Germany

Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg
Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B