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

[Greg Mirsky <[e-mail]>]

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]> 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 andMPLS-TP-TP, and hence the same restrictions shouldapply 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] [[e-mail]] On Behalf Of
> Greg Mirsky [[e-mail]]
> *Sent:* Wednesday, March 23, 2011 10:57 PM
> *To:* [e-mail]
> *Cc:* 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 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]>wrote:
>
>>
>> In message <[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 ...]
>