Subject: Re: [rrg] I-D Action:draft-irtf-rrg-recommendation-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Feb 2009 13:58:26 +1300

Hi,

Thanks for this draft. A few more comments from me:

> 3.1.1.  Transport

Probably useful to state that this is layer 4. I understand that over
at the ITU-T they have changed the meaning of the word 'transport' to
mean layer 2 (presumably in an effort to forget about OSI).

...
>    The consensus of the
>    group is that such site renumbering is a completely unacceptable
>    requirement and as such, these types of solutions are not of interest
>    for further exploration.

Mild rewrite as

   The consensus of the
   group is that such site renumbering is widely unacceptable for
   operational reasons and thus, these types of solutions are not of
   interest for further exploration in this group.

> 3.1.2.  Translation

Reading further, it occurred to me that this really should
be called Map & Translate, and that we should distinguish
stateful and stateless translation.

Also distinguish reversible and non-reversible translation.

It would be good if this and the following section brought out
the isomorphisms and differences between translation and
encapsulation very clearly.
(NAT is just swapping RLOC and EID, for example, but NAPT is
munging EIDs together before doing the swap.)

> 4.1.  No manual renumbering of end hosts
> 
>    There is clear consensus in the group that renumbering of sites must
>    not require manual intervention on a per-host basis.  

Yes. You might consider a reference to draft-carpenter-renum-needs-work
(the -02 draft will be out in a day or two). I'm not suggesting that
should be an RRG document; in fact it's being discussed in the IETF
Ops Area. But it does discuss exactly this topic.

    Brian

---

From: Scott Brim <[email-masked]>
Date: Sat, 21 Feb 2009 16:16:55 -0500

> mean layer 2 (presumably in an effort to forget about OSI).

They forgot about OSI years ago.  For a good time see
http://www.itu.int/rec/T-REC-Y.110/en on roles and "added value",
http://www.niven-jenkins.co.uk/An%20introduction%20to%20functional%20architecture.pdf,
and http://www.itu.int/rec/T-REC-Y.2611/en for functional
architecture.  For example in Y.2611 (where "identifier" is a
more-generic including both "name" and "address"):

    Identification is required in each layer network of the NGN
    transport stratum. A given entity will be assigned one or more
    identifiers depending on the function of that entity. FPBN layer
    network identifiers are independent of any client (and any server)
    layer network identifiers even if they share the same syntax or
    structure. At the boundary of a layer network, mapping and/or
    translation mechanisms are required in order to set up
    relationships between the identifier used by the client layer
    network and the identifier used by the server layer network.  

    NOTE – Identifiers could be determined from multiple discontinuous
    fields. The global uniqueness of an identifier may be provided by
    the context as well as the identifier itself. 

    Whether a given identifier is considered to be a name or an
    address is dependent on several factors including the perspective
    (and location) of the entity that is using (or mapping to) that
    identifier.  The same identifier can be considered an address to
    one entity and a name to a different entity because their
    perspective is different. 

>    interest for further exploration in this group.

+1

> be called Map & Translate

I don't see why.  Suppose I'm doing GSE.  I have a simple algorithm
for swapping the upper bits of an address field, and the algorithm is
always the same.  Is that really mapping?  I don't know of any
proposals that do actual mapping and then translating.

> , and that we should distinguish

Yes

> encapsulation very clearly.

Yes

> munging EIDs together before doing the swap.)

I don't know what you mean, munging EIDs together.  Do you mean
that it uses pieces from different headers?

Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 22 Feb 2009 11:10:48 +1300

Scott,

...
>     perspective is different.

Absolutely true.

...

> proposals that do actual mapping and then translating.

I agree that in most cases the mapping is algorithmic or trivial.
But if you classify shim6 here, it's actually building a small map
for each ULID (~=EID) that it handles.

...

> that it uses pieces from different headers?

No, I mean that it folds many EIDs into one RLOC, using the port
numbers to demultiplex.

   Brian

---

From: "Tony Li" <[email-masked]>
Date: Mon, 23 Feb 2009 11:41:16 -0800

Hi Brian,

Thanks for the comments. 

|> 3.1.1.  Transport
|
|Probably useful to state that this is layer 4. I understand that over
|at the ITU-T they have changed the meaning of the word 'transport' to
|mean layer 2 (presumably in an effort to forget about OSI).

Sure thing.  BTW, my understanding is that the PSTN folks were using
'transport' long ago to describe their TDM hierarchy.  In fact, it was these
newfangled packet folks that redefined 'transport'.  ;-)

