Subject: [Dots] Data channel issues with GET

From: "Jon Shallow" <[email-masked]>
Date: Fri, 3 Nov 2017 21:32:42 -0000

Hi Tiru et al,

I am having challenges coding up the GET for channel identifiers.

A DOTS Client as part of a DOTS gateway can use different client-identifiers
when doing a PUT for the alias-name.   The DOTS server will therefore have
multiple client-identifier arrays for the DOTS GW client.

However when doing a GET using 'content=config', as things currently stand,
only one client-identifier array can returned as per the below in Figure 7:-

===============================

"3.2.3.  Retrieving Installed Identifiers

   A GET request is used to retrieve the set of installed identifiers

   from a DOTS server (Section 3.3.1 in [RFC8040]).  Figure 6 shows how

   to retrieve all the identifiers that were instantiated by the DOTS

   client.  The content parameter and its permitted values are defined

   in Section 4.8.1 of [RFC8040].

     GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\

         content=config HTTP/1.1

     Host: {host}:{port}

     Accept: application/yang-data+json

          Figure 6: GET to retrieve all the installed identifiers

   Figure 7 shows response for all identifiers on the DOTS server.

   {

    "ietf-dots-data-channel-identifier:identifier": {

       "client-identifier": [

          "dz6pHjaADkaFTbjr0JGBpw",

          "iAYmCNPmrYoKoqzgFMiobw"

       ],

       "alias": [

         {

           "alias-name": "Server1",

           "traffic-protocol": [

             6"

===========

I think that the yang model needs to be re-written, by moving leaf-list
client-identifier down to the same level as alias-name as :-

===========

     container identifier {

          description "Top level container for identifiers";

              list alias {

                   key alias-name;

                   description "List of identifiers";

                   leaf alias-name {

                      type string;

                      description "alias name";

                   }

                   leaf-list client-identifier {

                      type binary;

                      description  "A client identifier conveyed by a DOTS
gateway

                                    to a remote DOTS server.";

                      reference

                         "I-D.itef-dots-signal-channel";

                   }

                   leaf-list target-ip {

================

And reflected appropriately throughout the data channel draft.

The issue is the same for the access control list - client-identifier needs
to be at the same level as acl-name

module: ietf-dots-access-control-list

  augment /ietf-acl:access-lists:

    +--rw client-identifier*   binary

=============

Needs to be

module: ietf-dots-access-control-list

  augment /ietf-acl:access-lists/ietf-acl:acl/:

    +--rw client-identifier*   binary

===============

And replicated as appropriate throughout the draft

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 3 Nov 2017 22:09:01 -0000

Hi Tiru et al,

In addition, on the signal channel, it is also worth considering moving
client-identifier to the same level as mitigation-id, so that

======

   1) To retrieve all DOTS signals signaled by the DOTS client.

     Header: GET (Code=0.01)

     Uri-Host: "host"

     Uri-Path: ".well-known"

     Uri-Path: "dots"

     Uri-Path: "version"

     Uri-Path: "mitigate"

     Observe : 0

     {

       "mitigation-scope": {

         "client-identifier": [

            "string"

         ]

       }

     }

========

Can be reduced to 

   1) To retrieve all DOTS signals signaled by the DOTS client.

     Header: GET (Code=0.01)

     Uri-Host: "host"

     Uri-Path: ".well-known"

     Uri-Path: "dots"

     Uri-Path: "version"

     Uri-Path: "mitigate"

     Observe : 0

=======

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Jon Shallow
Sent: 03 November 2017 21:33
To: [email-masked]
Subject: [Dots] Data channel issues with GET

Hi Tiru et al,

         content=config HTTP/1.1

     Host: {host}:{port}

   {

       "client-identifier": [

          "iAYmCNPmrYoKoqzgFMiobw"

       ],

       "alias": [

         {

           "alias-name": "Server1",

           "traffic-protocol": [

             6"

===========

===========

     container identifier {

              list alias {

                   key alias-name;

                   leaf alias-name {

                      type string;

                   }

                      type binary;

                      reference

                   }

                   leaf-list target-ip {

================

=============

Needs to be

===============

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 4 Nov 2017 04:15:53 +0000

Hi Jon,

GET request will only retrieve the alias-names installed by a DOTS client and not the alias-names for all the DOTS clients. The client-identifier array is uniquely identifying the DOTS client and does not need be repeated for every alias-name conveyed by the client.  Figure 6 is showing the GET request from the DOTS client, and the DOTS gateways will update the GET request to add and update the client-identifier array.
I don't think the client-identifier should be in the same level as alias-name.

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Saturday, November 4, 2017 3:03 AM
To: [email-masked]
Subject: [Dots] Data channel issues with GET

Hi Tiru et al,

A DOTS Client as part of a DOTS gateway can use different client-identifiers when doing a PUT for the alias-name.   The DOTS server will therefore have multiple client-identifier arrays for the DOTS GW client.

However when doing a GET using 'content=config', as things currently stand, only one client-identifier array can returned as per the below in Figure 7:-

   {

I think that the yang model needs to be re-written, by moving leaf-list client-identifier down to the same level as alias-name as :-

===========
     container identifier {

              list alias {
                   key alias-name;

                   leaf alias-name {
                      type string;

                   leaf-list client-identifier {
                      type binary;
                      description  "A client identifier conveyed by a DOTS gateway
                                    to a remote DOTS server.";

                      reference

                   leaf-list target-ip {

================

The issue is the same for the access control list - client-identifier needs to be at the same level as acl-name

=============
Needs to be

===============

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 4 Nov 2017 04:22:56 +0000

If the client-identifier is not conveyed by the DOTS gateway in the GET request, the DOTS server cannot determine the DOTS signals associated with a DOTS client, and will not return any results.
Irrespective of the method used by the DOTS client, the DOTS gateway should add the client-identifier to the requests from the DOTS clients.

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Saturday, November 4, 2017 3:39 AM
To: [email-masked]
Subject: Re: [Dots] Data channel issues with GET

Hi Tiru et al,

In addition, on the signal channel, it is also worth considering moving client-identifier to the same level as mitigation-id, so that

======

     Header: GET (Code=0.01)
     Uri-Host: "host"
     Uri-Path: ".well-known"
     Uri-Path: "dots"
     Uri-Path: "version"
     Uri-Path: "mitigate"
     Observe : 0
     {
       "mitigation-scope": {
         "client-identifier": [
            "string"
         ]
       }
     }
========
Can be reduced to

     Header: GET (Code=0.01)
     Uri-Host: "host"
     Uri-Path: ".well-known"
     Uri-Path: "dots"
     Uri-Path: "version"
     Uri-Path: "mitigate"
     Observe : 0

=======

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Jon Shallow
Sent: 03 November 2017 21:33
To: [email-masked]<mailto:[email-masked]>
Subject: [Dots] Data channel issues with GET

Hi Tiru et al,

   {

===========
     container identifier {

              list alias {
                   key alias-name;

                   leaf alias-name {
                      type string;

                      reference

                   leaf-list target-ip {

================

=============
Needs to be

===============

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Sat, 4 Nov 2017 10:46:44 -0000

Hi Tiru,

Agreed that a request from a DOTS client going through multiple DOTS
gateways will get the appropriate client-identifier added, and the response
initially generated by the final DOTS server will have all the
client-identifiers.

However, as the response passes back through the DOTS gateways, the
appropriate client-identifier will get stripped off and the originating DOTS
client will have no visibility of the client-identifiers - as per

"   A DOTS gateway MUST update the 'client-identifier' list in the

   response to remove the 'client-identifier' value it had added in the

   corresponding request before forwarding the response to the DOTS

   client."

So, Figure 6 and Figure 7 do not correctly portray the reality as seen by a
DOTS client (whether on a DOTS gateway or not).

When the DOTS Gateway client component generates the GET request should the
request be (to match Figure 7 response)

"    GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\

content=config&client-identifier=dz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMio
bw HTTP/1.1

     Host: {host}:{port}

          Figure 6: GET to retrieve all the installed identifiers"

=====

This still does not answer my implied concern - how does a DOTS gateway
client request all the aliases / filters / mitigations to sync up state
when, say, the DOTS gateway client restarts?

- The DOTS gateway may not know all the client-identifiers that are talking
to the server component of the DOTS gateway - they may be behind yet another
DOTS gateway.

Taking this more complex example involving multiple gateways (should it be
in the drafts somewhere for helping with client-identifier clarity?)

DOTS client (C1aj) ----------------------------------------- (S1j) DOTS
gateway J (C2j) ----------\   

DOTS client (C1bj) --------------------------------------------/
|

|

DOTS client (C1ax) ------- (S1x) DOTS gateway X (C2x) ------ (S2k) DOTS
gateway K (C3k) -------- (S3)    

DOTS client (C1bx) ----------/                                 |

                                                               |

DOTS client (C1ay) ------- (S1y) DOTS gateway Y (C2y) ---------/

DOTS client (C1by) ----------/

 

If C3k restarts how is he able to re-sync his information from S3?  C3K does
not have a GET 'all' capability with client-identifier being above the level
of alias-name.  It maybe that C3k does not need to re-sync, but C3k should
have the flexibility if C3k is, say, able to cache information to reduce the
number of requests having to pass all the way through to S3.

As an aside, in my current implementation, where CIH(xxx) is the Client
Identifier hash of xxx

C1ax does a PUT (alias-name=Server1),

C2x does a PUT (alias-name=Server1&client-identifer=CIH(C1ax)),

C3k does a PUT (alias-name=Server1&client-identifer=CIH(C1ax),CIH(C2x))

and S3 uniquely stores this alias-name as
(alias-name=Server1&client-identifer=CIH(C1ax),CIH(C2x),CIH(C3k))

so that if any of the DOTS clients do a PUT (alias-name=Server1) [with same
alias name] S3 can differentiate them all.

As CIH(C1ax) should be unique across all DOTS clients, do we really need to
add in all the other CIH() as the traffic passes up through to S3?

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 04 November 2017 04:16
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Data channel issues with GET

Hi Jon,

GET request will only retrieve the alias-names installed by a DOTS client
and not the alias-names for all the DOTS clients. The client-identifier
array is uniquely identifying the DOTS client and does not need be repeated
for every alias-name conveyed by the client.  Figure 6 is showing the GET
request from the DOTS client, and the DOTS gateways will update the GET
request to add and update the client-identifier array. 

I don't think the client-identifier should be in the same level as
alias-name. 

-Tiru

Hi Tiru et al,

         content=config HTTP/1.1

     Host: {host}:{port}

   {

       "client-identifier": [

          "iAYmCNPmrYoKoqzgFMiobw"

       ],

       "alias": [

         {

           "alias-name": "Server1",

           "traffic-protocol": [

             6"

===========

===========

     container identifier {

              list alias {

                   key alias-name;

                   leaf alias-name {

                      type string;

                   }

                      type binary;

                      reference

                   }

                   leaf-list target-ip {

================

=============

Needs to be

===============

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Sat, 4 Nov 2017 11:45:39 -0000

Actually, looking at RFC8040, the Figure 6 syntax should be

"    GET /restconf/data/ietf-dots-data-channel-identifier:identifier/\

         client-identifier=dz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMiobw?\

         content=config HTTP/1.1

     Host: {host}:{port}

To represent the Figure 7 output.

Correct?

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Jon Shallow
Sent: 04 November 2017 10:47
To: 'Konda, Tirumaleswar Reddy'; [email-masked]
Subject: Re: [Dots] Data channel issues with GET

Hi Tiru,

   client."

     Host: {host}:{port}

=====

|

                                                               |

 

Regards

Jon

Hi Jon,

-Tiru

Hi Tiru et al,

         content=config HTTP/1.1

     Host: {host}:{port}

   {

       "client-identifier": [

          "iAYmCNPmrYoKoqzgFMiobw"

       ],

       "alias": [

         {

           "alias-name": "Server1",

           "traffic-protocol": [

             6"

===========

===========

     container identifier {

              list alias {

                   key alias-name;

                   leaf alias-name {

                      type string;

                   }

                      type binary;

                      reference

                   }

                   leaf-list target-ip {

================

=============

Needs to be

===============

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 4 Nov 2017 14:11:31 +0000

From: Jon Shallow [mailto:[email-masked]]
Sent: Saturday, November 4, 2017 5:16 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: [Dots] Data channel issues with GET

Correct?

Yes, fixed.

-Tiru

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Jon Shallow
Sent: 04 November 2017 10:47
To: 'Konda, Tirumaleswar Reddy'; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Data channel issues with GET

Hi Tiru,

Agreed that a request from a DOTS client going through multiple DOTS gateways will get the appropriate client-identifier added, and the response initially generated by the final DOTS server will have all the client-identifiers.

However, as the response passes back through the DOTS gateways, the appropriate client-identifier will get stripped off and the originating DOTS client will have no visibility of the client-identifiers - as per
"   A DOTS gateway MUST update the 'client-identifier' list in the
   response to remove the 'client-identifier' value it had added in the
   corresponding request before forwarding the response to the DOTS
   client."

So, Figure 6 and Figure 7 do not correctly portray the reality as seen by a DOTS client (whether on a DOTS gateway or not).

When the DOTS Gateway client component generates the GET request should the request be (to match Figure 7 response)

"    GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\
         content=config&client-identifier=dz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMiobw HTTP/1.1
     Host: {host}:{port}
     Accept: application/yang-data+json

=====

This still does not answer my implied concern - how does a DOTS gateway client request all the aliases / filters / mitigations to sync up state when, say, the DOTS gateway client restarts?
- The DOTS gateway may not know all the client-identifiers that are talking to the server component of the DOTS gateway - they may be behind yet another DOTS gateway.

Taking this more complex example involving multiple gateways (should it be in the drafts somewhere for helping with client-identifier clarity?)

DOTS client (C1aj) ----------------------------------------- (S1j) DOTS gateway J (C2j) ----------\
DOTS client (C1bj) --------------------------------------------/                                  |
                                                                                                  |
DOTS client (C1ax) ------- (S1x) DOTS gateway X (C2x) ------ (S2k) DOTS gateway K (C3k) -------- (S3)
DOTS client (C1bx) ----------/                                 |
                                                               |
DOTS client (C1ay) ------- (S1y) DOTS gateway Y (C2y) ---------/
DOTS client (C1by) ----------/

If C3k restarts how is he able to re-sync his information from S3?  C3K does not have a GET 'all' capability with client-identifier being above the level of alias-name.  It maybe that C3k does not need to re-sync, but C3k should have the flexibility if C3k is, say, able to cache information to reduce the number of requests having to pass all the way through to S3.

As an aside, in my current implementation, where CIH(xxx) is the Client Identifier hash of xxx

C1ax does a PUT (alias-name=Server1),
C2x does a PUT (alias-name=Server1&client-identifer=CIH(C1ax)),
C3k does a PUT (alias-name=Server1&client-identifer=CIH(C1ax),CIH(C2x))
and S3 uniquely stores this alias-name as (alias-name=Server1&client-identifer=CIH(C1ax),CIH(C2x),CIH(C3k))
so that if any of the DOTS clients do a PUT (alias-name=Server1) [with same alias name] S3 can differentiate them all.

As CIH(C1ax) should be unique across all DOTS clients, do we really need to add in all the other CIH() as the traffic passes up through to S3?

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 04 November 2017 04:16
To: Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Data channel issues with GET

Hi Jon,

-Tiru

Hi Tiru et al,

   {

===========
     container identifier {

              list alias {
                   key alias-name;

                   leaf alias-name {
                      type string;

                      reference

                   leaf-list target-ip {

================

=============
Needs to be

===============

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Sat, 4 Nov 2017 14:25:46 -0000

Hi Tiru,

I still do not have an answer to my two other questions in my mail of 04
November 2017 10:47

One

"This still does not answer my implied concern - how does a DOTS gateway
client request all the aliases / filters / mitigations to sync up state
when, say, the DOTS gateway client restarts?

DOTS gateway."

Comment: The DOTS server will have the requesting DOTS client (client in a
DOTS gateway) identifier, so the DOTS server will filter on this, but is
incapable of sending back different passed upstream client identifiers
unless they are included in the GET request.

Two

====

In addition, I am not convinced that the DELETE statement is correct as per
RFC8040 - I think the & before alias-name should be a / which makes things
interesting if there is no client-identifier to put in the path.

  DELETE /restconf/data/ietf-dots-data-channel-identifier:identifier\

/client-identifier=dz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMiobw&alias-name=
Server1 HTTP/1.1

  Host: {host}:{port}

                        Figure 5: DELETE identifier

From: Dots [mailto:[email-masked]] On Behalf Of Konda,
Tirumaleswar Reddy
Sent: 04 November 2017 14:12
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Data channel issues with GET

From: Jon Shallow [mailto:[email-masked]] 
Sent: Saturday, November 4, 2017 5:16 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>;
[email-masked]
Subject: RE: [Dots] Data channel issues with GET

         content=config HTTP/1.1

     Host: {host}:{port}

Correct?

Yes, fixed.

-Tiru

Regards

Jon

From: Dots [mailto:  <mailto:[email-masked]> [email-masked]]
On Behalf Of Jon Shallow
Sent: 04 November 2017 10:47
To: 'Konda, Tirumaleswar Reddy';  <mailto:[email-masked]> [email-masked]
Subject: Re: [Dots] Data channel issues with GET

Hi Tiru,

   client."

     Host: {host}:{port}

=====

|

                                                               |

 

Regards

Jon

From: Dots [mailto:  <mailto:[email-masked]> [email-masked]]
On Behalf Of Konda, Tirumaleswar Reddy
Sent: 04 November 2017 04:16
To: Jon Shallow;  <mailto:[email-masked]> [email-masked]
Subject: Re: [Dots] Data channel issues with GET

Hi Jon,

-Tiru

From: Dots [ <mailto:[email-masked]> mailto:[email-masked]] On
Behalf Of Jon Shallow
Sent: Saturday, November 4, 2017 3:03 AM
To:  <mailto:[email-masked]> [email-masked]
Subject: [Dots] Data channel issues with GET

Hi Tiru et al,

         content=config HTTP/1.1

     Host: {host}:{port}

   {

       "client-identifier": [

          "iAYmCNPmrYoKoqzgFMiobw"

       ],

       "alias": [

         {

           "alias-name": "Server1",

           "traffic-protocol": [

             6"

===========

===========

     container identifier {

              list alias {

                   key alias-name;

                   leaf alias-name {

                      type string;

                   }

                      type binary;

                      reference

                   }

                   leaf-list target-ip {

================

=============

Needs to be

===============

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 4 Nov 2017 14:28:33 +0000

Hi Jon,

The DOTS gateway (C3k) does not send any requests on its own to the DOTS server (S3).  As per the discussion of DOTS gateways in https://tools.ietf.org/html/draft-ietf-dots-architecture-05, it's only relaying the messages from the downstream and upstream agents. The DOTS architecture does not discuss DOTS gateway acting as a caching server.

CIH(C1ax) would only be unique across all the DOTS clients communicating with the DOTS gateway X but may not be globally unique (across Gateways J and K), the current approach would ensure no probability of client-identifier collisions.

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Saturday, November 4, 2017 4:17 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: [Dots] Data channel issues with GET

Hi Tiru,

=====

Regards

Jon

Hi Jon,

-Tiru

Hi Tiru et al,

   {

===========
     container identifier {

              list alias {
                   key alias-name;

                   leaf alias-name {
                      type string;

                      reference

                   leaf-list target-ip {

================

=============
Needs to be

===============

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 4 Nov 2017 14:34:41 +0000

Hi Jon,

Please see inline

From: Jon Shallow [mailto:[email-masked]]
Sent: Saturday, November 4, 2017 7:56 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: [Dots] Data channel issues with GET

Hi Tiru,

I still do not have an answer to my two other questions in my mail of 04 November 2017 10:47

One

"This still does not answer my implied concern - how does a DOTS gateway client request all the aliases / filters / mitigations to sync up state when, say, the DOTS gateway client restarts?
- The DOTS gateway may not know all the client-identifiers that are talking to the server component of the DOTS gateway - they may be behind yet another DOTS gateway."

Comment: The DOTS server will have the requesting DOTS client (client in a DOTS gateway) identifier, so the DOTS server will filter on this, but is incapable of sending back different passed upstream client identifiers unless they are included in the GET request.

Two

====
In addition, I am not convinced that the DELETE statement is correct as per RFC8040 - I think the & before alias-name should be a / which makes things interesting if there is no client-identifier to put in the path.

[TR] Thanks, fixed.

-Tiru

  DELETE /restconf/data/ietf-dots-data-channel-identifier:identifier\
         /client-identifier=dz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMiobw&alias-name=Server1 HTTP/1.1
  Host: {host}:{port}

From: Dots [mailto:[email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 04 November 2017 14:12
To: Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Data channel issues with GET

From: Jon Shallow [mailto:[email-masked]]
Sent: Saturday, November 4, 2017 5:16 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] Data channel issues with GET

Correct?

Yes, fixed.

-Tiru

Regards

Jon

Hi Tiru,

=====

Regards

Jon

Hi Jon,

-Tiru

Hi Tiru et al,

   {

===========
     container identifier {

              list alias {
                   key alias-name;

                   leaf alias-name {
                      type string;

                      reference

                   leaf-list target-ip {

================

=============
Needs to be

===============

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Sat, 4 Nov 2017 14:51:46 -0000

Hi Tiru

See 3 comments inline

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 04 November 2017 14:29
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Data channel issues with GET

Hi Jon,

The DOTS gateway (C3k) does not send any requests on its own to the DOTS
server (S3).  As per the discussion of DOTS gateways in
https://tools.ietf.org/html/draft-ietf-dots-architecture-05, it's only
relaying the messages from the downstream and upstream agents. The DOTS
architecture does not discuss DOTS gateway acting as a caching server. 

Jon> OK - I will see if further implementation throws anything else up on
this - if not, I will leave it as it stands

CIH(C1ax) would only be unique across all the DOTS clients communicating
with the DOTS gateway X but may not be globally unique (across Gateways J
and K), the current approach would ensure no probability of
client-identifier collisions.

DOTS client (C1aj) -------------------------------------- (S1j) DOTS gateway
J (C2j) ------\   

DOTS client (C1bj) -----------------------------------------/
|

|

DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ----- (S2k) DOTS gateway
K (C3k) ---- (S3)    

DOTS client (C1bx) -------/                                 |

                                                            |

DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) --------/

DOTS client (C1by) -------/

Jon>  If gateway K detects a collision in any of CIH(C1ax), CIH(C1bx),
CIH(C1ay) and CIH(C1by), gateway K can then add in CIH(C2x) or CIH(C2y) as
appropriate to maintain uniqueness as seen by S3.  If there is no collision
in CIH(C1ax), CIH(C1bx), CIH(C1ay) and CIH(C1by), then these will be unique
to S3 when coming from C3k.  This then potentially saves some packet space
and allows for scaling beyond a small number of gateways.

Jon> I 100% agree that we must not have any client identifier collisions.

-Tiru

Hi Tiru,

   client."

     Host: {host}:{port}

=====

|

                                                               |

 

Regards

Jon

Hi Jon,

-Tiru

Hi Tiru et al,

         content=config HTTP/1.1

     Host: {host}:{port}

   {

       "client-identifier": [

          "iAYmCNPmrYoKoqzgFMiobw"

       ],

       "alias": [

         {

           "alias-name": "Server1",

           "traffic-protocol": [

             6"

===========

===========

     container identifier {

              list alias {

                   key alias-name;

                   leaf alias-name {

                      type string;

                   }

                      type binary;

                      reference

                   }

                   leaf-list target-ip {

================

=============

Needs to be

===============

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 4 Nov 2017 15:22:23 +0000

Hi Jon,

Please see inline [TR]

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Saturday, November 4, 2017 8:22 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: Re: [Dots] Data channel issues with GET

Hi Tiru

See 3 comments inline

Regards

Jon

Hi Jon,

Jon> OK - I will see if further implementation throws anything else up on this - if not, I will leave it as it stands

DOTS client (C1aj) -------------------------------------- (S1j) DOTS gateway J (C2j) ------\
DOTS client (C1bj) -----------------------------------------/                              |
                                                                                           |
DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ----- (S2k) DOTS gateway K (C3k) ---- (S3)
DOTS client (C1bx) -------/                                 |
                                                            |
DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) --------/
DOTS client (C1by) -------/

Jon>  If gateway K detects a collision in any of CIH(C1ax), CIH(C1bx), CIH(C1ay) and CIH(C1by), gateway K can then add in CIH(C2x) or CIH(C2y) as appropriate to maintain uniqueness as seen by S3.  If there is no collision in CIH(C1ax), CIH(C1bx), CIH(C1ay) and CIH(C1by), then these will be unique to S3 when coming from C3k.  This then potentially saves some packet space and allows for scaling beyond a small number of gateways.

[TR] Agreed. I am assuming there won't be more than 3 DOTS gateways b/w the DOTS client and server (client-side, server-side and one additional gateway because of recursive signalling).
As per our discussion, DOTS signal channel draft says, a DOTS gateway "MAY" add the client-identifier.

-Tiru

-Tiru

Hi Tiru,

=====

Regards

Jon

Hi Jon,

-Tiru

Hi Tiru et al,

   {

===========
     container identifier {

              list alias {
                   key alias-name;

                   leaf alias-name {
                      type string;

                      reference

                   leaf-list target-ip {

================

=============
Needs to be

===============

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Sat, 4 Nov 2017 16:27:41 -0000

Hi Tiru,

I agree that there is a MAY in

"client-identifier:  The client identifier MAY be conveyed by the DOTS

      gateway to propagate the DOTS client identity from the gateway's

      client-side to the gateway's server-side, and from the gateway's

      server-side to the DOTS server."

But the following implies it has to be done, even though there is not a MUST
- MAY should be included (as in '., the DOTS gateway MAY compute the
'client-identifier' value, as discussed above, and add the computed ." I
think.

"If the

   'client-identifier' value is already present in the mitigation

   request received from the DOTS client, the DOTS gateway computes the

   'client-identifier' value, as discussed above, and adds the computed

   'client-identifier' value to the end of the 'client-identifier' list."

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 04 November 2017 15:22
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Data channel issues with GET

Hi Jon,

Please see inline [TR]

Hi Tiru

See 3 comments inline

Regards

Jon

Hi Jon,

|

                                                            |

 

[TR] Agreed. I am assuming there won't be more than 3 DOTS gateways b/w the
DOTS client and server (client-side, server-side and one additional gateway
because of recursive signalling). 

As per our discussion, DOTS signal channel draft says, a DOTS gateway "MAY"
add the client-identifier. 

-Tiru

 

-Tiru

Hi Tiru,

   client."

     Host: {host}:{port}

=====

|

                                                               |

 

Regards

Jon

Hi Jon,

-Tiru

Hi Tiru et al,

         content=config HTTP/1.1

     Host: {host}:{port}

   {

       "client-identifier": [

          "iAYmCNPmrYoKoqzgFMiobw"

       ],

       "alias": [

         {

           "alias-name": "Server1",

           "traffic-protocol": [

             6"

===========

===========

     container identifier {

              list alias {

                   key alias-name;

                   leaf alias-name {

                      type string;

                   }

                      type binary;

                      reference

                   }

                   leaf-list target-ip {

================

=============

Needs to be

===============

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 6 Nov 2017 13:18:58 +0000

Hi Jon,

Please see inline [TR]

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Saturday, November 4, 2017 9:58 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: Re: [Dots] Data channel issues with GET

Hi Tiru,

But the following implies it has to be done, even though there is not a MUST - MAY should be included (as in '..., the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed ..." I think.

[TR] Agreed, fixed.

Cheers,
-Tiru

"If the

Regards

Jon

Hi Jon,

Please see inline [TR]

Hi Tiru

See 3 comments inline

Regards

Jon

Hi Jon,

-Tiru

-Tiru

Hi Tiru,

=====

Regards

Jon

Hi Jon,

-Tiru

Hi Tiru et al,

   {

===========
     container identifier {

              list alias {
                   key alias-name;

                   leaf alias-name {
                      type string;

                      reference

                   leaf-list target-ip {

================

=============
Needs to be

===============

Regards

Jon