

> route taken through any forwarding nodes. this object would be of
> extensibility class AB=10 (forward unchanged) or possibly AB=00  
> (reject
> if unknown). Typically, the
> originating node would only include such an object for diagnostic
> purposes (to
> avoid putting additional processing load on the forwarders).
>
> c') same as (c), but define the object as part of the base  
> specification
> (so all nodes would support it from the start).
>
> d) depend on a future GIST traceroute capability (e.g. the NSIS ping
> approach)
> to discover such forwarding nodes and find out what they are doing.  
> So,
> the
> diagnostics would not be built into the base protocol, but would be
> available as an extension to support investigations if message  
> mangling
> by forwarders turns out to be a problem.
>
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

2 -0400
From: Martin Stiemerling <[email-masked]>
Subject: Re: [NSIS] GIST issue on forwarders introducing errors
Date: Thu, 19 Oct 2006 16:04:04 +0200
To: "Hancock, Robert" <[email-masked]>
Cc: nsis <[email-masked]>

Hi Robert,

My preference is a). Taking care for all sources of implementation  
errors is IMHO just impossible.

   Martin

Am 12.10.2006 um 12:26 schrieb Hancock, Robert:

> Hi all,
>
> An issue has been raised on GIST nodes that process and forward
> messages introducing errors, and how to diagnose such errors.
> It is in the tracker as issue #132
> (http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue132)
> and the summary text
> is included below.
>
> This is a solicitation for input, especially from the
> implementors, on this matter. In the absence of input, my
> preference would be to leave the current protocol unchanged,
> but put stronger guidance in about it - this is essentially
> (a) below, pointing to (c) or (d) as possible future extensions.
> Or, we could extend the current specification along the lines of
> (b) or (c'). Please provide your preferences!
>
> cheers,
>
> robert h.
>
> ==============================================================
> [Following Routing Area Directorate comments from Adrian Farrel]
>
> The GIST specification allows nodes to forward messages, either after
> consultation  with the NSLP (section 4.3.2) or if there is no local  
> NSLP
> (4.3.4). However, the forwarding process does not change the IP header
> or
> included Network-Layer-Information object. This means that any errors
> introduced by the forwarding node will get reported back to the node
> that first originated the message; this will get confused because  
> it is
> being told about error conditions which it was not responsible for.
>
> There are several possible approaches for dealing with this:
>
> a) note more strongly in the text that the forwarder is supposed  
> not to
> change
> any of the GIST payloads, so it should not introduce any errors.
> Disadvantage of this: we have to trust implementations which do
> forwarding to be correctly
> written so that they do not introduce message changes in the process.
>
> b) allow or force the forwarding node to introduce a new object to
> indicate that it has processed the message in some non-trivial way
> (effectively introducing route recording). Probably one would still  
> want
> to report errors to the originator, but the error reporter would also
> include the recorded route to make diagnostics easier. Disadvantage of
> this approach: it makes the implementation of forwarding more complex,
> and in particular rules out implementations which do simple in-place
> modifications of the message (the goal for RMD for example).
>
> c) allow the originating node to include an object which records the
> route taken through any forwarding nodes. this object would be of
> extensibility class AB=10 (forward unchanged) or possibly AB=00  
> (reject
> if unknown). Typically, the
> originating node would only include such an object for diagnostic
> purposes (to
> avoid putting additional processing load on the forwarders).
>
> c') same as (c), but define the object as part of the base  
> specification
> (so all nodes would support it from the start).
>
> d) depend on a future GIST traceroute capability (e.g. the NSIS ping
> approach)
> to discover such forwarding nodes and find out what they are doing.  
> So,
> the
> diagnostics would not be built into the base protocol, but would be
> available as an extension to support investigations if message  
> mangling
> by forwarders turns out to be a problem.
>
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis