Re: [PWE3] GAL above and below the PW label

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Alexander Vainshtein writes:
>  
> Sriganesh, Curtis and all,
>  
> IMHO and FWIW I think that the only problem with VCCV Type 3 is the
> risk of OAM packets leaking out of T-PE towards the AC (if you
> accidentally set the TTL value too high). To the best of my
> understanding the offset proposal does not solve that - or did I miss
> something?

That can be fixed by looking at the next label (if there is one) before
forwarding at PW egress to the AC.  The implementation already has to
make a similar chack on every packet if CW is used, but looking after
the S=1 label entry.  If CW is used it would be wise to do both checks
(be liberal in what you accept and careful in what you forward).

> One way to solve it is to use VCCV Type 1 (clean where applicable).
> Another way would be by using GAL below the PW label (possible but
> messy). If the industry moves towards deprecating Ethernet PWs without
> CW, it becomes completely unnecessary.

I agree with your last sentence but I don't know that non-CW can be
depricated.

> My 2c,
>      Sasha

Curtis


> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
> > Sriganesh Kini
> > Sent: Thursday, March 31, 2011 10:09 AM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: Re: [PWE3] GAL above and below the PW label
> > 
> > All,
> > 
> > Just an FYI that a proposal for fate-sharing PW OAM and data given in
> > draft-kini-pwe3-inband-cc-offset
> > 
> > Just to summarize the proposal.
> > 1. It does not require GAL in PW. TTL expiry is used to alert the S/T-
> > PE.
> > 2. It is mainly applicable when CW is not used in the PW.
> > 3. It uses a fixed offset (negotiated between PW endpoints) after the
> > label stack before starting the OAM msg.
> > 4. The bytes between the label-stack and the fixed offset is referred
> > to as a pseudoflow header and is filled with byte-values (by the PE)
> > that represent the flow for which OAM is desired. This helps PW OAM
> > and data to fate-share even when the intermediate node looks beyond
> > label stack to do multipath forwarding decisions.
> > 
> > 
> > On Thu, Mar 31, 2011 at 12:03 AM, Curtis Villamizar <[e-mail]>
> > wrote:
> > >
> > > Loa, Dave, Sasha,
> > >
> > > I've snipped from various posts on the thread that Sasha started.
> >  See
> > > inline.
> > >
> > > In message <[e-mail]>
> > > Loa Andersson writes:
> > >>
> > >> All,
> > >>
> > >> missed a nuance in Sasha subject line.
> > >>
> > >> We have two issues
> > >>
> > >> - where the GAL is placed relative to the PW label, I  believe it is
> > >>    necessary to have the GAL below the PW label.
> > >>
> > >> - whether the the GAL label needs to be bottom of stack or not, it
> > >>    figure that this is really a discussion if it is possible to have
> > >>    a FAT label below the GAL or not. I'm not sure  about my
> > preferences
> > >>    but I think it is possible.
> > >>
> > >> /Loa
> > >
> > > I agree with Loa's summary.  Not putting GAL at the bottom may
> > confuse
> > > some LSR, but putting it above the PW label is likely to be even more
> > > problematic.
> > >
> > >
> > > In message
> > <[e-mail]
> > .se>
> > > David Allan I writes:
> > >>
> > >> It does become a new behavior, GAL with S=3D0. However the
> > combination of G=
> > >> AL being top label at the S-PE and TTL being encoded in the PW label
> > means =
> > >> that fate sharing is broken at every S-PE. Life only gets a little
> > more str=
> > >> ange if there is a FAT label as well...
> > >>
> > >> That being said, GAL as bottom label is broken in any ECMP
> > environment, whi=
> > >> ch is why GAL is a TP construct.
> > >>
> > >> my 2 cents
> > >> D
> > >
> > > Dave,
> > >
> > > If GAL is broken for ECMP, which it is, then all TP OAM is broken.
> > > If all it takes to fix it is simple then lets just fix it.
> > >
> > > This is what we'd have to do.
> > >
> > >  1) Relax the requirement that GAL be at the bottom
> > >
> > >  2) Have the ingress insert GAL in the stack immediately below the
> > >     label for which the measurement is made, keeping the rest of the
> > >     label stack in place.
> > >
> > > The only thing the midpoing LSR at a multipath (LAG, link bundle for
> > > MPLS) has to do is skip over the GAL when hashing, as if the GAL
> > > wasn't there.  That will yield the same hash value and it will
> > > preserve fate-sharing across multipath.
> > >
> > > I prefer that we fix things rather than complain that they are
> > broken.
> > >
> > > Curtis
> > > _______________________________________________
> > > pwe3 mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/pwe3
> > >
> > 
> > 
> > 
> > --
> > - Sri
> > _______________________________________________
> > pwe3 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/pwe3