Subject: RE: [Isis-wg] Comments on draft-ietf-isis-wg-multi-topology

From: "Manral, Vishwas" <[email-masked]>
Date: Wed, 31 Jul 2002 07:30:33 -0400

Hi Tony,

My doubt does not relate to the MT draft, however I have had this doubt for
some time now and thought this may a right time to clarify(in context of the
discussion).

Don't you think items that can be done internally, without affecting
interoperability but can be useful for the ISIS community as a whole be also
pursued by the ISIS-WG?

For example, we know that flooding reduction in meshed topologies is an
important problem to solve in link state protocols, why can the WG actually
work on an approach that may have interoperability concerns and not follow
something that does not, although they solve the same problem. Similar
doubts about other approaches like say refresh-optimization which can be
done totally internally without interoperability concerns. 

It seems to me "document current protocol implementation practices and
improvements" is a chartered goal of the working group.

Thanks,
Vishwas

-----Original Message-----
From: Tony Przygienda [mailto:[email-masked]]
Sent: Wednesday, July 31, 2002 12:43 PM
To: Alex Zinin
Cc: Naiming Shen; stefano previdi; [email-masked]
Subject: Re: [Isis-wg] Comments on draft-ietf-isis-wg-multi-topology

Alex Zinin wrote:

>Folks-
>
> Before I leave the exact wording decisions in the capable hands of
> this WG, I'd like to give my perspective on the issue of the scope of
> this document.
>
> What we have here is not just yet another useful ISIS TLV. We're
> talking about different forwarding behavior and routing calculations
> supporting it. As such, we need to give enough clue to the reader
> about the forwarding process and RIB/FIB construction to make sure we
> do not end up receiving mid-night support calls and troubleshooting a
> permanent routing loop because someone misinterpreted the spec. The
> smart-guys-will- figure-out argument is just not good enough. I do
> not see a problem in giving some generic rules that need to be
> followed and giving some valid examples of the approaches that can be
> used to implement them (as opposed to limiting implementations to
> them only). I guess my point is that routing is too important, so I'd
> rather us err on the side of descriptiveness. It might be a good idea
> to consider adding a separate section that talks about forwarding
> implications...
>

let's maybe take a step back and think about what is the essence of a 
workgroup
document like this given that the raison d'etre of a such a group is 
vendor-interoperability,
nothing more and nothing less. If you're easily bored by ramblings, skip 
1-3 and get to
conclusion at the end

1. It has to specify very precisely what and when shows up on the wire 
between nodes
   in terms of the protocol's packets.
   Those are formats, often supplemented by descriptive rules but it's 
basically syntax.
   This should not be screwed up since otherwise the spec is useless.
   These things mostly map pretty straightforward into implementation.
2. It has to specify a model to be followed of what the nodes do 
internally to get the
   proper protocol packets in and out to their neighbors. It's normally 
described as EFSM, again often
   supplemented by descriptive rules. This is basically semantics and it 
often takes quite
   a few iterations to get it right or a very long time to get the first 
version right.
   A very tight and unambiguous semantics produces hundreds of pages
   (commonly known as ATM Forum, OSI and such specs and traditionally 
despised by IETF folks,
   but loved by people who have to make money reliably from networks) 
and often
   leads to a certain 'rigidity" of the protocol since people tend to 
take 'biblical' positions
   on paragraphs within the spec to defend problems or advantages of 
their implementations
   and deployment scenarios. Within the
   realm of IETF, speed is often preferred over non-ambiguous semantic 
description at a cost
   of iterations and sometimes, ehem, initial interoperability problems.
   Finally, we do not forget  that the model described to exhibit such 
desired semantics is
   _just a model_. By whatever
   implementation means a meaningfull semantic behavior is achieved is 
none of
   the workgroup's business.
3. In Link-states we have the artifact of hop-by-hop forwarding that 
forces us to describe
   a model that produces a coherent 'forwarding-behavior' of the whole 
network, not just
   one node. This is normally done by
   providing people with variations of distributed Dijkstra's or 
Bellman's algorithms which are
   basically very statefull FSMs. It is a wonder that only deems on 
humans in modern
   times that such 'each-on-its-own'
   semantics generates a meaningfull behavior of a larger entity 
(something found also
   in other realms of modern science, people like Hayek being an early 
thinker of the
   whole concept if you have time and inclination for some deeper 
thoughts) .
   The specification of those computation is an aritifact in the sense 
that they
   are purely internal and not exchanged with neighbors so strictly they 
do not need
   standardization under normal circumstances (and e.g. purely 
source-routed protocols
   don't need them, something that still seems a mystery to many folks 
in the context
   of LSPs and CSPF). However, whether those computatons map into RIBs, 
forwarding decisions or
   on-demand computations or even contacting a local psychic is none of the
   workgroup's business. We just want the specific behavior achieved.

If you follow me so far, we should _not_ specify anything about what 
structures
the computations generate in MT, we just describe that to achieve a 
coherent
forwarding behavior, those algorithms and their results must be followed 
by some means
at the implementor's discretion.  So IMHO, we left the scope of our work 
with the
'hint at how many RIBs' and that's how we got into hot water. Saying 
that you run
separate decisions and forwarding must not generate loops would have 
been enough.

After all the rambling, here's my take as what to do: We had 
off-the-list some
discussions with a private application that made a perfect argument for 
a single RIB, it achieves the
semantics intended by a mean that suits its needs so any _MUST_ in terms of
multiple RIBs is redundant and wrong in its context. Alex is right since 
hinting at people with a suggestion that they could do a 'single' RIB 
will land them in hot water more
likely than not. What we should do IMO, is to say 'overlapping addresses 
in different topologies MUST not
lead to undesirable routing behavior such as forwarding loops. Such a 
behavior MAY be
prevented by storing the results of distinct computations in separate 
RIBs. Network configuration and any equivalent of
forwarding logic MUST ensure the same MT is used by all nodes from the 
source to the destination
when dealing with a packet.'

   let's get that converged

   -- tony

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

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 31 Jul 2002 10:23:11 -0700

>interoperability but can be useful for the ISIS community as a whole be also
nope, some attempt at this kind of stuff have proven failures in the 
past ... Just imagine what
will happen if you unknowningly suggest a 'MUST' for an implementation 
technique that some major
competitor of yours cannot incorporate into his deployed, successfull 
implementation. Ultimately,
do you think he'll even care to follow such a 'MUST' ?  And how would 
exactly prove that he
does not follow this 'MUST' ?

There is a small grey area but it is normally better to not get into 
'internal operations or
implementation techniques' unless there is no other choice.

>improvements" is a chartered goal of the working group.
that always means 'as far as they can affect inteoperability'

    -- tony