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

From: Scott Brim <[email-masked]>
Date: Sat, 21 Feb 2009 15:42:02 -0500

Hi.  A few questions ...

> 3.1.  A Mechanism Taxonomy
> 
>    In this taxonomy, solutions are grouped by the primary mechanisms
>    that they use to achieve their goals.

I'm wondering, in the categories {transport, translation,
encapsulation}, where would you put shim6?  It's below transport.
Would you say rewriting is translation?  Would you say an addition of
a header is an encapsulation?   

> 3.1.2.  Translation
> 
>    Translation solutions are characterized by a translation
>    operation between an identifier to a locator and back to an
>    identifier as the packet traverses the network.

Now that I've pondered this a little, I can't think of any approach
that does that (translate from identifier to locator and back again).
GSE only does it in one direction (->RLOC for source, ->ID for
destination).  GSE uses identifiers internally but does not need to
translate outgoing destination addresses or incoming source addresses
since they are already in RLOC form and must stay that way.  NAT-based
approaches and Six/One Router are also one-way: the local source
address is translated to an RLOC when outgoing, and the destination
address is translated to a local address when incoming.  Also except
for GSE and ILNP, the local "thing" is not an "identifier" in the
sense that the term is used here, a topology-independent name of a
single endpoint, or node ID.  It is a locator with limited scope.
Except in the case of GSE and ILNP it still names an attachment point
and has topological significance.

> 3.3.1.  Strategy A
> 
>    Local routing is based on an address, which functions as a GUID,
>    SID component and local locator,

Should this be an "and/or" or "or" instead of an "and"?  Or is this
supposed to be an in-line definition of "address"?  A local locator is
not necessarily also part of a session ID.

> 3.3.2.2.  Identifier variants
> 
>    B2a  Each host has a single numeric identifer to which the
>         locators are attached.  This identifier is used by the
>         layer-4/5 and higher protocols to compose the SID.
> 
>    B2b  Each service provided by a host has a globally unique,
>         hierarchical character-string identifier to which the
>         locators are attached.  Clients initiating communication
>         with that service negotiate a numeric SID which is unique
>         only within the scope of that service.

In this section I don't see the relevance of "numeric" and
"character-string".  To the functions using these identifiers, they
are just bits, regardless of what semantics a human might see in them.

Scott

---

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

Scott,

On 2009-02-22 09:42, Scott Brim wrote:
> destination).  

Shim6 does both translations in the case that ULID != RLOC, which
I think also answers your previous question. But certainly,
reversibility vs non-reversibility, and whether the translation
affects source, destination, or both, are facets of the taxonomy, I think.

    Brian

GSE uses identifiers internally but does not need to
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

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

Hi Scott,

|> 3.1.  A Mechanism Taxonomy
|> 
|>    In this taxonomy, solutions are grouped by the primary mechanisms
|>    that they use to achieve their goals.
|
|I'm wondering, in the categories {transport, translation,
|encapsulation}, where would you put shim6?  It's below transport.
|Would you say rewriting is translation?  Would you say an addition of
|a header is an encapsulation?   

As I've said in prior email, I'm less interested in refining this taxonomy.
I agree that there's arguments to put Shim6 in either translation or in map
& encap.  This doesn't seem like a productive argument.

|> 3.1.2.  Translation
|> 
|>    Translation solutions are characterized by a translation
|>    operation between an identifier to a locator and back to an
|>    identifier as the packet traverses the network.
|
|Now that I've pondered this a little, I can't think of any approach
|that does that (translate from identifier to locator and back again).

NAT, for example.

|Also except
|for GSE and ILNP, the local "thing" is not an "identifier" in the
|sense that the term is used here, a topology-independent name of a
|single endpoint, or node ID.  It is a locator with limited scope.

This is a terminology nit.  We've defined "identifier" to have zero
topological significance.  However, that's just taking a black-and-white
view of the world.  It's not unreasonable to have a name that has both
identification semantics and local locator scope.

|> 3.3.1.  Strategy A
|> 
|>    Local routing is based on an address, which functions as a GUID,
|>    SID component and local locator,
|
|Should this be an "and/or" or "or" instead of an "and"?  Or is this
|supposed to be an in-line definition of "address"?  A local locator is
|not necessarily also part of a session ID.

Yes, I think that this is an inline (and local) definition of address.
Obviously, that's not a requirement, just the local definition.

|> 3.3.2.2.  Identifier variants
|> 
|>    B2a  Each host has a single numeric identifer to which the
|>         locators are attached.  This identifier is used by the
|>         layer-4/5 and higher protocols to compose the SID.
|> 
|>    B2b  Each service provided by a host has a globally unique,
|>         hierarchical character-string identifier to which the
|>         locators are attached.  Clients initiating communication
|>         with that service negotiate a numeric SID which is unique
|>         only within the scope of that service.
|
|In this section I don't see the relevance of "numeric" and
|"character-string".  To the functions using these identifiers, they
|are just bits, regardless of what semantics a human might see in them.

Agreed, this is diverging from the conceptual and into the engineering.
References removed here, as well as others that I could trivially find.

Thanks,
Tony

---

From: Scott Brim <[email-masked]>
Date: Tue, 24 Feb 2009 06:43:58 -0500

> |that does that (translate from identifier to locator and back again).

NAT translates from a local locator to a global locator ("RLOC" in the
terminology you want us to adopt).  You say

> It's not unreasonable to have a name that has both