|>    The consensus of the
|>    group is that such site renumbering is a completely unacceptable
|>    requirement and as such, these types of solutions are not 
|of interest
|>    for further exploration.
|
|Mild rewrite as
|
|   The consensus of the
|   group is that such site renumbering is widely unacceptable for
|   operational reasons and thus, these types of solutions are not of
|   interest for further exploration in this group.

Sure.

|> 3.1.2.  Translation
|
|Reading further, it occurred to me that this really should
|be called Map & Translate, and that we should distinguish
|stateful and stateless translation.

True, but ALL solutions require mapping.  

|Also distinguish reversible and non-reversible translation.

I agree with the differentiation, but I'm really less interested in refining
the taxonomy from section 3.1 unless there's some clear, tangible benefit.
At this point, I'm much more interested in putting our efforts into the
section 3.3 approach.

|> 4.1.  No manual renumbering of end hosts
|> 
|>    There is clear consensus in the group that renumbering of 
|sites must
|>    not require manual intervention on a per-host basis.  
|
|Yes. You might consider a reference to draft-carpenter-renum-needs-work
|(the -02 draft will be out in a day or two). I'm not suggesting that
|should be an RRG document; in fact it's being discussed in the IETF
|Ops Area. But it does discuss exactly this topic.

Plug added.  ;-)

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Feb 2009 13:20:49 +1300

> At this point, I'm much more interested in putting our efforts into the

Fair enough, but I think that from the point of view of making referrals
and any other "address" dependencies in upper layers work, reversible
translation is in itself a clear benefit, almost isomorphic with encap/decap.

   Brian

---

From: "Tony Li" <[email-masked]>
Date: Mon, 23 Feb 2009 22:47:24 -0800

|Fair enough, but I think that from the point of view of making 
|referrals
|and any other "address" dependencies in upper layers work, reversible
|translation is in itself a clear benefit, almost isomorphic 
|with encap/decap.

Agree.

Tony

---

From: Scott Brim <[email-masked]>
Date: Tue, 24 Feb 2009 07:09:54 -0500

Excerpts from Tony Li on Mon, Feb 23, 2009 11:41:16AM -0800:
> At this point, I'm much more interested in putting our efforts into
> the section 3.3 approach.

Tony: I hadn't realized, when (from my point of view) people were
helping Bill sort out ways of thinking about approaches, that you were
intending to promote the result as the main part of what we would put
it our recommendation to the IETF.  I suppose I could go along with
that, even though it's a surprise, but I believe it's going to take a
lot of editing before it's ready to hand off.  I can contribute what I
think should happen, but as co-chair, how do you think we should
proceed?  For example, are you hoping to have something to present in
RTGarea?

Scott

---

From: "Tony Li" <[email-masked]>
Date: Tue, 24 Feb 2009 13:05:06 -0800

Scott,
 
|Tony: I hadn't realized, when (from my point of view) people were
|helping Bill sort out ways of thinking about approaches, that you were
|intending to promote the result as the main part of what we would put
|it our recommendation to the IETF.  

And I hadn't realized that Bill was going to be so productive in putting
something useful together.  

|I suppose I could go along with
|that, even though it's a surprise, but I believe it's going to take a
|lot of editing before it's ready to hand off.  I can contribute what I
|think should happen, but as co-chair, how do you think we should
|proceed?

FWIW, I would like to get more of Bill's involvement, but his day job seems
to be pressing him right now.  Lacking that, I'd welcome any editorial or
clarification changes that folks would like to propose.  I'm a bit more
hesitant about making significant changes without Bill's approval, but we
certainly can do so.

As always, other insights into the problem, discussions of architectural
conclusions that we can clearly draw and other conceptual items leading to
an architectural proposal are most welcome.  There's a lot more than could
be in this document outside of just taxonomy (e.g., mental question du jour:
do identifiers need to be globally unique?).

|  For example, are you hoping to have something to present in
|RTGarea?

No, no need.  As always, we owe a report to the IRTF Chair.  Nothing less,
nothing more.

Tony

---

From: Scott Brim <[email-masked]>
Date: Wed, 25 Feb 2009 08:10:20 -0500

Tony,

Here is what I see:

  - There have been a number of attempts at characterizing the
    solution space.  Once upon a time we were trying to establish
    dimensions along which they could be compared quantitatively.
    Lately we've just settled for describing them.  You took one of
    the more recent attempts and incorporated it in a draft you wrote,
    and are proposing that it represent the RRG's position on how to
    think about solutions in order to select one.  

  - You are applying strong control on the content -- if you disagree
    with an idea your position has strong weight -- but this conflicts
    with your stated role as "editor" and your position as co-chair in
    which you are mainly trying to create consensus.  If you want to
    be in an author role, please say so.

  - The conceptual framework was lifted from Bill Herrin and you do
    not want any modifications to happen without Bill's involvement.
    You want his opinions to carry significant weight.  But once you
    take the framework and put it in the RRG's draft, it isn't Bill's
    anymore.  

