[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

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

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

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