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

From: Luca Martini <[email-masked]>
Date: Fri, 11 Mar 2011 06:31:37 -0700

Greg ,
Some

On 02/18/11 11:15, Greg Mirsky wrote:
> Dear Luca,
> I see at least two issues:
>
>     * use of GAL for PW, in my view, is another VCCV CC type that has
>       to be negotiated as described in RFC 5085.
>
These are valid points, but this document in question does not define,
not discussed VCCV.
We have since posted a draft that proposes a new VCCV mode , and we
welcome comments regarding that document.
(draft-nadeau-pwe3-vccv-2-01.txt)

>     * use of GAL creates ambiguous situation when PW CW is used. The
>       benefit from extending GAL in PW, as I see, is for PWs that are
>       not required to use PW CW. That might be a good enough reason to
>       update RFC 5586 as proposed in the document but we must address
>       use cases of GAL in PWs that require presence PW CW. If we
>       prohibit or even discourage use of GAL for these PWs that have
>       PW VCCV as native Associated Channel, then architecture of ACh
>       for MPLS-TP PW not simplified as result of adopting the proposal.
>
> Regard
Greg,
The GAL is basically a notifier that the packet following the end of the
MPLS label stack, is explicitly defined as a G-ACH format.
Normally the packet would be decoded as an IP packet , unless the last
label on the stack indicated otherwise.

The GAL can certainly be applied  to a PW OAM packet on a PW that uses
the CW, and this document does not define that , nor restricts it.

The scope of this document is limited to removing an unnecessary
restriction in rfc5586, hence  this comment not applicable to this document.

Thanks.
Luca

> s,
> Greg
>
> On Fri, Feb 18, 2011 at 7:46 AM, Luca Martini <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Greg,
>
>     Sorry, but I do not remember the point you mention.
>     Can you explain again here ?
>     Thanks.
>     Luca
>
>
>     On 02/17/11 23:47, Greg Mirsky wrote:
>     > Dear Authors and All,
>     > prior to the meeting in Bejing and acceptance of this proposal as WG
>     > document Luca and I agreed that use of GAL with PW VCCV presents a
>     > problem.
>     > I was not attending the IETF-79, nor I found discussion of this
>     issue
>     > in the minutes. I think that this issue should be specified,
>     > explained. In my view, this document updates not only RFC 5586
>     > but RFC 5085 too.
>     >
>     > Regards,
>     > Greg
>     >
>     > Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt
>     >
>     > On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini
>     <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     Greg,
>     >
>     >     You are correct , the proposed update does not propose any
>     changes
>     >     to VCCV.
>     >     However the problem with vccv is not as simple as to ask for
>     a new
>     >     code point from IANA.
>     >     Given the good amount of discussion on this point, we should
>     >     probably have a discussion in Beijing.
>     >
>     >     Luca
>     >
>     >
>     >
>     >     On 10/29/2010 05:07 PM, Greg Mirsky wrote:
>     >>     Dear Authors,
>     >>     I think that proposed update of the Section 4.2. RFC 5586
>     makes it possible
>     >>     to use GAL on MPLS-TP PW that uses Control Word. I consider
>     it to be
>     >>     conflict between PW VCCV CC types because use of GAL is not
>     negotiated
>     >>     through PW VCCV negotiation. To avoid such situation I propose:
>     >>
>     >>        - in Section 5 request IANA to assign new CC Type "MPLS
>     Generic
>     >>        Associated Channel Label"
>     >>        - assign precedence to new CC Type that affects Section
>     7 RFC 5085
>     >>
>     >>     Regards,
>     >>     Greg
>     >>
>     >>
>     >>
>     >>     _______________________________________________
>     >>     mpls mailing list
>     >>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     >>     https://www.ietf.org/mailman/listinfo/mpls
>     >
>     >
>     >
>     > _______________________________________________
>     > mpls mailing list
>     > [email-masked] <mailto:[email-masked]>
>     > https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 11 Mar 2011 11:14:25 -0800

Dear Luca,
thank you for bringing draft-nadeau-pwe3-vccv-2-01 to my attention. I'll
send my comments to it in a separate e-mail.
I'll have to miss another opportunity to discuss your proposal in a meeting.
Please add my comments below to my earlier expressed WG LC comments:

   - the draft-lm-pwe3-mpls-tp-gal-in-pw-00 depends on any solution that
   addresses applicability of GAL in PW VCCV, e.g. solution proposed in
   draft-nadeau-pwe3-vccv-2-01;
   - the draft-lm-pwe3-mpls-tp-gal-in-pw-00 needs to mention such dependency
   and refer to any existing proposal;
   - I believe that the draft-lm-pwe3-mpls-tp-gal-in-pw-00 can be advanced
   in lock with document that addresses use of GAL in PW VCCV.

Regards,
Greg

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 11 Mar 2011 21:21:49 +0200

Greg, Luca,
As I've already stated in my comment on draft-nadeau-pwe3-vccv-2, IMHO it makes draft-lm-pwe3-mpls-tp-gal-in-pw completely useless.

My 2c,
     Sasha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Friday, March 11, 2011 9:14 PM
To: Luca Martini
Cc: [email-masked]; [email-masked]; pwe3; HUANG Feng F; [email-masked]
Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

Dear Luca,
thank you for bringing draft-nadeau-pwe3-vccv-2-01 to my attention. I'll send my comments to it in a separate e-mail.
I'll have to miss another opportunity to discuss your proposal in a meeting. Please add my comments below to my earlier expressed WG LC comments:

 *   the draft-lm-pwe3-mpls-tp-gal-in-pw-00 depends on any solution that addresses applicability of GAL in PW VCCV, e.g. solution proposed in draft-nadeau-pwe3-vccv-2-01;
 *   the draft-lm-pwe3-mpls-tp-gal-in-pw-00 needs to mention such dependency and refer to any existing proposal;
 *   I believe that the draft-lm-pwe3-mpls-tp-gal-in-pw-00 can be advanced in lock with document that addresses use of GAL in PW VCCV.
Regards,
Greg
On Fri, Mar 11, 2011 at 5:31 AM, Luca Martini <[email-masked]<mailto:[email-masked]>> wrote:
Greg ,
Some

Greg,

Thanks.
Luca

> s,
> Greg
>
> On Fri, Feb 18, 2011 at 7:46 AM, Luca Martini <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     Greg,
>
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     > <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
>     >
>     >     Greg,
>     >
>     >>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>     > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

---

From: venkatesan mahalingam <[email-masked]>
Date: Fri, 11 Mar 2011 15:12:51 -0500

Hi,
AFAIK, ACH can't be used without supporting the CW in HW.

As per RFC-5085, 5.1.1.  In-Band VCCV (Type 1)
CC Type-1 mode of VCCV operation MUST be supported when the control word is
present.

Are we implicitly mandating the CW (ACH) in HW by configuring/negotiating
the CC type-4?
It looks to me that CC type-1 for ACH without GAL and CC type-4 for ACH with
GAL.

IMO, if we support CC type-4, CC type-1 support is implicitly attained.

IMHO, it should be possible to get the MPLS-TP OAM control packets with or
without GAL from HW to CP by negotiating CC type-1 itself.

Some editorial comments for the draft-nadeau-pwe3-vccv-2-01.txt draft,
"
4.1.1.  MPLS VCCV Control Channel (CC) Type 4

   IANA is requested to augment the registry of "MPLS VCCV Control
   Channel Types" with the new type defined below. As defined in
   RFC5058, this new bitfield is to be assigned by IANA using
"
Replace the RFC5058 as RFC5085.

Thanks,
Venkat.

On Fri, Mar 11, 2011 at 2:21 PM, Alexander Vainshtein <
[email-masked]> wrote:

> Greg, Luca,
>
> As I’ve already stated in my comment on draft-nadeau-pwe3-vccv-2, IMHO it
> makes draft-lm-pwe3-mpls-tp-gal-in-pw completely useless.
>
>
>
> My 2c,
>
>      Sasha
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Greg Mirsky
> *Sent:* Friday, March 11, 2011 9:14 PM
> *To:* Luca Martini
> *Cc:* [email-masked]; [email-masked]; pwe3; HUANG Feng F;
> [email-masked]
> *Subject:* Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt
>
>
>
> Dear Luca,
> I'll have to miss another opportunity to discuss your proposal in a
> meeting. Please add my comments below to my earlier expressed WG LC
> comments:
>
>    - the draft-lm-pwe3-mpls-tp-gal-in-pw-00 needs to mention such
>    dependency and refer to any existing proposal;
> [email-masked]

-- 
Best Regards,
Venkatesan Mahalingam.

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 11 Mar 2011 15:58:22 -0500

> CC Type-1 mode of VCCV operation MUST be supported when the control word is present.
> 
> Are we implicitly mandating the CW (ACH) in HW by configuring/negotiating the CC type-4?
> It looks to me that CC type-1 for ACH without GAL and CC type-4 for ACH with GAL.

	The IETF's protocols do not mandate how they are to be implemented per se (i.e.:
