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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Alexander Vainshtein writes:
>  
> Curtis,
>  
> The results of the PWE3 survey (it is difficult to say how
> representative it really is) seem to indicate that ability to support
> CW in the Ethernet PW encapsulation is quite common (13-14 out of 17
> respondents) and reasonably used (8 out of 17 respondents).

Yes.  I personally would have liked to require CW.  Some operators
have indicated a preference for no CW, understanding that it won't
work for multipath, but will work in metro/access or small networks.

> This survey does not provide any information about using GAL with
> PWs. Maybe we should extend the survey to learn that?  My expectation,
> not based on any facts, is that no one has been using it at the
> moment:-).

I doubt anyone has implemented GAL with PW already.

> So if the choice is between fixing an old bug at the root (by
> deprecating PW encapsulations without CW) or adding a new patch (GAL
> in the PW) for the same purpose, I clearly prefer the first option.

Realistically we not be able to require CW at this point.  If we
could, I'd be in favor of doing so.  If not, then we are stuck with
GAL to provide one good method which will work fine with or without CW.


> Regards,
>      Sasha

Curtis


> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Thursday, March 31, 2011 11:17 AM
> > To: Alexander Vainshtein
> > Cc: Sriganesh Kini; [e-mail]; [e-mail]
> > Subject: Re: [PWE3] GAL above and below the PW label
> > 
> > 
> > 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