Subject: [Isis-wg] An alternative to RFC 3786

From: "Les Ginsberg \(ginsberg\)" <[email-masked]>
Date: Mon, 20 Feb 2006 08:30:06 -0800

Folks -

IS-IS has a limited space to advertise TLVs for a given system-id (256
fragments * the maximum fragment size (nominally 1492 bytes). This space
is quite generous when the only advertisements we need to be concerned
with are reachability advertisements (neighbors, leaf nodes). However,
ever since the days when TE extensions were first introduced, there has
been concern about how to cope with what happens if the additional
non-routing information the protocol is being asked to carry exceeds the
carrying capacity of the LSP set.

RFC 3786 was defined as a means of addressing this problem. However, RFC
3786 introduces interoperability issues with systems which do not
support the extensions defined therein. These issues were addressed by
the following:

a)the introduction of two operating modes. Mode 1 is specified in cases
where not all systems support the extensions. Mode 2 for when there are
no legacy systems.
b)Mode 2 also introduces changes to the SPF rules for considering LSPs
to allow the normal LSPs and extended LSPs to be considered as a single
set.

(See RFC 3786 for details)

I have long thought that a simpler means of solving the limited LSP
space
problem could be used if we recognized that the extended LSP space is
only
required to advertise information not used for the SPF computation.

I recently discussed this idea with two of the authors of RFC 3786 and
received positive responses. However, given the existence of RFC 3786,
I thought it prudent to ask the WG the following questions before
beginning the normal discussion procedures:

Is the introduction of a simplified replacement for RFC 3786 of
interest?
Are there any existing deployments of RFC 3786?

Thanx in advance for your feedback.

   Les

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

---

From: Saravana Kumar <[email-masked]>
Date: Tue, 21 Feb 2006 15:43:44 +0800

Les,

We have implemented this sometime back in 2003 and its been deployed in
the field since late 2004. Our implementation is based on RFC 3786 but
is somewhat simplified in the sense that, irrespective of the mode, we
always ensure that the lower order TLVs (NBR, area etc) are present only
in the original LSP set. This elimiates the need for adding extra
complexities in the implementation, like for instance the mechanism to
keep track of which (Extended) LSPSet a particular peer is being
advertised in and use that extended virtual system id to form
adjacencies with the peer. 

If I were to change RFC 3786 it would be something along these lines. I
would also eliminate the mode-2 support while still keeping the SPF
rules to consider the original and extended LSPs as a single LSP set
(optional).

I'am interested in knowing what alternative approach you are planning
and how it is better/simpler than RFC 3786. 

- Saravana

> -----Original Message-----
> From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
> Sent: Tuesday, February 21, 2006 12:30 AM
> To: [email-masked]
> Subject: [Isis-wg] An alternative to RFC 3786
> 
> 
> 
> Folks -
> 
> IS-IS has a limited space to advertise TLVs for a given 
> system-id (256 fragments * the maximum fragment size 
> (nominally 1492 bytes). This space is quite generous when the 
> only advertisements we need to be concerned with are 
> reachability advertisements (neighbors, leaf nodes). However, 
> ever since the days when TE extensions were first introduced, 
> there has been concern about how to cope with what happens if 
> the additional non-routing information the protocol is being 
> asked to carry exceeds the carrying capacity of the LSP set.
> 
> RFC 3786 was defined as a means of addressing this problem. 
> However, RFC 3786 introduces interoperability issues with 
> systems which do not support the extensions defined therein. 
> These issues were addressed by the following:
> 
> a)the introduction of two operating modes. Mode 1 is 
> specified in cases where not all systems support the 
> extensions. Mode 2 for when there are no legacy systems. 
> b)Mode 2 also introduces changes to the SPF rules for 
> considering LSPs to allow the normal LSPs and extended LSPs 
> to be considered as a single set.
> 
> I have long thought that a simpler means of solving the 
> limited LSP space problem could be used if we recognized that 
> the extended LSP space is only required to advertise 
> information not used for the SPF computation.
> 
> I recently discussed this idea with two of the authors of RFC 
> 3786 and received positive responses. However, given the 
> existence of RFC 3786, I thought it prudent to ask the WG the 
> following questions before beginning the normal discussion procedures:
> 
> Is the introduction of a simplified replacement for RFC 3786 
> of interest? Are there any existing deployments of RFC 3786?
>

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 23 Feb 2006 16:35:34 +0100

hi les,

some comments inline;

Les Ginsberg (ginsberg) wrote:
[ ... ]
> required to advertise information not used for the SPF computation.

well, since the original problem statement has been too store
TE information attached to (extd)ID-REACH i would be curious to
see your proposal - i am particularly interested
how to solve the problem of detaching TE information from
SPF relevant (=extd-IS-reach) TLVs ...

> Is the introduction of a simplified replacement for RFC 3786 of

i do not sense fragment space exhaustion b/c of IS-reach
advertisments as a real production problem today.

typically the biggest fragment-hog is the L1L2 router when performing
route leaking.

the largest networks L1L2 routers consume 20-50 fragments mostly
for ext-IP reach TLVs today. i am not sure if the
the "only" 80% headroom left problem should be
tackled at all.

> Are there any existing deployments of RFC 3786?

none that i am aware of.

tx,

/hannes