Subject: [NSIS] GIST Inbound/reception interface

From: Roland Bless <[email-masked]>
Date: Fri, 11 Jul 2008 10:36:09 +0200

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.

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?

Regards,
 Roland
_______________________________________________
nsis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nsis

---

From: "Robert Hancock" <[email-masked]>
Date: Mon, 14 Jul 2008 04:06:14 -0400

hi roland.

interesting questions: 

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]] 
> Sent: 11 July 2008 04:36
> To: Hancock, Robert
> Cc: [email-masked]
> Subject: GIST Inbound/reception interface
> 
> Hi Robert,
> 

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. 

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

---

From: Roland Bless <[email-masked]>
Date: Mon, 14 Jul 2008 15:00:56 +0200

Hi Robert,

> thought this was clear in section 7.1.2 but it isn't; it will be 

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?

> several and/or changing addresses assigned on a given interface.

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

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

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

> then determining internal vs. external from address alone is

Yep, this is clear.

> 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