RE: [Isis-wg] Simplified Extension of LSP Space for IS-IS Draft

["Les Ginsberg \(ginsberg\)" <ginsberg at cisco.com>]

Hannes -

> -----Original Message-----
> From: Hannes Gredler [mailto:hannes at juniper.net]
> Sent: Thursday, April 06, 2006 2:01 AM
> To: Les Ginsberg (ginsberg)
> Cc: Mike Shand (mshand); Stefano Previdi (sprevidi); Nischal Sheth;
isis-
> wg at ietf.org
> Subject: Re: [Isis-wg] Simplified Extension of LSP Space for IS-IS
Draft
> 
> les,
> 
> i have read through your draft and do think that there may
> be a simpler fix to all of the fragment scalability problems.
> 
> basic idea is to introduce a kind of connector-TLV
> where you can link arbitrary information to a diffent sysid
> in an additive fashion. unlike the IS ALias TLV it does not
> work at the SPF level but rather at the TLV parser level
> inside a router which extracts information and adds it
> to the internal representation of the LSDB.

I do not see how your connector-TLV differs from the Alias TLV.
I would also point out that the comment that the Alias TLV "work at the
SPF level" is not valid. Section 4.2.1 of the draft says:

"Information which is directly utilized in the SPF calculation MUST 
   NOT appear in an Extended LSP."

> 
> ---
> 
> for example lets assume that a node has two sysids
> 
> 1921.6800.1001  (main sysid)
> 1720.1600.1001  (leaf sysid)
> 
> in the main LSP we announce all SPF relevant information.
> 
> <lsp sysid=1921.6800.1001>
>    <area>
>    <nlpid>
>    <te-id>
>    <ip-interface>
>    <hostname>
>    <extd IS reach>
>       <neighbor sysid = xxxx.xxxx.xxxx metric 3000 no-subltv>
>    </extd IS reach>
> </lsp 1921.6800.1001>
> 
> in the leaf LSP we announce all non-SPF relevant information
> 
> <lsp sysid=1720.1600.1001>
>    <connector sysid=1921.6800.1001>
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    <extd IS reach>
>       <neighbor sysid=xxxx.xxxx.xxxx metric 0>

Why metric 0 here? Wouldn't max-metric be safer and more consistent with
RFC 3784?

>         <unreserved bandwidth>
>    </extd IS reach>
> 
>    /* occurence of a connector TLV links all TLV / subTLV
>       information found in that fragment in an additive fashion.
>       so we may repeat the extd-IS reach attribute with different
subTLV
> content.
>     */
> 
>    <extd IS reach>
>       <neighbor sysid=xxxx.xxxx.xxxx metric 0>
>         <interface-address>
>         <neighbor-address>
>         <unreserved bandwidth>
>    </extd IS reach>
> 
> </lsp 1720.1600.1001>
> 
> a receiving router should add all information found in a fragment
> containing the connector TLV in an additive fashion upon installation
in
> the
> local representation of the LSDB. for subTLV information the
higher-level
> TLV information serves as key. (in our example sysid is the key for
any
> subTLVs
> linked)
> 
> what needs to be taken care is security/purging related stuff if some
> external node
> wants to link information.
> 
> what do you think ?

As far as I can tell, the only difference between what the draft
proposes and your proposal is that in your proposal we would not have to
define a new TLV (call it "22a") to announce the TE sub-TLV information
normally associated with TLV 22. Whether this is better or not is
arguable - but at most I see this as not much more than a cosmetic
difference.

Treating the same TLV in two different ways based on whether it is found
in an extended LSP vs an original LSP is possible - but it has a risk in
that it IS a neighbor reachability TLV - although it is not intended to
be used in the same way as a neighbor reachability TLV. So long as no
system ever advertises a neighbor to the "leaf sysid" (which should not
happen), this should not cause a problem because the 2-way connectivity
check will prevent even legacy systems from mistakenly using this in
their SPF - and the use of maxmetric further protects against misuse. 

But I don't see that your proposal differs in any significant way from
the draft.

   Les
> 
> /hannes
> 
> 
> Les Ginsberg (ginsberg) wrote:
> > Folks -
> >
> > The draft describing the alternative to RFC 3786 is now available.
> >
> >
http://www.ietf.org/internet-drafts/draft-ginsberg-isis-extlsp-00.txt
> >
> >    Les

_______________________________________________
Isis-wg mailing list
Isis-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg