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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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,
> 
> 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?

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.

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

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.

> 
> 3) Section 3.3 restricts usage of GENAPP for experimental and
> propriatory usage. Does it have to be so?

YES!!

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

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

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

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.

> 
> 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)?

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

> 
> 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)?

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


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