Re: [mpls] I-D Action: draft-ietf-mpls-mna-requirements-10.txt

Unless I have missed something in the discussions of the MNA use cases, I
cannot find any MNA use case in draft-ietf-mpls-mna-usecases that cannot be
addressed using the MNA ISD solution. Until there's a use case for MNA that
addresses a real problem in the eyes of a WG, a real problem, I consider
the discussion of "large amount of data in MNA" an interesting theoretical
exercise. AFAICS, the adopted ISD MNA solution, is extendable and capable
of coexisting with PSD MNA. And that is good enough for me for now. I think
the "MAY" for the support of PSD is reasonable, and I support it. At this
time, I don't see anything that justifies changing it to "SHOULD".

Regards,
Greg

On Sat, Mar 2, 2024 at 9:14 AM Tony Li <tony1athome@gmail.com> wrote:

>
> [WG chair hat: OFF]
>
> The encoding is straightforward:
> 22 octets = 176 bits
>
> If you start with a Format B LSE, then you get 13 bits in that and you
> need 6 LSEs for the rest.
>
> If you start with a Format C LSE, then you can embed 20 bits in that. You
> then need 6 additional LSEs for the data. This seems obvious.
>
> This seems trivial.
>
> A side concern is why one needs 22 octets of precision in your timestamps.
> Do you really gain something useful over a 4 octet NTP timestamp?
>
> T
>
>
>
> On Mar 2, 2024, at 1:27 AM, Stewart Bryant <stewart.bryant@gmail.com>
> wrote:
>
> 
>
> On 1 Mar 2024, at 06:43, loa@pi.nu wrote:
>
> Can you show me how to transport 22 octets of mutable data in the
> stack? I don't think 22 octets is unreasonable.
>
>
> I agree. Certainly when it takes 10 octets to encode a PTP timestamp, 20
> octets does not sound excessive.
>
> Stewart
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>