Re: GIST Inbound/reception interface

hi roland.

interesting questions: 

> -----Original Message-----
> From: Roland Bless [mailto:[email protected]] 
> Sent: 11 July 2008 04:36
> To: Hancock, Robert
> Cc: [email protected]
> Subject: GIST Inbound/reception interface
> 
> Hi Robert,
> 
> I have similar questions related to sections 8.5 and B.2.:
> Section 8.5:
> 
> Binding: ...
>       the MRI/NSLPID for the messaging.  It also includes the 
> interface
>       on which the Query was received (since a Q-mode encapsulated
>       message is the one that will best follow the data path and so
>       arrive on the correct interface).
> 
> Not clear to me whether it is simply the interface index or
> a particular address of an interface. The i/f index may not
> suffice in certain scenario, esp. when you are using MobileIP
> on an interface.

The point here is what the reception interface information is used
for. The specific interface information is actually needed for
route change detection at the Responding node, and if the responding
node is doing delayed state installation then the cookie mechanism
is the only way to remember how the Q-mode message arrived. (I had
thought this was clear in section 7.1.2 but it isn't; it will be 
in v16.)

Given that, exactly how to represent the interface depends on how
the route change detection is being implemented in the node, for
which there is (I think rightly) a fair amount of implementation 
freedom. Some opaque representation (like the LIH of RSVP), or
an address, or both are all possible. Note that there could be
several and/or changing addresses assigned on a given interface.
To address your specific example, if a node happens to assign a 
new CoA to an interface for MIP, but Q-mode messages still arrive
through it, I would say that no route change has occurred, so 
logical handles are sufficient. 

> B.2.:
>    Inbound-Interface:  Attributes of the interface on which 
> the message
>       was received, such as whether it lies on the internal 
> or external
>       side of a NAT.  These attributes have only local 
> significance and
>       are implementation defined.
> 
> Is it only the attributes or also the i/f address?

What is passed up depends on what the application is interested
in: different applications may have different requirements. 
My personal preference would be to minimise the amount of
explicit addressing information exposed to signalling applications,
without really understanding why it is needed and whether there
is any alternative, and that has to be a case by case issue.
Once addresses escape into application layers, it is very 
difficult to recapture them. Again in this particular case,
addresses alone are certainly not sufficient - an application 
would still have to interpret them as internal or external, 
and in the case of a NAT bridging overlapping address spaces
then determining internal vs. external from address alone is
impossible. 

To summarise: if I were implementing, I would supply attributes
only unless and until a signalling application developer makes
a really good case to have the addressing also. But that is
admittedly partly a stylistic issue.

cheers,

robert h.

> 
> Regards,
>  Roland
>