[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Isis-wg] Simplified Extension of LSP Space for IS-IS Draft
Hannes -
> -----Original Message-----
> From: Hannes Gredler [mailto:hannes at juniper.net]
> Sent: Monday, April 10, 2006 1:33 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
>
> 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
Isis-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg