Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests

From: [email-masked] (Noel Chiappa)
Date: Tue, 22 Sep 2009 20:54:26 -0400 (EDT)

> From: Vince Fuller <[email-masked]>

    > the issue of UDP port 4341 being used for both control and data packets
    > ...
    > We have discovered through testing those imlementations that
    > Map-Request processing efficiency will be poor and that deployment on
    > an operational network will be problematic as long as UDP port 4341 is
    > used for both user data packets and Encapsulated Map Requests. The
    > changes that I described in my earlier message are intended to fix that
    > specific problem

>From what I've seen, nobody has a problem with that change. Maybe we should
focus on that for the moment, and get agreement on that, so that change can go
in -05 (or -06, I forget which one we're on now)?

I am happy with the change to stop using Data packets to encapsulate Control
packets

	Noel

---

From: Sam Hartman <[email-masked]>
Date: Tue, 22 Sep 2009 21:10:34 -0400

>>>>> "Noel" == Noel Chiappa <[email-masked]> writes:

    >> changes that I described in my earlier message are intended to fix that

    Noel> From what I've seen, nobody has a problem with that change. Maybe we should
    Noel> focus on that for the moment, and get agreement on that, so that change can go
    Noel> in -05 (or -06, I forget which one we're on now)?

I'd rather wait until we have a complete solution to #22.  I think it
is very problematic to implement half fixes.  

It makes it very easy for the editors to block changes they don't like
in a manner that makes the process much less open and fair.  It
removes a lot of the forcing functions for building consensus.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Sep 2009 21:16:04 -0700

> is very problematic to implement half fixes.

Man Sam, the solution of shared keys works really well. It is not a  
half solution.

Please, please, please let's be practical. A lot of security machinery  
doesn't have a proven track record over the last 20 years. We should  
learn from this and ask why this is the case.

> removes a lot of the forcing functions for building consensus.

It's not about like or dislike. It's about proving if we need it.  
Let's start somewhere simple first.

Dino

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Sam Hartman <[email-masked]>
Date: Wed, 23 Sep 2009 11:24:22 -0400

>>>>> "Dino" == Dino Farinacci <[email-masked]> writes:

    >>>> changes that I described in my earlier message are intended to fix
    Noel> From what I've seen, nobody has a problem with that change.
    >> Maybe we should
    Noel> focus on that for the moment, and get agreement on that, so
    >> that change can go
    >> is very problematic to implement half fixes.

    Dino> Man Sam, the solution of shared keys works really well. It is not a
    Dino> half solution.

    Dino> Please, please, please let's be practical. A lot of security machinery
    Dino> doesn't have a proven track record over the last 20 years. We should
    Dino> learn from this and ask why this is the case.

I've read your message several times, and I'll admit that I'm
completely puzzled how a comment I made about fixing map request
encapsulation has to do with shared keys, practical security machinary
or proven track records.

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 23 Sep 2009 08:42:55 -0700

I was mixing up threads because they have both been active. Sorry  
about that.

Dino