[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,
see answers / clarifications inline;
Les Ginsberg (ginsberg) wrote:
[ ... ]
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.
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)
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.
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)
And, you end up with two versions of the same TLV - one standalone and
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.
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.
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).
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.
i'd treat 226 like than any other leaf (non-SPF relevant) information.
tx,
/hannes
_______________________________________________
Isis-wg mailing list
Isis-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg