Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule

[Satoru Matsushima]

Now I seems I’m confused when I see what does the type define.

Does the type define type of value, or type of action/descritor?

Cheers,
--satoru

> 2017/11/28 14:11、Moses, Danny のメール:
> 
> I am OK with the current structure.
>  
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
> Sent: Tuesday, November 28, 2017 23:45
> To: Bertz, Lyle T [CTO] ; dmm@ietf.org
> Subject: Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule
>  
> So, then I don’t see the point of changing the current structure. Other 
> opinions?
>  
> From: Bertz, Lyle T [CTO] [mailto:lyle.t.be...@sprint.com] 
> Sent: Dienstag, 28. November 2017 19:42
> To: Marco Liebsch; dmm@ietf.org
> Subject: RE: FPC: Move Descriptor-/Action-Value into Rule
>  
> I intentionally left out my opinion from the analysis.  I am against both as 
> the reusability for a value of a Descriptor/Action (especially descriptor) 
> does not meet the define once, use many objective for Descriptors.  The 
> define once, use many for Rule re-use is already present in Policy.
>  
> From: Marco Liebsch [mailto:marco.lieb...@neclab.eu] 
> Sent: Tuesday, November 28, 2017 9:54 AM
> To: Bertz, Lyle T [CTO] ; dmm@ietf.org
> Subject: RE: FPC: Move Descriptor-/Action-Value into Rule
>  
> Hi Lyle,
> 
> I see the analysis you brought, thanks for that. My proposal #2 is not my 
> preference as it was
> only an attempt to extend and match what Satoru had in mind without losing 
> the value in current
> descriptors/actions. Maybe it did not help ;-)
>  
> I just see that an action value belongs to an actions type. Clearly there are 
> types which don’t require
> a value, e.g. drop. Here value is void and re-usability is ensured, IMO.
> But moving the value entirely out of action / descriptor I just saw 
> shortcomings.
>  
> So, you brought examples and arguments against proposal #1 and proposal #2.
> But I could not conclude if there are any preferences or alternative? Do we 
> leave it as it is now?
>  
> marco
>  
>  
> From: Bertz, Lyle T [CTO] [mailto:lyle.t.be...@sprint.com] 
> Sent: Montag, 20. November 2017 15:15
> To: Marco Liebsch; dmm@ietf.org
> Subject: RE: FPC: Move Descriptor-/Action-Value into Rule
>  
> Marco,
>  
> Thank you for the write up of both proposals.  Forgive the length of the 
> response but I wanted to provide concrete examples based upon the existing 
> data types.
>  
> Summary, see below for examples and details:
> -  Satoru’s Proposal (Proposal 1) - the use of only ID/Type could be 
> replaced by making the Type a U-Key (similar to a registry or identity in 
> YANG). In any arrangement though only the Type could be use.  The downside 
> for Proposal 1 is reusability.  
> -  Marco’s Proposal (Proposal 2) - To make sense the setting MUST not 
> be in any of the existing Settings, i.e. it is a setting that MUST NOT be 
> tied to the Mobility-Context, DPN Interface or the fact that a DPN was 
> assigned to enforce a Rule.  Does such an example exist?
>  
> >> My Opinion <
>  
> I would not pursue Proposal 1 due to the loss of reusability which is a key 
> benefit of entities under the Policy Model.
> I would not pursue Proposal 2 if we cannot find clear examples that the 
> settings can be placed in other settings locations.  I cannot think of an 
> example at this time but I am just one person and hope the team can provide 
> such examples.
>  
> Lyle
>  
> >> Detail <<<
>  
>  
> Let’s take a step back.   Consider the IPFilterRule (RFC 6733) to block 
> inbound port 22 traffic (even from itself)
> “deny in ip from any to assigned 22”
>  
> Recall that from 6733, “The keyword "assigned" is the address or set of 
> addresses assigned to the terminal.”
>  
> If I use a ‘IPFilterRule’ Descriptor Type (it is not in the spec; I am making 
> up a new type here) and provide a value of descriptor “in ip from any to 
> assigned 22”  you will note the only Setting to deal with here is ‘assigned’.
>  
> In Satoru’s proposal, we will call it Proposal 1, we could see a Descriptor 
> example as
> Descriptor-Definition
> Descriptor-Id = 22
> Descriptor-Type = IPFilterRule
> Action-Definition
> Action-Id = 11
> Action-Type = deny (or drop)
> Rule-Definition 
> Rule-Id = 21231
> Descriptor-Match-Type = AND
> Descriptor-Reference
> Descriptor-Id-Reference = 22
> Descriptor-Value = in ip from any to assigned 22
> Action-Reference
> Action-Id-Reference = 11
>  
> We see the tradeoffs clearly in this example, when the value is directly 
> determined by the type as in the deny Action-Type, the Action Reference is 
> quite small.  In the case of the Descriptor we see the value is still 
> incomplete and the setting ‘assigned’ is applied.
>  
> For Marco’s 

[DMM] Some review comments on draft-matsushima-spring-dmm-srv6-mobile-uplane-03

[Charlie Perkins]

Hello folks,

Here are some comments from my reading of the draft 
"matsushima-spring-dmm-srv6-mobile-uplane".


There are a lot of minor editorial revisions required, which I have 
already provided under separate email.


As I mentioned in previous email to this mailing list, I think it is 
important to describe previous efforts to provide a source-routing 
solution for mobility management, and to suggest reasons why the SRv6 
approach will find success despite the difficulties encountered by 
earlier efforts.


Much of the flexibility and power of the mechanism derives from the 
assumed existence of SRv6-capable routing nodes in the packet core, or 
at minimum at the edges of the core.  This is a reasonable assumption, 
but it diverges a bit from previous architectural guidelines by which we 
had attempted to minimize the mobility design impact on existing 
networks.  I hope that we can get some ideas about why such a new design 
philosophy is more appropriate now than in previous years.


This document naturally relies on existing SRv6 documents for 
terminology and understanding of the SRv6 operations.  In particular, 
reference is made to [I-D.filsfils-spring-srv6-network-programming], 
which is a nontrivial document to read.  I think it would be very nice 
if most of the terminology were explained in at least some detail within 
the mobile-uplane document in order to enable better progress within the 
[dmm] group.  Perhaps a lot of people in this group have not read the 
SRv6 documents in any great detail, at least not up to this point in time.


As a general comment, I found it confusing about whether "legacy" means 
IPv4, or "non-SRv6" IPv6.  For instance, I am not sure about whether 
"D::1" is IPv4 or IPv6 in the first paragraph of section 6.3.1.  As a 
related matter, I think that relying solely on terminology like S::1, 
D::1, A2::1, A2::B2, and so on soon becomes confusing.  More diagrams 
would be nice.


The document states:


   Existing mobile user-plane with IPv6 underlay is expected to be
   widely deployed.  Since IPv6 network should be interoperable with SRv6
   endpoints accommodated on it, interworking with existing IPv6
   network is out of scope of this document.


