Subject: [Pals] Candidate draft-ietf-pals-vccv-for-gal-01

From: Stewart Bryant <[email-masked]>
Date: Wed, 14 Jan 2015 15:36:51 +0000

Working Group/Co-authors

Following discussion on the list I have edited draft-ietf-pals-vccv-for-gal
to just define the GAL VCCV CC Type 4. As suggested the plan will then be
to write a new draft describing the migration strategy to type 1 and 4 only.
There is some text in here on migration and I am torn between taking it out
and leaving it in to explain why we are introducing the new CC type.

Because of the extensive changes I thought it best to post this candidate
to the list to make sure we are all on the same page. If this is going in
the right direction I will upload it as a draft replacing
draft-ietf-pals-vccv-for-gal-00.

I took Sasha's proposal of making FAT and GAL mutually exclusive which
in my view usefully simplified that aspect of the design.

I did quite a lot of work on the Capability Advertisment section which
will need to be checked very carefully, in particular the handling of the
error processing.

I would appreciate a quick review to see whether this is what the WG was
expecting, and then I can upload it ready for a detailed review if it
is on the right lines.

- Stewart

PWE3                                                           T. Nadeau
Internet-Draft lucidvision
Intended status: Standards Track                              L. Martini
Expires: July 18, 2015                                         S. Bryant
                                                            Cisco Systems
                                                         January 14, 2015

           Candidate for Using GAL as a VCCV Channel Indicator
                     draft-ietf-pals-vccv-for-gal-01

Abstract

    This document specifies a new Virtual Circuit Connectivity
    Verification (VCCV) (RFC5085) control channel type for use with
    pseudowires (PW) carried over an MPLS network.  This new channel type
    uses the Generic Associated Channel Label (GAL) (RFC5586) to
    distinguish VCCV packets from packets carrying user data.

Status of This Memo

    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

    This Internet-Draft will expire on July 18, 2015.

Copyright Notice

    Copyright (c) 2015 IETF Trust and the persons identified as the
    document authors.  All rights reserved.

    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
    carefully, as they describe your rights and restrictions with respect
    to this document.  Code Components extracted from this document must
    include Simplified BSD License text as described in Section 4.e of

Nadeau, et al.            Expires July 18, 2015 [Page 1]

Internet-Draft            GAL as a VCCV Channel January 2015

    the Trust Legal Provisions and are provided without warranty as
    described in the Simplified BSD License.

Table of Contents

    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
    2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
    3.  GAL VCCV Control Channel Type . . . . . . . . . . . . . . . .   3
    4.  FAT PWs . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
    5.  VCCV Capability Advertisement . . . . . . . . . . . . . . . .   4
    6.  Manageability Considerations  . . . . . . . . . . . . . . . .   5
    7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
    8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
      8.1.  MPLS VCCV Control Channel (CC) Type 4 . . . . . . . . . .   5
      8.2.  LDP Status Code . . . . . . . . . . . . . . . . . . . . .   6
    9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
    10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
      10.1.  Normative References . . . . . . . . . . . . . . . . . .   6
      10.2.  Informative References . . . . . . . . . . . . . . . . .   7
    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

    This document specifies a new Virtual Circuit Connectivity
    Verification (VCCV) [RFC5085] control channel (CC) type for use with
    pseudowires (PW) carried over an MPLS network that do not use the PW
    Control Word (CW) [RFC4385].  This new VCCV CC type uses the Generic
    Associated Channel Label (GAL) [RFC5586] to distinguish VCCV packets
    from packets carrying user data.  This new VCCV CC type introduces
    compatibility with the method of MPLS Label Switched Path (LSP)
    Operations, Administration, and Maintenance (OAM) identification,
    particularly in MPLS-TP networks [RFC5921].

    VCCV currently specifies three CC types.  VCCV CC Type 1 uses the PW
    Control Word (CW) to distinguish VCCV packets from packets carrying
    user data.  VCCV CC Types 2 and 3 require IP encapsulation for OAM
    packets they carry.  This was not an issue when [RFC5085] was
    designed, but is in conflict with the design goals of MPLS-TP
    [RFC5921] which does not otherwise require the availability of IP.
    VCCV CC Type 2 is not supported by multi-segment PWs (MS-PWs)
    [RFC6073].  A MS-PW operating without the CW therefore has to use
    VCCV CC Type 3 which identifies VCCV packets on the basis of TTL
    expiry.  Whilst less of an issue with a single segment PW (SS-PW), on
    an MS-PW this need to be accurately set to cause TTL expiry at the
    egress Terminating Provider Edge (T-PE) [RFC6073].  In the event of a
    error in the setting of the PW LSE TTL this can result in VCCV
    packets leaking into the attachment circuit which may disrupt the
    operation of the PW, or the user service, and is a security risk.

