Re: Notification to list from IETF Moderators team

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Let me chime in, as IPv6 and DNS are in 'my' current area (INT), on two points.

The former, as written by others, the use of 'garbage' may be perceived as offensive by some cultures. Like you (assumption of mine), English is not my primary language, and my only culture is Western Europe, i.e., I would not be shocked by the use of 'garbage', but would consider the whole sentence as emotional rather than factual, i.e., diminishing the impact of the sentence.

The latter, claiming that a protocol is not perfect without facts/explanations is rather useless on an IETF mailing list.

But, hey, we are all human beings who keep learning day after day ;-)

Best regards

-éric


On 12/10/2022, 15:13, "ietf on behalf of Masataka Ohta" <ietf-bounces@xxxxxxxx on behalf of mohta@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

    Keith Moore wrote:

    >> : IPv6 with unnecessarily lengthy 16B addresses without valid
    >> : technical reasoning only to make network operations prohibitively
    >> : painful is a garbage protocol.
    >> :
    >> : LISP, which perform ID to locator mapping, which is best
    >> : performed by DNS, in a lot less scalable way than DNS
    >> : is a garbage protocol.
    > 
    > Perhaps your feedback would be more generally useful if you described, 
    > in technical terms, why you believe DNS is a better ID-to-locator 
    > mapping than LISP is.

    You should have asked so in 2019.

    Anyway, with my reconfirmation in 2021, there was discussion on IPv6
    which, I believe, concluded that using MAC address as part of IP
    address is layer violation because MAC address length affect
    IP address format.

    But, in 2021, seemingly, no one was serious for LISP.

    > (I personally see a lot of technical problems with using DNS as an 
    > ID-to-locator mapping protocol, due to lack of speed, security, and 
    > reliability if not very robustly provisioned.

    As for speed, it's IP mobility which should be responsible for
    it. For security, I will post another message for a separate
    thread.

     > I'm not even convinced
     > that an ID/locator separation is desirable.

    Destination locator rewriting, for example, is useful for IP
    mobility forwarding to avoid IP over IP tunneling, that is, not
    to reduce MTU by rewriting home locator to foreign locator.

    Anyway, such rewriting is not possible with LISP where transport
    checksum (knowledge of which is unavailable at IP layer) is
    invalidated by the rewriting.

    						Masataka Ohta






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux