MPLS Transport Profile (MPLS-TP) Identifiers
draft-ietf-mpls-tp-identifiers-07

[Ballot discuss]
The security considerations text should IMO address
the consequences of identifiers that can be guessed or
derived from public values (such as ASNs). I don't think
that needs a huge amount of text, but I do think its
needed to alert implementers/deployers to some of the
possible consequences of e.g. starting at 1 and counting
up.

[Ballot discuss]
In Section 4:

  Within the context of a particular node, we call the identifier
  associated with an interface an Interface Number (IF_Num).  The
  IF_Num is a 32-bit unsigned integer assigned by the operator and MUST
  be unique within the scope of a Node_ID.  The IF_Num value 0 has
  special meaning (see Section 7.4, MIP Identifiers) and MUST NOT be
  used to identify an MPLS-TP interface.

There is clash in name and a partial superposition in semantics with the ifNumber and ifIndex objects defined in RFC 2863.

RFC 2863 defines ifNumber as "The number of network interfaces (regardless of their current state) present on this system."

RFC 2863 defines ifIndex as "A unique value, greater than zero, for each interface or interface sub-layer in the managed system."

This draft should mention that IF_Num has no relation with the ifNum object defined in RFC 2863, and that no mapping is mandated between this documents IF_Num and ifIndex in RFC 2863.