That's true, and what matters in the case of NAT is the "local locator"
semantics.  NAT is not treating the address field it translates as an
endpoint identifier, but as an address.  That's why I say NAT doesn't do
what you said it does.

> |> 3.3.1.  Strategy A

If we end up using this classification scheme in our recommendation to
the IETF, one thing we need to do is name these strategy buckets in ways
that are easier to remember than "A", "B", etc.

Scott

---

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

Hi Scott,

|NAT translates from a local locator to a global locator ("RLOC" in the
|terminology you want us to adopt).  

Actually, I'm not pushing a given terminology, just documenting what seems
to have evolved.

|You say
|
|> It's not unreasonable to have a name that has both
|> identification semantics and local locator scope.
|
|That's true, and what matters in the case of NAT is the "local locator"
|semantics.  NAT is not treating the address field it translates as an
|endpoint identifier, but as an address.  That's why I say NAT 
|doesn't do
|what you said it does.

Fair point.  You're right, the text in 3.1.2 is poor.  Let's take a pass at
fixing it:

Translation solutions are characterized by converting an original local
source name to a global name and then from the global name back to a final
local destination name.  The global names are assigned in an aggregatable
fashion to provide scalability.

Work for you?

|> |> 3.3.1.  Strategy A
|
|If we end up using this classification scheme in our recommendation to
|the IETF, one thing we need to do is name these strategy 
|buckets in ways
|that are easier to remember than "A", "B", etc.

Actually, I like it.  It's completely neutral, it avoids all of the
arguments about natural language naming, and it clear and succinct.  

Tony

---

From: Christian Vogt <[email-masked]>
Date: Wed, 25 Feb 2009 19:16:15 -0800

> that does that (translate from identifier to locator and back again).

Scott -

All address indirection solutions that are application-transparent do
map both source and destination addresses at both ends.  I.e., you have
four mappings per packets:  The respective local addresses (source
address at the sending side; destination address at the destination
side) are mapped to achieve provider independence.  The respective
remote addresses are mapped to achieve application transparency.

> NAT-based approaches and Six/One Router are also one-way: the local
> source address is translated to an RLOC when outgoing, and the
> destination address is translated to a local address when incoming.

As you mention Six/One Router -- this solution proposal actually has two
modes:  One mode is NOT application-transparent; this, as you say, maps
only the respective local addresses (two mappings per packet).  But
Six/One Router also has an application-transparent mode, which performs
all four mappings per packet.  The two modes are called Unilateral mode
and Bilateral mode, respectively.

And FWIW:  Six/One Router, Unilateral mode == NAT66.

- Christian

---

From: Scott Brim <[email-masked]>
Date: Wed, 25 Feb 2009 22:23:22 -0500

> remote addresses are mapped to achieve application transparency.

You just helped make my point.  The sentence says translation is from
an "identifier" to a "locator" and back again.  The scenario you
describe is not that, it's between global and local addresses.

> And FWIW:  Six/One Router, Unilateral mode == NAT66.

Agreed.

---

From: Christian Vogt <[email-masked]>
Date: Wed, 25 Feb 2009 19:52:58 -0800

Scott and Tony -

> Agreed, this is diverging from the conceptual and into the  

While the differentiation between "numeric" and "character-string" may
indeed not be directly relevant at the conceptual level, I think the
differentiation that Bill actually had in mind was between human-
readable and non-human-readable identifiers.  This does have conceptual
significance:  Since, ultimately, the identifier presented to the user
will have to be human-readable, solutions that use non-human-readable
identifiers will necessarily introduce a new layer of indirection,
whereas solutions that use a human-readable identifier don't have to.

FWIW, in Minneapolis, I presented a host-based solution [1] that uses
human-readable identifiers, and that does without a new indirection
layer.  The identifiers are DNS names.

- Christian

[1] http://users.piuha.net/chvogt/pub/2008/vogt-2008-hostname-oriented-stack.pdf

---

From: Christian Vogt <[email-masked]>
Date: Wed, 25 Feb 2009 20:02:37 -0800

Scott -

> describe is not that, it's between global and local addresses.

The mapping could be between any two name-spaces, whether one of them is
an identifier or not.  In fact, Shim6 is an example of an application-
transparent, translation-based method that maps between identifiers and
locators -- where the identifier is a recycled locator of which the
topological meaning is ignored.

- Christian

---

From: David Conrad <[email-masked]>
Date: Wed, 25 Feb 2009 19:04:42 -1000

Hi,

Just a minor point:

> remote addresses are mapped to achieve application transparency.

Yes, you need a mapping on both sides, but no, you don't need to do  
all 4 per packet. You can leave the source identifier unmapped.  You  
map the destination identifier to destination locator at the source  
edge and unmap the destination locator back into the destination  
identifer at the destination edge.  You only need to map the source  
when you need to send something back (yes, if you have multiple edge  
devices at the source, it can make it a bit more difficult to find the  
one the packet came out of if you need to).

As I said, a minor point.

Regards,
-drc

---

From: Christian Vogt <[email-masked]>
Date: Wed, 25 Feb 2009 22:08:52 -0800

David Conrad wrote:

> all
> 4 per packet. You can leave the source identifier unmapped.  [...]

That's correct, David.

At least, assuming that there won't be ingress filtering after the
source-side mapping.  But given that ingress filtering is typically
performed at the edge, I do agree with you.

That said, I think the main point here is not the number of mappings per
packet, but rather whether we want to be application-transparent.  After
all, the need for bilateral support, and for a global mapping system,
exists if and only if we want to be application-transparent.

- Christian