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

From: "Les Ginsberg \(ginsberg\)" <[email-masked]>
Date: Thu, 6 Apr 2006 22:35:56 -0700

Hannes -

> -----Original Message-----
> From: Hannes Gredler [mailto:[email-masked]]
> Sent: Thursday, April 06, 2006 2:01 AM
> To: Les Ginsberg (ginsberg)
> Cc: Mike Shand (mshand); Stefano Previdi (sprevidi); Nischal Sheth;
isis-
> [email-masked]
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 10 Apr 2006 10:32:55 +0200

hi les,

Les Ginsberg (ginsberg) wrote:
> [ ... ] 

your explanation around use of the Alias TLV makes sense.
i'll understand now what you had in mind.

 > [ ... ]

you mean other that there *is* a proposed solution for the
'increase subTLV space for TE' problem ;-)

you left the definition of such a TLV outside of the scope of your document,
which is a bummer if the talk is now about scaling reachability information
further, IMO we should not loose the opportunity and spot on there.

so what about rephrasing draft 6.3 as:

6.3     Moving TE Information to Extended LSPs

    One of the major sources of non-SPF related additional information
    in LSPs is the Traffic Engineering (TE) information carried in the
    extended IS reachability TLV (22) as defined in RFC 3784 and RFC
    4205. The restrictions defined in this document prohibit the
    presence of TLV 22 in Extended LSPs. In the event that there is a
    need to advertise TE information in Extended LSPs, it would be
    necessary to define a new TLV to carry the TE information.

    Utilization of a new TLV for TE information would provide additional
    benefits which include:

       . Elimination of the need for redundant IS neighbor TLVs to be
         processed as part of the SPF.

       . Easier support for a set of TE information associated with a
         single link which exceeds the 255 byte TLV limit by allowing
         the interpretation of multiple TLVs to be considered additive
         rather than mutually exclusive.

    Such an extension would require all routers on which the TE
    information is processed to support the new TLV as well as the
    extensions defined in this document.

  6.4     sub-TLV Connector TLV (connector)

    The proposed Connector TLV allows extension-capable ISs to link
    arbitrary subTLV information to existing IS reachability or IP
    reachability information.

          Type   25
          Length # of octets in the value field (1 to 255)
          Value

                                             No. of octets
              +-----------------------+
              | Connected TLV         |     1
              +-----------------------+
              | Connector Key length  |     1
              +-----------------------+
              | Connector Key         |     variable length
              +-----------------------+
              | Sub-TLV length        |     1
              +-----------------------+
              | Sub-TLVs (optional)   |     0 to 254
              +-----------------------+

            Connected TLV

                  TLV number where the subTLV information should be attached to.
                  possible Connected TLV numbers can be 22,222,135,236,237

            Connector Key length

                  Key length of the Connector Key.

            Connector Key

                  Key information where the subTLV information should be attached to.

            Sub-TLVs length

                  Total length of all sub-TLVs.

            Sub-TLVs

               A series of tuples with the same format described in 4.4

            Example 1: link a single admin group subTLV #3 to extd IS reach TLV #22

            Connected Key = 22
            Connector Key length = 7 (IS-reach Neigbor length)
            Connector Key = 1921.6801.0001.00
            Sub-TLV total length 6
            Sub-TLV Type 3
            Sub-TLV length 4
            Sub-TLV Value 0x00000000

            Example 2: link a swithing Cap descr subTLV #21 to MT IS reach TLV #222

            Connected Key = 222
            Connector Key length = 2+7 (MT length + IS-reach Neigbor length)
            Connector Key = Topology 2, 1921.6801.0001.00
            Sub-TLV total length 41
            Sub-TLV Type 21
            Sub-TLV length 39
            Sub-TLV Value { xxxx }

            Example 3: link a 64-bit admin-tag subTLV #2 to IP6 reach TLV #226

            Connected Key = 226
            Connector Key length = 4 (variable length encoding of IP6 prefix)
            Connector Key = 2000:1234/32
            Sub-TLV total length 10
            Sub-TLV Type 2
            Sub-TLV length 8
            Sub-TLV Value 0x0000000000000001

--

/hannes