Transparent Interconnection of Lots of Links
charter-ietf-trill-05

After discussion with Ted and Stewart (as the AD for PWE3), I would like to tighten the text as follows:

OLD
(4) Specify protocols for TRILL over pseudowires and TRILL over IP tunnels, for example to connect branch office TRILL switches to a central TRILL campus over the Internet.
NEW
(4) Specify protocols for TRILL over pseudowires using existing Pseudowire Emulation End-to-End (PWE3) standards, for example to connect branch office TRILL switches to a central TRILL campus over the Internet.

A terminology comment:

  (1) Following on from the TRILL OAM requirements (RFC 6905), specify a
  framework and specific protocols for the handling of Operations,
  Administration, and Maintenance (OAM) in networks using TRILL,
  focusing on fault management and performance and taking into
  consideration existing OAM mechanisms that might apply to TRILL.

I have a concern with the terms OAM framework and OAM protocols.
OAM is not about extra protocols. This is about in band, data plane management. 
Btw, this is in line with RFC6905 (from what I call recall from the table of content).

RFC 6291 and RFC 6905 speak about "OAM functions".

Proposal:
  (1) Following on from the TRILL Administration, and Maintenance (OAM)
  requirements (RFC 6905), specify OAM functions for TRILL data plane 
  management, focusing on fault management and performance and taking
  into consideration existing OAM mechanisms that might apply to TRILL.

Not really a block, but please correct this, or let's discuss it.

Following discussions with the IESG, I will ask the community during external review.

======= 

I would like to understand the long term strategy for the TRILL WG.

Each version of the TRILL charter takes the protocol closer to a full function network layer mirroring all of the functions that we find in IP and MPLS. If the IETF has embarked on the strategy of developing an alternate full function network layer with open eyes, then I am fine with us continuing, but I think it is worthwhile consciously establishing that this is our goal.

It also seems to me that at some stage we need to have some discussions with the IEEE about whether it is in the best interests of the industry to continue this work in IETF, or whether the industry would be better served by the transfer all or part of the project to them.

A TRILL re-charter is a watershed moment to consider these issues, and the purpose of this block it to cause the IESG to pause for a moment and consciously review the issues above.

If it is the view of the IESG that it is in the best interests of the industry for TRILL to continue on its current trajectory I will withdraw the block.