If I understand this correctly, it would be better to say that further 
specification is not needed for interworking with existing IPv6 
networks.  That's different than saying the interworking mechanism is 
out of scope.  And yet perhaps there is anyway something to say about 
whether firewalls would pass dataplane traffic carrying SRH (or why that 
doesn't matter).



The following claim needs a citation, I think:


Mobile user-plane requires a rate-limit feature.


Previous work in [dmm] and earlier mobility management working groups in 
the IETF have not placed this constraint in general for dataplane 
traffic.  Even for control plane traffic, mechanisms for rate limitation 
have not been designed very often.


Regarding the mechanism in the draft for rate limiting:


   In case of j bit length is zero in SID, the node should not do rate
   limiting unless static configuration or control-plane sets the limit
   rate associated to the SID.


It should also be allowed that rate limiting is not done when there has 
not been any such rate-limit Locator provided.


The mobile-uplane document goes into some depth to explain how 
interworking and anchoring work.  To do this, there are various examples 
with specific (example) addresses and named nodes. However, it is very 
important that the mobile node is registered somehow with the 
SRv6-capable nodes in the network.  The knowledge about where the mobile 
node is reachable in the access network has to be provided (in a secure 
way).  Maybe the specific registration control flow is reasonably kept 
separate from the user-plane operations, but at minimum the document has 
to describe exactly what is the assumed state of the network after the 
registration is complete.


The document states:


   A mobile network may be required to create a network slice that
   represents a set of network resources and isolates those resources from
   other slices.



The first clause seems to mean that the mobile network creates the 
slice.  Wouldn't the slice need to   be created before the mobile 
network exists?



Later in the same section:


   While network slicing has been discussed in the IETF and other
   standardization bodies, what functionalities are required for network
   slicing in mobile user-plane is further study item and to be
   discussed.



To me, this says that slicing is out of scope.  Maybe the discussion 
should be deleted.  Anyway, I think that slicing won't affect the design 
decisions for SRv6 mobility operations, regardless of how important 
slicing is in real life.


The document states:


    ..   the mobile control-plane may
   assume that one user-plane entity has one IPv6 address ...


I'm pretty sure this isn't true for IPv6 nodes.

Some of the 

Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule

[Moses, Danny]

I am OK with the current structure.

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Tuesday, November 28, 2017 23:45
To: Bertz, Lyle T [CTO] ; dmm@ietf.org
Subject: Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule

So, then I don't see the point of changing the current structure. Other 
opinions?

From: Bertz, Lyle T [CTO] [mailto:lyle.t.be...@sprint.com]
Sent: Dienstag, 28. November 2017 19:42
To: Marco Liebsch; dmm@ietf.org
Subject: RE: FPC: Move Descriptor-/Action-Value into Rule

I intentionally left out my opinion from the analysis.  I am against both as 
the reusability for a value of a Descriptor/Action (especially descriptor) does 
not meet the define once, use many objective for Descriptors.  The define once, 
use many for Rule re-use is already present in Policy.

From: Marco Liebsch [mailto:marco.lieb...@neclab.eu]
Sent: Tuesday, November 28, 2017 9:54 AM
To: Bertz, Lyle T [CTO] 
>; 
dmm@ietf.org
Subject: RE: FPC: Move Descriptor-/Action-Value into Rule

Hi Lyle,

I see the analysis you brought, thanks for that. My proposal #2 is not my 
preference as it was
only an attempt to extend and match what Satoru had in mind without losing the 
value in current
descriptors/actions. Maybe it did not help ;-)

I just see that an action value belongs to an actions type. Clearly there are 
types which don't require
a value, e.g. drop. Here value is void and re-usability is ensured, IMO.
But moving the value entirely out of action / descriptor I just saw 
shortcomings.

So, you brought examples and arguments against proposal #1 and proposal #2.
But I could not conclude if there are any preferences or alternative? Do we 
leave it as it is now?

marco


From: Bertz, Lyle T [CTO] [mailto:lyle.t.be...@sprint.com]
Sent: Montag, 20. November 2017 15:15
To: Marco Liebsch; dmm@ietf.org
Subject: RE: FPC: Move Descriptor-/Action-Value into Rule

Marco,

Thank you for the write up of both proposals.  Forgive the length of the 
response but I wanted to provide concrete examples based upon the existing data 
types.

Summary, see below for examples and details:

-  Satoru's Proposal (Proposal 1) - the use of only ID/Type could be 
replaced by making the Type a U-Key (similar to a registry or identity in 
YANG). In any arrangement though only the Type could be use.  The downside for 
Proposal 1 is reusability.

-  Marco's Proposal (Proposal 2) - To make sense the setting MUST not 
be in any of the existing Settings, i.e. it is a setting that MUST NOT be tied 
to the Mobility-Context, DPN Interface or the fact that a DPN was assigned to 
enforce a Rule.  Does such an example exist?

>> My Opinion <

I would not pursue Proposal 1 due to the loss of reusability which is a key 
benefit of entities under the Policy Model.
I would not pursue Proposal 2 if we cannot find clear examples that the 
settings can be placed in other settings locations.  I cannot think of an 
example at this time but I am just one person and hope the team can provide 
such examples.

Lyle

>> Detail <<<


Let's take a step back.   Consider the IPFilterRule (RFC 6733) to block inbound 
port 22 traffic (even from itself)
"deny in ip from any to assigned 22"



Recall that from 6733, "The keyword "assigned" is the address or set of 
addresses assigned to the terminal."

