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

From: "Les Ginsberg \(ginsberg\)" <[email-masked]>
Date: Mon, 10 Apr 2006 23:46:08 -0700

Hannes -

> -----Original Message-----
> From: Hannes Gredler [mailto:[email-masked]]
> Sent: Monday, April 10, 2006 1:33 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
> 
> 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.
> 

I do not disagree. The first version of the draft focused on the
definition of the solution framework. I did not want to distract from
that by defining "TLV 22a".

But, if the framework defined is accepted - and the consensus of the
group is that we should also include definition of "TLV 22a" in this
draft (whatever form that may take) - I have no problem with that.

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

I am not so sure I like this. Essentially what you are defining is a
generic TLV aliasing capability i.e. assigning a single TLV which can be
used to contain any other TLV which would otherwise be illegal to send
in an extended LSP. If I thought this was a generic capability we needed
(i.e. there were a lot of TLVs I couldn't send in extended LSPs that I
needed to do so to get the non-routing sub-TLVs advertised) - then I
might be inclined to look at your solution. But, I don't expect that.
And, you end up with two versions of the same TLV - one standalone and
one embedded in your connector TLV - with subtle format differences -
which doesn't seem like a win for the parsing logic.

I take the point however, that it is conceivable that the issues
associated with TLV 22 could arise with TLV 222 (MT IS neighbor) as
well.

As for TLV 226, I suspect that we may have to open the door for Prefix
advertisements to be allowed in extended LSPs. Considering an MT world
where IPV4, IPv6, multicast are all separate topologies - and the
possibility of that in combination with L1-L2 leaking without judicious
summarization and/or domain wide prefix distribution - I am wondering if
we can get away without allowing this. On this last point I invite other
comments - as the initial version of the draft prohibits even leaf node
info in extended LSPs for reasons of simplicity.

  Les

> --
> /hannes

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 11 Apr 2006 22:50:05 +0200

hi les,

see answers / clarifications inline;

> draft (whatever form that may take) - I have no problem with that.

i guess for clarity we first need to define what the problem is ;-)

is it

a.  scaling subTLV information of TLV22 further (= TLV 22a)
b.  scaling subTLV information of any parent TLV further (generic subTLV
     connector)

>>          Length # of octets in the value field (1 to 255)

well, thats the idea - key non SPF relevant subTLV information carried
in extended fragments to SPF relevant (MT)IS/IP reach TLV carried in non-extended
fragments (see Example 1)

> one embedded in your connector TLV  with subtle format differences -

i have no intententions to double-define all the extistent TLVs for
extended fragments - for simplicy reasons i'd like to have one generic container that
can hold subTLVs of all kind. furthermore the header of that container should be
flexible enough to attach the 'connected' subTLV information to any kind
of 'connected' parent TLV, hence the key-length and key fields;
this warrants scalability for present and future TLVs (capability subTLVs
come into mind)

> which doesn't seem like a win for the parsing logic.

i don't think that the extra parsing and data insertion logic,
would hurt to much given the benefit over overcoming an architectural
deficit (8bit length field) that each of the newer TLVs suffers.

> associated with TLV 22 could arise with TLV 222 (MT IS neighbor) as

that was the main idea - have a generic (and extensible) way of attaching
subTLV information to any kind of parent TLV. note that example 3 was only
given for illustrating the idea ( btw i don't expect an V6 prefix to carry more
64-Bit tags that fit into a single subTLV).

> info in extended LSPs for reasons of simplicity.

i'd treat 226 like than any other leaf (non-SPF relevant) information.

tx,

/hannes