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

[Alexander Vainshtein <[e-mail]>]

Greg,
Lots of thanks for a prompt response.

I see the problem a bit differently:

 1.  RFC 5654 explicitly states that data plane interoperability between IP/MPLS and MPLS-TP "MUST NOT require a gateway function". I.e., nothing in the data plane prevents the people from peering IP/MPLS and MPLS-TP domains.
 2.  Some forms of peering may be indeed problematic when it comes to OAM. But IMHO these problems do not exist in the case of MS-PWs  which perfectly fit the definition of a co-routed bi-directional LSP in MPLS-TP (even if they have been defined before the MPLS-TP work has began).
 3.  I think it is high time to state explicitly that when it comes to PWs, the IP/MPLS vs. MPLS-TP differentiation does not exist, be it in the data plane, OAM toolset, control plane or management plane. And, BTW, I believe that the original restriction of non-usage of GAL with PWs has been driven by implicit understanding of this fact.

My 2c,

     Sasha

________________________________
From: Greg Mirsky [[e-mail]]
Sent: Thursday, March 24, 2011 8:33 AM
To: Alexander Vainshtein
Cc: [e-mail]; Robert Rennison; [e-mail]; [e-mail]; [e-mail]; pwe3; HUANG Feng F
Subject: Re: [mpls-tp] [PWE3] [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

Dear Sasha,
I don't think that TP and non-TP networks should be peers, not server and client to each other. Even though nothing precludes them from being peers. I think that allowing TP and non-TP to be peers would create many, for example, OAM issues since much of MPLS, i.e. IP/MPLS, is outside of scope of MPLS-TP OAM. For instance, what is ME of merged LSP? Is it between LER's or between LER and MP?

Regards,
Greg

On Wed, Mar 23, 2011 at 10:44 PM, Alexander Vainshtein <[e-mail]<mailto:[e-mail]>> wrote:
Greg, Curtis and all,
I think that the linkage between TP/non-TP differentiation and restrictions on GAL usage is highly problematic.

E.g., consider an MS-PW with some segments crossing TP domains and some - non-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 complies 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.

And, last but not least, if we decide to allow GAL in the middle of the label stack (overriding RFC 5586 and RFC 5960), we must also define how a packet with GAL in the middle of the label stack is forwarded when GAL is exposed, similar to what has been done in RFC 3032 for RAL.

My 2c,
     Sasha


________________________________
From: [e-mail]<mailto:[e-mail]> [[e-mail]<mailto:[e-mail]>] On Behalf Of Greg Mirsky [[e-mail]<mailto:[e-mail]>]
Sent: Wednesday, March 23, 2011 10:57 PM
To: [e-mail]<mailto:[e-mail]>
Cc: Robert Rennison; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; 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 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 <[e-mail]<mailto:[e-mail]>> wrote:

In message <[e-mail]<mailto:[e-mail]>>
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 ...]