If I use a 'IPFilterRule' Descriptor Type (it is not in the spec; I am making 
up a new type here) and provide a value of descriptor "in ip from any to 
assigned 22"  you will note the only Setting to deal with here is 'assigned'.

In Satoru's proposal, we will call it Proposal 1, we could see a Descriptor 
example as
Descriptor-Definition
Descriptor-Id = 22
Descriptor-Type = IPFilterRule
Action-Definition
Action-Id = 11
Action-Type = deny (or drop)
Rule-Definition
Rule-Id = 21231
Descriptor-Match-Type = AND
Descriptor-Reference

Descriptor-Id-Reference = 22
Descriptor-Value = in ip from any to assigned 22
Action-Reference
Action-Id-Reference = 11

We see the tradeoffs clearly in this example, when the value is directly 
determined by the type as in the deny Action-Type, the Action Reference is 
quite small.  In the case of the Descriptor we see the value is still 
incomplete and the setting 'assigned' is applied.

For Marco's proposal, we will call it Proposal 2:
Descriptor-Definition
Descriptor-Id = 22
Descriptor-Type = IPFilterRule
Descriptor-Value = in ip from any to assigned 22
Action-Definition
Action-Id = 11
Action-Type = deny (or drop)
Rule-Definition
Rule-Id = 21231
Descriptor-Match-Type = AND

Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule

[Marco Liebsch]

So, then I don't see the point of changing the current structure. Other 
opinions?

From: Bertz, Lyle T [CTO] [mailto:lyle.t.be...@sprint.com]
Sent: Dienstag, 28. November 2017 19:42
To: Marco Liebsch; dmm@ietf.org
Subject: RE: FPC: Move Descriptor-/Action-Value into Rule

I intentionally left out my opinion from the analysis.  I am against both as 
the reusability for a value of a Descriptor/Action (especially descriptor) does 
not meet the define once, use many objective for Descriptors.  The define once, 
use many for Rule re-use is already present in Policy.

From: Marco Liebsch [mailto:marco.lieb...@neclab.eu]
Sent: Tuesday, November 28, 2017 9:54 AM
To: Bertz, Lyle T [CTO] 
>; 
dmm@ietf.org
Subject: RE: FPC: Move Descriptor-/Action-Value into Rule

Hi Lyle,

I see the analysis you brought, thanks for that. My proposal #2 is not my 
preference as it was
only an attempt to extend and match what Satoru had in mind without losing the 
value in current
descriptors/actions. Maybe it did not help ;-)

I just see that an action value belongs to an actions type. Clearly there are 
types which don't require
a value, e.g. drop. Here value is void and re-usability is ensured, IMO.
But moving the value entirely out of action / descriptor I just saw 
shortcomings.

So, you brought examples and arguments against proposal #1 and proposal #2.
But I could not conclude if there are any preferences or alternative? Do we 
leave it as it is now?

marco


From: Bertz, Lyle T [CTO] [mailto:lyle.t.be...@sprint.com]
Sent: Montag, 20. November 2017 15:15
To: Marco Liebsch; dmm@ietf.org
Subject: RE: FPC: Move Descriptor-/Action-Value into Rule

Marco,

Thank you for the write up of both proposals.  Forgive the length of the 
response but I wanted to provide concrete examples based upon the existing data 
types.

Summary, see below for examples and details:

-  Satoru's Proposal (Proposal 1) - the use of only ID/Type could be 
replaced by making the Type a U-Key (similar to a registry or identity in 
YANG). In any arrangement though only the Type could be use.  The downside for 
Proposal 1 is reusability.

-  Marco's Proposal (Proposal 2) - To make sense the setting MUST not 
be in any of the existing Settings, i.e. it is a setting that MUST NOT be tied 
to the Mobility-Context, DPN Interface or the fact that a DPN was assigned to 
enforce a Rule.  Does such an example exist?

>> My Opinion <

I would not pursue Proposal 1 due to the loss of reusability which is a key 
benefit of entities under the Policy Model.
I would not pursue Proposal 2 if we cannot find clear examples that the 
settings can be placed in other settings locations.  I cannot think of an 
example at this time but I am just one person and hope the team can provide 
such examples.

