On Nov 2, 2011, at 23:23 , Templin, Fred L wrote:
Thankfully, I missed most of the earlier threads related
to this. But, on the subject of identifiers, Robin is right.
What the IETF protocol known as LISP calls identifiers are
actually IP addresses. And, IP addresses name *interfaces*;
they
Ralph,
This document calls for the assignment of a new HIP Packet Type from the HIP
Packet Type registry,
http://www.iana.org/assignments/hip-parameters/hip-parameters.xml Assignment of
HIP Packet Types requires IETF consensus. The purpose of this last call is to
assess IETF consensus for
From: Robin Whittle r...@firstpr.com.au
The LISP protocol does not introduce a new namespace for
Identifiers (for hosts, interfaces or whatever).
The long-term concept is that it needs to be a phased introduction:
initially, IPvN addresses are used on both sides of the mapping in
Hi Jari,
thanks for your input. We will discuss this issue in the context of all
the HIP bis specs within the HIP WG.
Cheers,
Gonzalo
On 03/11/2011 1:29 PM, Jari Arkko wrote:
Ralph,
This document calls for the assignment of a new HIP Packet Type from the HIP
Packet Type registry,
Noel and others,
Let's say we have an end system with as many ISP
connections as you like - each with its own locator
address. Let's say the end system also has multiple
loopback interfaces - say it has two, for example.
The end system connects to a first VPN and receives
the endpoint address
From: Templin, Fred L fred.l.temp...@boeing.com
Let's say the end system also has multiple loopback interfaces - say it
has two, for example.
Why? What does that buy you?
Which one (A or B) is the end system's identity?
Suppose I assign two endpoint identifiers to a host.
Noel,
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On
Behalf Of Noel Chiappa
Sent: Thursday, November 03, 2011 7:08 AM
To: ietf@ietf.org
Cc: j...@mercury.lcs.mit.edu
Subject: RE: LISP is not a Loc-ID Separation protocol
From: Templin, Fred
From: Templin, Fred L fred.l.temp...@boeing.com
one to one correspondence with the end system's multiple VPN
connections. The internal virtual interfaces keep the VPNs separate.
As logically separate sources for incoming/outbound packets, they are just
like multiple real
Hi Noel,
-Original Message-
From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu]
Sent: Thursday, November 03, 2011 7:43 AM
To: ietf@ietf.org
Cc: j...@mercury.lcs.mit.edu
Subject: RE: LISP is not a Loc-ID Separation protocol
From: Templin, Fred L fred.l.temp...@boeing.com
From: Templin, Fred L fred.l.temp...@boeing.com
No; not multiple identities. One identity; multiple interfaces and
multiple addresses.
But to the network, a thing with multiple identity names (no matter what the
exact namespace the names come from) looks like multiple things -
Dear Jari,
Am 03.11.2011 um 12:29 schrieb Jari Arkko:
Ralph,
This document calls for the assignment of a new HIP Packet Type from the HIP
Packet Type registry,
http://www.iana.org/assignments/hip-parameters/hip-parameters.xml Assignment
of HIP Packet Types requires IETF consensus. The
Hi Noel,
But I must confess I'm kind of confused as to why any of this
matters? I
mean, it's fun philosophical debate (well, for some people, I
guess :-), but
so what?
It just circles back again to the fact that what LISP
calls EID is something that names an interface; not
an end system.
From: Templin, Fred L fred.l.temp...@boeing.com
It just circles back again to the fact that what LISP calls EID is
something that names an interface; not an end system.
And I keep pointing out that an LEID which is assigned to a virtual interface,
one which is created _solely_ as
Hi Noel,
-Original Message-
From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu]
Sent: Thursday, November 03, 2011 8:28 AM
To: ietf@ietf.org
Cc: j...@mercury.lcs.mit.edu
Subject: RE: LISP is not a Loc-ID Separation protocol
From: Templin, Fred L fred.l.temp...@boeing.com
From: Templin, Fred L fred.l.temp...@boeing.com
.. an LEID which is assigned to a virtual interface, one which is created
_solely_ as a place to hold the system's identity ..
...
.. a name which i) is purely identity, ii) has no location info of
any kind in it, iii)
Short version: If Noel's statements:
http://www.ietf.org/mail-archive/web/ietf/current/msg70356.html
reflect the position of most LISP protocol developers
and if I have understood him correctly then we are all
agreed that the LISP
Noel,
-Original Message-
From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu]
Sent: Thursday, November 03, 2011 8:40 AM
To: ietf@ietf.org
Cc: j...@mercury.lcs.mit.edu
Subject: RE: LISP is not a Loc-ID Separation protocol
From: Templin, Fred L fred.l.temp...@boeing.com
15 30
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
I read it If you don't play nice .. we're going to make you. You are
going to eat your Broccoli and like it and no whining ..
From: George Willingmyre [mailto:g...@gtwassociates.com]
Sent: Wednesday, November 02, 2011 11:01 PM
To: Richard Shockey; 'IETF-Discussion list'
Subject: Re: The
Richard Shockey rich...@shockey.us wrote:
From: George Willingmyre [mailto:g...@gtwassociates.com]
I do not know what is the meaning of the sentence,
we expect all carriers to negotiate in good faith in response to requests
for IP-to-IP interconnection for the exchange of voice traffic.
Richard Shockey rich...@shockey.us wrote:
From: George Willingmyre [mailto:g...@gtwassociates.com]
I do not know what is the meaning of the sentence,
we expect all carriers to negotiate in good faith in response to
requests
for IP-to-IP interconnection for the exchange of voice traffic.
Richard Shockey wrote:
IMHO, they're talking obligation to interconnect between
carriers as required by actual law.
Please forgive a probably naive question;
Does this mean that a carrier that recently jumped in the voice market
(it could be either an ISP now providing VOIP to their customers
Total of 202 messages in the last 7 days.
script run at: Fri Nov 4 00:53:02 EDT 2011
Messages | Bytes| Who
+--++--+
7.43% | 15 | 8.86% | 132533 | r...@firstpr.com.au
4.46% |9 | 3.85% |57623 |
The IESG has received a request from the SIP for Instant Messaging and
Presence Leveraging Extensions WG (simple) to consider the following
document:
- 'Connection Establishment for Media Anchoring (CEMA) for the Message
Session Relay Protocol (MSRP)'
draft-ietf-simple-msrp-cema-03.txt as a
82nd IETF Meeting
Taipei, Taiwan
November 13-18, 2011
Host: Taiwan Network Information Center (TWNIC)
Host Website: http://ietf82.tw/
Meeting venue: Taipei International Convention Center (TICC)
http://www.ticc.com.tw/index_en.aspx
Register online at:
25 matches
Mail list logo
