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

From: [email-masked]
Date: Wed, 16 May 2001 07:02:24 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title		: MPLS LDP Query Message Description
	Author(s)	: P. Ashwood-Smih, A. Paraschiv
	Filename	: draft-ietf-mpls-lsp-query-02.txt
	Pages		: 17
	Date		: 15-May-01
	
This document describes the encoding and procedures for three new LDP
messages, the Query Message and Query-Reply Message and Partial
Query-Reply Message (the last one is almost identical to the Query-
Reply message; therefore all references to the Query-Reply messages
imply the Partial Query-Reply messages as well, unless otherwise
specified).  An LER sends a Query message when it needs to find out
information about an LSP. The Query message is sent for an
established LSP.  The Query message can be used for LDP LSPs as well
as for CR-LSPs.  The queried data is encoded into the Query-Reply
messages. The Query Message carries only the list of hops.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-query-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-lsp-query-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-lsp-query-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Loa Andersson <[email-masked]>
Date: Thu, 17 May 2001 11:04:24 +0200

All,

something that struck me, draft-ietf-mpls-lsp-query-02.txtabout 
having read only the the abstract and leafed through the draft.
LDP LSPs and the lose parts of CR-LDP LSPs have a certain dynamic
character, i.e. when a next hop changes the LSP follow that change.

How is a possible change in network topology co-ordinted when a 
querry message is sent. Given that we receive the respnse to a querry
at "t" and some time later "t+n" a topology change occurs. Do we 
need to re-send querries each time "something" happen? Or do we try
to calculate if a particular LSP has changed becasue of the topology
change.

/Loa

-- 
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: Eric Gray <[email-masked]>
Date: Thu, 17 May 2001 09:32:58 -0400

Loa,

    I think that the whole query mechanism is being suggested because
people want to check from time to time to see where an LSP is going
at some time.  The only conceivable reason for wanting to do this is a
direct result of the dynamism you mention.  Consequently, I think you
are getting the cart before the horse - you send a query to find out if
the LSP has changed and (from time to time) you send others.  Maybe
you do this because you've experienced some 'aftershocks' of route
changes (such as a storm of LSAs), or maybe you do it periodically.

    You don't need a mechanism to detect when the last query is out of
date - the existence of a query mechanism, all by itself, means you
believe that the information can become stale.  Therefore, having some
means to detect when this is more likely can be seen as a nice to have
- but unnecessary - optimization.

--
Eric Gray

---

From: Loa Andersson <[email-masked]>
Date: Thu, 17 May 2001 23:24:46 +0200

Eric,

I don't know much about horses (or carts) but if I read you correct
what I get from the querry is that I know a situation at the point
in time when (or shortly before) I receive the querry response! But 
I can't rely on that info if I want to take some actions at that point
in time or later. Why should this be a "nice to have"?

/Loa

---

From: Eric Gray <[email-masked]>
Date: Thu, 17 May 2001 17:52:38 -0400

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))'.  And
what constitutes 'good enough' knowledge of the state of the
network may be difficult to standardize - especially without
some real deployment experience.

    I am not particularly for or against this particular draft, but
I do not know that it makes sense to try to dictate when it
makes sense to use a query mechanism if we have one.

--
Eric Gray

---

From: Loa Andersson <[email-masked]>
Date: Fri, 18 May 2001 07:26:50 +0200

Eric,

Eric Gray wrote:
> 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

The conservative position would be that you have "good enough"
knowledge from the IGP.

> makes sense to use a query mechanism if we have one.

Sorry, was not trying to dictate "when" the use of the query, 
rather asking if the knowledge you will get from the query would be 
worth the effort. But on the other hand I don't want to dictate
the "non-when" either.

Query along, just be aware of the "unreliable" nature of the response.
I would be extremely cautious to take any critical decision 
based on that "knowledge".

/Loa

---

From: Eric Gray <[email-masked]>
Date: Fri, 18 May 2001 10:47:44 -0400

Loa,

    I understand your point, now, and agree.

--
Eric Gray