Dear Ramesh,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Softwires [mailto:[email protected]] De la part de
> [email protected]
> Envoyé : vendredi 4 mai 2018 17:26
> À : [email protected]; [email protected]
> Cc : [email protected]; [email protected]
> Objet : Re: [Softwires] ISP CGN logging inc. Destination ??
> 
> Dear Ian,  thanks for clarifications.
> 
> Regulator in India mandated to preserve the following details for each flow.
> 1.    Source IP + Port (private for end subscriber device)

[Med] Please note that this one may be overlapping among multiple subscribers 
if DS-Lite is used. 

> 2.    Destination IP + Port (public)

[Med] Does the regulator require to preserve "Destination IP + Port" even if a 
public IP address is assigned to a subscriber?

> 3.    Translated IP + port (public)
> 4.    Date and time
> 
> There is no brainer and all this is available in NAT44. MAP being stateless,
> no such data available from MAP-BR. We are exploring alternate option on BR
> to create this data in MAP.
> 
> Pls advise.
> 
> Regds
> ramesh
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: 04 May 2018 17:28
> To: Rajiv Asati (rajiva)
> Cc: Softwires-wg list; [email protected]; Ramesh R Chandra
> Subject: Re: [Softwires] ISP CGN logging inc. Destination ??
> 
> Hi Rajiv,
> 
> Please see inline.
> 
> Cheers,
> Ian
> 
> > On 4. May 2018, at 12:01, Rajiv Asati (rajiva) <[email protected]> wrote:
> >
> > Ian,
> >
> > Thanks for sharing the URL. While not explicit, “all metadata” would
> include both source and destination A+P. Is that the right interpretation?
> 
> [if - My understanding is that per-flow logging is necessary to meet the
> requirement, but I’m not familiar enough with the legislation to know what
> exactly needs to be stored.]
> 
> >
> > If an ISP were to use “binding” mode on the BR, then without using net
> flow/IPFIX, How could the compliance be achieved ?
> 
> [if - If there’s address sharing and the requirement is to provide an exact
> match to a data retention request (in some countries, a list of e.g. 16 users
> is OK), then AFAICS, you have to use IPFIX.
> 
> The implementation problem for this is compounded by the lack of state table
> on most BR implementations (e.g. how do you know when a UDP session has
> completed without state for that flow?)]
> 
> 
> "Confidentiality Warning: This message and any attachments are intended only
> for the use of the intended recipient(s).
> are confidential and may be privileged. If you are not the intended
> recipient. you are hereby notified that any
> review. re-transmission. conversion to hard copy. copying. circulation or
> other use of this message and any attachments is
> strictly prohibited. If you are not the intended recipient. please notify the
> sender immediately by return email.
> and delete this message and any attachments from your system.
> 
> Virus Warning: Although the company has taken reasonable precautions to
> ensure no viruses are present in this email.
> The company cannot accept responsibility for any loss or damage arising from
> the use of this email or attachment."
> _______________________________________________
> Softwires mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to