Re: proposed standard

[Noel Chiappa <[e-mail]>]

	For those who don't know what Martha was referring to when she
mentioned Tony Li and I, here is the relevant message:

	Noel

------------


Date: Mon, 4 May 92 12:50:17 -0400
Message-Id: <[e-mail]>
Subject: Re:  comments on the architecture document


	Martha:

	Tony Li and I have been having a discussion about the ability of
IDPR to support incremental deployment of new 'transit policies' (i.e.
what I call attributes, both of links and nodes). I suggested three
possible ways of handling this:

>	    I'll deal only with how someone who doesn't understand a new
>    attribute uses map elements which are marked with them; actually
>    allocating the new attribute number from the number czar, defining
>    its syntax and semantics, etc, are clearly trivial.
>	    In the simplest algorithm, you simply ignore any links or
>    nodes in your topology map which have attributes you do not
>    understand. You then construct a route using the other links. Of
>    course, this may result in a non-optimal route, or no route at all,
>    when one is possible.
>	    In the next version, all attributes are divided into two
>    classes, informative and restrictive. The former say something about
>    the link, but will not result in any traffic being dropped or
>    refused. You can safely use any link which has informative
>    attributes you do not understand; you may not get great service, but
>    TANSTAAFL. You can't use links which have restrictive attributes you
>    don't understand; your traffic may croak.
>	    In the last version I can think up quickly, links with
>    restrictive attributes have to fail at set-up time if someone who is
>    not allowed to use them mistakenly tries to set-up across them. (You
>    pretty much have to do this policy enforcement anyway, since if you
>    trusted people not to use your links if you simply advertised they
>    couldn't use them, they'd probably discover they could ignore the
>    advertisement and use you anyway. It's also obviously more efficient
>    to do the policy enforcement at set-up time, rather then per-packet;
>    an argument for the set-up version of source routing.) If you do
>    this, you can try using links whose restrictive attributes you don't
>    understand; if you really can't use it, you get bonked. Not very
>    efficient, but...
>	    This also allows you to have have attributes on links which
>    are deliberately *not* globally understood. You may not want
>    everyone to understand your policy markings...
>
> I understand that there are ways of migrating to new types of policies
> and I understand that the ways that you mentioned would work.  I do
> not believe that ANY of them are in the protocol as it stands today.
> I would love it for you to point me to something that I missed.  


Not having read the spec, I couldn't answer his question, but assumed that
at least two strategies could be followed:

>	   I haven't read the protocol spec recently enough to be able to
>   say one way or the other if you missed something. I would assume that
>   you could do either 1 (ignore all links with attributes you don't
>   understand) or 3 (try a setup and see if the access control bounces you)
>   within the existing protocol even with no support in the protocol; i.e.
>   if it's not in the spec, it's upwardly compatible.
>
> By my reading, if you try to stuff "new" items into a policy packet, other
> implementations will (a) ignore you completely or (b) roll over and die.


	I briefly discussed this with you on the phone, and you indicated
that in fact approaches 1 and 3 would work.
	Can you please address Tony's supposition that an implementation
which follows the spec will in some way completely ignore a link-state
update if it contains 'transit policies' which it does not recognize (but
may be able to parse and ignore)?
	Clearly, if the spec for processing incoming link state packets (or
whatever IDPR calls them :-) is written in such a way that packets with
unrecognized attributes are discarded, this will make the protocol much
less able to incrementally deploy new attributes, which I would consider
a major problem.

	Noel