Rare project developers

hi,

rare/freerouter devvie here...
as we previously had a -ct implementation, this was the right moment to start 
playing with the -car draft...
please find attached the first successful bgp session with this afi, resulted 
in the following lfib table:

r1#show ipv4 bgp 1 car labels
prefix      local  evpn*16  pmsi*16  remote  hop
1.1.1.0/30  null   0        0        928424  1.1.1.2
1.1.1.4/30  null   0        0        928424  1.1.1.2
2.2.2.2/32  null   0        0        928424  1.1.1.2
2.2.2.3/32  null   0        0        450533  1.1.1.2
3.3.3.0/24  null   0        0        132324  1.1.1.2

r1#

this is the nlri part of packet #5 from the pcap showing the initial flood of 
the local prefixes
from r1 in 
https://github.com/rare-freertr/freeRtr/blob/master/cfg/rout-bgp695.tst:

0000   10 09 01 1e 01 01 01 00 00 00 00 00 01 03 aa 0e
0010   31 10 09 01 20 02 02 02 01 00 00 00 00 01 03 aa
0020   0e 31 0f 08 01 18 03 03 03 00 00 00 00 01 03 aa
0030   0e 31 0f 08 01 18 03 03 04 00 00 00 00 01 03 aa
0040   0e 31

from now, we'll track this common draft closely, so once you're done with 
your stacks, please ping us for an interop test! :)

br,
csaba mate


On 2/6/23 22:27, Susan Hares wrote:
> Greetings CAR Author Team and CT Author team:
>
> The operators have expressed their wish to the IDR chairs to have a single color/intent-based solution rather than two solutions (CAR or CT).   The operators in China have also 
> indicated their need for a solution that handles SRv6.
>
> The IDR chairs feel that a single proposed standard solution that adds 
> additional error handling to an adaption of the CAR format within the 
> multi-protocol format for AFI/SAFI:
>
>          0                                     1                              
>        2                                     3
>
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       | Address Family ID (AFI))           |       SAFI             |   NH 
> length       |
>
>       +---------------------------------------------------------------+
>
>       | Network address of the Next Hop                                       
>                     //
>
>       +---------------------------------------------------------------+
>
>       | Reserved (0)   | NLRI count       |   sequence of NLRIS               
>         |
>
>        +---------------------------------------------------------------+
>
> NLRI count     This is a count of NRLIs which follow.   This count improves 
> some of the error handling scenarios.
>
>       Where each NLRI has:
>
>         0                                     1                               
>       2                                     3
>
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       | NLRI Length     |   Key Length     |     NLRI Type     | Intent type  
>    |
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       | Intent length |     Intent (variable)                                 
>                   //
>
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       | Prefix Length |     IP Prefix (variable)                              
>                //
>
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>         Followed by optional TLVs encoded as below:
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       |         Type           |       Length         |       Value 
> (variable)                   //
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> NLRI count -
>
> Intent TLVs will be defined the working group.   Intents may be:
>
> 1)Color
>
> 2)RD     which is unique RD for intent.
>
> VPN Routing Distinguishers are included in the normal location in VPNs.     
> This also means that VPN SAFIs will identify the Prefix.
>
> A requirement of this merged solution will be the full support for SRv6.
>
> Our email conversations with the operators have indicated that this solution is acceptable as a proposed standard solution.   Since the operators have indicated the support for this 
> technical solution and a desire for a single solution, we are going to start a design team for    proposed standard    draft for Color/intent based on this solution.
>
> We would like a senior editor from the CAR author team and a senior editor from the CT author team to create this initial draft based on the above description.   The editors will be 
> expected to do the following things:
>
> 1.Discuss the merge on a Design-Team mail list,
>
> 2.Put the document in the IDR WG github,
>
> 3.Keep track of issues on the IDR WG github,
>
> 4.Create the merged draft by IETF-116,
>
> 5.Provide a progress report at IETF-116, and
>
> 6.Participate in an interim after IETF-116.
>
> Please propose one or more senior editors from your team.   The IDR chairs 
> will select from your candidates one senior author from the CAR team and one 
> senior author from the CT team.
>
> I have requested help from the IDR chairs (Jeff and Keyur) and the Spring Chairs (Bruno and Joel) to provide ongoing review for this document.   I will remain the shepherd for the 
> process.
>
> Cheers, Sue
>
> ( <>)
>
> [If you have trouble responding to this email, you may use my professor email 
> address:
>
> Dr. Susan Hares:  <>. ]

Attachment: zzz.pcap
Description: application/vnd.tcpdump.pcap