Hello folks,
Has there been any further determination about where the
AAAv6 work should proceed? It seems to me that it does
fit within the AAA working group now. If an URP working
group is created in the future, and they want to have the
work item, a transfer could be discussed at that time.
Alex,
> Jim,
>
> Jim Bound wrote:
> >
> > I think we should do b via an experimental draft. Go write some code and
> > see if it works in the test beds (e.g. 6bone, 6init, Eurosix, DoD). Then
> > report back. This will give us some experience.
> >
> > I think doing anything to promote routi
Alex,
Well aware of RSVP-TE. I believe MPLS to be different than intserv.
I also believe MPLS Labels could become moot in theory with the correct
use of the flowlabel and become what the label does for MPLS via the flow
label. Then I believe tunneling like RSVP-TE could be eliminated to
distrib
% As far as the actual A6 vs debate goes, it all boils down to this:
% If we cock this up, then in a hundred years time, the odds are that
% sysadmins are going to be swearing at us for the mistakes we made. OTOH,
% if we just sit and talk it back and forth for a while, the status quo
% w
Bill Manning wrote:
> %
> % On Wed, Aug 15, 2001 at 09:56:37PM +0700, Robert Elz wrote:
> % > Date:Wed, 15 Aug 2001 06:00:34 -0700 (PDT)
> % > From:Bill Manning <[EMAIL PROTECTED]>
> % > Message-ID: <[EMAIL PROTECTED]>
> % >
> % > | Then the Internet is doome
Jim,
Jim Bound wrote:
>
> I think we should do b via an experimental draft. Go write some code and
> see if it works in the test beds (e.g. 6bone, 6init, Eurosix, DoD). Then
> report back. This will give us some experience.
>
> I think doing anything to promote routing based on transport+por
> From: Daniel Chuang [mailto:[EMAIL PROTECTED]]
>
> [...] what kind of information
> will be put into the "agent-addr" in the v1 Trap
> PDU in the ipv6-only node?
>
> A couple of options:
>
> 1. SNMPv1 traps are not allowed for ipv6-only node.
>
> 2. modify RFC1157.
>
> 3. any other creativ
Hello,
ipv6IfStateChange is defined as follows:
ipv6IfStateChange NOTIFICATION-TYPE
OBJECTS {
ipv6IfDescr,
ipv6IfOperStatus
}
STATUS current
DESCRIPTION
"An ipv6IfStateChange notification signifies
that there has been a change in the
Jim,
Please reexamine.
As a hint, note that MPLS, which is using *mutable* labels, is using
RSVP-TE (extension of RSVP
for Traffic Engineering) as one of the label distribution mechanisms.
Alex
Jim Bound wrote:
>
> Yes I would as a note. I want what we orginally called for and to make
> su
Alex Conta wrote:
>
> Thomas Narten wrote:
> >
> > [...] When someone can make a compelling argument for why
> > the bits need to be defined in a certain way (i.e., there is a real
> > application for which using the bits provides significant benefits,
> > and those benefits do not appear achie
Thanks for the clarification,
Alex
Thomas Narten wrote:
>
> > Are you saying that the "intended semantics and usage of the Flow
> > Label field" documented in the Appendix A of RFC 2460 are optional?
>
> Optional at best, so yes.
>
> Note that when 2460 was advanced to Draft Standard, there w
Thomas Narten wrote:
>
> [...] When someone can make a compelling argument for why
> the bits need to be defined in a certain way (i.e., there is a real
> application for which using the bits provides significant benefits,
> and those benefits do not appear achievable through other means) that
> Are you saying that the "intended semantics and usage of the Flow
> Label field" documented in the Appendix A of RFC 2460 are optional?
Optional at best, so yes.
Note that when 2460 was advanced to Draft Standard, there was IESG
pushback on including the Appendix A definition of the Flow Lab
Kenjiro Cho wrote:
>
> Jun-ichiro itojun Hagino wrote:
> > So, kjc wanted to at least identify each of the flow, at least for
> > statistics purposes, <...>
> > on (b).
>
> minor correction:
>
> My point was that leaving the flowlabel field unused doesn't do any
> good for QoS/IPv
Thomas Narten wrote:
>
> > [...] If we do nothing,
> > we have effectively chosen the intserv-only usage.[...]
> >
> Is this really the case?
>
> RFC 2460 actually says:
>
> > 6. Flow Labels
> >
> >The 20-bit Flow Label field [...]
> >
> >Appendix A describes the current intended sem
Jun-ichiro itojun Hagino wrote:
> So, kjc wanted to at least identify each of the flow, at least for
> statistics purposes, as well as traffic classification/policying
> if possible. Even if end nodes use ESP, he would liked to identify a
> flow from other flows. So, he
Pekka Savola wrote:
>
> On Fri, 17 Aug 2001, Alex Conta wrote:
> > The Diffserv QoS engines in the access routers do a policing
> > (classification&metering&dropping) that trims the high level QoS traffic
> > -- hacked by a user, or not -- to the level specified in SLAs, TCAs. So,
> > a user, a
>I also prefer eth0 over link12. Using the names used to define the zones
>(either the default interface names or actual zone definitions) seems to be
>more useful than generating a somewhat arbitrary name and displaying that.
>How is the user supposed to correlate link12 back to the actual eth0
Brian,
I would vote for (e) as well. I would rather wait until someone
can demonstrate that an application/use will benefit greatly from the
use of the flow label bits.
Brian
Bob Hinden wrote:
>
> Brian,
>
> At 08:45 AM 8/16/2001 -0500, Brian E Carpenter wrote:
> >I think the WG needs to
I voted for (b), with our past experience.reason.
It may be useful to comment from out experiences, so I'll try to
explain.
We had some offsite meeting network setup in Japan, just like IETF
terminal cluster, but with more aggressive experimental one. We u
On Monday, 08/20/2001 at 11:15 ZE2, Francis Dupont
<[EMAIL PROTECTED]> wrote:
> In your previous mail you wrote:
>
>> => I prefer real names than xxxNNN. Can we get both (i.e. a config
file
>> plus a default translation rule)?
>
>I do not object to introducing real names, but I'd lik
> The problem with this is that the text we have today effectively selects
> option b), since it endorses the pseudo-random value. If we do nothing,
> we have effectively chosen the intserv-only usage. That's why I started
> this thread.
Is this really the case?
RFC 2460 actually says:
> 6. F
Hi Jim,
Of course it can, a CAM is programmable and that's not he problem, in fact
the current with the current CAM you could do a 576 bit wide lookup if you
are smart (and those bits does not need to be consecutive in the packet) in
OC-192 which is sufficient for IPv6 multicast.
It can but I don
In your previous mail you wrote:
I'm not sure about the issue of "net$cape", but we (some KAME users
and I) sometimes use link-local addresses for ssh and telnet, in order
=> ssh and telnet are standard applications on *BSD (and there are
dynamicallly linked). So they will inherit the get
In your previous mail you wrote:
> => I prefer real names than xxxNNN. Can we get both (i.e. a config file
> plus a default translation rule)?
I do not object to introducing real names, but I'd like to leave that
part as implementation dependent, and just define the formal aliase
Brian wrote:
> The distinction made in the proposal by the MSB is between a
> pseudo-random
> value as defined in RFC 2460 Appendix A (for intserv) and a
> non-random value
> (for diffserv). But they are both e2e values, unlike the
> DSCP. This should
> be documented.
>
But who need any of
Out of your choices I vote for (b). I also vote for John's notion of "just a
QoS hint".
Also, relax the pseudo-random number requirement of the flow label. Routers
can't really know how good the PRF used by the host is, so no router should
assume the flow label to be a pseudo random number! Also,
27 matches
Mail list logo
