Re: [Dime] Dime NAI Routing

[Avi Lior <avi at bridgewatersystems.com>]

I have inline comments as well as new comment:

The over arching problem as I see it is that when you read the document, at least the introduction and abstract you get the sense that the draft is intending to fix base diameter behavior.

But in responses I get, I get the feeling that the intent is really to have an Application based routing scheme using NAI.



If you are trying to fix base then we need a robust backwards compatible way of doing things.  As well, we can argue whether or not it should be placed in DIME.  There is more work to do.

If you are trying to write a document that describes how one would do Application routing using NAI. Then that does not belong in base so we should stop debating that.  And actually in this case what you are doing is fine and you are probably there.

So which is it?  And once we pick we should be clear in the text.

We could come up with a hybrid solution by the way.

If the priority is to make sure that the packet gets to the destination, then:
You set the destination-realm to the final destination and intermediaries that support decorated NAI use the decorated NAI without modification to the destination-realm.  Intermediaries that don't know about decorated NAI will just perform the destination-realm routing.  As you point out you get looping but its not infinite looping.  At least the message would get to the final destination.

If NAI routing is the most important thing then you set the destination-realm to the next hop of the Decorated NAI.  Each hop that supports this scheme will use the decorated-nai and will update the realm.  If a hop is reached that does not understand decorated NAI then the packet will be consumed locally.


Please see inline for more comments 

> -----Original Message-----
> From: jouni korhonen [mailto:jouni.nospam at gmail.com] 
> Sent: March 3, 2009 5:44 PM
> To: Avi Lior
> Cc: Lionel.morand at orange-ftgroup.com; Mark Jones; 
> tena at huawei.com; Hannes.Tschofenig at gmx.net; dime at ietf.org
> Subject: Re: Dime NAI Routing
> 
> Hi Avi,
> 
> Thanks for reading & commenting the I-D.
> 
> On Mar 2, 2009, at 11:41 PM, Avi Lior wrote:
> 
> > A couple of comments:
> >
> > 1)  The draft should mention something about the presence of 
> > Destination-Host AVP.
> >
> > The rule for routing is that the Destination-Host AVP is 
> not looked at 
> > until the message reaches the terminal realm as determined by the 
> > decorated NAI.
> 
> Where you would suggest to include the clarifying text? In 
> Section 4.2.?

I don't know.  I will have to look at the draft. This is really a side issue and depends on the intent of the draft.

> 
> 
> > 2) I dont like the way Destination-Realm is being used.
> >
> > The draft states that the destination realm is updated on a 
> hop by hop 
> > basis together with the decorated NAI.
> 
> I assume that is the only way to ensure the request message 
> really goes through all wanted realms.

Correct.  And in some cases NAI routing is going to be more important and in some cases it will be more important to make sure the message makes it all the way.
 
> 
> > If an intermediary is not compliant with the scheme 
> presented by this 
> > draft it will result in the intermediary consuming the 
> message locally 
> > - since the message contains the destination realm equal to
> > its realm.   Thus the message is not going to reach the destination.
> 
> That is the reason why the I-D suggests only using the 
> decoration stuff with a new application that is known to 
> support this I-D. In that way legacy agents can be bypassed.

Okay so here you are clear this is Application based routing.

> >
> > Instead, I propose that the destination realm should be 
> always set to 
> > the terminal realm, thus:
> >
> > Agents that are compliant with the draft will first look at 
> the NAI to 
> > determine whether the packet has reached the terminal realm 
> or where 
> > it should be routed next;
> 
> Are you proposing to make the routing decision based on the 
> User-Name (and ignore the Destination-Realm all together) in 
> cases where 1) the agent supports this I-D and 2) the 
> User-Name contains a decorated NAI?
> Once the decorated NAI would have been "consumed" the 
> checking would be based on the Destination-Realm again..?

Almost. In the case where you want to guarantee packet delivery irrespective of whether nodes are compliant with this draft, then you set the destination-realm to the final destination of the decorated NAI.  Agents that support your scheme would use the decorated NAI to determine how to route to the next hop.  Agents that don't support your scheme will use the destination-realm to determine how to route to the next hop (they will ignore the decorated NAI).

> > Agents that are not compatible with the draft will use the 
> old rules 
> > for routing and would route the message according to the 
> destination- 
> > realm only and thus the message will reach the final destintaion 
> > albeit not necessarily according to the decorated NAI. But 
> at least it 
> > would work.
> >
> >
> > Did I miss anything?
> 
> What happens if.. the route happens to have some 
> non-compliant agents and when the request reaches its final 
> end (e.g. according to the inter-connection architecture) the 
> User-Name still has decorated NAI?
> Would the decorated NAI compliant server/proxy send to 
> request back to some other realm pointed by the User-name? 
> This would effectively cause a routing loop, right?
 No. It may cause a loop but it wont be an infinite loop.  So it depends, in some cases I may be okay with have strange routing but I will at least get the packet there. So it depends what I want to achieve.

> 
> Cheers,
>         Jouni
> 
> 
> 
> >
> >
> 
>