in HW or not). The draft addresses the operational concerns of configuration/complexity 
by having 1 mode for each of the major operational scenarios: with or without the CW.

> IMHO, it should be possible to get the MPLS-TP OAM control packets with or without GAL from HW to CP by negotiating CC type-1 itself.

	There is no negotiation; VCCV uses a capability advertisement. But more to the point, 
the proposed operation rule here is simple and straight-forward: if you have configured the CW and advertised 
that as per the rules for use of the CW, then Type 1 MUST be used. If not, use Type 4 (if both sides are capable).  

> Replace the RFC5058 as RFC5085.

	Cool, thanks. We will fix this in the next rev.

	--Tom

> 
> Thanks,
> Venkat.
> 
> On Fri, Mar 11, 2011 at 2:21 PM, Alexander Vainshtein <[email-masked]> wrote:
> Greg, Luca,
> 
> As I’ve already stated in my comment on draft-nadeau-pwe3-vccv-2, IMHO it makes draft-lm-pwe3-mpls-tp-gal-in-pw completely useless.
> 
>  
> My 2c,
> 
>      Sasha
> 
>  
> the draft-lm-pwe3-mpls-tp-gal-in-pw-00 depends on any solution that addresses applicability of GAL in PW VCCV, e.g. solution proposed in draft-nadeau-pwe3-vccv-2-01;
> the draft-lm-pwe3-mpls-tp-gal-in-pw-00 needs to mention such dependency and refer to any existing proposal;
> I believe that the draft-lm-pwe3-mpls-tp-gal-in-pw-00 can be advanced in lock with document that addresses use of GAL in PW VCCV.
> Regards,
> Greg
> 
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 12 Mar 2011 06:44:47 +0200

Venkat,

You have asked "Are we implicitly mandating the CW (ACH) in HW by configuring/negotiating the CC type-4?"

IMO the answer is "No".
In VCCV Type 1 the first nibble of the CW is a data path (HW if you wish) exception mechanism forwarding the packets to an OAM entity.

In VCCV Type 4 GAL acts as such an exception mechanism. ACH is actually only needed to decide on the ACH Type. And it would not even be examined if the TTL in the PW label has not expired.

My 2c,
     Sasha

________________________________
From: venkatesan mahalingam [[email-masked]]
Sent: Friday, March 11, 2011 10:12 PM
To: Alexander Vainshtein; Greg Mirsky; Luca Martini; [email-masked]; [email-masked]; pwe3; HUANG Feng F; [email-masked]
Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

Hi,

Thanks,
Venkat.

On Fri, Mar 11, 2011 at 2:21 PM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
Greg, Luca,
As I’ve already stated in my comment on draft-nadeau-pwe3-vccv-2, IMHO it makes draft-lm-pwe3-mpls-tp-gal-in-pw completely useless.

My 2c,
     Sasha

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Greg Mirsky
Sent: Friday, March 11, 2011 9:14 PM
To: Luca Martini
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; pwe3; HUANG Feng F; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

Dear Luca,

Greg,

Thanks.
Luca

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

--
Best Regards,
Venkatesan Mahalingam.

---

From: Robert Rennison <[email-masked]>
Date: Tue, 22 Mar 2011 12:22:12 -0400

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-2 amounts 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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Friday, March 11, 2011 2:22 PM
To: Greg Mirsky; Luca Martini
Cc: [email-masked]; [email-masked]; pwe3; HUANG Feng F; [email-masked]
Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

Greg, Luca,

My 2c,
     Sasha

Dear Luca,

Greg,

Thanks.
Luca

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 22 Mar 2011 18:00:07 +0000

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