Here is what I would like to happen:

  - Consensus discussion on what should go in a recommendation draft.
    A categorization of solutions is probably a good idea but it isn't
    enough -- we should talk about how we think it in particular can
    be used, but also how we think the draft as a whole might be used
    by the IETF to make progress.  As it stands I don't think the
    draft is very useful to the IETF.

  - Consensus discussion on what's in it already, particularly (of
    course) the chunking of approaches into categories.  In this,
    sorry Bill but you're just another individual.  

I was relieved to hear that you aren't trying to submit a draft before
this meeting.  I will write up what I can on this over the next few
weeks.  I'm about to go on a four-cities-in-a-week tour so I won't be
able to produce anything for the group to get their teeth into until
the 2nd week of March, but I request a time slot in the RRG agenda to
present some proposals.  If all goes well I won't need it, but I would
like to reserve the slot just in case.  

Thanks ... Scott

---

From: "Tony Li" <[email-masked]>
Date: Wed, 25 Feb 2009 13:32:12 -0800

Hi Scott, 

|  - There have been a number of attempts at characterizing the
|    solution space.  Once upon a time we were trying to establish
|    dimensions along which they could be compared quantitatively.
|    Lately we've just settled for describing them.  You took one of
|    the more recent attempts and incorporated it in a draft you wrote,
|    and are proposing that it represent the RRG's position on how to
|    think about solutions in order to select one.  

More precisely, I'm interested in using it as one means of thinking about
the problem space.  I'm not saying it's the only one.  It seems useful, so
let's use it.

|  - You are applying strong control on the content -- if you disagree
|    with an idea your position has strong weight -- but this conflicts
|    with your stated role as "editor" and your position as co-chair in
|    which you are mainly trying to create consensus.  If you want to
|    be in an author role, please say so.

Yes, as "editor" of this document, I'm exercising stronger control over the
content here.  This is not in conflict with my stated role as a 'neutral'
co-chair, where I'm not an advocate of any given particular proposal.  As
you well know, I've always been an advocate of us making forward progress.
At this time, this seems to be the best way to move forward.

|  - The conceptual framework was lifted from Bill Herrin and you do
|    not want any modifications to happen without Bill's involvement.
|    You want his opinions to carry significant weight.  But once you
|    take the framework and put it in the RRG's draft, it isn't Bill's
|    anymore.

More precisely, I'm concerned about taking Bill's work, citing it as his
(absolutely necessary, of course) and then modifying it without his assent.
Obviously, we can make it clear that this is a diverging derivative, but I'm
still hopeful that we can get Bill's involvement.  

That said, the first priority is to make forward progress.  If that means
that his taxonomy needs improvement, then that needs to happen.  If it's a
significant change, then we'll attribute Bill, make the change, and diverge
from his direction.

|Here is what I would like to happen:
|
|  - Consensus discussion on what should go in a recommendation draft.
|    A categorization of solutions is probably a good idea but it isn't
|    enough -- we should talk about how we think it in particular can
|    be used, but also how we think the draft as a whole might be used
|    by the IETF to make progress.  As it stands I don't think the
|    draft is very useful to the IETF.

Again, the IETF is irrelevant.  This is our internal process.

I support the idea of a consensus discussion of what should go into the
draft, and that's already what's happening.  Yes, the draft is not supposed
to just be about taxonomy.  I would definitely like to add more consensus
items to it and I welcome and encourage the discussion.  I'd like to
explicitly invite folks to open new topics for consensus (in an orderly,
polite and sensible fashion, of course).

|I was relieved to hear that you aren't trying to submit a draft before
|this meeting.

I _have_ submitted a draft before the meeting.  That's what you are already
reading.  I will be submitting an update to it at the end of this week (or
sooner, depending on other events).

|I will write up what I can on this over the next few
|weeks.  I'm about to go on a four-cities-in-a-week tour so I won't be
|able to produce anything for the group to get their teeth into until
|the 2nd week of March, but I request a time slot in the RRG agenda to
|present some proposals.  If all goes well I won't need it, but I would
|like to reserve the slot just in case.  

I welcome that and again point your to our normal process for requesting
agenda slots.

Cheers,
Tony