Jinmei,
Is everyone else OK with this proposed change?
I generally agree with the change, but I'm afraid a fresh reader of
this RFC-to-be will wonder about the removal, comparing to RFC3315.
So it would be nice to provide at least a pointer to relevant
discussion/drafts.
Good point.
I will add an
Ran,
You probably need to go through the mail archive and meeting minutes
from the period when RFC 3697 was being developed to find all the
arguments. That was most of 2002 and 2003. But I think the simplest
form of the argument is that it is intended to allow rapid
classification of a packet as
The flowlabel must be restored end-to-end, but can be mutable in route
over the network per 3697. See current 6LSA submissions now we are
determining where to work on this within the IETF currently, as one
example. Prototype implementation has been done and effort is underway
to determine how to
On Fri, Apr 22, 2005 at 06:09:13AM -0400, Bound, Jim wrote:
The flowlabel must be restored end-to-end, but can be mutable in route
over the network per 3697.
I guess this means that if an ICMP error message is generated then
the chunk of the original packet quoted by the ICMP error should
I guess this means that if an ICMP error message is generated then
the chunk of the original packet quoted by the ICMP error should
reflect the e2e flow label?
Absolutely. If that is not done then the implementation or solution is
not compliant to 3697 is my view.
Using the flow label
On Fri, 22 Apr 2005, JINMEI Tatuya / [ISO-2022-JP] ¿ÀÌÀãºÈ wrote:
[...]
then the host will try the Host Configuration Behaviour
(Solicit/Advertise/Request/Reply exchanges), but the server does not
respond to the Solicits. According to the DHCPv6 specification, the
host will send Solicits
At 13:41 20/04/2005 -0500, [EMAIL PROTECTED] wrote:
* I have not read the latsts update of the IPsec specs. Do
they know state
it clearly that if you're using IPsec, you should drop those
ICMP messages
that arrive without IPsec authentication? (If not, IPsec won't help).
The new IPsec
On 2005-Apr-22, at 2:15 PM, Harisreeprasad Gowda wrote:
I think it should be the global address of the interface over which
the IBGP
peering is established.
IBGP sessions are usually plumbed between loopback interfaces, not
physical interfaces. So, most of the time, your suggestion and
I think it should be the global address of the interface over which the IBGP
peering is established.
-Hari.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Vijayanand C - CTD, Chennai.
Sent: Thursday, April 21, 2005 10:24 AM
To: ipv6@ietf.org; idr@ietf.org
