Re: draft of a core protocol spec

This was a casual query I got from an operator.
The concern was that the scale was no longer that
of a broadcast LAN and for mostly IP applications
he was wondering if more synergy was possible.

I myself would like to preserve layer integrity
and I have my own reservations so I'll let this
one rest.

Thanks,
Albert


----- Original Message -----
From: <[email protected]>
To: <[email protected]>; <[email protected]>; <[email protected]>
Sent: Monday, November 18, 2002 1:42 PM
Subject: RE: [IPORPR] draft of a core protocol spec


> Albert,
>
> Yes, it would be a big layer violation to allow L3 clients to optionally set
the RPR TTL. L3 should view the ring (almost) no differently than it views a
broadcast LAN.
>
> In any case, there is no mechanism to allow a (L3) client to set the (RPR)
TTL.
>
> jl
>
> -----Original Message-----
> From: A.Herrera [mailto:[email protected]]
> Sent: Saturday, November 09, 2002 7:47 PM
> To: Vinay Bannai; Anoop Ghanwani; 'Frank Kastenholz'; John Lemon;
> [email protected]
> Subject: Re: [IPORPR] draft of a core protocol spec
>
>
> Will it be a big layer violation to allow L3 clients
> to optionally set RPR TTL. Given that we're dealing
> with 10gig, near-WAN, 100+node ring topologies that
> can easily carry megabit streams gone astray.
>
> I agree L3 TTL checks network loops and RPR TTL
> checks ring loops but a large ring is a large network
> by itself :-)
>
> Albert
>
> ----- Original Message -----
> From: "Vinay Bannai" <[email protected]>
> To: "A.Herrera" <[email protected]>; "Anoop Ghanwani"
<[email protected]>;
> "'Frank Kastenholz'" <[email protected]>; <[email protected]>;
> <[email protected]>
> Sent: Saturday, November 09, 2002 11:58 AM
> Subject: RE: [IPORPR] draft of a core protocol spec
>
>
> > Hi Albert,
> >
> > Your later observation is correct. The setting of the RPR TTL is directly a
> > funtion of the local ring topology and it does not and should not have any
> > bearing on the L3 TTL. It would correct to keep the TTL from percolating up
> > and down the layers. The L3 TTL and the RPR TTL serve two entirely different
> > purposes and should not have linkage. The L3 TTL avoids infinite looping in
> > a network whereas, the RPR TTL serves the function of keeping the packet
> > looping infinitely within a RPR ring.
> >
> > If one were to choose to use a MPLS label between the layer 2 and layer 3,
> > then the issue of setting of the MPLS label becomes slightly interesting but
> > that has nothing to do with RPR.
> >
> > Vinay
> >
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]On Behalf Of
> > A.Herrera
> > Sent: Saturday, November 09, 2002 8:31 AM
> > To: Anoop Ghanwani; 'Frank Kastenholz'; [email protected];
> > [email protected]
> > Subject: Re: [IPORPR] draft of a core protocol spec
> >
> >
> >
> > ----- Original Message -----
> > From: "Anoop Ghanwani" <[email protected]>
> > To: "'Frank Kastenholz'" <[email protected]>; <[email protected]>;
> > <[email protected]>
> > Sent: Friday, November 08, 2002 11:55 AM
> > Subject: RE: [IPORPR] draft of a core protocol spec
> > >
> > > There used to be a TTL many draft versions ago, so that's
> > > probably the reason for your recollection :).  It was subsequently
> > > removed because it was decided that anything above the MAC
> > > shouldn't need to know about TTL.
> > >
> > > -Anoop
> >
> > Just a quick question for the WG. It could be
> > outside the scope of the core spec or it might be
> > a non-issue altogether.
> >
> > How is L3 TTL reconciled with RPR TTL. Given that
> > we no longer deal with LANs but rather large
> > MANs.
> >
> > Say, a packet from a traditional mesh hits,
> > traverses, then exits 3 large metro rings (of
> > over 100 nodes each), does the L3 TTL decrement by
> > 3. And should this packet somehow find an entry back
> > to the first ring, shouldn't there be a mechanism for
> > an earlier discard. Or do we treat these rings the
> > way PWE3 treats their tunnels where the TTLs don't
> > percolate up nor percolate down.
> >
> > Albert
> >
> >
> > _______________________________________________
> > IPORPR mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/iporpr
> >
> > _______________________________________________
> > IPORPR mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/iporpr
>
> _______________________________________________
> IPORPR mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/iporpr