Subject: RE: [NSIS] [Fwd: I-D ACTION:draft-bless-nsis-resv-aggr-00.txt]

From: "Shivanajay Marwaha" <[email-masked]>
Date: Thu, 2 Nov 2006 09:57:15 +0800

Hi Roland,
 
I read your I-D and I have two questions:-
 
1. Are you also considering route change detection (in section 3.3) caused by end-host's mobility. 
2. Based on the solution in section 4.4, in a multi-homing scenario (mentioned in section 3.4), will multiple Reserve messages be sent to multiple De-aggregators on individual paths?
 
Regards,
Shiv 

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]] 
> Sent: Thursday, October 19, 2006 5:55 PM
> To: [email-masked]
> Subject: [NSIS] [Fwd: I-D ACTION:draft-bless-nsis-resv-aggr-00.txt]
> 
> Hi all,
> 
> the earlier mentioned draft was now published in the I-D repository:
> 
> -------- Original-Message --------
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: Inter-Domain Reservation Aggregation 
> for QoS NSLP
> 	Author(s)	: R. Bless, M. Doll
> 	Filename	: draft-bless-nsis-resv-aggr-00.txt
> 	Pages		: 19
> 	Date		: 2006-10-18
> 	
>    QoS NSLP is a recently proposed signaling protocol that allows to
>    establish QoS reservations in the Internet.  In order to 
> enable large
>    scale deployment, inter-domain aggregation should be considered as
>    mechanism to allow for the necessary scalability.  This draft
>    describes the major problems that must be solved and proposes also
>    solutions to these problems, requiring only modest 
> modifications and
>    extensions to the currently defined GIST and QoS NSLP 
> specifications.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bless-nsis-resv-aggr-00.txt
> 
> To remove yourself from the I-D Announcement list, send a 
> message to [email-masked] with the word 
> unsubscribe in the body of the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> 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-bless-nsis-resv-aggr-00.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-bless-nsis-resv-aggr-00.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.
> 
> 

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

---

From: Roland Bless <[email-masked]>
Date: Fri, 03 Nov 2006 13:28:26 +0100

Hi Shivanajay,

> I read your I-D and I have two questions:-

Thanks for reading the draft.

> caused by end-host's mobility. 

Basically we consider any route change that affects the inter-domain
routes of existing flows no matter what was its cause.
However, end-host mobility will be mostly
transparent (i.e. not visible) because the host will move within a
domain (using HMIP, NetLMM, etc.). If it is moving between domains it
will usually get a new IP address, and, thus we would consider it to be
a new flow rather than a rerouted flow.

> 2. Based on the solution in section
> 4.4, in a multi-homing scenario (mentioned in section 3.4), will
> multiple Reserve messages be sent to multiple De-aggregators on
> individual paths?

No, you will always send only one RESERVE per flow.
There are different multi-homing solutions, so there are
different effects in case of failures depending on the
specific deployed solution.
If the MRI stays the same, a failure may cause a re-routing
to the alternative provider. The rerouting may or may not
affect the AS path, so sec. 3.3/4.3 applies.

Regards,
 Roland