.
Cheers,
Rajiv Asati
VP.CTO, Cisco
“Focus on what we can do with what we have, not the other way around.”
On Nov 4, 2022, at 9:19 AM, Poscic, Kristian (Nokia - US)
wrote:
I agree with Jordan, that it should NOT be made a MUST.
In the extreme, someone can use this as attack so that BR does
I agree and sometimes flexibility becomes an unwanted necessity (as is the case
here with option (a)).
IMO, option (b) length based check for NH should be preferred, since it works
for all AFI/SAFIs with an assumption that NH could be one IPv4 or IPv6 prefix.
Very reasonable option.
Option
Thanks, Eric & Dave.
--
Cheers,
Rajiv
From: Eric Vyncke
Date: Tuesday, May 28, 2019 at 3:07 AM
To: David Black , "tsv-...@ietf.org"
Cc: Softwires-wg list , IETF Discussion ,
"draft-ietf-softwire-iftunnel@ietf.org"
Subject: Re: Tsvart last call review of draft-ietf-softwire-iftunnel-04
nel@ietf.org"
Subject: Tsvart last call review of draft-ietf-softwire-iftunnel-04
Resent-From:
Resent-To: "mohamed.boucad...@orange.com" ,
, Rajiv Asati , Yong Cui
, Eric Vyncke ,
, Yong Cui
Resent-Date: Tuesday, May 7, 2019 at 6:45 PM
Reviewer: David Black
Review result:
1. Not aware
2. Not aware.
Cheers,
Rajiv Asati
Distinguished Engineer, CX CTO Office
> On Jan 28, 2019, at 9:43 AM, "ian.far...@telekom.de"
> wrote:
>
> Hi Yong,
>
> Please see inline below.
>
> Thanks,
> Ian
>
> On 26.01.19, 13:08,
Support (as a co-author).
--
Cheers,
Rajiv
From: Softwires on behalf of "ianfar...@gmx.com"
Date: Tuesday, January 8, 2019 at 11:48 AM
To: Yong Cui
Cc: Softwires-wg list
Subject: Re: [Softwires] WGLC for draft-ietf-softwire-iftunnel-01
HI Yong,
Sorry for the late response. I’m still
), then it would warrant a solution such as IPFIX anyway, in
which case, it would also implicitly solve for the stateless 4o6 techniques.
--
Cheers,
Rajiv
From: "mohamed.boucad...@orange.com" <mohamed.boucad...@orange.com>
Date: Wednesday, May 9, 2018 at 3:30 AM
To: Rajiv Asati &
day, May 9, 2018 at 3:25 AM
To: "yiu_...@comcast.com" <yiu_...@comcast.com>, Rajiv Asati <raj...@cisco.com>
Cc: "ianfar...@gmx.com" <ianfar...@gmx.com>, Softwires-wg list
<softwires@ietf.org>, "int-a...@ietf.org" <int-a...@ietf.org>
Subject
l.com" <ramesh.r.chan...@ril.com>
Date: Tuesday, May 8, 2018 at 1:15 AM
To: "yiu_...@comcast.com" <yiu_...@comcast.com>
Cc: "ianfar...@gmx.com" <ianfar...@gmx.com>, Rajiv Asati <raj...@cisco.com>,
Softwires-wg list <softwires@ietf.org>, "int-a...@iet
Thanks, Med. This makes it very explicit.
--
Cheers,
Rajiv
From: "mohamed.boucad...@orange.com" <mohamed.boucad...@orange.com>
Date: Monday, May 7, 2018 at 1:30 AM
To: Rajiv Asati <raj...@cisco.com>, Softwires-wg list <softwires@ietf.org>,
"int-a...
.
The need for connection logging may go beyond the concern of size of logging
data - user privacy. And this carries over to not only A+P techniques, but
also IPv6. IOW, this concern may not be limited to address sharing techniques.
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services
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 an ISP were to use “binding” mode on the BR, then without using net
flow/IPFIX, How could the compliance be achieved ?
Cheers,
Rajiv Asati
there is no logging in such solutions. If such a
guideline was also mandated for native IPv6, then it would pose an interesting
deployment issue.
--
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco
PS: Few may be aware of Govt. of India’s mandate* to log both source and
destination IP+port pair
, then
MAP-T or E enabled on CPE by default going forward (recalling the trials)?
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services
On Apr 10, 2018, at 5:00 AM,
"xiechf@chinatelecom.cn<mailto:xiechf@chinatelecom.cn>"
<xiechf@chinatelecom.cn<mailto:xiec
a second IETF last call and
then advance the document.
Could we not combine the LC and the question in 1-go?
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services
CITT CTO Office
On Nov 11, 2014, at 11:12 AM, Ted Lemon
ted.le...@nominum.commailto:ted.le...@nominum.com wrote:
Dear softwire
, not close to
zero due to PMTUD etc.?
AFAIK, RFC6888 doesn¹t mention such a problem or requirement for CGN?
IMO, there shouldn¹t be any normative recommendation, if this problem is
mentioned.
--
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco
-Original Message-
From: Ted Lemon ted.le
UmmŠthat doesn¹t cut it either, since softwire node will always have to
formulate the 32-bit IPv4 address even if /32 is conveyed. Also,
Software interface is not defined anywhere in this document.
How about the following -
--
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco
Good point, Woj. What I described was indeed the default behavior.
--
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco
-Original Message-
From: Wojciech Dec wdec.i...@gmail.com
Date: Thursday, November 14, 2013 4:48 AM
To: Rajiv Asati raj...@cisco.com
Cc: Kristian Poscic
Hi Kristian,
Yes, that's correct.
--
Cheers,
Rajiv
-Original Message-
From: Poscic, Kristian Poscic kristian.pos...@alcatel-lucent.com
Date: Tuesday, November 12, 2013 6:31 PM
To: Softwires-wg list softwires@ietf.org
Subject: [Softwires] port-forwards in MAP
Just wanted to
Hi Edwin,
This document has been quite useful to few of upcoming MAP-T deployments.
I would be supportive of its adoption in this WG, if/when prompted by the
chairs.
--
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco
-Original Message-
From: Edwin Cordeiro ecorde...@nic.br
Date
Typically, an IP address pertains to a CPE. So, a common BCP is to employ
uRPF to detect/mitigate the source-address spoofing.
In A+P environment (such as that of MAP), an IPv4 address + port-range
pertain to a CPE. So, it is tempting to think that the port-range aware
uRPF is needed to avoid
I really don't see the need for having to specify more than one BR
prefixes (of whatever length) inside a single MAP domain. Let alone FQDN
or list of IP addresses.
The reason is that having multiple BR prefixes in the same domain would at
best allow the upstream traffic to go to different BR.
I agree, Simon.
Cheers,
Rajiv
-Original Message-
From: Simon Perreault simon.perrea...@viagenie.ca
Date: Friday, April 26, 2013 11:22 AM
To: Rajiv Asati raj...@cisco.com
Cc: Ole Troan otr...@employees.org, Softwires-wg list
softwires@ietf.org
Subject: Re: [Softwires] MAP based
.
Cheers,
Rajiv
-Original Message-
From: Cameron Byrne cb.li...@gmail.com
Date: Friday, April 26, 2013 12:01 PM
To: Rajiv Asati raj...@cisco.com
Cc: Ole Troan otr...@employees.org, Simon Perreault
simon.perrea...@viagenie.ca, Softwires-wg list softwires@ietf.org
Subject: Re: [Softwires] MAP
I agree with Med. In reality, it is highly unlikely that each and every Dhcpv4
option would be needed for an ipv6 only host.
And the ones that are really needed, would better move to dhcvpv6 sooner than
later. It would be prudent for us to do find the delta instead of carrying over
the legacy
Ole, Tom,
I would suggest fixing port offset to 6 rather than 4, since 0-1023 are
the system/reserved ports that should be avoided by default. This also
allows increasing the IP address sharing efficiency, suffice to say, as
Tom already noted.
Pls see RFC6335.
Of course, the default
I thought we had closed this optic after the extensive discussion on the
mailing list few months back.
Cheers,
Rajiv
-Original Message-
From: Ole Troan o...@cisco.com
Date: Wednesday, February 13, 2013 6:17 PM
To: Tom Taylor tom.taylor.s...@gmail.com
Cc: Softwires-wg list
I support (a).
Not allowing the usage of the reserved port range 0-1023 is one less thing
for an operator to worry about.
0-1023 range is good enough to be blocked.
Cheers,
Rajiv
-Original Message-
From: Ole Troan o...@cisco.com
Date: Tuesday, February 5, 2013 8:38 AM
To:
+1 in keeping both.
-Original Message-
From: wang.c...@zte.com.cn wang.c...@zte.com.cn
Date: Monday, January 28, 2013 9:38 PM
To: Wojciech Dec wdec.i...@gmail.com
Cc: Softwires-wg list softwires@ietf.org, remi.desp...@free.fr
remi.desp...@free.fr, softwires-boun...@ietf.org
is whether to import these algorithm parameters EXPLICITLY into IPv6
address or not.
Lw4o6 does not import anything into IPv6 address.
Nor does MAP in a typical deployment. IOW, MAP doesn't require IPv6 prefix
assignment (or addressing policy) to be different from what it would be
without MAP.
Let's not leave anything in the drafts as loose-ends for the readers (e.g.
Implementors, designers, architects) to (mis)interpret.
We better provide recommendations, if/as needed in case of ambiguity or
disagreement.
IMO, /64 (or less) usage for end-user prefix is better off as a MAP (-E)
I just noticed an opportunity for the technical fix-up in section 5.1.
The current text suggests reserving the first IPv6 prefix in an End-user
IPv6 prefix for MAP. Well, we should't be reserving the entire prefix. We
just need an address.
Please consider updating the text.
OLD:
zero) of
the summary routes.
Cheers,
Rajiv
-Original Message-
From: Yiu Lee yiu_...@cable.comcast.com
Date: Monday, November 12, 2012 1:33 PM
To: Rajiv Asati raj...@cisco.com, Softwires-wg list softwires@ietf.org
Subject: Re: [Softwires] MAP-E 1:1 for HA
I am not talking about whether a MAP-domain
One can define a MAP-domain consisting of 1 CE or N CEs. This is more of a
deployment choice.
Cheers,
Rajiv
-Original Message-
From: Lee, Yiu Lee yiu_...@cable.comcast.com
Date: Friday, November 9, 2012 2:43 PM
To: Softwires-wg list softwires@ietf.org
Subject: [Softwires] MAP-E 1:1 for
Let's not get into debating the local behavior e.g. Implementation
specifics (since one can argue that the router vendors can provide
comparable optimization for host routes as well as non-host routes).
If I as a vendor were really bothered about host vs. non-host
control-plane data-plane, then
Favor of both.
When will the opportunity be to change from experimental to standards? and
what will it take ?
Thanks.
Cheers,
Rajiv
Sent from my Phone
On Sep 25, 2012, at 12:45 AM, Suresh Krishnan suresh.krish...@ericsson.com
wrote:
Hi all,
During the softwire WG meeting at IETF84
+1
I also support MAP-E and MAP-T, as Maglione pointed out. We need to be
respectful of the design team that produced MAP based on consideration and
requirements. Not to forget that MAP-T (unlike others) has already been
deployed.
Cheers,
Rajiv
Sent from my Phone
On Aug 8, 2012, at 5:35 AM,
Support.
Cheers,
Rajiv
-Original Message-
From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On
Behalf Of Satoru Matsushima
Sent: Friday, July 20, 2012 6:12 AM
To: Suresh Krishnan
Cc: Softwires WG; Yong Cui
Subject: Re: [Softwires] Call for adoption of
This is a moot argument, as we have seen many protocols (take MPLS for
example) that were proposed to do just X, evolved to do X, Y, Z and
more.
Who would have thought that BGP would be advertising MAC addresses when
BGP was first introduced?
Let's focus on the operational problems solved (or
I am not fond of the proposed change.
After all, most of the other documents refer to stateful without taking a
side (e.g. carrier-side), and so this document should state stateless in the
same regard.
Of course, where it makes sense to clarify, it must be clarified that stateless
is in the
1. Rajiv Asati, Cisco: Yes
2. Rajiv Asati, Cisco: MAP
Cheers,
Rajiv
-Original Message-
From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org]
On
Behalf Of Alain Durand
Sent: Wednesday, April 04, 2012 5:14 PM
To: softwires@ietf.org WG
Cc: int-...@tools.ietf.org
I am disappointed with this approach.
Despite the support, the WG adoption of MAP documents has been delayed for
a label reason. I find it unfair since the label can be changed any time
until the IESG review. How can it be a hold-up?
One would have to wonder the intent of forming the design team
I am well aware of this, but this doesn't explain why 4rd mapping rules
similar
to those of CERNET2 wouldn't have, like MAP-T, IPv4 to IPv6 communication
(single translation) supported.
As said in RFC6219, CERNET hosts have their IPv6 addresses configured via
manual configuration or
I prefer what draft-tsou-softwire-port-set-algorithms-analysis calls
GMA
(still trivial to implement and to use but harder to trace).
I agree. GMA is defined here, btw -
http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-0
2#section-4.1
Cheers,
Rajiv
-Original
+1
Cheers,
Rajiv
Sent from my Phone
On Feb 11, 2012, at 3:30 AM, Francis Dupont francis.dup...@fdupont.fr wrote:
In your previous mail you wrote:
(1) Either issue a WG LC, or
+1
francis.dup...@fdupont.fr
___
Softwires mailing list
I would shy away from drawing that conclusion, given the implementation
specifics.
Cheers,
Rajiv
-Original Message-
From: Rémi Després [mailto:despres.r...@laposte.net]
Sent: Tuesday, February 07, 2012 8:28 AM
To: Rajiv Asati (rajiva)
Cc: Satoru Matsushima; Softwires WG; Wojciech
ability instead of the more general five-tuple based IPv4
classification ability should be reserved, when deliver IPv4 over
IPv6?
How would one get 5-tuple based classification when delivering IPv4 over
IPv6, if the v4 packet is not translated into v6?
The fact of the matter is that 5-tuple
Hi Xie,
China Telecom have placed the prototype of DIVI in its product
network
and gave a systematic test , and we haven't found any reachibility
problem due
to option processing in tranlation box. Moreover, during Tinghua 100th
Thanks for sharing your deployment experience. This
every IP-only app work now on
n900?
Cheers,
Rajiv
-Original Message-
From: Cameron Byrne [mailto:cb.li...@gmail.com]
Sent: Wednesday, September 28, 2011 3:14 PM
To: Rajiv Asati (rajiva)
Cc: Mark Townsley; Hui Deng; Softwires-wg list; Behave WG; IETF Discussion;
Dan Wing (dwing
Hi Cameron,
Very interesting ( clever indeed).
How does this clever code ensure that all but a few (pesky apps)
continue to use IPv6 interface instead of the NAT46 interface?
Cheers,
Rajiv
-Original Message-
From: behave-boun...@ietf.org [mailto:behave-boun...@ietf.org] On
Behalf
tunneling). It may be that the recommendation is specifically against
*stateful* double translation
That may be reasonable. And the document may reflect that.
IETF recommends using dual-stack or tunneling based solutions
for
IPv6 transition and specifically recommends against
that the interim meeting agenda would end up allowing more
than one WGs work on 4v6 transition options. Not the best intent in
favor of larger internet community.
Cheers,
Rajiv
-Original Message-
From: Rajiv Asati (rajiva)
Sent: Friday, August 19, 2011 11:04 AM
To: 'Alain Durand'
Cc
Yes for 5 and 4.
On 20 August 2011 16:21, Yong Cui cuiy...@tsinghua.edu.cn wrote:
Hi folks,
Following our rough concensus during Quebec City meeting and
according to our charter/milestones, the chairs would like to
ask the mailing list for the confirmation to
Yong,
Why is dIVI not included In the discussion ?
Could you please clarify?
Cheers,
Rajiv
Sent from Phone
On Aug 19, 2011, at 8:10 AM, Yong Cui cuiy...@tsinghua.edu.cn wrote:
Hi folks,
We, softwire wg chairs, in agreement with our ADs, are announcing
an interim meeting in Beijing
+1.
The RFP angle is an important one, Simon.
Cheers,
Rajiv
Sent from Phone
On Aug 19, 2011, at 8:57 AM, Simon Perreault simon.perrea...@viagenie.ca
wrote:
On 2011-08-19 05:19, Tetsuya Murakami wrote:
draft-murakami-softwire-4rd
draft-murakami-softiwire-4v6-translation
I think it
, not
just a particular solution.
Cheers,
Rajiv
-Original Message-
From: Alain Durand [mailto:adur...@juniper.net]
Sent: Friday, August 19, 2011 9:44 AM
To: Rajiv Asati (rajiva)
Cc: Yong Cui; softwires@ietf.org; liziye; iesg-secret...@ietf.org;
Ralph Droms
(rdroms)
Subject: Re
Nejc,
Good table indeed.
If you could add few more service related impact due to other features such as
UPNP inside home, DPI in the network, L4 QoS in the network, L4-aware routing
etc., then it would be quite insightful. I may also help you with that.
Cheers,
Rajiv
-Original
: xiaohong.d...@orange-ftgroup.com [mailto:xiaohong.deng@orange-
ftgroup.com]
Sent: Wednesday, August 10, 2011 5:35 AM
To: despres.r...@laposte.net; Rajiv Asati (rajiva)
Cc: softwires@ietf.org
Subject: RE: [Softwires] Clarification of the stateles/stateful discussion
|-Original
Satoru-san,
This is an important point that most of us forget that restricting to
n ports doesn't equate to just n NAT sessions rather many more than
n sessions. We must add that to the 4v6 motivation draft as well as to
the 4v6 comparison draft.
port. There may be multiple session to
Hi Cameron,
Please see inline,
I believe the mapped mode has some similar challenges in mobile as
DS-lite. It is an IP in IP tunnel. It is really a non-starter in
3GPP networks as the draft amply notes.
Thanks for sharing your opinion about the 4v6 encap mode as well as
other tunneling
doesn't really solve the problem, considering the
evolving operational practices.
Cheers,
Rajiv
-Original Message-
From: Jan Zorz @ go6.si [mailto:j...@go6.si]
Sent: Monday, August 01, 2011 10:32 AM
To: Rémi Després
Cc: Rajiv Asati (rajiva); softwires@ietf.org
Subject: Re: [Softwires
Indeed.
And we keep forgetting an important point that most of us have been
*just* fine with only 1000 (or 2000) ports since that's what most
CPE/home routers in our homes had with NAT44, by default.
Cheers,
Rajiv
-Original Message-
From: softwires-boun...@ietf.org
Jan,
The better solution would be to allocate more ports to the user,
depending on ISP policy.
The CPE/home router can log the exhaustion of the binding and this could
be notified by SNMP (at least in the managed CPE case).
Cheers,
Rajiv
-Original Message-
From:
Cameron,
... there are not enough public
address to give these users (growth through 2015) each 2000 ports.
Agreed. Please note that 2000 ports per subscriber is just one allocation
point. It could be as low as 16 ports per subscriber.
In wireline deployments, 256 or 512 or 1000 ports
We agree that different operators (whether in 3GPP/mobile space or Wireline
(DSL/Cable/Fiber) space) would embrace stateful or stateless NAT based
solution, per their short-term long-term plans and associated constraints.
Perhaps, it could be phrased a bit better in the draft, but that's not
I think definitely we should define the first case, isn't reduce
redundant
delivery the original spirit of multicast? Deliver multicast over an
IPv6
multicast disabled network doesn't seem quite persuading, except the
legacy
case.
And AMT has been devised to address that very space. :)
We
Remi,
Note also that, in 3GPP where power consumption is important, the IPv4v6
bearer option completely avoids the IPv6 header overhead (no need for 4V6).
Don't follow this. Could you please expand?
Cheers,
Rajiv
-Original Message-
From: softwires-boun...@ietf.org
Cameron,
Since i have seen 3G/LTE on a few of these related threads, i will
state that it is unlikely that mobile wireless providers and the
3GPP/GSMA will adopt yet another tunneling protocol or user equipment
modification.
Thanks for sharing your opinion, as most of us may not be caring
Support.
Cheers,
Rajiv
-Original Message-
From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com]
Sent: Friday, June 17, 2011 2:32 AM
To: mohamed.boucad...@orange-ftgroup.com
Cc: Satoru Matsushima; Softwires-wg; 'Softwire Chairs'; Lee, Yiu;
olaf.bonn...@telekom.de;
69 matches
Mail list logo