Nadeau, et al.            Expires July 18, 2015 [Page 2]

Internet-Draft            GAL as a VCCV Channel January 2015

    The new VCCV CC type defined in this specification addresses these
    problems for PWs that do not use the CW.

    For reasons of network efficiency and due to hardware constraints it
    is not possible to address these issue by mandating that all PWs use
    the PW CW, hence the introduction of this new VCCV CC type.

2.  Requirements Language

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
    "OPTIONAL" in this document are to be interpreted as described in
    [RFC2119].

3.  GAL VCCV Control Channel Type

    When the PW CW is not used, the GAL VCCV Control Channel (CC) type
    defined in this section MAY be used.  This is referred to as VCCV CC
    Type4 throughout the rest of this of this document.  VCCV Type 4 uses
    the encapsulation shown in Figure 1.

    0 1
                     2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            PW LSE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           GAL LSE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 1|Version|   Reserved    |        Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | |
    ~                        VCCV Message Body ~
    | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                  Figure 1

    The VCCV message body is preceded by a Generic Associated Channel
    Header as defined in [RFC5586], in which the Channel Type identifies
    the type and format of the OAM message carried in the VCCV message
    body.

    The GAL LSE MUST contain the GAL reserved label as defined in
    [RFC5586].

Nadeau, et al.            Expires July 18, 2015 [Page 3]

Internet-Draft            GAL as a VCCV Channel January 2015

    The PW LSE is constructed according to the existing procedures that
    apply to the type of pseudowire that is in use.

    Note that the inclusion of a GAL following the PW LSE over a label
    switched path subject to Equal-Cost Multi-path (ECMP) load balancing
    can cause the OAM packet to take a different path through the network
    from the corresponding PW data packets.  If that is not acceptable,
    then an alternative VCCV type must be used.

4.  FAT PWs

    [RFC6391] specifies that when the flow-aware transport (FAT) of
    pseudowires over an MPLS packet switched network has been signalled
    or configured, the Flow LSE MUST be present.  It further specifies
    that "the flow label MUST NOT be an MPLS reserved label (values in
    the range 0..15) [RFC3032]", and that "If a flow LSE is present, it
    MUST be checked to determine whether it carries a reserved label.  If
    it is a reserved label, the packet is processed according to the
    rules associated with that reserved label; otherwise, the LSE is
    discarded."

    This document specifies that if the flow-aware transport of
    pseudowires over an MPLS packet switched network has been signalled
    or configured then the presence of VCCV message is indicated by the
    use of a GAL in place of the flow LSE.

    This is consistent with [RFC6391], and the packet structure is
    identical to that shown in Figure 1.

    Note that the use of a GAL in place of the flow label over a label
    switched path subject to ECMP can cause the OAM packet to take a
    different path through the network from the corresponding PW data
    packets.  If that is not acceptable, then an alternative VCCV type
    must be used.

5.  VCCV Capability Advertisement

    The VCCV capability advertisement MUST match the c-bit setting that
    is advertised in the PW FEC element [RFC4447].  If the c-bit is set,
    indicating the use of the PW CW, then VCCV CC Type 4 MUST NOT be
    advertised.  If the c-bit is not set, indicating that the PW CW is
    not in use, then an equipment supporting this specification MUST
    advertise VCCV CC Type 4.  Advertisement of VCCV CC Types 1 and 4 are
    therefore mutually exclusive.

    A PE supporting VCCV CC Type 4 MAY advertise other VCCV CC types as
    defined in [RFC5085] .

Nadeau, et al.            Expires July 18, 2015 [Page 4]