On 22/03/2011 16:22, Robert Rennison wrote:
> 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:
>
> 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 ?
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Alexander Vainshtein
> *Sent:* Friday, March 11, 2011 2:22 PM
> *To:* Greg Mirsky; Luca Martini
> *Cc:* [email-masked]; [email-masked]; pwe3; HUANG Feng F; 
> [email-masked]
> As I've already stated in my comment on draft-nadeau-pwe3-vccv-2, IMHO 
> it makes draft-lm-pwe3-mpls-tp-gal-in-pw completely useless.
>
> My 2c,
>
>      Sasha
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Greg Mirsky
> thank you for bringing draft-nadeau-pwe3-vccv-2-01 to my attention. 
> I'll send my comments to it in a separate e-mail.
>     * the draft-lm-pwe3-mpls-tp-gal-in-pw-00 depends on any solution
>       that addresses applicability of GAL in PW VCCV, e.g. solution
>       proposed in draft-nadeau-pwe3-vccv-2-01;
>     * the draft-lm-pwe3-mpls-tp-gal-in-pw-00 needs to mention such
>     * I believe that the draft-lm-pwe3-mpls-tp-gal-in-pw-00 can be
>       advanced in lock with document that addresses use of GAL in PW VCCV.
>
> Regards,
> Greg
>
> <mailto:[email-masked]>
>
> <mailto:[email-masked] <mailto:[email-masked]>>
>
> > > <mailto:[email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
> > >
> > >     Greg,
> > >
> <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>
> > <mailto:[email-masked] <mailto:[email-masked]>>>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 23 Mar 2011 13:57:15 -0700

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 <[email-masked]> wrote:

>
> In message <[email-masked]>
> Stewart Bryant writes:
> >
> 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
>
>
> > > <
> http://tools.ietf.org/html/draft-lm-pwe3-mpls-tp-gal-in-pw-00#section-4.2
> >.
[snipped ...]

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 24 Mar 2011 07:44:39 +0200

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

In message <[email-masked]<mailto:[email-masked]>>

Stewart,

Curtis

[snipped ...]

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 23 Mar 2011 23:33:45 -0700

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 <
[email-masked]> wrote:

> 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:
>
>
>  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:* [email-masked] [[email-masked]] On Behalf Of
> Greg Mirsky [[email-masked]]
> *Sent:* Wednesday, March 23, 2011 10:57 PM
> *To:* [email-masked]
> *Cc:* Robert Rennison; [email-masked]; [email-masked];
> [email-masked]; 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,
> On Wed, Mar 23, 2011 at 1:25 PM, Curtis Villamizar <[email-masked]>wrote:
>
>>

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 24 Mar 2011 08:59:06 +0200

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 [[email-masked]]
Sent: Thursday, March 24, 2011 8:33 AM
To: Alexander Vainshtein
Cc: [email-masked]; Robert Rennison; [email-masked]; [email-masked]; [email-masked]; 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 <[email-masked]<mailto:[email-masked]>> wrote:
Greg, Curtis and all,
I think that the linkage between TP/non-TP differentiation and restrictions on GAL usage is highly problematic.

My 2c,
     Sasha

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

Regards,
Greg

Stewart,

Curtis

[snipped ...]

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 25 Mar 2011 22:02:57 -0400

In message <[email-masked]>
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=

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: [email-masked] [[email-masked]] On Behalf Of Greg=
>  Mirsky [[email-masked]]
> Cc: Robert Rennison; [email-masked]; [email-masked]; [email-masked]=
> ; 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 <[email-masked]<mailto=
> :[email-masked]>> wrote:
>  
> > > <http://tools.ietf.org/html/draft-lm-pwe3-mpls-tp-gal-in-pw-00#section-=
> 4.2>.
> > >           the label stack (i.e., S bit set to 1). However, in other MPL=
> S
> > >
> > >           the GAL may appear within the label stack or its use with PWs=
> .
> > >
> > >       is replaced by:
> > >
> > > and if one has to use  a GAL with a PW this would be the place to put i=
> t,
> > >

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 26 Mar 2011 08:39:33 +0200

Curtis, 
Please see inline below. I've snipped the text that is not relevant to my comment.

Regards,
     Sasha

________________________________________
From: [email-masked] [[email-masked]]
Sent: Saturday, March 26, 2011 4:02 AM
To: Alexander Vainshtein
Cc: Greg Mirsky; [email-masked]; Robert Rennison; [email-masked]; [email-masked]; [email-masked]; pwe3; HUANG Feng F
Subject: Re: [mpls-tp] [PWE3] [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

In message <[email-masked]>
Alexander Vainshtein writes:
... snipped ...
>> 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 pack et 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

> Curtis

IMHO this would not work for, say MS-PWs with GAL above the PW label as proposed in draft-nadeu.

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 27 Mar 2011 15:01:45 -0400

Sasha,

Thanks for trimming.  I further trimmed and also dropped mpls-tp.

This email has suggested change to the internet-draft below.

It is important that any proposal to use GAL with PW not break
traceroute on the containing LSP.  Since a goal is to also suport
MS-PW (as you point out below) and LSP hierarchy, an LSR needs to be
able to forward payload containing GAL.  See inline to keep the
context.

Btw - the new name of the document is:
draft-ietf-pwe3-mpls-tp-gal-in-pw-00.txt

Another suggestion is why not drop the -TP from the title.  GAL
applies to all MPLS, not just -TP.

Curtis

In message <[email-masked]>
> Please see inline below. I've snipped the text that is not relevant

A few simple rules would work for LSP ping (not using TTL), LSP
traceroute (using TTL), PW ping (including MS-PW, not using TTL), and
MS-PW traceroute (using TTL to identify the set of S-PE).

  original (rfc5586.txt):

   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.  Where the GAL is at the bottom
   of the label stack (i.e., S bit set to 1), then it MUST always be
   followed by an ACH.

   The GAL MUST NOT appear in the label stack when transporting normal
   user-plane packets.  Furthermore, when present, the GAL MUST NOT
   appear more than once in the label stack.

  replacement:

   In MPLS and MPLS-TP, the GAL MUST be used with packets on a G-ACh
   on LSPs, Concatenated Segments of LSPs, and with Sections.  GAL MAY
   be used with PWs.  It MUST always be at the bottom of the label
   stack (i.e., S bit set to 1).  GAL must appear immediately below
   the label for which a G-Ach is associated.  The ingress SHOULD
   determine whether labels below GAL are supported by intermediate
   and egress LSR, otherwise GAL must also be at the bottom of the
   stack.  

   The GAL MUST NOT be added to normal user-plane packets.  User-plane
   packets which already contain GAL may be transported.  When
   present, the GAL MUST NOT appear more than once in the label stack.

At some later point in the document (could be section 3 and 4) add:

  Backwards compatibility:

   In order to insure that LSR which strictly conform to [RFC5586] and
   require that GAL be on the bottom of the stack, an ingress SHOULD
   determine whether all intermediate LSR and the egress LSR support
   labels after the GAL label.

   <<< add mechanism to advertise capability here or disclaimer that
       it is elsewere in some ISIS or OSPF extensions >>>

  Rules for handling GAL and TTL expired with GAL:

   GAL MUST be place directly beneath label for the LSP or PW for
   which the channel is relevant.  Additional labels MAY be placed
   below GAL to affect packet entropy based decisions at multipoint
   links such as link bundles and Ethernet LAG.  See [Backwards
   compatibility] for limitations on labels below GAL.

   LSR using label stack based packet entropy based decisions at
   multipoint links SHOULD ignore a GAL label for the purpose of
   entropy harvesting and continue entropy harvesting as though GAL
   were not present.

   When processing TTL Expiration on a packet, if the label
   immediately following is GAL, then a ACH MUST be immediately below
   the bottom of the MSPL stack and the ACH must be processed.

   When a LSP POP or PW POP occurs, if the next label is GAL, then a
   ACH MUST be immediately below the bottom of the MSPL stack and the
   ACH must be processed.

Note that for PW, GAL is after the PW label and before the fat-pw
label (if present).

We also need to change the security section a bit.

   Refer to [RFC5586] for general MPLS security considerations.

   GAL in user payload must be forwarded to support GAL at a client
   layer.  If an LSR interprets GAL at the bottom of stack to be
   relevant to a G-Ach for the label for which a TTL has expired, then
   a client layer G-Ach payload may be applied to a server layer.
   Use of the uniform model, or a pipe model TTL set too low with an
   attack which increases hop count (physical attack), plus an LSR
   that erroneously interprets GAL anywhere in the stack or at bottom
   of stack to be a G-Ach at the layer for which TTL has expired,
   provides a low probability attack vector.

   This attack vector would only exist if intermediate LSR on the path
   interpretted TTL anywhere in the stack or at bottom of stack as
   their own G-Ach.  This document requires that the GAL only be
   considered if it is immediately following a TTL expire or POP.
   [RFC5586] is silent on forwarding (or not forwarding packets
   contraining GAL at the ingress to a hierarchical LSP, and is
   unclear as to whether TTL expired can be applied to GAL at the
   bottom of stack well below the label for which TTL expired.

   The vulnerability is associated with the behaviour defined in
   [RFC5586] and would be fixed if all LSR conformed to the updates to
   [RFC5586] in this document.

   The potential for this attack vector to become exploitable as a
   result of an older LSR which adheres only to [RFC5586] can be
   eliminated by offering an option to block forwarding of traffic
   containing GAL if the backward compatibility check defined in
   [Backwards compatibility] reveals intermediate or egres LSR not
   advertising the capability defined in this document.  LSR SHOULD
   provide such an option.