I am not aware of any IPR related to this draft.
Thanks
Senthil
>
> > -Message d'origine-
> > De : Softwires [mailto:softwires-boun...@ietf.org] De la part de Ian
> > Farrer
> > Envoyé : mardi 14 novembre 2017 02:57
> > À : draft-ietf-softwire-dslite-y...@ietf.org
Sorry, it took a while to get back to this. Thanks for your comments. Please
see below for the responses.
Thanks
Senthil
On 2/8/17, 1:15 PM, "Softwires on behalf of Senthil Sivakumar (ssenthil)"
<softwires-boun...@ietf.org on behalf of ssent...@cisco.com> wrote:
I had re
I had reached out to Dan Wing and some others, as suggested by Ian to get
reviews on the
https://tools.ietf.org/html/draft-sivakumar-yang-nat-05.
I am just posting the response from Dan here, I will address his comments in a
separate email and copy the alias.
Thanks
Senthil
Use
Hi Ian,
The NAPT44 in the lwB4 MUST implement ICMP message handling behaviour
conforming to the best current practice documented in [RFC5508]
If the lwB4 receives an ICMP message without the ICMP identifier field for
errors detected inside the IPv6 tunnel, the node should relay
the ICMP error
On 2/7/14 12:12 PM, Simon Perreault simon.perrea...@viagenie.ca wrote:
Le 2014-02-07 11:01, ian.far...@telekom.de a écrit :
This part is still not OK:
5.2.1. Changes to RFC2473 and RFC6333 Fragmentation Behaviour
On receiving an encapsulated packet containing an IPv4 fragment,
the
Introduction - the first paragraph needs some revision.
Experiences from initial IPv6 deployments indicate that transitioning
a network providers' domain fully to IPv6 requires not only the
continued support of legacy IPv4 users connected to the boundary of
that domain, allowing IPv4
Support.
On 2/5/13 12:29 AM, Suresh Krishnan suresh.krish...@ericsson.com wrote:
Hi all,
This draft was a result of the discussion initiated at the softwire
meeting in Atlanta to attempt to come up with a unified CPE
specification that can work with both MAP and lw4o6. This call is being
On 1/30/13 10:52 AM, Tom Taylor tom.taylor.s...@gmail.com wrote:
On 30/01/2013 9:56 AM, Rémi Després wrote:
Le 2013-01-30 13:47, Ole Troan o...@cisco.com :
Tom,
[...]
[Ole said:]
I'm fine with fixing a to 4.
if an end user needs well known ports, give her a full address.
[Rémi
I believe the prefix length 64 should be allowed. It is upto the
operator to choose the prefix length of their choice.
On 1/28/13 8:59 AM, Ole Troan otr...@employees.org wrote:
The examples in my previous note sort of provided backing for my view
that the MAP endpoint IPv6 prefix can be
Hi Remi,
On 1/28/13 11:16 AM, Rémi Després despres.r...@laposte.net wrote:
Senthil,
2013-01-2815:24, Senthil Sivakumar (ssenthil) ssent...@cisco.com :
I believe the prefix length 64 should be allowed.
It is upto the
operator to choose the prefix length of their choice.
Agreed.
No one
On 1/28/13 12:56 PM, Ole Troan otr...@employees.org wrote:
Senthil,
[...]
The draft says that:
(a) The PSID is:
+--+---+---+---+---+---+---+---+---+
|PL| 8 16 24 32 40 48 56 |
+--+---+---+---+---+---+---+---+---+
|64| u | IPv4 address | PSID | 0 |
On 1/24/13 6:56 PM, Satoru Matsushima satoru.matsush...@gmail.com
wrote:
On 2013/01/25, at 5:08, Tom Taylor tom.taylor.s...@gmail.com wrote:
This caught my eye too. Why repeat the PSID?
Does anyone have the reason of it must not?
I guess the question should be the converse, why should it
Could we make this explicit the prefix lengths can be of any arbitrary
length? Or bit boundaries? Or nibble boundaries?
Thanks
On 1/25/13 1:36 PM, Ole Troan otr...@employees.org wrote:
Tom,
We have two choices on this one:
a) prohibit the use of an end user IPv6 prefix of length greater
On 1/25/13 1:09 PM, Tom Taylor tom.taylor.s...@gmail.com wrote:
We have two choices on this one:
a) prohibit the use of an end user IPv6 prefix of length greater than 64
bits;
I would think that is restrictive.
b) simply remove the reference to RFC6052, or qualify it by saying that
the IID
As an implementor, I would like to see the prefix length to be either in
byte boundaries or atleast nibble boundaries.
It makes life a little easier.
How about this:
The prefix lengths can be of arbitrary length and does not have to be in
byte boundaries.
The MAP devices SHOULD allow the
,
softwires@ietf.orgmailto:softwires@ietf.org
softwires@ietf.orgmailto:softwires@ietf.org
Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains
hi Senthil,
inline for maoke2
2012/12/12 Senthil Sivakumar (ssenthil)
ssent...@cisco.commailto:ssent...@cisco.com
Hi Maoke,
Please see inline
-lucent.com,
softwires@ietf.orgmailto:softwires@ietf.org
softwires@ietf.orgmailto:softwires@ietf.org
Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains
hi Senthil,
interesting discussion. see inline.
2012/12/11 Senthil Sivakumar (ssenthil)
ssent...@cisco.commailto:ssent
From: Poscic, Kristian (Kristian)
kristian.pos...@alcatel-lucent.commailto:kristian.pos...@alcatel-lucent.com
Date: Monday, December 10, 2012 3:06 PM
To: softwires@ietf.orgmailto:softwires@ietf.org
softwires@ietf.orgmailto:softwires@ietf.org
Subject: [Softwires] MAP-E/T overlaping ranges and
On 12/3/12 4:55 AM, mohamed.boucad...@orange.com
mohamed.boucad...@orange.com wrote:
Hi Ole,
As a background, the usual modes supported by a CPE are: IPv4-only,
Dual-stack. A natural mode to be added to the list is IPv6-only ... but
this mode is not sufficient to reflect whether IPv4 service
19 matches
Mail list logo
