Re: [Idr] CAR/CT merged document

[[e-mail]]

after a heavy chat on an other list let me give you some question marks i encountered during having this tiny step:

dear bgp-car team could you please help me better understand the intent here?

for example imho no way to keep the prefixes sorted properly because of the variable length nlri
encoding with the non-key fields... now which one would be the first in your imaginary sorting algorithm?
and why? how would that compareTwoPrefixes code would look alike on a non-fixed-length nlri?
1.1.1.1/32:red ?
1.1.1.1/32:red+label=123 ?
1.1.1.1/32:red+index=123 ?
1.1.1.1/32:red+srv6=1234::1 ?
and that latter 2, so for example we have a whole bgp attribute just for doing sr(v6) properly in bgp:
https://www.rfc-editor.org/rfc/rfc8669.html and it was you and you really have at least a decoder in your shows already!!!!
then why do you want it be there in the nlri once again!?

and after the merger, what is that additional intent type1/2 tlv thing? seemingly you want -car and -ct in the same afi or what? :)

and what's with the safeguard nlri-count field? seriously? you're clearly declared here that it's an n-p-hard nrli to have! just saying...

so my overall opinion is please stop killing bgp! "it hurts me doc when you're doing this"
and i had some other smaller question marks also during implementing -car...

sorry but i'm in the bad mood!

br,
cs




On 2/8/23 11:31, [e-mail] wrote:
> 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
>>
>> ([e-mail] <mailto:[e-mail]>)
>>
>> [If you have trouble responding to this email, you may use my professor email address:
>>
>> Dr. Susan Hares: [e-mail] <mailto:[e-mail]>. ]
>>