The normal situation is that an EID block is delegated to an
administrative authority (a company). They use it.
They may use the main block, and use some sub-blocks. That produces
"holes" which are overlapping prefixes. The handling of that is
described in the document. The ETRs which are re
Maybe I am missing something, but these two look like changes to the
spec which will improve interoperability, and are easily done.
Is there a good reason not to add the clarifications that are requested
here?
Yours,
Joel
On 6/22/2011 6:32 PM, Alia Atlas wrote:
i) For instance, if an ETR re
Since we have said repeatedly we waat this to work, it should be stated.
If it is already stated, I apologize but I can not find it. The
section you quoted from the ToC doesn't.
Yours,
Joel
On 6/22/2011 6:32 PM, Alia Atlas wrote:
f) Sec 5: There is no indication in the packet formats that I
I don't think your paraphrase quite captures it.
In the abstract theory, the bit string represented by A could be an EID
for one device and an RLOC for a different device.
As the architecture is realized, if a given bit string is both an RLOC
and an EID, it must refer to the same entity in both
or such a draft?
Alia
On Wed, Jun 22, 2011 at 6:49 PM, Joel M. Halpern wrote:
The normal situation is that an EID block is delegated to an administrative
authority (a company). They use it.
They may use the main block, and use some sub-blocks. That produces "holes"
which are o
example, if a sub-block is used for something with very fine
grain RLOCs.)
So I am still missing what needs to be specified.
The text says taht the ETR needs to know about all sub-blocks.
Yours,
Joel
On 6/23/2011 4:24 PM, Alia Atlas wrote:
On Thu, Jun 23, 2011 at 3:46 PM, Joel M. Halpern
I believe Alia is correct about this.
Unless I have missed something, there is no way for an ITR receiving
nested prefixes to tell the difference between the case (described in
the base LISP spec) when the longer prefix MUST be used, and cases of
traffic engineering where it is only a matter o
If I am reading the text Alia qutoed below correctly, the text assumes
that an ETR will do something different with a map reply based on the
whether it thinks the source address is an EID.
I think this is basically indeterimnable.
More importantly, that would be an ETR behavior, which the ALT s
If I am reading this exchange properly, Dino, you are saying you do not
want LISP ITRs to follow the general router advice from RFC 4443.
Is this a matter of taste?
Is there a technical difference that should be stated why different
behavior may be appropriate?
Yours,
Joel
On 6/27/2011 12:26
There appear to be two related technical issues here.
The first one is on refreshing entries. A refresh of a less-specific
with overlapping more-specifics will inherently provide refresh of the
more-specifics. Even if an implementor does not realize that, he will
do the right thing. We can
Just to clarify what you are asking Ron,
would you like the text to say "SHOULD send an ICMP"?
And in which places would you like it to say that?
Thanks,
Joel
On 6/27/2011 12:23 PM, Ronald Bonica wrote:
Dino,
Maybe I am misreading you, but your response to me seems to contradict your response
as their outer header
destination addresses."
Yours,
Joel
On 6/28/2011 2:47 PM, Vince Fuller wrote:
On Fri, Jun 24, 2011 at 02:28:35PM -0400, Joel M. Halpern wrote:
If I am reading the text Alia qutoed below correctly, the text assumes
that an ETR will do something different with a ma
Thanks. Joel
On 6/28/2011 3:02 PM, Vince Fuller wrote:
On Tue, Jun 28, 2011 at 02:55:16PM -0400, Joel M. Halpern wrote:
Unless we are prepared to modify the base LISP spec ETR behavior, I
would remove everything from "Note" to the end of of the quoted
paragraph from section 3.
Original Message
Subject: Nomcom 2011-2012: Third Call for Volunteers
Date: Mon, 4 Jul 2011 08:47:17 -0700 (PDT)
From: NomCom Chair
To: IETF Announcement list
CC: i...@ietf.org
This is the Third call for Volunteers for the 2011-12 Nomcom. We are
almost through the voluntee
I may be missing something. Maybe something imp0ortant. But pretneding
for the moment that I understand this discussion...
Fundamentally, if a subscriber DoS' himself, and denies himself service,
then he hurts himself. So?
Now, there do need to be ways that this is prevented from hurting t
see what paths they see as worth investigating.
Yours,
Joel
On 7/18/2011 4:36 PM, Noel Chiappa wrote:
> From: "Joel M. Halpern"
> Fundamentally, if a subscriber DoS' himself, and denies himself
> service, then he hurts himself. So?
The issue is th
lude the caveat.
Ron
-Original Message-----
From: Joel M. Halpern [mailto:j...@joelhalpern.com]
Sent: Wednesday, July 20, 2011 1:56 PM
To: Ronald Bonica
Cc: Noel Chiappa; j...@inconcepts.biz; lisp@ietf.org
Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why
is IPv6 b
(Terry, I believe you saw this, copying the WG for everyone's information.)
This Genart review makes an interesting point. I would like to hear
from the authors as to whether they agree.
Yours,
Joel M. Halpern
Original Message
Subject: [Gen-art] Gen-ART LC review of
Please help by nominating folks (yourself, or other people you beleive
can do the job well.)
Thank you,
Joel
Original Message
Subject: Nomcom 2011-2012: Second Call for Nominations
Date: Sat, 17 Sep 2011 19:05:38 -0700 (PDT)
From: NomCom Chair
To: IETF Announcement list
CC:
I believe his point is that
1) We have a bunch of efforts to prevent spoofed source IP addresses
(RLOCs) in the net today. No tehy don't work perfectly, but we are
working on improving them. Assume for discussion they work.
2) In the pwesence of LISP, under a variety of circumstances, it is
p
Fred, "Authorized" is I think the wrong word to use to describe the
publication. Or at least a misleading word. The IRTF process is such
that the RG did not actually approve the publication of any of the
solutions. The RG Chair sponsored the publication as an output of the
RG. IRTF procedur
Original Message
Subject: Nomcom 2011-2012: Call for community feedback
Date: Tue, 11 Oct 2011 14:04:22 -0700 (PDT)
From: NomCom Chair
To: IETF Announcement list
CC: i...@ietf.org
As per RFC 5680, NomCom 2011-2012 is issuing a call to the entire IETF
community for feedback o
I have been exchanging notes with Adrian about his request for a
disclaimer on the Mapping Service document.
I believe we have agreed on text which is appropriate.
THere is one implication on the text below. We will have to make sure
we put appropriate warnings in the LISP base spec. But I be
Ari, on what basis did you come to the conclusion below.
The goal (putting aside transition) is not that EIDs will come from 1918
space, but that we will be able to remove the EID blocks (and their
dis-aggregations) from the global routing table.
The use of the EID as the destination is within
The problem I have with that view is that although it is accurate, it is
also bascially not explained.
For charter reasons, we left out any explanation of the private spaces,
other than putting in the hook for instance-ID.
So, yes, as long as all of the users of a given mapping system and given
Dino, are any of these ones we asked you to move around earlier for some
reason? (I want to try to avoid saying A, no B, no A...)
Assuming these were not previously moved for some reason, I am happy
with most of Jari's suggests.
I do think referencing the registry for AFIs is the right thing
Given that, as far as I can tell, failing to perform the source checks
leaves the site using the weak ETR at risk, but does not harm anyone else,
and given that this is experimental,
it seems sufficient to leave the text the way it is.
Yours,
Joel
On 10/27/2011 1:04 PM, Dino Farinacci wrote:
O
I am a bit concerned that the description of the cases does not work.
In particular, if I am reading the text (preserved below) properly, it
says that the ITR can use the presence of a covering prefix in the
regular BGP table to tell that a destination is a non-LISP destination.
But in order for
Removing option 1 would solve my concern very nicely. Thanks.
Joel
On 2/3/2012 3:10 PM, Darrel Lewis wrote:
On Feb 3, 2012, at 10:35 AM, Joel M. Halpern wrote:
I am a bit concerned that the description of the cases does not work.
In particular, if I am reading the text (preserved below
This item is included in the proposed recharter of the WG.
I hope to see it produced, and a prefix assigned, in a timely fashion.
Yours,
joel
On 2/7/2012 2:37 PM, Roger Jørgensen wrote:
Is this draft to be considered dead in the water or are there still
thought going into it?
We were a few that
If I may separate issues for a moment,
the absence of milestones is because Terry and I have to come up with a
proposal for them which matche sthe revised goals.
If you read the rest of the differences, you will see that the general
question of what LISP is aimed at providing is indeed still t
The preliminary agenda for the Paris meeting has been announced.
We have been given a 1.5 hour slot on Tuesday afternoon from 3:20 pm til
5pm.
The details as provided to the WG chairs are below.
yours,
Joel
Original Message
Subject: lisp - Requested session has been scheduled
I would like to call the working groups attention to an important
achievement.
Thanks to the tremendous efforts of the authors, with the approval by
the IESG of draft-ietf-lisp-ms-16, all 7 LISP documents which we sent to
the IESG have now been approved for publication as RFCs.
Thank you,
Joel
Actually John, I would have to disagree with your assertion about what
it takes to describe the archtiecture.
It may take engineering and evaluating some cache management schemes
before one can decide whether the archtiecture is a good one. But that
is very different from being able to describe
management quesiton is made significantly
easier by having a clean architecture description.
Yours,
Joel
On 3/14/2012 10:40 AM, John Scudder wrote:
One further remark:
On Mar 13, 2012, at 3:04 PM, Joel M. Halpern wrote:
...
It may take engineering and evaluating some cache management schemes
The nomcom process is critical for the proper function of the IETF.
Please volunteer if you are eligible.
Thank you,
Joel
Original Message
Subject: NomCom 2012-13 Call for Volunteers
Date: Fri, 06 Jul 2012 14:15:33 -0700
From: NomCom Chair
To: IETF Announcement List
The I
Which charter item does that fall under?
Thank you,
Joel
On 7/11/2012 9:46 PM, cheng@zte.com.cn wrote:
Hello,
If time is available, may I have a 10min slot for "LISP Single-Hop DHT
Mapping Overlay"?
thank you,
Li Cheng
internet-dra...@ietf.org 写于 2012-07-09 15:24:49:
>
> A new vers
If you are eligible, are not looking for appointment, and have not yet
volunteered, please do so. The nomcom is important for the viability of
the IETF.
Thank you,
Joel
Original Message
Subject: NomCom 2012-2013: Second Call for Volunteers
Date: Tue, 24 Jul 2012 13:06:04 -0
Sorry to belabour the obvious, but the community really needs folks to
volunteer.
Thanks,
Joel
Original Message
Subject: NomCom 2012-2013: Third Call for Volunteers
Date: Mon, 30 Jul 2012 21:44:25 -0700
From: NomCom Chair
To: IETF Announcement List
The NomCom 2012-2013 Cal
Please help the community.
Thank you,
Joel
Original Message
Subject: Help the NomCom: Nominations and Feedback
Date: Wed, 05 Sep 2012 17:21:29 -0700
From: NomCom Chair
To: Working Group Chairs
The IETF Nominations Committee (NomCom) is currently seeking
nominations for indiv
The definition of how to actually perform such forwarding would have to
be done in (or in close collaboration with) the L2VPN WG. This document
does not define how that is done. It reserves a code point for
identifying the specific kind of information, if someone does want to do it.
I have s
draft-chiappa-lisp-introduction and draft-chiappa-lisp-architecture have
been adopted as working group documents.
While they will eventually be named draft-ietf-lisp..., there is no
reason to wait on that for discussion, review, comment, etc...
Particularly, it would be very helpful if folks se
Sorry, the references are going to have to be reorganized.
Even for an Informational document (which this is and should be), there
are normative references and informative references.
The distinction is based on whether the reference needs to be understood
in order to understand this document.
These are the documents we reference in the approved LISP docs.
Yours,
Joel
Original Message
Subject: Document status
Date: Fri, 14 Sep 2012 09:08:30 +0200
From: Ole Trøan
To: i...@ietf.org 6man
all,
fyi: the chairs have just requested the IESG to publish:
draft-ietf-6ma
adopt this document as a WG document.
Yours,
Joel M. Halpern
PS: Let me use this opportunity to note that final publication of this
will be blocked by WG completion of several of our other documents. The
chairs are looking for WG discussion of the documents to address the
first 4 milestones in o
having the
working group decide if it wants to accept the RIG document.
Yours,
Joel M. Halpern
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
Sorry, that sentence is "once the blocking documents are dealt with
there should be no problem with ..."
Yours,
Joel
On 10/11/2012 12:02 PM, Dino Farinacci wrote:
As for the bit of good news, we did conclude that one the blocking
documents are dealt with, there should be n problem with having t
As a general comment from a chair, a document which references LISP does
not need to be done in he LISP WG. (Telling us about it is
appreciated.) A document which defines how to use LISP to do something
needs to be coordinated with the LISP WG.
Yours,
Joel
On 10/21/2012 10:13 AM, Luigi Iann
If I understood, you expressed disagreement with the general description
of LISP security.
Can you suggest what approach you would like to see taken?
Thank you,
Joel
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
I had not gotten that distinction from your earlier note.
Yours,
Joel
On 10/23/2012 5:50 PM, Damien Saucez wrote:
On 23 Oct 2012, at 23:29, "Joel M. Halpern" wrote:
If I understood, you expressed disagreement with the general description of
LISP security.
Can you suggest what ap
Please provide input to help the nomcom.
Thank you,
Joel
Original Message
Subject: Help the NomCom: Community Feedback
Date: Wed, 31 Oct 2012 20:13:18 -0700
From: NomCom Chair
To: Working Group Chairs
The IETF Nominations Committee (NomCom) continues to seek input from
the I
Correction to the deadline for feedback.
Yours,
Joel
Original Message
Subject: Re: [85all] NomCom: Office Hours in Atlanta
Date: Thu, 1 Nov 2012 08:22:48 -0400
From: Matthew Lepinski
To: 85...@ietf.org
I apologize for a minor error in the message below.
In order to ensure th
Whatever else is going on, LISP EIDs do not have geographic
significance. They do not have IP Routing topological significance.
The are not aggregateable.
They are intended to beused by a site as a single prefix. Hence, the
desired behavior (within the /16) is exactly the same as that needed
It is a fair question to ask whether the allocation strategy and polices
need to be spelled out at the time of the reservation. Possibly we made
the wrong call on keeping them separate. Part of the issue is that fo
current experimentation having the block is more important, but for
longer ter
sizes for everyone.
Yours,
Joel
On 11/16/2012 11:35 AM, Brian E Carpenter wrote:
Joel,
On 16/11/2012 16:00, Joel M. Halpern wrote:
...
With regard to interworking and deployment, there are a number of
documents that deal with that. They discuss what the currently
understood deployment
I have to say I rather lik the iea of a query to the mapping system that
asks for a simple, small set of prefixes with the property that anything
outside of that set is by definition unknown to that mapping system. A
mapping system with no clue returns 0/0.
Yours,
Joel
On 11/21/2012 3:03 PM,
ot; is
extraneous. (And similarly for section 5.4)
Yours,
Joel M. Halpern
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
ditional costs involved, to be borne by some party, since
the P-ITR devices under consideration are handling all
non-LISP-originated traffic for the customer sites?
Yours,
Joel M. Halpern
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
I did consider whether it was relevant that the box might have enough
room for the whole table.
The section is "Cache Overflow", so I figure it was safe for discussion
to assume that there was insufficient space.
Yours,
Joel
On 12/13/2012 11:09 AM, Noel Chiappa wrote:
>
Thank you for responding to my comments.
With regard to the discussion of MS, ALT, and DDT, it seems to me that
there are a couple of reasons for splitting DDT out:
1) MS and ALT are already documented, and need better security
description. This seems the sensible place to fill that. IN cont
PM, Noel Chiappa wrote:
> From: "Joel M. Halpern"
> The section is "Cache Overflow", so I figure it was safe for discussion
> to assume that there was insufficient space.
Ah, good point.
Still, I think the discussion in my note is probably worth putti
as it is ;-) )
ciao
Luigi
On 13 Dec. 2012, at 17:39 , Joel M. Halpern wrote:
Thank you for responding to my comments.
With regard to the discussion of MS, ALT, and DDT, it seems to me that there
are a couple of reasons for splitting DDT out:
1) MS and ALT are already documented, and need better
17:27 , Joel M. Halpern wrote:
Agreed, your action would be to remove the DDT material from this document.
The question of how the DDT spec handles having sufficient security discussion
is a separate matter.
Yours,
Joel
On 12/14/2012 6:01 AM, Luigi Iannone wrote:
Hi Joel,
I've got your po
Tis is an interesting piece of work.
Once we clear the current blocking documents, I look forward to
discussion on the list of the pros and cons of the ideas presented herein.
Yours,
Joel
PS: As a minor item, when you respin this document, please shorten the
abstract. A lot.
On 12/26/2012
Commenting just on this one piece, the reason for suggesting separating
the two pieces has two components, as I understand the situation.
1) There is a belief that it would be helpful to get the prefix soon.
2) working out, ad then clearly documen, the plan for LISP EID
assignment / delegation s
And this gets to the reason why specifying the allocation policy will
take a lot longer.
From what I understand of LISP, and speaking only as an individual
participant, it is not at all obvious tome that the RIRs have an
inherent role in LISP EID allocation. LISP EIDs are not regional in any
m
I would note in passing that
A) There is no particular reason that EID registration / allocation
needs to be done by the RIRs
A') There is no reason to prohibit the RIRs from providing this
function, in competition with others, if they are interested
B) There is no particular indication that the
Yes, Reverse DNS is appropriate for these Identifiers. That is not
normally an RIR issue, as I understand it.
Assuming that hte working group does indeed move to LISP DDT, as it has
indicated, there is no intention to use RPKI within this space.
The question of how proxy advertisements, whic
aimed at use cases
which while interesting are not within the charter of the working group.
Dino has nonetheless gone out of his way to address your comments.
What are you looking for?
Yours,
Joel M. Halpern, speaking as co-chair
On 1/18/2013 5:46 PM, heinerhum...@aol.com wrote:
Dino,
In
or?
Yours,
Joel M. Halpern, speaking as co-chair
On 1/18/2013 5:46 PM,heinerhum...@aol.com <mailto:heinerhum...@aol.com> wrote:
Dino,
In spite of adding 4 locator octets you still need NAT !:-( C'mmon!
And you try to sell it as a great feature! :-(
Your position is: Thanks to
Maybe I misunderstand, but I thought the point of the locator status
bits was to tell me whether the individual ETRs were up, and had
connectivity to the site that they are serving. If so, then the
unpredictability of reachability across the net from the ITR(s) to the
individual ETRs would see
I was discussing the architecture document and it was poited out (and I
agree) that section 6.4 came out badly. I think that the first step
towards a solution (which may be sufficient) is to include a one
paragraph description of DDT.
Yours,
Joel
__
The authors have submitted a major revision of this documet.
Please read it (the diff tool will show you have much they have changed.
We need to be confident that the working group is happy with the changes
the authors hae made.
We will discuss this in orlando. Email comments before then would b
As a participant, I have an even stronger pinion on the RIR references
than terry.
I think that the block management needs to define
o who the root is
o what policy we require for allocating blocks to allocators (the root
is not an allocator
o What the behavioral requirements are for an alloca
allocation policies. The behaviors are
VERY different, as are the assignment implications.
Yours,
Joel
On 2/27/2013 6:59 AM, Luigi Iannone wrote:
Hi,
On 27 Feb. 2013, at 01:46 , Joel M. Halpern wrote:
As a participant, I have an even stronger pinion on the RIR references than
terry.
I
That similar. My point is specifically to stay out fo "who" except for
the root.
Yours,
Joel
On 2/27/2013 2:38 PM, Roger Jørgensen wrote:
On Wed, Feb 27, 2013 at 5:20 PM, Joel M. Halpern wrote:
Actually Luigi, in my personal opinion:
1) It is not our job or our requirement to i
o "who" except for
the root.
Yours,
Joel
On 2/27/2013 2:38 PM, Roger Jørgensen wrote:
On Wed, Feb 27, 2013 at 5:20 PM, Joel M. Halpern wrote:
Actually Luigi, in my personal opinion:
1) It is not our job or our requirement to involve the RIRs. It is our job
to come up with what we th
nt, as are the assignment implications.
Yours,
Joel
On 2/27/2013 6:59 AM, Luigi Iannone wrote:
Hi,
On 27 Feb. 2013, at 01:46 , Joel M. Halpern wrote:
As a participant, I have an even stronger pinion on the RIR references than
terry.
I think that the block management needs to define
o who th
wrote:
On Wed, Feb 27, 2013 at 8:44 PM, Joel M. Halpern wrote:
That similar. My point is specifically to stay out fo "who" except for the
root.
excellent, think we can agree on that really, and that's one direction to think.
I would really like to hear if any other have other
alternative.
Best regards,
as
P.D. Same as previus, rir hat off
On 01/03/2013 17:03, Joel M. Halpern wrote:
Could you please explain why you beieve it is important to consider the
RIRs? It is quite possible I am missing something.
As a participant, I believe I have said clearly that I prefer that
Oe reason I like the registry/registrar architectural model fo EID
allocation is that it avoids end-site lockin with someone who might
raise their annual maintenance fees.
That does not mean it has to be done by the same folks who do RNS today.
Although they certainly should be allowed to do
If we have one set of criteria for how organizations can become EID
assigners, then w have one simple and consistent set of rules. The fact
that some of the organizations who might choose to participate may wear
other hats (RIR, DNS Registrar, ...) does not create in and of itself
any addition
Sender: lisp-boun...@ietf.org
On-Behalf-Of: j...@joelhalpern.com
Subject: Re: [lisp] Fwd: I-D Action:
draft-iannone-lisp-eid-block-mgmnt-01.txt
Message-Id: <512d576b.6030...@joelhalpern.com>
Recipient: buxt...@cintas.com
--- Begin Message ---
As a participant, I have an even stronger pinion on
Well, there are regular reports of folks taking down BGP sessions
because they exceed the number of prefixes they can handle.
And LISP EIDs are more granular and varied than BGP prefixes usually are.
So it does seem a reasonable question to ask how we will protect
ourselves against this sort of
Maybe I am naive, but it strikes me that trying to extend link-local
IPv6 multicasts with LISP is probably a bad idea. Within the mobile
device scope, the registration mechanisms would seem to provide better
tools for things like address duplication prevention.
While I don't know if the docum
ote:
Joel - if we talk about link-local multicast being forwarded it is in context
of an L2 overlay where EIDs are MAC addresses. So NVO3 related work, even
though NVO3 is not limited to L2 overlays.
Dino
On Mar 24, 2013, at 3:54 PM, "Joel M. Halpern" wrote:
Maybe I am naive, bu
My apologies for not getting to this issue soone.
The approach being taken in this version of the document seems to me to
be ineffective. As a simple example, section 5.2 says that EID-to-RLOC
cache Threats are Severity level 2, meaning that it can be dealt with by
turning off certain feature
Jeff, could you please look at the section on this threat in the
document, and provide comments on where it is incorrect.
Thank you,
Joel
On 5/6/2013 12:02 PM, Jeff Wheeler wrote:
On Mon, May 6, 2013 at 11:45 AM, Joel M. Halpern wrote:
The approach being taken in this version of the
If you are eligible (and if chosen willing to forgo appointment), please
volunteer.
Thank you,
Joel
Original Message
Subject: NomCom 2013-2014 Call for Volunteers
Date: Mon, 13 May 2013 21:08:59 +
From: Mankin, Allison
To: ietf-annou...@ietf.org
The IETF nominating comm
As per my previous email, with corrected dates for forms sake:
Original Message
Subject: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in first
sentence
Date: Mon, 13 May 2013 21:27:21 +
From: Mankin, Allison
To: ietf-annou...@ietf.org
The IETF nominating commi
For tose who care about meeting locations, and do not read IETF Announce
or IETF Discuss.
Yours,
Joel
Original Message
Subject: IETF Meeting in South America
Date: Thu, 23 May 2013 08:54:12 -0700
From: The IAOC
To: IETF Announcement List
CC: i...@ietf.org
As you may know t
For those of you who did not get the message the first time...
Yours,
Joel
Original Message
Subject: Oooops CORRECTION Reply to This - Re: Nomcom 2013-14
Volunteering - 2nd Call
Date: Wed, 29 May 2013 21:08:56 +
From: Mankin, Allison
Reply-To: Mankin, Allison
To: ietf-a
Using the LISP mapping system to pass keys for use in the data plane is
beyond what is in our current charter.
Once we clear that blocking items, it would be reasonable to discuss this.
Personally, I find arguments other than the shared anonymity pool to be
more persuasive as to the value of th
tariat-re...@ietf.org>>
*Date:* September 2, 2013 at 4:42:06 AM PDT
*To:* "Dino Farinacci" mailto:farina...@gmail.com>>, "David Meyer" mailto:d...@cisco.com>>, "Job Snijders" mailto:j...@instituut.net>>
*Cc:* "Terry Manderson&qu
Doesn't this depend upon where the ITR is?
If, as is usually proposed, the ITR is a piece of CPE, then it will hide
the content of my message (good), and my individual EID (okay), but it
won't hide which site is sending the packet, which is an awful lot of
information.
Also, moving the ITR to
Speaking personally, I have some concerns about this.
I think my concerns can be lumped into two related categories. Bother
are about interoperability.
Firstly, I find the registration of LCAFs without any explanation of how
or why they would be used to be awkward. I know that some members
If I were writing these things, I would put the registration for each of
those types in the companion document. That way, a reader could judge
the safety and utility of the proposed usage. Otherwise, the
registration itself is not understandable.
Asked backwards, why is there value in puttin
I was reminded in recent discussion that the LCAF AFI is allowed both
for RLOCs and for EIDs.
For RLOCs, I have raised the concern that when an ETR injects RLOCs
using various LCAFs, it has no way to know whether the receiving ITRs
will be able to understand the LCAF. For some cases, this is
Congratulations to the authors, and thanks for their diligent work.
Particularly when we got conflicting OPS Area advice on some things.
Yours,
Joel
On 9/13/13 3:59 PM, The IESG wrote:
The IESG has approved the following document:
- 'LISP MIB'
(draft-ietf-lisp-mib-13.txt) as Experimental RF
TR using a
complex LCAF RLOC can reasonably expect the ITR to understand it.
Comments, opinions, or rotten tomatoes?
Yours,
Joel M. Halpern
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
1 - 100 of 324 matches
Mail list logo