Lyle

>> Detail <<<


Let's take a step back.   Consider the IPFilterRule (RFC 6733) to block inbound 
port 22 traffic (even from itself)
"deny in ip from any to assigned 22"



Recall that from 6733, "The keyword "assigned" is the address or set of 
addresses assigned to the terminal."

If I use a 'IPFilterRule' Descriptor Type (it is not in the spec; I am making 
up a new type here) and provide a value of descriptor "in ip from any to 
assigned 22"  you will note the only Setting to deal with here is 'assigned'.

In Satoru's proposal, we will call it Proposal 1, we could see a Descriptor 
example as
Descriptor-Definition
Descriptor-Id = 22
Descriptor-Type = IPFilterRule
Action-Definition
Action-Id = 11
Action-Type = deny (or drop)
Rule-Definition
Rule-Id = 21231
Descriptor-Match-Type = AND
Descriptor-Reference

Descriptor-Id-Reference = 22
Descriptor-Value = in ip from any to assigned 22
Action-Reference
Action-Id-Reference = 11

We see the tradeoffs clearly in this example, when the value is directly 
determined by the type as in the deny Action-Type, the Action Reference is 
quite small.  In the case of the Descriptor we see the value is still 
incomplete and the setting 'assigned' is applied.

For Marco's proposal, we will call it Proposal 2:
Descriptor-Definition
Descriptor-Id = 22
Descriptor-Type = IPFilterRule
Descriptor-Value = in ip from any to assigned 22
Action-Definition
Action-Id = 11
Action-Type = deny (or drop)
Rule-Definition
Rule-Id = 21231
Descriptor-Match-Type = AND
Descriptor-Reference

Descriptor-Id-Reference = 22
Descriptor-Value-Settings = [ assign = ... ]
Action-Reference
Action-Id-Reference = 11

For Proposal 1, the use of only ID/Type could be replaced by making 

Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule

[Bertz, Lyle T [CTO]]

I intentionally left out my opinion from the analysis.  I am against both as 
the reusability for a value of a Descriptor/Action (especially descriptor) does 
not meet the define once, use many objective for Descriptors.  The define once, 
use many for Rule re-use is already present in Policy.

From: Marco Liebsch [mailto:marco.lieb...@neclab.eu]
Sent: Tuesday, November 28, 2017 9:54 AM
To: Bertz, Lyle T [CTO] ; dmm@ietf.org
Subject: RE: FPC: Move Descriptor-/Action-Value into Rule

Hi Lyle,

I see the analysis you brought, thanks for that. My proposal #2 is not my 
preference as it was
only an attempt to extend and match what Satoru had in mind without losing the 
value in current
descriptors/actions. Maybe it did not help ;-)

I just see that an action value belongs to an actions type. Clearly there are 
types which don't require
a value, e.g. drop. Here value is void and re-usability is ensured, IMO.
But moving the value entirely out of action / descriptor I just saw 
shortcomings.

So, you brought examples and arguments against proposal #1 and proposal #2.
But I could not conclude if there are any preferences or alternative? Do we 
leave it as it is now?

marco


From: Bertz, Lyle T [CTO] [mailto:lyle.t.be...@sprint.com]
Sent: Montag, 20. November 2017 15:15
To: Marco Liebsch; dmm@ietf.org
Subject: RE: FPC: Move Descriptor-/Action-Value into Rule

Marco,

Thank you for the write up of both proposals.  Forgive the length of the 
response but I wanted to provide concrete examples based upon the existing data 
types.

Summary, see below for examples and details:

-  Satoru's Proposal (Proposal 1) - the use of only ID/Type could be 
replaced by making the Type a U-Key (similar to a registry or identity in 
YANG). In any arrangement though only the Type could be use.  The downside for 
Proposal 1 is reusability.

-  Marco's Proposal (Proposal 2) - To make sense the setting MUST not 
be in any of the existing Settings, i.e. it is a setting that MUST NOT be tied 
to the Mobility-Context, DPN Interface or the fact that a DPN was assigned to 
enforce a Rule.  Does such an example exist?

>> My Opinion <

