Re: [mpls-tp] [PWE3] [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

Curtis Villamizar <curtis@occnc.com> Sat, 26 March 2011 02:01 UTC

Return-Path: <curtis@occnc.com>
X-Original-To: mpls-tp@core3.amsl.com
Delivered-To: mpls-tp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C23928C0D6; Fri, 25 Mar 2011 19:01:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cokGVTy6vMtH; Fri, 25 Mar 2011 19:01:42 -0700 (PDT)
Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 70DAE3A6877; Fri, 25 Mar 2011 19:01:42 -0700 (PDT)
Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p2Q22vsK065505; Fri, 25 Mar 2011 22:02:57 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com)
Message-Id: <201103260202.p2Q22vsK065505@harbor.orleans.occnc.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
From: Curtis Villamizar <curtis@occnc.com>
In-reply-to: Your message of "Thu, 24 Mar 2011 07:44:39 +0200." <A3C5DF08D38B6049839A6F553B331C76D6FB8BEACE@ILPTMAIL02.ecitele.com>
Date: Fri, 25 Mar 2011 22:02:57 -0400
Sender: curtis@occnc.com
Cc: "mpls@ietf.org" <mpls@ietf.org>, "mpls-tp@ietf.org" <mpls-tp@ietf.org>, "lihan@chinamobile.com" <lihan@chinamobile.com>, pwe3 <pwe3@ietf.org>, HUANG Feng F <Feng.f.Huang@alcatel-sbell.com.cn>, Robert Rennison <Robert.Rennison@ecitele.com>
Subject: Re: [mpls-tp] [PWE3] [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt
X-BeenThere: mpls-tp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: curtis@occnc.com
List-Id: MPLS-TP Mailing list <mpls-tp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-tp>
List-Post: <mailto:mpls-tp@ietf.org>
List-Help: <mailto:mpls-tp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Mar 2011 02:01:44 -0000

In message <A3C5DF08D38B6049839A6F553B331C76D6FB8BEACE@ILPTMAIL02.ecitele.com>
Alexander Vainshtein writes:
>  
> Greg, Curtis and all,
> I think that the linkage between TP/non-TP differentiation and restrictions=
>  on GAL usage is highly problematic.

Yes.  I agree.

> E.g., consider an MS-PW with some segments crossing TP domains and some - n=
> on-TP ones (this is a realistic example).
>  
> IMHO GAL is part of the data plane that is shared by IP/MPLS and MPLS-TP-TP=
> , and hence the same restrictions should apply uniformly. IMHO RFC 5960 com=
> plies with this principle.
>  
> RFC 5960 also seems to impose the restriction on GAL being at the bottom of=
>  stack. E.g., please look at the following text fragment:
>  
>  
>    If the TTL of an LSP label expires, then the label with the
>    S (Bottom of Stack) bit set is inspected to determine if it is a
>    reserved label.  If it is a reserved label, the packet is processed
>    according to the rules of that reserved label.  For example, if it is
>    a Generic Associated Channel Label (GAL), then it is processed as a
>    packet on the Generic Associated Channel (G-ACh); see Section 4.  If
>    the TTL of a PW expires at an S-PE or T-PE, then the packet is
>    examined to determine if a Generic Associated Channel Header (ACH) is
>    present immediately below the PW label.  If so, then the packet is
>    processed as a packet on the G-ACh.

This is used in the traceroute cacpability where TTL is set to a low
value and increased until the egress is reached.

This would have to be changed to look for GAL in any position, not
just at the bottom of stack.  If each label entry has to be inspected,
this is about the same effort as looking for the S bit (bit test vs
mask and 20 bit compare).  This only occurs on TTL expired, which is
always more work than normal forwarding.

The alternate, to keep fate-sharing, is to put GAL under the fat-pw
label in a PW.  This requires more work on every packet forwarded to
check for this additional label.  Some hardware (none I've had a hand
in designing) assumes that a PW has a fixed overhead below it and
looks for zero in CW at a fixed offset from the PW label.

Keeping GAL on the bottom, trying to acheive fate-sharing with fat-pw,
and putting GAL below the fat-pw, would burden the common case of
forwarding.  Allowing GAL anywhere burdens the far less common TTL
expired processing operation.

> And, last but not least, if we decide to allow GAL in the middle of the lab=
> el stack (overriding RFC 5586 and RFC 5960), we must also define how a pack=
> et with GAL in the middle of the label stack is forwarded when GAL is expos=
> ed, similar to what has been done in RFC 3032 for RAL.
>  
> My 2c,
>      Sasha

If GAL is encountered, then it is processed just as it would be if TTL
was set high and GAL was encountered as a result of the final POP in a
containing LSP exposing only the GAL.  The G-Ach is after the bottom
of stack, where ever bottom of stack is found.

Curtis

> ________________________________
> From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Greg=
>  Mirsky [gregimirsky@gmail.com]
> Sent: Wednesday, March 23, 2011 10:57 PM
> To: curtis@occnc.com
> Cc: Robert Rennison; mpls@ietf.org; mpls-tp@ietf.org; lihan@chinamobile.com=
> ; pwe3; HUANG Feng F
> Subject: Re: [mpls-tp] [PWE3] [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-=
> 00.txt
>  
> Dear Curtis and All,
> I believe that any restriction on placing GAL in a label stack set in Secti=
> on 4.2, RFC 5886 is relevant only for MPLS-TP PSN. For non-TP PSNs there ar=
> e no restrictions set in RFC 5886 on where in a label stack GAL might appea=
> r. Some of use cases mentioned by Curtis are outside of MPLS-TP scope and, =
> as I understand, use of GAL in these cases is not regulated by the RFC 5886=
> .
> As to the issue of using GAL in PW there would not be a problem if not for =
> possible conflict with PW VCCV CC Type 1. If GAL presents PW VCCV CC Type 4=
> , properly updates RFC 5085, and for MPLS-TP PWs complies with the RFC 5886=
>  - we might be good.
>  
> Regards,
> Greg
>  
> On Wed, Mar 23, 2011 at 1:25 PM, Curtis Villamizar <curtis@occnc.com<mailto=
> :curtis@occnc.com>> wrote:
>  
> In message <4D88E3A7.4040502@cisco.com<mailto:4D88E3A7.4040502@cisco.com>>
> Stewart Bryant writes:
> >
> > If there is IETF consensus to update RFC5586 with this change then the
> > process is relatively simple:
> >
> > The document making the update notes that it does the update, and the AD
> > draws attention to
> > this in the IETF LC.
> >
> > Stewart
>  
>  
> Stewart,
>  
> The restriction that GAL be at the bottom of stack was simply a
> mistake IMHO.  I stated that during MPLS WG discussion before it
> became an RFC but it went through as is anyway with that restriction.
> Even then it was said that if there were a strong reason to relax it
> that it could be considered later.  That time may have come.
>  
> There are a number of reasons that labels might want to go below GAL,
> including to use OAM to diagnose the connectivity (or lack of) that is
> experienced only for a specific label stack combinations where
> multipath (link bundle, LAG, less applicable is ECMP in this case) is
> used.
>  
> In this case though, the GAL under the LSP label currently indicates
> that after the POP that OAM needs to be done (or more accurately that
> a G-Ach of some type is being carried).  If the GAL is put above the
> PW label it is in that same place and there is an ambiguity.  It is an
> ambiguity that for some but not all defined OAM can be resolved by
> looking at information in BFD that makes it unambiguous.  Unless I'm
> mistaken, in CC/CV the label stack above GAL provides the context.
>  
> Another solution would be to put GAL under the PW label.  It would
> probably be best to put GAL under PW but over the fat-pw label.  The
> PW implementation, seeing the PW was not BOS, could look at the next
> label to see if the label is reserved and specifically if it is GAL,
> and if not process as payload (unless CW is also used).  If CW was not
> used the only advantage is 4 bytes less in payload but the same size
> in OAM packets.  This is an advantage though.
>  
> On a related topic, if we must put ELI plus entropy label on the stack
> we have saved nothing relative to fat-pw plus CW.  ELI as a
> termination of hash search may have other uses though (MPLS-TP).
>  
> I would be in favor of a very short draft just relaxing the
> requirement that GAL be at the bottom of stack, independent of the
> reason for doing so, since a number of reasons have emerged.  The
> behavior would be to throw away the rest of the label stack when the
> GAL label is exposed and look at the MPLS payload interpreting it as
> an G-Ach channel (most often, but not exclusively, as OAM).  This
> relaxation of the BOS restriction would be independent of usage.
>  
> Curtis
>  
>  
> > On 22/03/2011 16:22, Robert Rennison wrote:
> > >
> > > Luca, Thomas,
> > >
> > > A couple of clarification questions.
> > >
> > > I'm trying to understand what the combination of the two drafts,
> > > -lm-pwe3-mpls-tp-gal-in-pw, and draft-nadeau-pwe3-vccv-2amounts to.
> > >
> > > So, I think I understood the draft-nadeau-pwe3-vccv-2 in that it's
> > > saying use VCCV type 1 where possible and if not then use the new type
> > > 4, whereby  in type 4 the exception mechanism is triggered by the use
> > > of the GAL,  and I appreciated the diagram in section 3 to lock this
> > > is, so far so good.
> > >
> > > Now I read -pwe3-mpls-tp-gal-in-pw and I'm thinking , Ok these two
> > > drafts could work together since this one is trying to lay the "legal
> > > framework" i.e fix up the RFCs which mandated that the GAL could not
> > > be used with the PW.
> > >
> > > Then I get hit with a brick wall in the form of the statements in the
> > > last 2 paras of section 3 of tp-gal-in-pw which state.
> > >
> > > - Section 4.2
> > > <http://tools.ietf.org/html/draft-lm-pwe3-mpls-tp-gal-in-pw-00#section-=
> 4.2>.
> > > (GAL Applicability and Usage) in [RFC5586
> > > <http://tools.ietf.org/html/rfc5586>], the
> > >
> > >       original text:
> > >
> > >           In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
> > >
> > >           LSPs, Concatenated Segments of LSPs, and with Sections, and
> > >
> > >           MUST NOT be used with PWs. It MUST always be at the bottom of
> > >
> > >           the label stack (i.e., S bit set to 1). However, in other MPL=
> S
> > >
> > >           environments, this document places no restrictions on where
> > >
> > >           the GAL may appear within the label stack or its use with PWs=
> .
> > >
> > >       is replaced by:
> > >
> > >           In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
> > >
> > >           LSPs, Concatenated Segments of LSPs, and with Sections, and
> > >
> > >           MAY be used with PWs. It MUST always be at the bottom of the
> > >
> > >           label stack (i.e., S bit set to 1). However, in other MPLS
> > >
> > >           environments, this document places no restrictions on where
> > >
> > >           the GAL may appear within the label stack.
> > >
> > > It's the bit about the GAL MUST be at the bottom of the label stack,
> > > this is clearly inconsistent with what is proposed in the
> > > draft-nadeau-pwe3 where one can clearly see the GAL above the PW label
> > > and if one has to use  a GAL with a PW this would be the place to put i=
> t,
> > >
> > > Now I can hear you saying "oh but look at the text below this, where
> > > we state .."However, in other MPLS environments , this document places
> > > no restrictions on where the GAL may appear within the label stack.
> > > This is consistent with draft-nadeau "   In which case I'd retort with
> > > ; what are we to do for PWs in   MPLS-TP, since what's in draft-nadeau
> > > would not be allowed ?
> > >
> > > Clarification /explanation appreciated.
> > >
> > > Cheers
> > >
> > > Rob Rennison
> > >
> [snipped ...]