Internet-Draft            GAL as a VCCV Channel January 2015

    If the remote PE supports VCCV CC Type 4, and the PW CW is not in
    use, then the following capability advertisement precedence rules
    supersede those defined in Section 7 of [RFC5085] :

    1.  Type 4: GAL VCCV Control Channel.

    2.  Type 2: MPLS Router Alert Label.

    3.  Type 3: MPLS PW Label with TTL == 1.

    If the remote PE finds that VCCV CC Types 1 and 4 are both
    advertised, or that c-bit is set and VCCV CC Type 4 is advertised,
    then it should report the error to the operator through the
    management interface in use, and send a Label Release Message with a
    status code "VCCV Type Error".

6.  Manageability Considerations

    Whilst the introduction of this additional VCCV CC type increases the
    number of VCCV CC types that the operator needs to manage, it
    addresses the issues with VCCV CC Types 2 and 3 described in
    Section 1, and is a necessary per-requisite of the long term strategy
    of the PALS working group to consolidate the VCCV channel types down
    to only VCCV CC Types 1 and 4.  This consolidation and will be the
    subject of future work by the PALS working group.

    In the event of a misconfiguration of this VCCV CC type, the PW is
    taken out of service and the operator advised as described in
    Section 5.

    Attention is drawn to the possible absence of fate sharing between PW
    data packets and VCCV CC Type 4 packets described in Section 3 and
    Section 4.

7.  Security Considerations

    This document does not by itself raise any new security
    considerations beyond those described in [RFC5085].  It addresses the
    possibility of packet leaking that can occur with VCCV CC Type 3.

8.  IANA Considerations

8.1.  MPLS VCCV Control Channel (CC) Type 4

    IANA is requested to assign a new bit from the MPLS VCCV Control
    Channel (CC) Types registry in the PWE3-parameters name space in
    order to identify VCCV type 4.  It is recommended that Bit 3 be
    assigned to this purpose which would have a value of 0x08.

Nadeau, et al.            Expires July 18, 2015 [Page 5]

Internet-Draft            GAL as a VCCV Channel January 2015

    MPLS VCCV Control Channel (CC) Types

          Bit (Value)    Description   Reference
          ============   ===========   ==================
          Bit X (0x0Y)   Type 4        This Specification

8.2.  LDP Status Code

    IANA is requested to assign a new Status Code from the Label
    Distribution Protocol (LDP) Parameters name space:

    Status Code Name Space

          Range/Value  E  Description      Reference
          ===========  =  ===============  =========
          0x000000xx   0  VCCV Type Error  This Specification

9.  Acknowledgments

    The authors wish to thank Alexander (Sasha) Vainshtein for his review
    comments and for his proposal to make the GAL and Flow labels
    mutually exclusive.  This proposal let to a significant
    simplification of this design.

10.  References

10.1.  Normative References

    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

    [RFC4385]  Bryant, S., Swallow, G., Martini, L., and D. McPherson,
               "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
               Use over an MPLS PSN", RFC 4385, February 2006.

    [RFC4447]  Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
               Heron, "Pseudowire Setup and Maintenance Using the Label
               Distribution Protocol (LDP)", RFC 4447, April 2006.

    [RFC5085]  Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
               Connectivity Verification (VCCV): A Control Channel for
               Pseudowires", RFC 5085, December 2007.

    [RFC5586]  Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
               Associated Channel", RFC 5586, June 2009.

Nadeau, et al.            Expires July 18, 2015 [Page 6]

Internet-Draft            GAL as a VCCV Channel January 2015

    [RFC6073]  Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
               Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.

    [RFC6391]  Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
               J., and S. Amante, "Flow-Aware Transport of Pseudowires
               over an MPLS Packet Switched Network", RFC 6391, November
               2011.

10.2.  Informative References

    [RFC5921]  Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
               Berger, "A Framework for MPLS in Transport Networks", RFC
               5921, July 2010.

Authors' Addresses

    Thomas D. Nadeau
    lucidvision

    Email: [email-masked]

    Luca Martini
    Cisco Systems

    Email: [email-masked]

    Stewart Bryant
    Cisco Systems

    Email: [email-masked]

Nadeau, et al.            Expires July 18, 2015 [Page 7]

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 14 Jan 2015 15:33:45 -0500

Stewart,

Thanks, I just gave it a quick read-through and it looks (to me) like just
what the WG has requested. I think the introductory text is at a good level
to motivate the new VCCV type without getting into all of the details of
migration.

