Support this draft as a WG item.
Cheers,
Rajiv
> -Original Message-
> From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org]
On
> Behalf Of Bill Storer (bstorer)
> Sent: Monday, October 27, 2008 7:11 PM
> To: Pradosh Mohapatra (pmohapat); softwires@ietf.org;
> alain_dur...@c
Support.
Cheers,
Rajiv
> -Original Message-
> From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com]
> Sent: Friday, June 17, 2011 2:32 AM
> To:
> Cc: Satoru Matsushima; Softwires-wg; 'Softwire Chairs'; Lee, Yiu;
> olaf.bonn...@telekom.de; isa...@ptinovacao.pt;
cheng...@chinamobil
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 [mailto:softw
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 carin
...@townsley.net]
> Sent: Tuesday, July 26, 2011 4:39 PM
> To: Rajiv Asati (rajiva)
> Cc: Rémi Després; Wojciech Dec; Softwires-wg; Wojciech Dec (wdec)
> Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E
>
>
> On Jul 26, 2011, at 4:30 PM, Rajiv Asati (rajiva) wrote:
>
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
Jan,
Interesting enough, the static port-set is one of the reasons why many
find 4v6 being so useful.
Cheers,
Rajiv
> -Original Message-
> From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org]
On Behalf
> Of Jan Zorz @ go6.si
> Sent: Monday, August 01, 2011 5:26 AM
> To:
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@ie
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 [mailto:softwires
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: softwires-boun...@i
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
M
> To: Jan Zorz go6.si
> Cc: Softwires-wg; Rajiv Asati (rajiva)
> Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
>
>
> Le 1 août 2011 à 16:31, Jan Zorz @ go6.si a écrit :
>
> > On 8/1/11 4:22 PM, Rémi Després wrote:
> >>
&
> I appreciate that, and agree that the case for stateless A+P mapping is
> clearer for DSL and optical fibers than for 3GPP
There are other 3GPP operators who favor using stateless A+P mapping, so I
would shy away from the above agreement. Of course, different operators have
different constrain
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. :)
W
about solutions, of course.
Cheers,
Rajiv
> -Original Message-
> From: Cameron Byrne [mailto:cb.li...@gmail.com]
> Sent: Monday, August 01, 2011 12:38 PM
> To: Rajiv Asati (rajiva)
> Cc: Rémi Després; Softwires-wg; Paco Cortes; Wojciech Dec (wdec)
> Subject: Re: [Softw
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 dif
ajiv
> -Original Message-
> From: 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
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 Message
gt; 'scattered' port-set.
>
> But I don't understand will the figure be different with 'scattered' port-set
> NAT? To my knowledge, it's something todo with app's behaviours and NAT
> type(EIM in our test).
> Would you explain if I miss some
; To: Rajiv Asati (rajiva); Simon Perreault; softwires@ietf.org
> Subject: Re: [Softwires] Clarification of the stateles/stateful discussion
>
> This could be a separate table. The good thing about this table is that is
> clean and focused.
>
>
> On 8/12/11 7:08 AM, &quo
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" wrote:
> Hi folks,
>
> We, softwire wg chairs, in agreement with our ADs, are announcing
> an interim meeting in Beijing on September 26 &
+1.
The RFP angle is an important one, Simon.
Cheers,
Rajiv
Sent from Phone
On Aug 19, 2011, at 8:57 AM, "Simon Perreault"
wrote:
> On 2011-08-19 05:19, Tetsuya Murakami wrote:
>> draft-murakami-softwire-4rd
>> draft-murakami-softiwire-4v6-translation
>>
>> I think it might be good to
of dIVI.
> However, according to our current Softwire charter and Milestones,
> dIVI is not the most urgent thing to do in Softwire.
>
> Yong
>
> -Original Message-
> From: "Rajiv Asati (rajiva)"
> Date: Fri, 19 Aug 2011 08:16:05 -0400
> To: Yong Cui
v6 options, 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
Yes for 5 and 4.
> On 20 August 2011 16:21, Yong Cui 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 adopt the followi
#
I am afraid 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
&
> doing here). As such, the ability to assign or not that port range should be
> left to each SP and not excluded by default.
+1.
Cheers,
Rajiv
> -Original Message-
> From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf
> Of mohamed.boucad...@orange.com
> Sent
> 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 aga
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
Behal
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 inva
code? IOW, does 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; IET
> 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-t
Yes. I support WG adoption (and carry on the discussion further).
Cheers,
Rajiv
Sent from my Phone
On Jan 30, 2012, at 11:31 AM, Ole Trøan wrote:
> hi,
>
> the MAP (Mapping of address and port) design team has now written and
> published the following sets of drafts.
>
> the base document (
> C2. The sharing ratio sounds a calculated result, not a ‘given’ condition;
I would very much favor having a sharing ratio as a 'given' variable, instead
of a calculated result (and instead of EA-bit length, if needed be) since it is
easier to understand, explain and work it out.
In fact, most
> the 4rd-E case, the BR checks that the source address in the IPv4 header
> matches that of the IPv6 address.
Could this check (and filtering) be done without incurring a performance
penalty?
Cheers,
Rajiv
Sent from my Phone
On Feb 7, 2012, at 8:03 AM, Rémi Després wrote:
>
> Le 2012-02
Hi Cameron,
Good question. Yes, MAP is deployable even in that case (though the
mileage may vary). One deployment approach suggested below.
What's really interesting is that MAP-T CE function (with sharing
ratio=1, thereby disabling NAT44 on CE) could get us quite comparable to
the CLAT function,
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 Matsushim
Indeed. Such a scenario makes little sense to me, given that MAP requires
native IPv6 connectivity anyway.
IOW, if CE is able to get native IPv6 anyway for MAP, then anything non-native
IPv6 would have no usage.
Cheers,
Rajiv
Sent from my Phone
On Feb 7, 2012, at 9:36 PM, "Lee, Yiu" wrote:
+1
Cheers,
Rajiv
Sent from my Phone
On Feb 11, 2012, at 3:30 AM, "Francis Dupont" wrote:
>
> In your previous mail you wrote:
>
>> (1) Either issue a WG LC, or
>
> +1
>
> francis.dup...@fdupont.fr
> ___
> Softwires mailing list
> Softwires@ietf.o
> 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 Mes
> 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 configura
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 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
Cheers,
Rajiv
Sent from my Phone
On Jun 12, 2012, at 9:14 AM, "mohamed.boucad...@orange.com"
wrote:
>
> Hi Yiu,
>
>
> +1.
>
>
> Cheers,
> Med
>
>> -Message d'origine-
>> De : softwires-boun...@ietf.org
>> [mailto:softwires-boun...@ietf.org] De la part de Lee, Yiu
>> Envoyé
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 not
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 dra
+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,
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"
wrote:
> Hi all,
> During the softwire WG meeting at IETF84 a series of questions* t
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: , Yiu Lee
Date: Friday, November 9, 2012 2:43 PM
To: Softwires-wg list
Subject: [Softwires] MAP-E 1:1 for HA
>I have a question for the HA design conce
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
1:1 looks a
>stateful solution to me.
>
>
>On 11/10/12 1:34 AM, "Rajiv Asati (rajiva)" wrote:
>
>>
>>One can define a MAP-domain consisting of 1 CE or N CEs. This is more of
>>a
>>deployment choice.
>>
>>Cheers,
>>Rajiv
>&
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 le
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)
rec
+1 in keeping both.
-Original Message-
From: "wang.c...@zte.com.cn"
Date: Monday, January 28, 2013 9:38 PM
To: Wojciech Dec
Cc: Softwires-wg list , "remi.desp...@free.fr"
, "softwires-boun...@ietf.org"
Subject: [Softwires] 答复: Re: [softwire] #19: IPv4 address superfluous in
MAP-E Inter
> 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 MA
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
Date: Tuesday, February 5, 2013 8:38 AM
To: "despres.r...@laposte.net"
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
Date: Wednesday, February 13, 2013 6:17 PM
To: Tom Taylor
Cc: Softwires-wg list
Subject: Re: [Softwires] MAP-04: BMR and forwarding ru
My vote is to keep 1:1 mode in MAP. Removing it just doesn't make sense
(else, we might as well remove supporting host routing (/32 or /128) from
dynamic routing protocols).
Cheers,
Rajiv
-Original Message-
From: "mohamed.boucad...@orange.com"
Date: Thursday, February 14, 2013 5:55 AM
T
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 va
Good catch, indeed. Needs to be updated.
Cheers,
Rajiv
Sent from my Phone
On Mar 8, 2013, at 4:58 PM, "Poscic, Kristian (Kristian)"
mailto:kristian.pos...@alcatel-lucent.com>>
wrote:
I think the following needs to be corrected in the softwire-map draft:
MAP Configuration
For a given M
Hi Tom,
Good catch. We also caught this last week and started formulating the
revised text.
We may strive to rewrite this section a bit, time permitting.
> Question: does the second sentence say anything different from the first
> one?
Not really. :)
> Question: if the MAP node is configured
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
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 the
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. Bu
I agree, Simon.
Cheers,
Rajiv
-Original Message-
From: Simon Perreault
Date: Friday, April 26, 2013 11:22 AM
To: Rajiv Asati
Cc: Ole Troan , Softwires-wg list
Subject: Re: [Softwires] MAP based attribution and spoofing
>Le 2013-04-26 16:50, Rajiv Asati (rajiva) a éc
R Address
>Hi Rajiv,
>
>Thanks for your response. Comments in line.
>
>Cheers,
>Ian
>
>
>
>On 26/04/2013 17:12, "Rajiv Asati (rajiva)" wrote:
>
>>
>>I really don't see the need for having to specify more than one BR
>>prefixes (of w
ification, IMO.
Cheers,
Rajiv
-Original Message-
From: Cameron Byrne
Date: Friday, April 26, 2013 12:01 PM
To: Rajiv Asati
Cc: Ole Troan , Simon Perreault
, Softwires-wg list
Subject: Re: [Softwires] MAP based attribution and spoofing
>On Fri, Apr 26, 2013 at 7:50 AM, Rajiv Asati (raj
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
Date: Thursday, Septem
Hi Kristian,
Yes, that's correct.
--
Cheers,
Rajiv
-Original Message-
From: , Kristian Poscic
Date: Tuesday, November 12, 2013 6:31 PM
To: Softwires-wg list
Subject: [Softwires] port-forwards in MAP
>Just wanted to confirm one thing for MAP-E in regards to static port
>forwards.
naturally the non-address-shared mode of MAP to consider (i.e.
>when PSID length =0). Here each MAP user has a full IPv4 address and of
>course also the corresponding full port range.
>
>
>Cheers,
>
>Wojciech
>
>
>
>On 13 November 2013 19:12, Rajiv Asati
Support.
--
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco
-Original Message-
From: , Edwin Mallette
Date: Thursday, February 20, 2014 10:25 AM
To: Softwires-wg list
Cc: Yong Cui
Subject: Re: [Softwires] Working group last call for
draft-ietf-softwire-map-t-05
>Support.
>
>>--
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
-Ori
It might be worth understanding why this problem is even worth
addressing/mentioning.
Is the possibility of 2 or more host devices (behind 2 or more MAP CE
routers) sharing the same IPv4 address would be "generating the fragmented
packets" towards the same destination around the same time, not cl
Ted,
I would therefore like the working group to consider changing the proposed
status of MAP-T to Proposed Standard.
That's quite reasonable. And I agree, especially given that few operators have
already deployed and asked for the same.
If the working group agrees, we would go through a secon
John,
Thanks for sharing the usefulness of MAP and its applicability to cable MSOs.
Glad to read that MAP-T/R being included in the eRouter spec.
The drafts you mention are at the verge of becoming RFCs, as they are in RFC
editor queue. Perhaps, another month.
Cheers,
Rajiv
> On Jun 18, 201
Chongfeng,
Happy to hear wide IPv6 deployment in CT production network.
Could you please help us understand how is this draft related to the above ?
Perhaps, moving from v4-only/dual-stack to IPv6-only (between CPE and BNG
through ASBR) and deploying MAP function on CPE. Is that it ? If yes, t
Is there an RFC (besides 6269) that encourages / discourages CGN logging of
destination IP+Port if source IP+port is already logged?
RFC6269 does mention the below, as compared to the server side logging of
source IP+port -
// logging the destination address on the NAT is inferior
to logging
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
Dis
3 May 2018, at 22:50, Rajiv Asati (rajiva)
mailto:raj...@cisco.com>> wrote:
Is there an RFC (besides 6269) that encourages / discourages CGN logging of
destination IP+Port if source IP+port is already logged?
RFC6269 does mention the below, as compared to the server side logging o
tination ??
Hi Rajiv,
Please check RFC6888 which says the following:
REQ-12: A CGN SHOULD NOT log destination addresses or ports unless
required to do so for administrative reasons.
Cheers,
Med
De : Softwires [mailto:softwires-boun...@ietf.org] De la part de Rajiv Asati
(rajiva)
Env
gds
ramesh
-Original Message-
From: ianfar...@gmx.com<mailto:ianfar...@gmx.com> [mailto:ianfar...@gmx.com]
Sent: 04 May 2018 17:28
To: Rajiv Asati (rajiva)
Cc: Softwires-wg list; int-a...@ietf.org<mailto:int-a...@ietf.org>; Ramesh R
Chandra
Subject: Re: [Softwires] ISP CGN logging
A+P requirement. Using SA+P from 5-tuple should help to correlate with
user IP based on DHCP assignment.
Key here is on BR to do 5-tuple after de-encapsulation of IPv6. Rajiv, pls
check if we can do this on ASR9k as BNG.
Regds
Ramesh
From: Lee, Yiu [mailto:yiu_...@comcast.com]
Sent: 09 May 2018
penditure (CAPEX) considerations). This requirement is
easily met with stateless solutions.
Cheers,
Med
De : Softwires [mailto:softwires-boun...@ietf.org] De la part de Rajiv Asati
(rajiva)
Envoyé : mardi 8 mai 2018 23:43
À : ramesh.r.chan...@ril.com; yiu_...@comcast.com
Cc : softwire
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 catchi
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, "Softwires on behalf of Yong Cui"
> wrote:
>
>D
Hi David,
Thanks for your review and comments. QQ -
>My fundamental concern with this draft is that the MIB-2 tunnel type
>registry is seriously incomplete and out of date, as there are a large
>number of tunnel types that aren't included in that registry, e.g., IPsec
>tunnel-mode AMT tunneling.
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
D
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 (a
Jordan’s distinction about tunneling vs translation is key here given the
considerations for the normative language.
Mike’s suggestion is not that BR should calculate checksum, rather that BR
should forward packets with UDP checksum being 0. Is that right, Mike? If so,
then it is reasonable.
90 matches
Mail list logo