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

[Lamberto Sterling <[e-mail]>]

Hi all,
I do not see the benefit that GAL in PW can bring while current three CC
type does not own. If there is no agreed benefit, why we add overload to the
indurstry (more HW design), and complexity to the interoperability by
ourself? When IETF refuse draft-bhh-1731 as OAM tool for MPLS-TP, the reason
is again interoperability and indurstry HW cost, and personally agree with
that.

Lamberto



> ------------------------------
>
> Date: Sat, 12 Mar 2011 06:44:47 +0200
> From: Alexander Vainshtein <[e-mail]>
> Subject: Re: [PWE3] [mpls] WG LC
>        draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt
> To: venkatesan mahalingam <[e-mail]>, "[e-mail]"
>        <[e-mail]>
> Cc: Luca Martini <[e-mail]>, "[e-mail]"
>        <[e-mail]>,     "[e-mail]" <
> [e-mail]>,
>        pwe3 <[e-mail]>,   HUANG Feng F <
> [e-mail]>
> Message-ID:
>        <[e-mail]>
> Content-Type: text/plain; charset="windows-1252"
>
> 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 [[e-mail]]
> Sent: Friday, March 11, 2011 10:12 PM
> To: Alexander Vainshtein; Greg Mirsky; Luca Martini; [e-mail];
> [e-mail]; pwe3; HUANG Feng F; [e-mail]
> Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt
>
> 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.
>
> 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 <
> [e-mail]<mailto:[e-mail]>>
> 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: [e-mail]<mailto:[e-mail]> [mailto:
> [e-mail]<mailto:[e-mail]>] On Behalf Of Greg
> Mirsky
> Sent: Friday, March 11, 2011 9:14 PM
> To: Luca Martini
> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]
> <mailto:[e-mail]>; pwe3; HUANG Feng F; [e-mail]<mailto:
> [e-mail]>
> 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 <[e-mail]<mailto:
> [e-mail]>> wrote:
> 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 <[e-mail]
> <mailto:[e-mail]>
> > <mailto:[e-mail]<mailto:[e-mail]>>> 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
> >     <[e-mail]<mailto:[e-mail]> <mailto:
> [e-mail]<mailto:[e-mail]>>
> >     > <mailto:[e-mail]<mailto:[e-mail]> <mailto:
> [e-mail]<mailto:[e-mail]>>>> 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
> >     >>
> >     >>
> >     >>