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

["Andrew G. Malis" <[e-mail]>]

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 <[e-mail]> wrote:

>  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: [e-mail]
>
>
>    Luca Martini
>    Cisco Systems
>
>    Email: [e-mail]
>
>
>    Stewart Bryant
>    Cisco Systems
>
>    Email: [e-mail]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Nadeau, et al.            Expires July 18, 2015                 [Page 7]
>
>
> _______________________________________________
> Pals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pals
>
>