Subject: RE: I-D ACTION:draft-ietf-mpls-lsp-query-02.txt

From: "Don Fedyk" <[email-masked]>
Date: Tue, 22 May 2001 00:17:41 -0400

Loa

The query draft is general and can be applied to LDP as well
as CR-LDP where it functions analogous to RSVP-TE record route.
An IGP drives topology for both LDP and the TE portions for 
TE based paths.

other comments below:
> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: Monday, May 21, 2001 6:53 AM
> To: Fedyk, Don [BL60:2868:EXCH]
> Cc: Eric Gray; MPLS Mailing List
> Subject: Re: I-D ACTION:draft-ietf-mpls-lsp-query-02.txt
> 
> 
> Don,
> 
> I think Eric and I agreed that perfect/precise knowledge of the
> state of the network is not possible. What I suggested was that
> the IGPgives me the knowledge I need, i.e. good enough.

Good enough if the LDP strictly follows the IGP. But if it 
uses route pining or some form of load spreading a query 
tells like it is.
> 
> The precision/prefection of the knowledge gained by the IGP vs.
> a query is not better or worse, just different.
> 
Agreed, a query is more detailed and not performed as often.

> The situation I talked about was when the dynamic aspect of e.g.
> has changed a link, because of changes in the IGP, not the other
> way around.
> 
Not sure how you change an IGP, but topology changes force recomputation
and new next hops which get reflected into LDP. I wouldn't use query 
to effect this but I might you query to verify some of the LSPs.

> Have you calculated the amount of state that needs to be kept and
> the amount of traffic to be sent and/or received to second-guess
> the IGP - assuming that you uses just ten percent of the available
> label speace?
> 

Not sure I understand your question.
There is no second guessing. The IGP is in tack. The LSPs are in some form
following either an IGP path or a strict explicit path. The query verifies 
a path by following it. Again a query is mostly like a ping or a trace route
with more information pertaining to the LSP. The point I made in my previous

email is that this trace route information can be more accurate than the IGP
TE information but of course the IGP next hop information is accurate. But 
just like ping and trace route the query is a reality check for the IGP and 
may go beyond the scope of an IGP.  You need both. One is not a substitute 
for the other.

Don

> /Loa
> 
> > Don Fedyk wrote:
> 
> > > > Loa,
> > > >
> > > >     Because you cannot have perfect knowledge of the state of
> > > > the network.  What you say about the difference in the state of
> > > > the network between times 't' and 't+n' will also be true of the
> > 
> > > > difference between times 't+(a(n))' and 't+((a+1)(n))'.
> > >
> > > This seems to strengthen what I said. At any point in time, after
> > > just shortly before the receipt of the query response, there is
> > > an uncertainty in the
> > >
> > > > And
> > > > what constitutes 'good enough' knowledge of the state of the
> > > > network may be difficult to standardize - especially without
> > > > some real deployment experience.
> > >
> > > The conservative position would be that you have "good enough"
> > > knowledge from the IGP.
> > 
> > Not really. You have knowledge of aggregates but a query gives you
> > precise
> > information. You don't need to update the IGP every time a path
> > changes
> > you only need to when thresholds have been crossed. As far as
> > knowing when to
> > query it is quite reasonable to keep a path changed state a the end
> > of
> > an LSP that can tell you whether there is change since the last
> > query.
> > 
> > <snip>
> > 
> > Don
> 
> -- 
> Loa Andersson
> Chief Architect,
> Utfors Research, Architecture and Future Lab (URAX)
> Utfors AB
> Råsundavägen 12
> Box 525, 169 29 Solna
> Office          +46 8 5270 2000
> Office direct   +46 8 5270 5038
> Mobile          +46 70 848 5038
> Email           [email-masked]
> WWW             www.utfors.se
>

---

From: Loa Andersson <[email-masked]>
Date: Tue, 22 May 2001 09:02:10 +0200

Don,

if you want to do a traceroute equivalent for MPLS that's fine and
useful, though I thought that that was taken care of by the 
draft-ietf-mpls-icmp-02.txt.

If you want to take any other actions, like rerouting traffic, I 
still haven't seen that what the query gives us is more, more 
useful or more accurate than what we have from the IGP.

Other reflection:
A security section is missing, I would think that there could be 
any number of interesting security issues in this type of scenario.

As for the RSVP-TE RRO is also seems to be more restricted hops,
labels and info on per platform or per interface labels, even though
the authors call the "global". Still haven't really understood
what use a series of labels might be, MPLS just define how
distribution
of labels is done not allocation.

/Loa