Hi Acce,
you are just not formulating your objections in the correct way. For
example, if specification said that Tag TLV must not exceed 64 Kb in
size that would technically put a bound but this would be both pointless
and wouldn't satisfy you.
Another part is why RI LSA is being singled out - why unbound data
in, say, Network LSA is OK and unbound data in RI LSA is not? Especially
given that RI LSA can be extended to the adjacent LSIDs and the Network
LSA cannot.
Tag data ARE expected to be very small and very stable, so the
choice of RI LSA to advertise them is very reasonable.
Anton
On 10/22/2013 10:05 PM, Acee Lindem wrote:
I don't disagree that the typical use case is a single tag with the
likelihood of mult-tag use cases diminishing exponentially as the
number of tags increases. My point is that unbounded TLVs MUST NOT be
included in the OSPF RI LSA. What part of that is hard to
understand? I think that 16 is a reasonable maximum and that beyond
16 would imply encoding ulterior information that should have its own
TLV or LSA anyway. Acee
On Oct 22, 2013, at 3:48 PM, Anton Smirnov wrote:
Hi Acee, it looks to me that the most probable deployment will use
1 tag. Router advertising 100 tags already sounds unreasonable.
Defining new LSID to originate LSA with (typically) only 4 bytes of
useful information is not optimal. Choice of RI LSA to advertise
some small data is reasonable. RI LSA is far from getting too big.
If there is a concern of RI LSA overfilling then we can extend
range of opaque IDs - but is it really necessary at this point?
Anton
On 10/21/2013 09:55 PM, Acee Lindem wrote:
I think we are in a circular argument here and I'm not discuss
this independently with each of the authors. Either you have to
limit the number of tags, define a new LSA, or do the work to
make RI LSA multi-instance. All are viable alternatives with
differing pros and cons - including it in the existing RI LSA is
not a viable alternative. Remember to request a session if you
plan to present it at IETF 88.
Thanks, Acee
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
