Hi Teco,
Thank you for your response.
As you say, it might serve as a reference to
define the protocol for policy exchange.
We will define the generic policy data set that can also use
in
RSVP Filter_Spec, in our document, or "A Policy Data
Set for Flow
Distribution". However, our document doesn't define
protocol for
policy exchange.
I think that we should discuss the possibility of reusing
of
RSVP Filter_Spec when we define the protocol for policy
exchange.
Kazuyuki
Teco_Boot Wrote:
> 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.
>
>> -----Original Message-----
>> From: Kazuyuki Tasaka [mailto:ka-tasaka kddilabs.jp]
>> Sent: dinsdag 31 juli 2007 14:01
>> To: Teco_Boot
>> Cc: 'Monami6 WG'
>> Subject: Re: [Monami6] Monami6 Filter Rules
>>
>> Hi Teco,
>>
>> Teco_Boot wrote:
>>> Hi Kazuyuki,
>>> I understand RSVP is to be used in a different
context.
>>> Defining a protocol for classifying traffic is
a common attribute.
>> I agree.
>>
>>> 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.
>> 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
>>
>>> Teco.
>>>
>>>> -----Original Message-----
>>>> From: Kazuyuki Tasaka [mailto:ka-tasakakddilabs.jp]
>>>> Sent: dinsdag 31 juli 2007 8:20
>>>> To: Monami6 WG
>>>> Subject: Re: [Monami6] Monami6 Filter
Rules
>>>>
>>>> Hello Teco,
>>>>
>>>> Teco_Boot wrote:
>>>>> Hi,
>>>>> Have we evaluated using the RSVP filter
mechanism (Filter_Spec) for
>>>> Monami6?
>>>>
>>>> I believe that we don't do it yet.
>>>>
>>>>> 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.
>>>> 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
>>>>
>>>>> Teco.
>>>>>
>>>>>
>>>>>
_______________________________________________
>>>>> Monami6 mailing list
>>>>> Monami6ietf.org
>>>>> https:
//www1.ietf.org/mailman/listinfo/monami6
>>>>>
>>>>>
>>>>
_______________________________________________
>>>> Monami6 mailing list
>>>> Monami6ietf.org
>>>> https:
//www1.ietf.org/mailman/listinfo/monami6
>>>
>
>
_______________________________________________
Monami6 mailing list
Monami6ietf.org
https:
//www1.ietf.org/mailman/listinfo/monami6
|
