Subject: [Monami6] Monami6 Filter Rules

From: "Teco_Boot" <[email-masked]>
Date: Wed, 25 Jul 2007 22:00:16 +0200

Hi,
Have we evaluated using the RSVP filter mechanism (Filter_Spec) for Monami6?
Classifying a flow for queue selection (RSVP) and interface selection
(Monami6) looks very similar to me. I think we should try to use what we
already have. 
Teco.

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

---

From: Kazuyuki Tasaka <[email-masked]>
Date: Tue, 31 Jul 2007 15:20:12 +0900

Hello Teco,

> Have we evaluated using the RSVP filter mechanism (Filter_Spec) for Monami6?

I believe that we don't do it yet.

> (Monami6) looks very similar to me. I think we should try to use what we

I also think that classifying a flow for queue selection (RSVP)and
interface selection (Monami6) looks very similar and we should refer
to how to classify a flow and select the interface.

However, there are differences between RSVP and Protocol to set filter 
rules for Monami6. As one difference, RSVP is receiver-oriented, but
Protocol to set filter rules for Monami6 is user-oriented or
operator-oriented. User-oriented means MN(or MR)-oriented and 
operator-oriented means HA-oriented.

For example, when a user need to set up preferences (Section 3.3, 3.4
and 3.5 of Motivations and Scenarios for Using Multiple Interfaces and
Global Addresses), I think that MN or MR should not only set filter
rules for downlink from HA but also set filter rules for uplink.

In the following draft, it is considered.
http://www.ietf.org/internet-drafts/draft-mitsuya-monami6-flow-distribution-policy-03.txt

regards,
kazuyuki

---

From: "Teco_Boot" <[email-masked]>
Date: Tue, 31 Jul 2007 10:01:14 +0200

Hi Kazuyuki,
I understand RSVP is to be used in a different context.
Defining a protocol for classifying traffic is a common attribute.
Using RSVP itself would add IntServ QoS for MIP tunnel, which could be
needed also. So RSVP support could already be implemented and reuse the
filter definition sub-protocol for BU looks an attractive option to me.
Teco.

> -----Original Message-----
> From: Kazuyuki Tasaka [mailto:[email-masked]]
> Sent: dinsdag 31 juli 2007 8:20
> To: Monami6 WG
> Subject: Re: [Monami6] Monami6 Filter Rules
> 
> Hello Teco,
> 
> Teco_Boot wrote:
> > Hi,

---

From: Kazuyuki Tasaka <[email-masked]>
Date: Tue, 31 Jul 2007 21:01:21 +0900

Hi Teco,

> Defining a protocol for classifying traffic is a common attribute.

I agree.

> filter definition sub-protocol for BU looks an attractive option to me.

I think that we should consider reusing if filter definition 
sub-protocol for BU does not depend on RSVP and it is generic. If it is 
not so, we should modify it to define generic filter rules for MONAMI6 
or newly define it.
Could you tell me documents that described filter definition 
sub-protocol for BU?

regards,
kazuyuki

---

From: "Teco_Boot" <[email-masked]>
Date: Tue, 31 Jul 2007 14:46:55 +0200

Hi Kazuyuki,

I am not an RSVP expert. Here a snapshot for checking RSVP Filter_Spec:
RFC2205: RSVP - APPENDIX A. Object Definitions
RFC2746: RSVP Operation Over IP Tunnels
RFC3209: RSVP-TE: Extensions to RSVP for LSP Tunnels

I think RSVP-TE has a similar context as MONAMI6. 

Teco.

> Sent: dinsdag 31 juli 2007 14:01
> To: Teco_Boot
> Cc: 'Monami6 WG'