I would not pursue Proposal 1 due to the loss of reusability which is a key 
benefit of entities under the Policy Model.
I would not pursue Proposal 2 if we cannot find clear examples that the 
settings can be placed in other settings locations.  I cannot think of an 
example at this time but I am just one person and hope the team can provide 
such examples.

Lyle

>> Detail <<<


Let's take a step back.   Consider the IPFilterRule (RFC 6733) to block inbound 
port 22 traffic (even from itself)
"deny in ip from any to assigned 22"



Recall that from 6733, "The keyword "assigned" is the address or set of 
addresses assigned to the terminal."

If I use a 'IPFilterRule' Descriptor Type (it is not in the spec; I am making 
up a new type here) and provide a value of descriptor "in ip from any to 
assigned 22"  you will note the only Setting to deal with here is 'assigned'.

In Satoru's proposal, we will call it Proposal 1, we could see a Descriptor 
example as
Descriptor-Definition
Descriptor-Id = 22
Descriptor-Type = IPFilterRule
Action-Definition
Action-Id = 11
Action-Type = deny (or drop)
Rule-Definition
Rule-Id = 21231
Descriptor-Match-Type = AND
Descriptor-Reference

Descriptor-Id-Reference = 22
Descriptor-Value = in ip from any to assigned 22
Action-Reference
Action-Id-Reference = 11

We see the tradeoffs clearly in this example, when the value is directly 
determined by the type as in the deny Action-Type, the Action Reference is 
quite small.  In the case of the Descriptor we see the value is still 
incomplete and the setting 'assigned' is applied.

For Marco's proposal, we will call it Proposal 2:
Descriptor-Definition
Descriptor-Id = 22
Descriptor-Type = IPFilterRule
Descriptor-Value = in ip from any to assigned 22
Action-Definition
Action-Id = 11
Action-Type = deny (or drop)
Rule-Definition
Rule-Id = 21231
Descriptor-Match-Type = AND
Descriptor-Reference

Descriptor-Id-Reference = 22
Descriptor-Value-Settings = [ assign = ... ]
Action-Reference
Action-Id-Reference = 11

For Proposal 1, the use of only ID/Type could be replaced by making the Type a 
U-Key (similar to a registry or identity in YANG). In any arrangement though 
only the Type could be used.  The result would be the elimination of the 
Descriptor-Definition and Action-Defintion.

The downside for Proposal 1 is reusability.  If I wanted to reuse the value "in 
ip from any to assigned 22" with a 

Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule

[Marco Liebsch]

Hi Lyle,

I see the analysis you brought, thanks for that. My proposal #2 is not my 
preference as it was
only an attempt to extend and match what Satoru had in mind without losing the 
value in current
descriptors/actions. Maybe it did not help ;-)

I just see that an action value belongs to an actions type. Clearly there are 
types which don't require
a value, e.g. drop. Here value is void and re-usability is ensured, IMO.
But moving the value entirely out of action / descriptor I just saw 
shortcomings.

So, you brought examples and arguments against proposal #1 and proposal #2.
But I could not conclude if there are any preferences or alternative? Do we 
leave it as it is now?

marco


From: Bertz, Lyle T [CTO] [mailto:lyle.t.be...@sprint.com]
Sent: Montag, 20. November 2017 15:15
To: Marco Liebsch; dmm@ietf.org
Subject: RE: FPC: Move Descriptor-/Action-Value into Rule

Marco,

Thank you for the write up of both proposals.  Forgive the length of the 
response but I wanted to provide concrete examples based upon the existing data 
types.

Summary, see below for examples and details:

-  Satoru's Proposal (Proposal 1) - the use of only ID/Type could be 
replaced by making the Type a U-Key (similar to a registry or identity in 
YANG). In any arrangement though only the Type could be use.  The downside for 
Proposal 1 is reusability.

-  Marco's Proposal (Proposal 2) - To make sense the setting MUST not 
be in any of the existing Settings, i.e. it is a setting that MUST NOT be tied 
to the Mobility-Context, DPN Interface or the fact that a DPN was assigned to 
enforce a Rule.  Does such an example exist?

>> My Opinion <

