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

[Alexander Vainshtein <[e-mail]>]

Sriganesh,
Please see inline below.

Regards,
     Sasha


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Sriganesh Kini
> Sent: Thursday, March 31, 2011 11:18 AM
> To: Alexander Vainshtein
> Cc: [e-mail]; [e-mail]
> Subject: Re: [PWE3] GAL above and below the PW label
> 
> Sasha, that issue with VCCV Type-3 (without CW) is not addressed by
> the draft. 
[[[Sasha]]] That is what I said:-(
> > Practically, is that a major issue ? Especially setting TTL
> > 1 for SS PW is possible I guess but would be some kind of serious
> operational oversight. Besides such a packet would fail some check
> along the path.
[[[Sasha]]] If you mean SS-PW, then the chance for an error(sending an OAM packet with TTL > 1
or sending a data packet with TTL = 1) is small and should be treated as an implementation bug.
With  dynamic MS-PWs, the number of segments of a MS-PW can change with time, so that the originally 
Correct TTL setting would suddenly result in leakage of OAM packets out of the AC.
All this is described in detail in 6073.
> 
> Also, what I heard at the mic regarding impl results is that it
> doesn't make sense to deprecate what is already deployed.
> 
[[[Sasha]]] To the best of my recollection, what has been said at the mike is that you cannot
change optional CW usage to mandatory when you progress from PS to DS.
But, to the best of my understanding of the IETF process and practice, nothing prevents us
from publishing a BCP document that would declare non-usage of the CW deprecated.
This would push the vendors to support it in their new boxes (SW upgrades), and it would
be understood by the operators as a suggestion to transit to using the CW if their equipment
supports it -- all that without outlawing non-usage of the CW.

> Note that CC Type 1 prevents ECMP (when FAT-PW is not available).
> Using GAL below PW also requires ECMP based on label hashing to ignore
> reserved labels.
> 
> 2011/3/31 Alexander Vainshtein <[e-mail]>:
> > 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?
> >
> > 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.
> >
> > My 2c,
> >     Sasha
> >
> >
> >> -----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
> > _______________________________________________
> > pwe3 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/pwe3
> >
> 
> 
> 
> --
> - Sri