Re: GIST Inbound/reception interface

Hi Robert,

Robert Hancock wrote:
> 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.)

No, this wasn't actually the point. I was aware of the
requirement to have the "reception interface" in the Resp-Cookie
and I guess that it is probably sufficiently clear in the spec.
On the other hand: not clear to me what actions the responder can
take with the route change information since it is usually the
querier that has to do something, but I guess that it is actually
up to the NSLP what to do. So if the NLI in the query doesn't change
but the "reception interface" you would consider it as route change?

> 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.

Sure, that's the case we are currently considering.

> 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. 

Really? The node may have changed its point of attachment
and now there may be a really different route/path to it.
So for QoS NSLP at least the reservation must be adapted.

> 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,

Basically, that's correct. But the (PC-)MRI carries addressing
information nevertheless, so this cannot be really hidden as the
application has to be aware of the flow.

> 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. 

Yep, this is clear.

> 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.

Actually we tried to hide the mobility of the node from the
application that uses QoS NSLP, but that wasn't easily possible,
e.g., the application needs to take the overhead by additional
mobility headers etc. into account when defining the QSPEC.
So, currently we think it is good to have an additional
interface where applications can get additional information about
flows if required.

BTW: found some typos in draft-ietf-nsis-ntlp-16:
- p. 28, sec. 4.3.1, Q-Mode Encapsulation: s/wth/with/
- p. 32, sec. 4.3.4, third last sentence: s/mode/made/.

Regards,
 Roland