(there could be such a mapping and maybe some operators will use the same value, but we need not assume it's required)

[Ballot discuss]
Thanks for writing this draft. I would like to recommend its
publication as an RFC, but before that I had two question marks that
I'd like to understand better. It may be that I'm just missing some
background information, I'm not necessarily saying that there is a problem in the
document.

I would like to talk about the choice of "::" as a separator. The
document does not make it clear if this only a syntactic construct in
this document or also something that might appear in configuration
interfaces, debug outputs, or even on the wire in textual messages. If
so, are there any cases where a colon or double colon of an IPv6
address might lead to am ambigious representation?

Secondly, Section 5.3 maps tunnel endpoint addresses to node
identifiers. I'd like to discuss when such mappings are possible, as
it certainly sees that in some contexts (e.g., signaling) you actually
need an address, not an identifier, particularly when for IPv6 the
node identifiers are not addresses.

[Ballot discuss]
#1) Is there a reason there's not a normative reference for OAM in the intro: "OAM, as defined in [RFC6291], functions"?  Should the phrase "MPLS-TP management and OAM functions" be changed to match the recommendations in 6291 by using the phrase "MPLS-TP OAM and Management (O&M) function"

#2) I'm not so sure I buy the "this is a framework so we're not going to say anything" argument in the security considerations. The abstract and intro say that this document defines identifiers and it's telling operators how to make them (see 1st comment).  If you're going to do that then I think you need to say something about how the identifier's uniqueness is guaranteed and maybe a couple of generic things about might happen if they're not unique.  I don't think you need to say a lot, but something along the lines of:

Uniqueness of the identifiers from this document is guaranteed by the assigner (e.g., a Global_ID is unique based on the assignment of ASNs from IANA and both a Node_ID and a IF_Num are unique based on the assignment by an operator).  Failure by an assigner to use unique values for the identifier will [insert words - an example: result in the end of the world as we know it because an operator will have unleashed the zombie apocalypse].

#3) If this is really a framework, should it be a standards track doc?  Maybe it should be a BCP because you're telling operators how to identify their stuff?

[Ballot discuss]
A number of IETF Last Call comments need to be addressed in a new revision...

=====

AD review

Add the following section:

7.2.1.  MPLS-TP Section MEP_IDs

  IP compatible MEP_IDs for MPLS-TP are simply the IF_IDs of each end
  of the section.  For example, for a section whose MEG_ID is

      A1-IF_ID::Z9-IF_ID

  the Section MEP_ID at A1 would be

      A1-IF_ID

  and the Section MEP_ID at Z9 would be

      Z9-IF_ID.

  Where the Section MEP_ID needs to be globally unique, this is
  accomplished by using globally unique Node_IDs as defined above.
  Thus a globally unique Section MEP_ID becomes

      Global_ID::IF_ID.

---

Section 1.3

OLD
The notation does define a preferred ordering of the fields.
NEW
The notation defines a preferred ordering of the fields.
END

---

Section 1.3

OLD
Z9 is used to indicated the
NEW
Z9 is used to indicate the
END

=====

Greg Mirsky

I have a question to new Section MEP-ID. In MPLS-TP a Section can be either physical link or logical, section layer LSP, link. I think that listed Section MEP_ID addresses the former case. Would Section MEP-ID in the latter case be the LSP MEP-ID? I think that both cases must be identified and their Section MEP-IDs listed.

=====

Alessandro D'Alessandro

Sect 7:
  A maintenance point is either a Maintenance
  Entity Group End-point (MEP) or a Maintenance Entity Group
  Intermediate Point (MIP). Maintenance points are uniquely associated
  with a MEG.

This is true for MEP. MIP, as currently defined, are not uniquely associated with a MEG.

---

Sec 7.4
  At a cross-connect point, in order to automatically generate MIP_IDs
  for MPLS-TP, we simply use the IF_IDs of the two interfaces which are
  cross-connected

The above given definition refers to "intermediate node". It should be extended to cover also the case of "end nodes" because MIPs could be located in such nodes when per-interface MEPs model is applied (e.g. draft-ietf-mpls-tp-oam-framework and Yoshinori's contributions) a reference to sect 4, where IF_ID are defined, should be added

=====

ITU-T Question 12/15

https://datatracker.ietf.org/documents/LIAISON/file1237.pdf

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (MPLS-TP Identifiers) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'MPLS-TP Identifiers'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-07-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This document specifies an initial set of identifiers to be used in
  the Transport Profile of Multiprotocol Label Switching (MPLS-TP).
  The MPLS-TP requirements (RFC 5654) require that the elements and
  objects in an MPLS-TP environment are able to be configured and
  managed without a control plane.  In such an environment many
  conventions for defining identifiers are possible.  This document
  defines identifiers for MPLS-TP management and OAM functions suitable
  to IP/MPLS conventions.

  This document is a product of a joint Internet Engineering Task Force
  (IETF) / International Telecommunication Union Telecommunication
  Standardization Sector (ITU-T) effort to include an MPLS Transport
  Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge
  (PWE3) architectures to support the capabilities and functionalities
  of a packet transport network as defined by the ITU-T.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-identifiers/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-identifiers/


No IPR declarations have been submitted directly on this I-D.

PROTO writeup for draft-ietf-mpls-tp-identifiers-06

  (1.a) Who is the Document Shepherd for this document?

Ross Callon is the document shepherd for draft-ietf-mpls-tp-identifiers. He has read this version of the document and believes that it is ready for forwarding to the IESG for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

draft-ietf-mpls-tp-identifiers has had extensive review both within the MPLS WG and in ITU-T, and has been updated based on the many comments received. The disposition of each comment has been documented in email to the MPLS WG.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No concerns.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of?

No concerns.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

This document defines a format for MPLS-TP LSP Identifiers based on global node IDs (ie, IP addresses) for both ends of the LSP. Previously the draft also defined a format for MPLS-TP identifiers based on ICCs (ITU Carrier Codes). There was a request from a few people to allow use of global node IDs for one end of the LSP and ICCs based IDs for the other end of the same LSP. After extensive discussion on the MPLS WG email list, there was a clear consensus to progress the document without support for mixed use. Subsequently technical problems with the ICC format were discovered.  Due to the anticipated delay in getting these resolved, the ICC based identifiers were removed from the document. Both LSP Identifiers based on ICC formats, and the possible use of mixed identifiers (with one end of the LSP identified using ICCs and the other end identified using global IDs) have been left for further study.

Other than this issue there was little controversy, and the document is needed for important ongoing work on MPLS-TP.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarize the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No appeal threatened.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits?

Yes. The document passes ID nits with no errors and no warnings.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state?

References split appropriately. All normative references are to standards track RFCs, except for RFC2119 which is a BCP.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document?

IANA section exists. There are no IANA actions for this document.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

Not Applicable.  There is a notation format defined for specifying identifiers, which is both straightforward and clearly defined in the documents in section 1.3 “Notational Conventions”.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

  Technical Summary

      This document specifies identifiers for MPLS-TP objects.  Included are identifiers
      which are compatible with existing IP, MPLS, GMPLS, and Pseudowire definitions.

Working Group Summary

      This document defines a format for MPLS-TP LSP Identifiers based on global node IDs
      (ie, IP addresses) for both ends of the LSP. Previously the draft also defined a format
      for MPLS-TP identifiers based on ICCs (ITU Carrier Codes). There was a request from a
      few people to allow use of global node IDs for one end of the LSP and ICCs based IDs
      for the other end of the same LSP. After extensive discussion on the MPLS WG email
      list, there was a clear consensus to progress the document without support for mixed
      use. Subsequently technical problems with the ICC format were discovered.  Due to the
      anticipated delay in getting these resolved, the ICC based identifiers were removed
      from the document. Both LSP Identifiers based on ICC formats, and the possible use of
      mixed identifiers (with one end of the LSP identified using ICCs and the other end
      identified using global IDs) have been left for further study.

      Other than this issue there was little controversy, and the document is needed for
      important ongoing work on MPLS-TP.

Document Quality
 
      The document has been extensively reviewed and is an important basis for ongoing
      work on MPLS-TP. Many of the identifiers using standard IETF addressing fields are
      already implemented by default in MPLS and pseudowire systems. A number of
      vendors are building MPLS-TP solutions and will include identifier formats described
      in this document.