[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    RE: John Scudder's No Objection on draft-ietf-6man-ipv6-alt-mark-16: (with COMMENT)
From:       Giuseppe Fioccola <giuseppe.fioccola=40huawei.com () dmarc ! ietf ! org>
Date:       2022-07-13 16:38:41
Message-ID: 6adabfee67a04d7fbdc9e7bd202831ef () huawei ! com
[Download RAW message or body]

Hi John,
Please see my reply inline as [GF]

Giuseppe

-----Original Message-----
From: John Scudder <jgs@juniper.net> 
Sent: Wednesday, July 13, 2022 6:11 PM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Cc: The IESG <iesg@ietf.org>; draft-ietf-6man-ipv6-alt-mark@ietf.org; \
                6man-chairs@ietf.org; ipv6@ietf.org; bob.hinden@gmail.com; \
                otroan@employees.org
Subject: Re: John Scudder's No Objection on draft-ietf-6man-ipv6-alt-mark-16: (with \
COMMENT)

Hi Giuseppe,

> On Jul 13, 2022, at 4:34 AM, Giuseppe Fioccola <giuseppe.fioccola@huawei.com> \
> wrote: 
> 4. In  §5.3, This is OK,
> 
> The FlowMonID allocation procedure can be stateful or stateless.  In
> case of a stateful approach, it is required that each source node
> stores and keeps track of the FlowMonID historic information in order
> to assign unique values within the domain.  This may imply a complex
> procedure and it is considered out of scope for this document.
> 
> But, isn't most of the complexity required in this case for the 
> purposes of tracking and retrieving what ID you associated with which 
> flow? And therefore, that complexity would also be required in the 
> case of a centralized controller, mentioned just a few paragraphs down in bullet 2?
> 
> [GF]: Yes, I can also add this consideration. But, I think that for the controller \
> it can be easier since it instructs the nodes and it can keep track of the assigned \
> IDs. But, for a distributed solutions, each source node should also know the IDs \
> assigned by other source nodes and this complicates much more.

I still don't get why each source node needs to also know the IDs assigned by other \
source nodes, since

   it is RECOMMENDED to consider the 3-tuple FlowMonID, source and
   destination addresses:

So, unless that recommendation is ignored, it would be fine for source node A and \
source node B to choose the same FlowMonID, since the triple would still differ on \
the SA element. No?

[GF]: Yes, for the point-to-point case you are right but it is needed a coordination \
in the case of a multipoint flow where more sources may be instructed to use the same \
FlowMonID. And the controller may reconfigure FlowMonIDs and source/destination \
address filtering to zoom in (or zoom out) from a network cluster up to the single \
flow.

—John
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]