Cheers,
Andy

On Wed, Jan 14, 2015 at 10:36 AM, Stewart Bryant <[email-masked]> wrote:

> _______________________________________________
> Pals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pals
>
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 15 Jan 2015 10:03:13 +0000

Stewart,
Lots of thanks for a very nice re-write of the draft that, from my POV, resolves all outstanding technical issues raised so far and moved discussion of operational issues ( consolidation of VCCV Types, migration strategy etc.)  out of scope of a clear-cut technical specification.

I have added a couple of minor comments inline below that hopefully could be useful. Please feel free to use (or not to use) them as you see fit.

Regards,
       Sasha
Email: [email-masked]
Mobile: 054-9266302

From: Pals [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Wednesday, January 14, 2015 5:37 PM
To: [email-masked]; [email-masked]
Subject: [Pals] Candidate draft-ietf-pals-vccv-for-gal-01

Working Group/Co-authors

- Stewart

PWE3                                                           T. Nadeau

Abstract

Status of This Memo

Copyright Notice

Table of Contents

1.  Introduction

   VCCV CC Type 2 is not supported by[[Sasha]] not applicable to?   multi-segment PWs (MS-PWs)
[[Sasha]] Maybe you could add that VCCV Type 3 remains mandatory for segment OAM of MS-PWs and that it is  combined with VCCV Type 1 for MS-PWs that use the CW – this is explicitly stated in RFC 6073.

   For reasons of network efficiency and due to hardware constraints it
   is not possible to address these issue by mandating that all PWs use
   the PW CW, hence the introduction of this new VCCV CC type.
[[Sasha]] Maybe you could add that PWs without the CW are already widely deployed, and this is one of the reasons why mandating all PWs use the CW is not realistic.

2.  Requirements Language

   0 1
                    2                   3

                                 Figure 1

   then an alternative VCCV type must be used.[[Sasha]] Is this not a MUST?

4.  FAT PWs

   must be used.[[Sasha]] is it not MUST?

   Whilst the introduction of this additional VCCV CC type increases the
   number of VCCV CC types that the operator needs to manage, it
   addresses the issues with VCCV CC Types 2 and 3 described in
   Section 1, and is a necessary per-requisite [[Sasha]] pre-requisite? of the long term strategy
   of the PALS working group to consolidate the VCCV channel types down
   to only VCCV CC Types 1 and 4.  This consolidation and[[Sasha]]? Migration strategy? Something seems to be missing here.   will be the
   subject of future work by the PALS working group.
[[Sasha]] I am not sure that discussion of the PALS WG long-term strategy in a  standards track document is appropriate. The rationale for introducing VCCV Type 4 is quite clear since it resolves specific issues with VCCV Type 2 and VCCV Type 3.
Maybe it is worth mentioning that, just as VCCV Type 1, VCCV Type 4 can be combined with VCCV Type 3 for segment OAM of MS-PWs.

8.  IANA Considerations

8.2.  LDP Status Code

   Status Code Name Space

9.  Acknowledgments

10.  References

Authors' Addresses

   Thomas D. Nadeau
   lucidvision

   Email: [email-masked]<mailto:[email-masked]>

   Luca Martini
   Cisco Systems

   Email: [email-masked]<mailto:[email-masked]>

   Stewart Bryant
   Cisco Systems

   Email: [email-masked]<mailto:[email-masked]>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 15 Jan 2015 13:57:01 +0000

Than you for looking at this Sasha

I forgot one thing that you picked up on - MS-PW

I have added a new section 5

When using VCCV CC Type 4 for MS-PWs, a PE transmitting the
VCCV packet to a Switching PE (S-PE) MUST set the TTL to
the appropriate value to expire at that S-PE. An S-PE that
supports this specification MUST inspect packets PW packet
that are received as a result of TTL expiry, determine
whether a GAL follows the PW LSE. If a GAL is present
the S-PE then processes the VCCV packet.

An S-PE that does not support this specification would
be expected to reject as malformed a VCCV CC Type 4
packet that was received. This is because the S-PE
would expect the PW LSE to be bottom of stack (the
non FAT case) and for the LSE at bottom of stack not
to be a reserved label (both the FAT and the non-FAT
cases). An S-PE that did not make this reserved label
check would then find that the first nibble following
the label stack was 0x1 and not the expected start
of an IP packet. It would hence be expected to also
reject the packet. This update to the behaviour of
S-PEs is therefore backwards compatible.

On 15/01/2015 10:03, Alexander Vainshtein wrote:
>
> Stewart,
>
> Lots of thanks for a very nice re-write of the draft that, from my 
> POV, resolves all outstanding technical issues raised so far and moved 
> discussion of operational issues ( consolidation of VCCV Types, 
> migration strategy etc.)  out of scope of a clear-cut technical 
> specification.
>
> I have added a couple of minor comments */inline below/ *that 
> hopefully could be useful. Please feel free to use (or not to use) 
> them as you see fit.
>
> Regards,
>
> Sasha
>
>    VCCV CC Type 2 is not supported by*/[[Sasha]] not applicable to? /*
>
yes - done
>
> multi-segment PWs (MS-PWs)
> */[[Sasha]] Maybe you could add that VCCV Type 3 remains mandatory for 
> segment OAM of MS-PWs and that it is  combined with VCCV Type 1 for 
> MS-PWs that use the CW – this is explicitly stated in RFC 6073./*
>
>
I have added

Note that VCCV CC Type 3 remains mandatory for multi-segment PW (MS-PW)
OAM  and it is currently combined with VCCV CC Type 1 for MS-PWs that
use the CW [RFC6073]. This specification enables the combination of
VCCV CC Type 3 with VCCV Type 4 for PWs that do not support the CW
Section5]

> */[[Sasha]] Maybe you could add that PWs without the CW are already 
> widely deployed, and this is one of the reasons why mandating all PWs 
> use the CW is not realistic./*
>
>
It now says:

For reasons of network efficiency and due to hardware constraints it is not
possible to address these issue by mandating that all PWs use the PW CW,
hence the introduction of this new VCCV CC type. PWs without the CW are
widely deployed, and hence mandating that all PWs use the CW is not a
viable way to address this issue.
>    then an alternative VCCV type must be used.*/[[Sasha]] Is this not 
> a MUST? /*
>
yes - and it's twin later
>    Section 1, and is a necessary per-requisite */[[Sasha]] 
> pre-requisite?/*
>
yes
>
> of the long term strategy
>    to only VCCV CC Types 1 and 4.  This consolidation and*/[[Sasha]]? 
> Migration strategy? Something seems to be missing here. /* will be the
> */[[Sasha]] I am not sure that discussion of the PALS WG long-term 
> strategy in a  standards track document is appropriate. The rationale 
> for introducing VCCV Type 4 is quite clear since it resolves specific 
> issues with VCCV Type 2 and VCCV Type 3./*
>
/*I have got rid of the long term strategy text. We can put it back if 
anyone objects
during later stage review.
*/
>
> *//*
>
> */Maybe it is worth mentioning that, just as VCCV Type 1, VCCV Type 4 
> can be combined with VCCV Type 3 for segment OAM of MS-PWs./*
>
/*Already done.*/
> *//*
I will leave it out there for another day to see if there are any more 
comments before I upload it.

- Stewart

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 15 Jan 2015 15:12:04 +0000

Stewart,
Lots of thanks for a prompt response.
The text covering segment OAM for MS-PWs is very clear and, from my POV, fully covers the backward compatibility issues.
As far as I am concerned, the new version can be posted “as is”, but, of course, this is up to you and your co-authors.

Regards,
       Sasha

From: Stewart Bryant [mailto:[email-masked]]
Sent: Thursday, January 15, 2015 3:57 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: Re: [Pals] Candidate draft-ietf-pals-vccv-for-gal-01

Regards,
       Sasha
Email: [email-masked]<mailto:[email-masked]>
Mobile: 054-9266302

   VCCV CC Type 2 is not supported by[[Sasha]] not applicable to?
yes - done

I have added

It now says:

   Whilst the introduction of this additional VCCV CC type increases the
   number of VCCV CC types that the operator needs to manage, it
   addresses the issues with VCCV CC Types 2 and 3 described in
   Section 1, and is a necessary per-requisite [[Sasha]] pre-requisite?
yes

I have got rid of the long term strategy text. We can put it back if anyone objects

Already done.

I will leave it out there for another day to see if there are any more comments before I upload it.

- Stewart