Subject: [Isis-wg] draft-ietf-isis-genapp

From: "Ilya Varlashkin" <[email-masked]>
Date: Mon, 1 Sep 2008 18:06:32 +0200

Hi All,

I've went once more through the draft and have few questions. 

1) What correct implementation should do if it received GENINFO TLV when
specific node doesn't have a client for arbitrary Application ID or when
it has given AppID but expected different format of the address?

2) Should address info really belong to GENINFO TLV itself and not to
e.g. "Additional Application Specific Info"? Consider GENAPP is used to
carry info about multiple AFI (e.g. IPv4, IPv6, VPNv4) for given node.
Wouldn't it be better to pack address along with AFI info either in
sub-TLV or in App-Specific info section of the TLV? Such approach could
avoid confusion as to which AFI address belong to when same application
(AppID) is used with multiple AFI.

3) Section 3.3 restricts usage of GENAPP for experimental and
propriatory usage. Does it have to be so? Considering that GENAPP
doesn't really care what's inside App-Specific info, then anyone could
potentially put any sort of info to it (and take responsibility within
his/her realm for doing so), is it really bad? For example, I may want
to experiment with distribution of some network information using GENAPP
but I'm not yet sure whether it will benefit community at large or only
specific part of it, so this is sort of experiment. Doing so do I make
implementation non-compliant?

4) To section 4.1: it may sometimes be desirable to do selective
downwards leaking based on either AppID or even app-specific info (e.g.
I want some App's be leaked across whole Level1-level2-level1 path,
while others only Level1-Level2 and no further). Would it make sense to
add a word that this is valid thing to do? This is mostly to prevent
problems when one implementation provides such selective leaking
facility, while the other one (found on the same network) assumes that
is somebody leaked something then information was complete (and use it
for any sort of integrity/sanity) checking.

5) To section 5: while it's definetely desirable to use multiple
instances, does it have to be restricted at the implementation level or
could choice be left to network operator (with defaulting to multiple
instances if GENAPP extentions are enable)?

6) Should or should not GENAPP extention be turned off by default and
enabled only by explicit knob (as follow-up on item (5) above)?

Kind regards,
iLya
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 16 Sep 2008 23:46:39 -0700

Ilya -

I have been away - but I do not see that any response to your questions
has been sent in the interim - so hopefully this belated reply is still
useful.

Inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Ilya Varlashkin
> Sent: Monday, September 01, 2008 9:07 AM
> To: IETF IS-IS
> Subject: [Isis-wg] draft-ietf-isis-genapp
> 
> Hi All,
> 

Section 2 states:

" The manner in which the information contained in GENINFO TLVs is
   exchanged between an instance of the IS-IS protocol and the
   application which generates/consumes the GENINFO is outside the scope
   of this specification."

Logically, if there is no consumer for information on a given router the
information is simply unused.

As far as format issues, that would represent a bug either in the
originator of the information or the consumer - which again is out of
scope for this draft (IS-IS is serving only as the transport and is not
directly responsible for the correctness of the information). But
generally information which appears erroneous in some way is best
ignored.

> (AppID) is used with multiple AFI.

The inclusion of IPv4/IPv6 address information is optional - note the
use of the I/V bits to indicate whether these fields are present. It is
expected that the use of these fields would be a common practice.
Providing an encoding scheme in the generic portion of the TLV
eliminates the need for each application to define a subTLV for this
information and is therefore more efficient. However a given application
can choose NOT to include these fields.

> propriatory usage. Does it have to be so?

YES!!

> Considering that GENAPP

The requirement is that users of GENAPP get IANA assignments for both
the Application ID and any application specific subTLVs they require.

If you want to play around with proprietary stuff please use TLV 250
(draft-ietf-isis-experimental-tlv-05.txt).

> for any sort of integrity/sanity) checking.

I believe what is specified in Section 3.1 supports what you are
describing. Note that the S/D bits apply to a single TLV - which is
always associated with one - and only one - application.

> instances if GENAPP extentions are enable)?

Note that Section 5 uses "SHOULD" - not "MUST".

> enabled only by explicit knob (as follow-up on item (5) above)?

I am not clear on your question here.

As far as originating information, it seems clear that some
configuration would be required in order to enable an application on a
given router. This is, of course, out of scope of the draft.

As far as flooding is concerned, IS-IS protocol forbids the modification
of an LSP generated by one IS by another IS - so if GENAPP information
is inserted it will always be flooded w/o modification by other routers.

Inter-level leaking is another matter of course - but if a router
supports the draft and it receives an LSP which contains a GENINFO TLV
then it MUST follow the specified procedures regarding the S/D bits.

   Les