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

From: stefano previdi <[email-masked]>
Date: Tue, 23 Jul 2002 10:59:01 +0200

Hi Naiming,

just a few comments on draft-ietf-isis-wg-multi-topology. 

> 9.  MT SPF Computation
> 
>    Each MT MUST run its own instance of the decision process.
>    The LSP overload bit and pseudo-node LSPs are used by all topologies
>    during computation.  Reverse connectivity check within SPF MUST
>    follow the according MT to assure the bi-directional reachability.
>    The results of each computation MUST be stored in a separate RIB,
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    otherwise overlapping addresses in different topologies could
>    lead to undesirable routing behavior such as forwarding loops. 

I believe that use of overlapping addresses will require more than just 
separate RIBs. When the router will receive an IP packet, it will have to use 
some other mechanisms (than just IP destination address lookup) in order to 
determine which RIB it has to use to forward such packet (especially when you 
play with multiple topologies in the same address family).

Therefore I found the following statement: "MUST be stored in a separate RIB" 
a bit extreme and not totally correct. It's not needed in all cases and, in 
the cases where it's needed (assuming overlapping addresses are used), it's 
not enough to ensure correct forwarding.

Of course if you use a separate set of adjacencies/interfaces for each 
topology, then you're safe... but this means a complete overlay network and I 
believe it's not the scope of the MT-ISIS draft...

So, I would suggest to drop the "MUST be stored in a separate RIB" and add a 
more generic statement saying that if multiple RIBs are used (because of 
overlapping addresses), then the forwarding layer MUST have a mechanism 
allowing correct RIB selection for incoming packets.

> 9.1 Generic MT SPF (GSPF) for Network Management

[...]

>    Implementations SHOULD allow the administrator to control the
>    setting of MT Management Color to specific prefixes of the router
>    and the setting of Generic MT SPF to install the MT Mangement
>    colored routes into specific RIB. It is recommended for the
>    administrator's to ensure consistent configuration of all routers
>    in the domain to prevent undesirable forwarding behavior.

####
Same here. If you use unique addresses for your management MT, then you don't 
need a separate RIB. Otherwise you also need the forwarding layer to decide 
which RIB to use.... and in this particular case it's not trivial.
####

s.

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

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 23 Jul 2002 09:00:14 -0700

>>   The results of each computation MUST be stored in a separate RIB,

Stefano, here's my opinion modulo Naiming's one

In a sense, what you say is correct, if you read the 'MUST' as an 
implementation guideline. The intention
was to say 'provides equivalent functionality to multiple RIBs'. A 
better wording, however not to
'bloated', welcome. I would however strongly disagree to even suggest 
that things can be stored in the
'same' RIB in some special cases. Just too messy ...

As to overlaping address spaces, I agree that the draft is not enough 
but anything more (e.g.
looking at stripped labels or other stuff to decide between RIBs) is out 
of the scope of this document.

>believe it's not the scope of the MT-ISIS draft...
nope

>allowing correct RIB selection for incoming packets.
again, better wording welcome and IMHO the mechanism can be hinted at 
but it is outside the
scope.

    -- tony

---

From: Alex Zinin <[email-masked]>
Date: Tue, 23 Jul 2002 14:51:42 -0700

> 'same' RIB in some special cases. Just too messy ...

Exactly. In fact, I think it was a "SHOULD" or "MAY" at first, and
I suggested it is changed to a "MUST" for this very reason.

> of the scope of this document.

I remember having the same concern when reviewing the first version
of this draft a year ago. Since I'm not the only one, what we could
probably do is describe (as opposed to specify) or enumerate mechanisms
that could potentially be used to associate an incoming packet with
a specific topology and RIB, i.e., a somewhat descriptive hint :)

Alex

---

From: stefano previdi <[email-masked]>
Date: Tue, 30 Jul 2002 16:08:28 +0200

> I suggested it is changed to a "MUST" for this very reason.

I still believe that "MUST" is introducing constraints that are outside the 
scope of this draft.

I believe this draft is intended to describe a way to build different SPTs, 
but not the way packet forwarding is done (as long as packets are forwarded 
according to the SPT associated to a given MT)

s.

---

From: Naiming Shen <[email-masked]>
Date: Tue, 30 Jul 2002 10:02:21 -0700

