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

Greg Mirsky <gregimirsky@gmail.com> Wed, 23 March 2011 20:55 UTC

Return-Path: <gregimirsky@gmail.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 0609C3A694C; Wed, 23 Mar 2011 13:55:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.723
X-Spam-Level:
X-Spam-Status: No, score=-2.723 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 s87bvyV0xvNg; Wed, 23 Mar 2011 13:55:42 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id CC3923A68D6; Wed, 23 Mar 2011 13:55:41 -0700 (PDT)
Received: by vxg33 with SMTP id 33so7539893vxg.31 for <multiple recipients>; Wed, 23 Mar 2011 13:57:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NATeo5XlpGZjwKhbS8DSmt+xmeeeS6PxwljJdmX/Lb8=; b=aKWN0f/v5jdXOL7vKGrnEOvs7roOATLrTQxzbZzQ/dxUH8eMd3DreItestBsdmv3fg nZoXDlDVF1eeeeSMy48akcPOBNTAFTwFttVZCoxiz3A7+rtTrthAKMtZOKqssIrxt+J3 53pi/vk4dw8emxVUxTmkPjRlqydHwVeTxnaCk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gSqBhoGDxJLTTUB4rH+akqz2yPlrggnRbrRLWIovu9zl6CL/z+0H7admn5+qON3m5u Irbsu8EP+lwpKkU2gKXEOe1dwk6IbgT9Fsje2Wjs24ZT5SCZPrHCWXZgEt53DlwCOaQZ odXVGNW5DfWFTYdOqQ8S9HcZT176drjE449hI=
MIME-Version: 1.0
Received: by 10.52.67.73 with SMTP id l9mr7406761vdt.287.1300913835406; Wed, 23 Mar 2011 13:57:15 -0700 (PDT)
Received: by 10.52.168.6 with HTTP; Wed, 23 Mar 2011 13:57:15 -0700 (PDT)
In-Reply-To: <201103232025.p2NKPr2t076600@harbor.orleans.occnc.com>
References: <4D88E3A7.4040502@cisco.com> <201103232025.p2NKPr2t076600@harbor.orleans.occnc.com>
Date: Wed, 23 Mar 2011 13:57:15 -0700
Message-ID: <AANLkTikNZH9w2iNRVwUAMmzJ2ktkjSfcdssNbEFvgNpr@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
To: curtis@occnc.com
Content-Type: multipart/alternative; boundary="20cf307f32040af5a2049f2c9b4c"
Cc: Robert Rennison <Robert.Rennison@ecitele.com>, "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>
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
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: Wed, 23 Mar 2011 20:55:44 -0000

Dear Curtis and All,
I believe that any restriction on placing GAL in a label stack set in
Section 4.2, RFC 5886 is relevant only for MPLS-TP PSN. For non-TP PSNs
there are no restrictions set in RFC 5886 on where in a label stack GAL
might appear. 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> wrote:

>
> In message <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
> MPLS
> > >
> > >           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
> it,
> > >
> > > 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 ...]