Subject: [RRG] Mapping Distribution and Management: contribution for comments

From: "K. Sriram" <[email-masked]>
Date: Wed, 16 Jul 2008 18:09:14 -0400

I am submitting a contribution (co-authored with Young-Tak Kim and 
Doug Montgomery)
on the topic of "Architectural Considerations for Mapping 
Distribution Protocols"
for discussion and comment on this list.

A link to the paper is:
http://www.antd.nist.gov/~ksriram/NGRA_map_mgmt.pdf

We offer some thoughts on architectural concepts with
the view of enabling efficiency and performance for
mapping distribution protocols.
Our purpose with this contribution is to highlight
some subtleties in the design considerations
for mapping distribution and management,
and invite discussion/comments.

Sriram

K. Sriram, Ph.D.
Advanced Network Technologies Division
National Institute of Standards and Technology
100 Bureau Drive, Stop 8920
Gaithersburg, MD 20899-8920
Phone: (301) 975-3973
E-Mail: [email-masked]
Web:  http://www.antd.nist.gov/~ksriram/

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 27 Jul 2008 00:44:21 +1200

Hi,

On 2008-07-17 10:09, K. Sriram wrote:
> I am submitting a contribution (co-authored with Young-Tak Kim and Doug
> Montgomery)
> on the topic of "Architectural Considerations for Mapping Distribution
> Protocols"

I have a couple of questions about Fig. 3:

Firstly, what is the advantage in the lower layer
of ETRs (ETR1-6) being ETRs at all? If they are handling
locators that aggregate at ETR7 and ETR8 respectively,
why not just en/decapsulate at ETR7 and ETR8?

(To be clear, the suggestion I put out some months ago didn't
just have a hierarchy of ETRs; it also had a hierarchy
of locator domains and a hierarchy of maps, so you would
decapsulate and re-encapsulate with a different mapping at
each layer. That was supposed to be a scaling mechanism.)

Secondly, your two multihoming examples are only connected
to second layer ETRs (ETR7 and ETR8). Is there any reason
you can't multi-home at the first layer?

    Brian

---

From: [email-masked]
Date: Sat, 26 Jul 2008 09:37:59 -0400

> each layer. That was supposed to be a scaling mechanism.)

Thank you for your comments.
We have similar reasons in mind for a hierarchy of ETRs.
Please also see slide #18 in our presentation (draft):
http://www.antd.nist.gov/~ksriram/MDP_Dublin_KS_Slides.pdf
where we mention possibility of recursive map-and-encap.
Further, we are assuming that some subprefixes (subnets) 
are amenable to aggregation at higher layer ETR and yield to 
mapping table reduction while there may be other prefixes 
that are not aggregatable. In the latter case, the prefix
may as well have lower layer ETR as its locator just in 
case there are shorter paths from some ITRs to that ETR.
At this time, we are putting forward some ideas for 
discussion and trying to see where we can go with this. 

> you can't multi-home at the first layer?

Sure, they can multi-home at the first layer. What we show 
in the figure was just to state an example. 

Can you please provide me a link to your earlier message
about hierarchy of ETRs?

Thanks again for the comments.
Sriram

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 27 Jul 2008 02:15:05 +1200

Hi, thanks for the explanations.

<snip>

> Can you please provide me a link to your earlier message

There was a thread "Idea for shooting down" in November 2007.
The thread started at http://psg.com/lists/rrg/2007/msg00556.html

The document it was based on is still at
http://www.cs.auckland.ac.nz/~brian/DFZng.pdf.
I would probably used different terminology today; it certainly
isn't a worked-out proposal.

   Brian

---

From: [email-masked]
Date: Sun, 27 Jul 2008 17:11:58 EDT

In einer eMail vom 26.07.2008 16:22:28 Westeuropäische Normalzeit schreibt  
[email-masked]:

Brian

Brian, 
Your draft reminds me of PNNI although your hierarchy is based on  BGP/DV and 
not OSPF/Dijkstra. 
PNNI's hierarchy  had to be in compliance with some particular AFI,  i.e. 
with prefixes from one of these 4 :Data Country Code, E.164,  designated 
numbering for enterprises, private numbering plan. Concurrently all  the remaining 3 
AFIs had to be serviced nevertheless as well.
 
Myself, I would have favored the hierarchy of your solution, if I  wouldn't 
have made progress meanwhile with respect to: getting rid of ALL  this prefix 
building stuff, getting rid of the need for configuration (who is  border node, 
who is peer group leader; a router wouldn't even need some  configurational 
data that indicated up to which hierarchical level it has to  deal with) - and 
finally getting rid of a fix hierarchy itself.
 
DV-based versus topology-aware:
Not long ago Lixia asked for comments regarding a draft which praised the  
map-encap's benefits for multipath. There is a proverb: The whole is more than  
the sum of its parts. Applied: The topology is more than all routes to all  
destination nodes. By knowing the topology all routes to some destination could  
be provided (including those which contain some crankback hops). But 
certainly  not, given today's BGP, where a router has no idea what happens 
(transitively)  with an UPDATE message it is forwarding. Also, a router does not inform a 
 neighbor about a worse route, if this neighbor has told him a better route. 
I.e. distance vector based solutions prevent perfect multipath  routing.
 
Heiner