Stefano,

 ] On Tuesday 23 July 2002 23:51, Alex Zinin wrote:
 ] > Tuesday, July 23, 2002, 9:00:14 AM, Tony Przygienda wrote:
 ] > > Stefano, here's my opinion modulo Naiming's one
 ] > 
 ] > > In a sense, what you say is correct, if you read the 'MUST' as an 
 ] > > implementation guideline. The intention
 ] > > was to say 'provides equivalent functionality to multiple RIBs'. A 
 ] > > better wording, however not to
 ] > > 'bloated', welcome. I would however strongly disagree to even suggest ]  
 ] > > that things can be stored in the
 ] > > 'same' RIB in some special cases. Just too messy ...
 ] > 
 ] > Exactly. In fact, I think it was a "SHOULD" or "MAY" at first, and
 ] > I suggested it is changed to a "MUST" for this very reason.
 ] 
 ] I still believe that "MUST" is introducing constraints that are outside t ] he 
 ] scope of this draft.

I sort of agree with you that "SHOULD" is a better wording in this case.
We advice people this should be the way to do things, but if someone has
a creative mechanism also make it work, we probably don't care, its
internal to the box.

 ] 
 ] I believe this draft is intended to describe a way to build different SPT ] s, 
 ] but not the way packet forwarding is done (as long as packets are forward ] ed 
 ] according to the SPT associated to a given MT)
 ] 
 ] s.
 ]  
 > > As to overlaping address spaces, I agree that the draft is not enough ]  
 ] > > but anything more (e.g.
 ] > > looking at stripped labels or other stuff to decide between RIBs) is  ] out 
 ] > > of the scope of this document.
 ] > 
 ] > I remember having the same concern when reviewing the first version
 ] > of this draft a year ago. Since I'm not the only one, what we could
 ] > probably do is describe (as opposed to specify) or enumerate mechanisms
 ] > that could potentially be used to associate an incoming packet with
 ] > a specific topology and RIB, i.e., a somewhat descriptive hint :)

I also feel that the wording "additional mechanism MAY be used to resolve 
 the topology identity of the incoming IP packets on the interface."
is a good enough hint. Since whatever more specific we hint, people don't
have to follow; some implementation can come up a neat way to leave the
hint obsolete. I personally don't see this "overlapping IP space on the
same interface" is the way to use MT extensions.

thanks.

 ] > 
 ] > Alex
 ] > 
 ] > 
 ] > 
 ] > >>Of course if you use a separate set of adjacencies/interfaces for eac ] h 
 ] > >>topology, then you're safe... but this means a complete overlay netwo ] rk 
 ] and I 
 ] > >>believe it's not the scope of the MT-ISIS draft...
 ] > >>
 ] > > nope
 ] > 
 ] > >>So, I would suggest to drop the "MUST be stored in a separate RIB" an ] d 
 ] add a 
 ] > >>more generic statement saying that if multiple RIBs are used (because ]  of 
 > >>overlapping addresses), then the forwarding layer MUST have a mechani ] sm 
 ] > >>allowing correct RIB selection for incoming packets.
 ] > >>
 ] > > again, better wording welcome and IMHO the mechanism can be hinted at ]  
 ] > > but it is outside the
 ] > > scope.
 ] > 
 ] > 
 ] > >     -- tony
 ] > 
 ] > 

- Naiming

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 30 Jul 2002 11:02:40 -0700

Naiming Shen wrote:

> ] >=20
> ] > > In a sense, what you say is correct, if you read the 'MUST' as an=20
> ] > > was to say 'provides equivalent functionality to multiple RIBs'. A=20
> ] > > 'bloated', welcome. I would however strongly disagree to even suggest=
> ] =20
> ] >=20
> ] I still believe that "MUST" is introducing constraints that are outside t=
> ] he=20
> ] scope of this draft.
>
thinking twice about it, ok, you guys have a point but please, under no 
circumstances suggest that
things could be in a single RIB but strongly direct in the direction of 
two cleanly disjoint RIBs.

>
>
> ] 
> ] I believe this draft is intended to describe a way to build different SPT=
> ] s,=20
> ] but not the way packet forwarding is done (as long as packets are forward=
> ] ed=20
> ] =20
> > > As to overlaping address spaces, I agree that the draft is not enough=
> ] =20
> ] > > looking at stripped labels or other stuff to decide between RIBs) is =
> ] out=20
> ] >=20

yepp, let's just hint, enumerations and solutions are outside scope of 
this draft

    -- tony

---

From: Alex Zinin <[email-masked]>
Date: Tue, 30 Jul 2002 14:19:51 -0700

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

 Thanks.
 
-- 
Alex

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 31 Jul 2002 00:12:34 -0700

> to consider adding a separate section that talks about forwarding

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

---

From: stefano previdi <[email-masked]>
Date: Wed, 31 Jul 2002 13:30:01 +0200

> when dealing with a packet.'

I agree.

s.