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

From: "Les Ginsberg \(ginsberg\)" <[email-masked]>
Date: Tue, 21 Feb 2006 10:29:10 -0800

Saravana -

Thanx for the feedback.
It sounds to me that what we have in mind is very similar to what you
have implemented - which is good!!

As soon as I have a clearer indication that it makes sense to go forward
I will make available a draft which will provide all the details.

   Les

> -----Original Message-----
> From: Saravana Kumar [mailto:[email-masked]]
> Sent: Monday, February 20, 2006 11:44 PM
> To: Les Ginsberg (ginsberg)
> Cc: [email-masked]
> Subject: RE: [Isis-wg] An alternative to RFC 3786
> 
> 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.
> >
> > (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
> >

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

---

From: "Les Ginsberg \(ginsberg\)" <[email-masked]>
Date: Thu, 23 Feb 2006 10:38:28 -0800

Hannes -

Thanx for your reply.
Inline.

> From: Hannes Gredler [mailto:[email-masked]]
> Sent: Thursday, February 23, 2006 7:36 AM
> Subject: Re: [Isis-wg] An alternative to RFC 3786
> 
> hi les,
> 
> some comments inline;
> 
> Les Ginsberg (ginsberg) wrote:
> [ ... ]
> > 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.
> 
> 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 ...
> 

That issue will be discussed in the proposal. (Sneak preview: there is
no magic.)

> > 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?
> 
> i do not sense fragment space exhaustion b/c of IS-reach
> advertisments as a real production problem today.
> 

Neither do we. However, given the continued introduction of additional
non-routing information to be carried by the IGPs (and more on the way)
- it is a possibility. If RFC 3786 was not already defined, I think we
would all be happy to wait until the problem became more imminent. But
given the existence of RFC 3786, the concern is that when the problem
has to be addressed there won't be enough time to agree on an
alternative. Once RFC 3786 has significant deployment, it becomes much
more difficult to advocate an alternative. So this is primarily an
attempt to get what we think is the better alternative in place while
there is still an opportunity to do so.

   Les

> 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