Skip to main content

PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol
RFC 6361

Revision differences

Document history

Date Rev. By Action
2017-05-16
08 (System) Changed document authors from "James Carlson" to "James Carlson, Donald Eastlake"
2015-10-14
08 (System) Notify list changed from pppext-chairs@ietf.org, draft-ietf-pppext-trill-protocol@ietf.org to pppext-chairs@ietf.org
2012-08-22
08 (System) post-migration administrative database adjustment to the No Objection position for Stewart Bryant
2012-08-22
08 (System) post-migration administrative database adjustment to the No Objection position for Pete Resnick
2012-08-22
08 (System) post-migration administrative database adjustment to the No Objection position for Stephen Farrell
2011-08-26
08 Cindy Morgan State changed to RFC Published from RFC Ed Queue.
2011-08-25
08 (System) RFC published
2011-07-01
08 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2011-07-01
08 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2011-06-30
08 (System) IANA Action state changed to Waiting on Authors from In Progress
2011-06-30
08 (System) IANA Action state changed to In Progress from Waiting on Authors
2011-06-30
08 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent.
2011-06-29
08 (System) IANA Action state changed to Waiting on Authors from In Progress
2011-06-29
08 (System) IANA Action state changed to In Progress
2011-06-29
08 Cindy Morgan IESG state changed to Approved-announcement sent
2011-06-29
08 Cindy Morgan IESG has approved the document
2011-06-29
08 Cindy Morgan Closed "Approve" ballot
2011-06-29
08 Cindy Morgan Approval announcement text regenerated
2011-06-29
08 Cindy Morgan Ballot writeup text changed
2011-06-29
08 Jari Arkko Ballot writeup text changed
2011-06-29
08 Jari Arkko State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup.
2011-06-14
08 (System) New version available: draft-ietf-pppext-trill-protocol-08.txt
2011-06-12
08 Stephen Farrell
[Ballot discuss]
The security considerations section of this doesn't appear to specify any
mandatory to implement (MTI) security mechanism. It does say that there are …
[Ballot discuss]
The security considerations section of this doesn't appear to specify any
mandatory to implement (MTI) security mechanism. It does say that there are
lots of possible choices and perhaps one of the referenced specifications
does have some MTI security mechanism that's inherited but that's not
clear to me, and nor, I guess would it be clear to a developer. Can you
pick one of the various security mechanisms and nominate that as MTI
or highlight that something inherited is MTI?
2011-06-12
08 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2011-06-12
08 Jari Arkko Ballot writeup text changed
2011-06-09
08 Cindy Morgan Removed from agenda for telechat
2011-06-09
08 Cindy Morgan State changed to IESG Evaluation::AD Followup from IESG Evaluation.
2011-06-09
08 Pete Resnick
[Ballot comment]
The IESG has determined that this should have been an individual submission, so it will moved to an individual submission and the last …
[Ballot comment]
The IESG has determined that this should have been an individual submission, so it will moved to an individual submission and the last call will be extended to address the issue.
2011-06-09
08 Pete Resnick [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from Discuss
2011-06-09
08 Amy Vezza State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2011-06-09
08 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded
2011-06-09
08 Adrian Farrel
[Ballot comment]
I agree with Ralph, the IANA section does not make it easy for IANA to get this right without having to ask questions. …
[Ballot comment]
I agree with Ralph, the IANA section does not make it easy for IANA to get this right without having to ask questions.

Please name the registry (not the protocol field). I assume you are using the "PPP DLL Protocol Numbers" registry.

Please make it clear whether you expect all values of "XX" to be the same or not.
2011-06-09
08 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2011-06-09
08 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-06-08
08 David Harrington [Ballot Position Update] New position, No Objection, has been recorded
2011-06-08
08 Amanda Baber
IANA understands that, upon approval of this document, there are three
IANA Actions that must be completed.

In the PPP DLL Protocol Numbers registry in …
IANA understands that, upon approval of this document, there are three
IANA Actions that must be completed.

In the PPP DLL Protocol Numbers registry in the Point-to-Point (PPP)
Protocol Field Assignments registry located at:

http://www.iana.org/assignments/ppp-numbers

three new protocol numbers will be registered as follows (each will use
the [ RFC-to-be ] as the reference):

Value (in hex) Protocol Name
TBD-00XX TRILL Network Protocol (TNP)
TBD-40XX TRILL Link State Protocol (TLSP)
TBD-80XX TRILL Network Control Protocol (TNCP)

Where TBD-00xx represents a value where the first two hex digits are
zeros, and where TBD-40xx represents a value where the first two hex
digits are "40" etc.

IANA understands that this is the only action required upon approval for
publication.
2011-06-08
08 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2011-06-08
08 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-06-07
08 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2011-06-07
08 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-06-06
08 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded
2011-06-06
08 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-06-05
08 Pete Resnick
[Ballot discuss]
I have real process concerns with this document.

The PPPEXT charter says, "The group is not expected to create new specifications, and if …
[Ballot discuss]
I have real process concerns with this document.

The PPPEXT charter says, "The group is not expected to create new specifications, and if a need for such work comes up, a recharter is required." No charter changes occurred during the relevant timeframe. (Imagine the worst case scenario: Nobody expects PPPEXT to be producing new standards track documents without a re-charter, so nobody gave any attention to this document because there was no recharter announcement. For context, PPPEXT has not published a document since 2006, and hasn't published a standards track document since 2004.) So this document is, at the very least, outside of the scope of the charter for the WG. That's a straight up process violation.

The IESG writeup says that there is no document shepherd because the (only) WG chair is the author of the document. That's not itself a process violation, but it is a concern. So I went to review the mailing list to see the history. This causes me concern also:

Oct 2009: Chair submits -00, I-D which he authored. Asks for acceptance by WG. Silence. Put on WG page anyway.

May/June 2010: Chair/author submits -01 I-D. One editorial comment.

June 2010: Chair asks if anyone else has read the document. Silence.

Jan 2011: Chair/author submits -02 I-D. Silence for 10 days, at which point chair makes a WGLC. Flurry of messages from 2 participants, 2 other messages, mostly about IS-IS.

February 2011: One message about the draft, unreplied to until mid-March.

March 2011: A few messages from the same two participants as January.

March/April 2011: Chair/author submits -03 I-D. A few messages from the same two participants.

May 2011: Chair/author submits -04 I-D. Three "looks OK to me" comments, one "agree to disagree" comment. Chair/author submits -05 I-D to fix nits. AD does review.

May/June 2011: Chair/author submits -06 I-D to address AD comments. IETF LC. RTG Area review. Another flurry of IS-IS discussion.

June 2011: Chair/author submits -07 I-D removing references to IS-IS including a complete change in a normative requirement in section 2 without any discussion I can find on the mailing list. Document goes to IESG Review.

All of this seems problematic. I would prefer to see this document re-submitted as an individual submission through the AD and not as the product of this WG, mostly due to the charter violation, but also because (a) the chair as author makes this tricky and (b) it did not get significantly more review than it would have as an individual submission anyway. Maybe this is just process twiddling, but the above all looks very bad from a process perspective.
2011-06-05
08 Pete Resnick [Ballot Position Update] New position, Discuss, has been recorded
2011-06-03
08 Stewart Bryant [Ballot comment]
Thank you for addressing my concerns.
2011-06-03
08 Stewart Bryant [Ballot Position Update] Position for Stewart Bryant has been changed to No Objection from Discuss
2011-06-03
08 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Paul Hoffman.
2011-06-03
07 (System) New version available: draft-ietf-pppext-trill-protocol-07.txt
2011-06-03
08 Stewart Bryant
[Ballot discuss]
The RTG-dir review comments :

http://www.ietf.org/mail-archive/web/rtg-dir/current/msg01533.html

Need to be addressed before publication. I understand that the authors have
accepted all the comments and …
[Ballot discuss]
The RTG-dir review comments :

http://www.ietf.org/mail-archive/web/rtg-dir/current/msg01533.html

Need to be addressed before publication. I understand that the authors have
accepted all the comments and will be publishing text that addresses them.
2011-06-03
08 Stewart Bryant [Ballot Position Update] New position, Discuss, has been recorded
2011-06-03
08 Ralph Droms
[Ballot comment]
I think the IANA considerations section needs more information for the creation of the "TNCP Configuration Options" registry; e.g., what is the format …
[Ballot comment]
I think the IANA considerations section needs more information for the creation of the "TNCP Configuration Options" registry; e.g., what is the format of the registry, what information needs to be provided for new registrations?
2011-06-03
08 Ralph Droms
[Ballot discuss]
I think the IANA considerations section needs more information for the creation of the "TNCP Configuration Options" registry; e.g., what is the format …
[Ballot discuss]
I think the IANA considerations section needs more information for the creation of the "TNCP Configuration Options" registry; e.g., what is the format of the registry, what information needs to be provided for new registrations?
2011-06-03
08 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded
2011-06-03
08 Stephen Farrell
[Ballot discuss]
The security considerations section of this doesn't appear to specify any
mandatory to implement (MTI) security mechanism. It does say that there are …
[Ballot discuss]
The security considerations section of this doesn't appear to specify any
mandatory to implement (MTI) security mechanism. It does say that there are
lots of possible choices and perhaps one of the referenced specifications
does have some MTI security mechanism that's inherited but that's not
clear to me, and nor, I guess would it be clear to a developer. Can you
pick one of the various security mechanisms and nominate that as MTI
or highlight that something inherited is MTI?
2011-06-03
08 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded
2011-06-02
08 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko
2011-06-02
08 Jari Arkko Ballot has been issued
2011-06-02
08 Jari Arkko Created "Approve" ballot
2011-06-01
08 Samuel Weiler Request for Last Call review by SECDIR is assigned to Paul Hoffman
2011-06-01
08 Samuel Weiler Request for Last Call review by SECDIR is assigned to Paul Hoffman
2011-06-01
08 Samuel Weiler Assignment of request for Last Call review by SECDIR to Alan DeKok was rejected
2011-05-31
08 Samuel Weiler Request for Last Call review by SECDIR is assigned to Alan DeKok
2011-05-31
08 Samuel Weiler Request for Last Call review by SECDIR is assigned to Alan DeKok
2011-05-25
08 Amy Vezza Last call sent
2011-05-25
08 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <pppext@ietf.org>
Reply-To: ietf@ietf.org
Subject: Last Call: <draft-ietf-pppext-trill-protocol-06.txt> (PPP TRILL Protocol Control Protocol) to Proposed Standard


The IESG has received a request from the Point-to-Point Protocol
Extensions WG (pppext) to consider the following document:
- 'PPP TRILL Protocol Control Protocol'
  <draft-ietf-pppext-trill-protocol-06.txt> 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-06-08. 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


  The Point-to-Point Protocol (PPP) defines a Link Control Protocol
  (LCP) and a method for negotiating the use of multi-protocol traffic
  over point-to-point links.  This document describes PPP support for
  Transparent Interconnection of Lots of Links (TRILL) Protocol,
  allowing direct communication between Routing Bridges (RBridges) via
  PPP links.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pppext-trill-protocol/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pppext-trill-protocol/


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


2011-05-25
08 Jari Arkko Placed on agenda for telechat - 2011-06-09
2011-05-25
08 Jari Arkko Last Call was requested
2011-05-25
08 Jari Arkko State changed to Last Call Requested from AD Evaluation::AD Followup.
2011-05-25
08 Jari Arkko Last Call text changed
2011-05-25
08 (System) Ballot writeup text was added
2011-05-25
08 (System) Last call text was added
2011-05-25
08 (System) Ballot approval text was added
2011-05-25
08 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-05-25
06 (System) New version available: draft-ietf-pppext-trill-protocol-06.txt
2011-05-24
08 Jari Arkko
State changed to AD Evaluation::Revised ID Needed from AD Evaluation.<br>AD review comments:

I have reviewed this draft. I think it is basically in good shape, …
State changed to AD Evaluation::Revised ID Needed from AD Evaluation.<br>AD review comments:

I have reviewed this draft. I think it is basically in good shape, but needs to make a few things more explicit & correct small issues.

I'm expecting a new draft version.

Section 2.1:

> Data
>
>  This field contains data in the same format as for the
>  corresponding LCP Code numbers.
>


Can you clarify what this actually means. It was not clear (to this reader, at least). Is this where the configuration options would be, if some were defined? But if so, what does LCP code numbers have to do with it?

Section 2.2:

> When TNCP is in Opened state, TNP packets MAY be sent by setting the
> PPP Protocol field to hex TBD-00XX (TNP) and placing the TRILL-
> encapsulated data in the PPP Information field.
>
> A summary of this format is provided below:
>
>    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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | V | R |M|Op-Length| Hop Count | Egress (RB2) Nickname        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Ingress (RB1) Nickname        | Inner Destination MAC ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>
> This is identical to the TRILL Ethernet format except that the Outer
> MAC header and Ethertype are replaced by the PPP headers and Protocol
> Field, and the Ethernet FCS is not present.  Both user data and ESADI
> packets are encoded in this format. 

Please add a reference to the document and Section where these fields are defined.

> When TNCP is in Opened state, TLSP packets MAY be sent by setting the
> PPP Protocol field to hex TBD-40XX (TLSP) and placing the IS-IS
> Payload in the PPP Information field. 

TRILL version of IS-IS, I presume. Please provide a reference to the RFC that specifies the IS-IS payload used in this context.

> 1. On a PPP link, TRILL always uses P2P Hellos.  There is no need
>    for TRILL-Hello frames, nor is per-port configuration necessary.
>    P2P Hello messages, per section 9.3 of [6], do not use Neighbor
>    IDs.

Section 9.3 of [6] seems to talk about something else. If you meant [1] it has no Section 9.3. Please clarify.

> If the peer is not an RBridge, then TRILL is not
> possible.

I think you mean that if the peer is not an RBridge then the negotiation in this specification fails and no TRILL is used for the PPP link.

> The encapsulated network layer data, carried in TNP packets, and
> topology information, carried in TLSP packets, MUST NOT be sent
> unless TNCP is in Opened state.  If a TNP or TLSP packet is received
> when TNCP is not in Opened state and LCP is Opened, an implementation
> SHOULD respond using LCP Protocol-Reject.
>
> 3. TRILL PPP Behavior
I did not find a specification for the state machine (open/closed) in the draft. Please specify.

> 4. MTU-probe and MTU-ack messages are not needed on a PPP link.
>    Implementations MUST NOT send MTU-probe and SHOULD NOT reply to
>    these messages.  The MTU computed by LCP SHOULD be used instead.
>    Negotiating an LCP MTU of at least 1524, to allow for an inner
>    Ethernet payload of 1500 octets, is RECOMMENDED.

I think you mean TRILL MTU-probe. Please point to the appropriate section of [1] so that the reader knows for sure which messages you are referring to.
2011-05-24
08 Jari Arkko State changed to AD Evaluation from Publication Requested.
2011-05-24
08 Jari Arkko Ballot writeup text changed
2011-05-24
08 Jari Arkko Ballot writeup text changed
2011-05-23
08 Jari Arkko Ballot writeup text changed
2011-05-23
08 Jari Arkko Ballot writeup text changed
2011-05-23
08 Cindy Morgan
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he …
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

The document shepherd is James Carlson, also the author and WG
chair. The shepherd has reviewed this version of the document
and believes 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?

The document has had review from both key WG participants
(Bill Simpson, Vern Schryver) and from key participants in the
TRILL WG (Jon Hudson, Yizhou Li, Don Eastlake).

The document shepherd has no concerns about the depth or
breadth of the reviews.

(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?

The document shepherd believes that all relevant areas have
reviewed the document and contributed.

(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? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No specific concerns, and no known IPR.

(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?

The document has concurrence from the individuals who have
participated in the discussion.

The vast majority of the working group is typically silent, so
hearing at all from them is unusual, and a positive sign for
the document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise 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 threats are known. The one dissenting issue -- Bill
Simpson's concern about IS-IS System ID in a deployment with
no source of System ID generation -- has been dealt with
successfully by creating a new draft that addresses the
situation for IS-IS and adding a reference in this document.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

The document shepherd has put the current text through all of
those checks, and it satisfies the checker and has no known
additional criteria to meet.

(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? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Yes, it has references split into normative and informative.

There's one downward reference, and it's in the informative
reference list. This is to Bill Simpson's "Generation of
Unique IS-IS System Identifiers" draft.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section is present and describes the
new values introduced by this document. The registries are
clearly identified and the allocation procedures are noted.

(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?

No formal languages are present in the draft.

(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

The Point-to-Point Protocol (PPP) defines a Link Control
Protocol (LCP) and a method for negotiating the use of
multi-protocol traffic over point-to-point links. This
document describes PPP support for Transparent Interconnection
of Lots of Links (TRILL) Protocol, allowing direct
communication between Routing Bridges (RBridges) via PPP
links.

Working Group Summary

There is consensus in the WG to publish this document. There
was some discussion in the working group about IS-IS System
IDs, and the draft reflects the consensus.

Document Quality

There is a long list of vendors implementing TRILL, but at
this point there are none that have announced support for
TRILL over PPP. The PPP extensions described here are
trivial, and the overall system implementation issues have
been discussed in detail with several of the TRILL WG
participants. No significant implementation, deployment, or
interoperability concerns exist.

Significant reviewers include Bill Simpson, Donald Eastlake,
and Vern Schryver.
2011-05-23
08 Cindy Morgan Draft added in state Publication Requested
2011-05-23
08 Cindy Morgan [Note]: 'James Carlson (carlsonj@workingcode.com) is the document shepherd.' added
2011-05-23
05 (System) New version available: draft-ietf-pppext-trill-protocol-05.txt
2011-05-09
04 (System) New version available: draft-ietf-pppext-trill-protocol-04.txt
2011-03-30
03 (System) New version available: draft-ietf-pppext-trill-protocol-03.txt
2011-01-06
02 (System) New version available: draft-ietf-pppext-trill-protocol-02.txt
2010-11-28
08 (System) Document has expired
2010-05-27
01 (System) New version available: draft-ietf-pppext-trill-protocol-01.txt
2009-10-19
00 (System) New version available: draft-ietf-pppext-trill-protocol-00.txt