In retrospect, I believe I made at least one mistake when writing the A6
RFC, which is going for a "full recursion" model. This triggers all
kinds of "interesting" possibilities. Going for a site model would have
been more appropriate: basically, one could request that the "prefix
domain name" poi
> On Thu, Aug 16, 2001 at 08:44:59AM -0500, Brian E Carpenter wrote:
> > I think the WG needs to decide once and for all whether the flow
label
> is
> >a) a CATNIP or MPLS-like routing handle
> > or b) a QOS hint for intserv only
> > or c) a QOS hint for intserv and diffserv
> > or d) a waste
Derek Fawcus wrote:
> Specifically - I see it as a way of replacing the srcPort/dstPort tuple
> that routers peek at in the TCP/UDP header. Currently I only see this
> being used in one scenario, that is for load balancing across multiple
> paths.
>
> At the moment (for v4) if a lookup on the
On Thu, Aug 16, 2001 at 08:44:59AM -0500, Brian E Carpenter wrote:
> I think the WG needs to decide once and for all whether the flow label is
>a) a CATNIP or MPLS-like routing handle
> or b) a QOS hint for intserv only
> or c) a QOS hint for intserv and diffserv
> or d) a waste of bits
>
>
Bill Sommerfeld writes:
> > > It seems that it would be appropriate for an implementation to
> > > "reclassify" packets at the time of encapsulation into ESP -- the
> > > packet is, after all, going through a logical trust boundary as it's
> > > being encrypted..
> >
> >If I underst
> > It seems that it would be appropriate for an implementation to
> > "reclassify" packets at the time of encapsulation into ESP -- the
> > packet is, after all, going through a logical trust boundary as it's
> > being encrypted..
>
>If I understand Brian's concern correctly, that may
>
> Oh. I now see what I missed. Why doesn't including
> the SPI into the flow key work? You wouldn't be
> able to police based on port numbers (ie try to be
> a firewall), but some would say that's a feature
> not a bug.
Well, except that there's no such thing as a "well known SPI"..
When done co
Bill Sommerfeld writes:
> >Huh? I thought that one of the requirements for ESP was to
> >copy the DSCP to the outer header. If I recall correctly,
> >this bothers some people from a traffic analysis standpoint,
> >but that seems to be part and parcel with QoS so that doesn't
>
>Huh? I thought that one of the requirements for ESP was to
>copy the DSCP to the outer header. If I recall correctly,
>this bothers some people from a traffic analysis standpoint,
>but that seems to be part and parcel with QoS so that doesn't
>hold much water IMO.
It seems th
Brian,
Current (intserv) usage requires signaling to convey the semantics for the
opaque flow label values. The diffserv usage would allow the flow label
itself to function as a pointer to the semantics (taken out of configuration
file or equivalent). In both cases the classifier will most likely
Derek Fawcus wrote:
>
> On Thu, Aug 16, 2001 at 08:44:59AM -0500, Brian E Carpenter wrote:
> > I think the WG needs to decide once and for all whether the flow label is
> >a) a CATNIP or MPLS-like routing handle
> > or b) a QOS hint for intserv only
> > or c) a QOS hint for intserv and diffse
Derek Fawcus wrote:
>
> > 2) If there is an alternative format, that is not pseudo-random (as
being
> > proposed), the routers will have to implement look-ups that function
> > efficiently with that format. Since we do not know what portion of the
> > traffic in the future would use this non-pseu
I certainly don't care about the pseudo-random requirement for unique-per-host
opaque flow labels, but if we agree that the flow label may be used for diffserv
then it has to have semantics (i.e. it is not an opaque value). For that I am sure
we need the MSB as a flag bit, so that a classifier can
Michael Thomas wrote:
>
> Brian E Carpenter writes:
> > The point is that when a packet crosses an administrative domain boundary,
> > the downstream ISP typically wants to reclassify the packet all over again,
> > i.e. does not accept the incoming DSCP as definitive. This was a very
> > clea
Hi!
Are there any differences between IPv6 networks
and IPv4 networks with respect to Layer II
(i.e., vlans etc.)?
I would appreciate your help. Thanks in advance!
Regards,
Swamy
IETF IPng Working Group Mailing Li
Although I do agree with Bernard on some points, I believe that waiting for
MIPv6 to be RFCed may be too late. The issue is that many folks will need
an AAA infrastructure to deploy MIPv6, and waiting for the RFC will simply
push out MIPv6 deployments. The issues with MIPv6 are mostly in the secur
I wonder if people think that IPv6 introduces additional requirements to the
AAA protocols (Radius/Diameter). My viewpoint is that a AAA protocol has to
be able to do 2 things to be compatible with IPv6:
1. Use IPv6 for transport i.e.: a AAA client in an IPv6 Only or Dual Stack
node to be able to
Bernard Aboba wrote:
> >
> > I think the URP WG should be chartered ASAP and AAAv6 taken
> there as a
> > possible solution. Where can I find the current proposal for the URP
> > charter?
> >
>
> Just as the AAA WG is not the appropriate place to do the
> work of subject
> area WGs, it is not
On Tue, 21 Aug 2001, Jim Bound wrote:
> the traffic class will provide diff serv metric and the flow identifies
> the E2E connection with the src addr.
My intuitive feeling is that if we leverage the end to end properties of
IPv6 in the address space, then we should do likewise, end to end, for
On Tue, 21 Aug 2001, Alex Conta wrote:
> at page 15, in the draft. "(c)" protects the value of the flow label, or
> rather, its meaning, where it is relevant to protect it.
>
> That is because, the value in itself, alone, is not meaningful. It is
> the meaning of the value, which is important,
Brian,
Let's then just say that it would be architecturally better to only have one
format that satisfies all the needs. With better I mean things like less
text in the specification, simpler implementations, less bugs, better
interoperability etc.
At this point no-one has established that there
21 matches
Mail list logo
