Stewart, all,

As Yihao pointed out, we are working on an update to the draft to focus the 
discussion on the communication scenarios and problems arising in those 
scenarios. In that sense, we agree with your desire for a holistic discussion 
and see this upcoming update as one of the next towards that.

With that in mind, I suggest that we continue the discussions after this 
upcoming update since it is not the intention at this stage to propose any 
solutions or constrain any thinking about solutions but to agree that problems 
may exist that will need to be addressed.

Best regards,

Dirk

From: Int-area [mailto:[email protected]] On Behalf Of Stewart Bryant
Sent: 05 February 2021 15:59
To: Jiayihao <[email protected]>
Cc: Lin Han <[email protected]>; 
[email protected]; int-area <[email protected]>; 
[email protected]; [email protected]; 
[email protected]
Subject: Re: [Int-area] The small address use case in FlexIP




On 5 Feb 2021, at 12:06, Jiayihao 
<[email protected]<mailto:[email protected]>> wrote:

- Indeed, the network scale of limited domain is supposed to be less that IPv6, 
but it doesn't mean the address space should be strictly less than 128-bit. If 
the space of the address is abundant enough, the public key could be embedded 
without truncation (compare to CGA in IPv6) for certain security purpose.

Interesting, what are the advantages in adding the signature of the address in 
the address as opposed to carrying it in a different field?

The disadvantage is that you bind the address to the signature algorithm which 
you would not want to do since you would expect to change the signature 
algorithm during the lifetime of the protocol.

Also would you really want to feed the signature into the longest match engine? 
Of course you could and there are some advantages in that you look up both the 
address and it signature, but I think you loose longest match capability and 
you significantly increase the size of the TCAM or other FIB design memory, and 
that memory is very expensive as it determines the line rate of the forwarder.

So this points back to the need for a holistic discussion of what we are trying 
to achieve, the extent to which modifying existing protocols satisfies that 
need, and whether (given the presupposed need for a gateway) we should be 
looking for a single protocol, a family of protocols, or an adaptable protocol.

I don’t think we can design the addressing system in the absence of a 
discussion on those points.

Best regards

Stewart


_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to