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

From: mike shand <[email-masked]>
Date: Thu, 01 Aug 2002 10:00:00 +0100

Manral,

This is VERY important. The specification MUST be restricted to what can be 
observed on the wire. i.e. the packet formats and the operation of the FSM. 
Anything which doesn't affect that has no place in the specification.

In the context of the current discussion about MT, of course the way you 
forward certain data packets as a result of the routing protocol 
information you receive *is* an externally visible phenomenon, and 
therefore the spec has a right (and a duty) to dictate it, but it doesn't 
have a right to dictate the internal mechanisms which you use to achieve 
that required behaviour.

In other words I STRONGLY agree with Tony.

         Mike

At 10:23 31/07/2002 -0700, Tony Przygienda wrote:
>Manral, Vishwas wrote:
>
>>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?
>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.
>
>>
>>It seems to me "document current protocol implementation practices and
>>improvements" is a chartered goal of the working group.
>that always means 'as far as they can affect inteoperability'
>
>    -- tony
>
>
>
>
>
>_______________________________________________
>Isis-wg mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/isis-wg

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

---

From: Naiming Shen <[email-masked]>
Date: Sun, 04 Aug 2002 16:47:07 -0700

We'll put out another version of the MT draft soon. thanks.

 ] 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
 ] 
 ] Tuesday, July 30, 2002, 11:02:40 AM, Tony Przygienda wrote:
 ] > Naiming Shen wrote:
 ] 
 ] >>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
 ] >> ] >=20
 ] >> ] > > In a sense, what you say is correct, if you read the 'MUST' as an=2
0
 ] >> ] > > implementation guideline. The intention
 ] >> ] > > was to say 'provides equivalent functionality to multiple RIBs'. A=
20
 ] >> ] > > better wording, however not to
 ] >> ] > > 'bloated', welcome. I would however strongly disagree to even sugge
st=
 ] >> ] =20
 ] >> ] > > that things can be stored in the
 ] >> ] > > 'same' RIB in some special cases. Just too messy ...
 ] >> ] >=20
 ] >> ] > 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=20
 ] >> ] 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.
 ] >>
 ] > 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 S
PT=
 ] >> ] s,=20
 ] >> ] but not the way packet forwarding is done (as long as packets are forwa
rd=
 ] >> ] ed=20
 ] >> ] according to the SPT associated to a given MT)
 ] >> ] 
 ] >> ] s.
 ] >> ] =20
 ] >> > > As to overlaping address spaces, I agree that the draft is not enough
=
 ] >> ] =20
 ] >> ] > > but anything more (e.g.
 ] >> ] > > looking at stripped labels or other stuff to decide between RIBs) i
s =
 ] >> ] out=20
 ] >> ] > > of the scope of this document.
 ] >> ] >=20
 ] >> ] > 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 mechanis
ms
 ] >> ] > 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.
 ] >>
 ] 
 ] > yepp, let's just hint, enumerations and solutions are outside scope of 
 ] > this draft
 ] 
 ] >     -- tony
 ] 
 ] >>
 ] >>
 ] 
 ] 

- Naiming