I would not pursue Proposal 1 due to the loss of reusability which is a key 
benefit of entities under the Policy Model.
I would not pursue Proposal 2 if we cannot find clear examples that the 
settings can be placed in other settings locations.  I cannot think of an 
example at this time but I am just one person and hope the team can provide 
such examples.

Lyle

>> Detail <<<


Let's take a step back.   Consider the IPFilterRule (RFC 6733) to block inbound 
port 22 traffic (even from itself)
"deny in ip from any to assigned 22"



Recall that from 6733, "The keyword "assigned" is the address or set of 
addresses assigned to the terminal."

If I use a 'IPFilterRule' Descriptor Type (it is not in the spec; I am making 
up a new type here) and provide a value of descriptor "in ip from any to 
assigned 22"  you will note the only Setting to deal with here is 'assigned'.

In Satoru's proposal, we will call it Proposal 1, we could see a Descriptor 
example as
Descriptor-Definition
Descriptor-Id = 22
Descriptor-Type = IPFilterRule
Action-Definition
Action-Id = 11
Action-Type = deny (or drop)
Rule-Definition
Rule-Id = 21231
Descriptor-Match-Type = AND
Descriptor-Reference

Descriptor-Id-Reference = 22
Descriptor-Value = in ip from any to assigned 22
Action-Reference
Action-Id-Reference = 11

We see the tradeoffs clearly in this example, when the value is directly 
determined by the type as in the deny Action-Type, the Action Reference is 
quite small.  In the case of the Descriptor we see the value is still 
incomplete and the setting 'assigned' is applied.

For Marco's proposal, we will call it Proposal 2:
Descriptor-Definition
Descriptor-Id = 22
Descriptor-Type = IPFilterRule
Descriptor-Value = in ip from any to assigned 22
Action-Definition
Action-Id = 11
Action-Type = deny (or drop)
Rule-Definition
Rule-Id = 21231
Descriptor-Match-Type = AND
Descriptor-Reference

Descriptor-Id-Reference = 22
Descriptor-Value-Settings = [ assign = ... ]
Action-Reference
Action-Id-Reference = 11

For Proposal 1, the use of only ID/Type could be replaced by making the Type a 
U-Key (similar to a registry or identity in YANG). In any arrangement though 
only the Type could be used.  The result would be the elimination of the 
Descriptor-Definition and Action-Defintion.

The downside for Proposal 1 is reusability.  If I wanted to reuse the value "in 
ip from any to assigned 22" with a different list of Descriptors then it must 
be redefined in the model.  This is due to the fact that 
'Descriptor-Id-Reference' points to an entry in the Descriptors-Definitions 
List.  If I made a local key then reuse is possible but now I need a local key 
for each Descriptor and compound key of Rule-Id / Descriptor-Id  in the 
entry.   This also becomes problematic when the Descriptors are smaller than 
the Identifiers that reference them.

For Proposal 2, the idea is to permit settings (variable substitution) to occur 
within the 

Re: [DMM] Call for adoption of draft-matsushima-spring-dmm-srv6-mobile-uplane-03 as DMM WG document

[Satoru Matsushima]

I support the adoption as a co-author.

Cheers,
--satoru


> 2017/11/14 16:02、Sri Gundavelli (sgundave) のメール:
> 
> Folks:
> 
> The following message commences a two week call for opinions on the adoption 
> of draft-matsushima-spring-dmm-srv6-mobile-uplane-03 as a DMM Working 
> document. 
> 
> ---
> The DMM working group is considering adopting the draft, 
> "draft-matsushima-spring-dmm-srv6-mobile-uplane-03” as a working group 
> document. The chairs have polled the room for opinions during IETF100, and it 
> was determined that there is good support for taking up this work. The chairs 
> would like to confirm the same in the mailing list.  Please provide your 
> feedback.
>   
> 
> Document Link:
> https://www.ietf.org/id/draft-matsushima-spring-dmm-srv6-mobile-uplane-03.txt
> 
> Slides:
> https://datatracker.ietf.org/meeting/100/materials/slides-100-dmm-srv6-for-mobile-user-plane/
> 
> Background:
> https://datatracker.ietf.org/meeting/100/materials/slides-100-dmm-mobile-data-plane-evolution-motivation-goals/
> ---
> 
> Regards
> Dapping & Sri
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm