Hello,
I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review, and 
sometimes on special request. The purpose of the review is to provide 
assistance to the Routing ADs. For more information about the Routing 
Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-pppext-trill-protocol-06.txt
Reviewer: Mike Shand
Review Date: 31 May 2011
IETF LC End Date: 8 June 2011
Intended Status: Proposed Standard


Summary:

I have some minor concerns about this document that I think should be 
resolved before publication.


Comments:
The reference to RFC 1142 is misleading and dangerous. RFC 1142 is a 
poor copy of a pre-standard version of IS-IS ( ISO DP 10589, as opposed 
to ISO/IEC 10589 version 2). There are significant technical differences 
between RFC 1142 and the ISO standard.

Note that, for this reason, it is proposed that RFC 1142  be 
re-classified as historic.
(see http://tools.ietf.org/html/draft-shand-rfc1142-to-historic-01).

It should never be used as a reference for IS-IS.

The correct reference for ISO/IEC 10589 is :-

International Organization for Standardization,
"Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473)",
ISO/IEC 10589:2002, Second Edition, Nov 2002.


Consequently some references to sections in this draft need to be modified,
as noted below.


Major Issues:
No major issues found.

Minor Issues:

1) Section 2 para 3 last sentence.

says "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."

I assume that such a packet MUST be discarded, but that in addition the 
implementation SHOULD respond with a LCP Protocol-Reject. Is this 
correct, and if so, does it need clarification?

I note that RFC 1661 explicitly states
"Any supported network-layer protocol packets received when the 
corresponding NCP is not in the Opened state MUST be silently discarded."
So RFC 1661 requires a silent discard, whereas this draft encourages an 
explicit reject.

2) Section 2.2 para 1

says "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."

I think this is the wrong use of "MAY". MAY implies that TNP packets may 
be sent as described here, or by some other undisclosed encoding. Surely 
what is meant is that if TNP packets are sent, they MUST be encoded as 
described here.

Similarly in Section 2.3. concerning TLSP packets.


3) Section 3, bullet 1.

The text:-

per "Point-to-Point IS to IS Hello PDU" (section 9.3 of [6] in PDF, 9.7 
in text), do not use Neighbor IDs."

should simply refer to section 9.7 in ISO/IEC 10589 second edition.

4) In addition, it may be helpful here to draw attention to the 
requirement in [1] 4.2.4.1 that the IS-IS three way hand shake MUST be 
used on such links. In particular, the reference (in the present draft) 
in the last sentence of section 2.3 to "only an arbitrary circuit ID", 
rather than an "extended circuit ID" as described in RFC 5303, and the 
clause "do not use Neighbor IDs" at the end of section 3 bullet 1, may 
give the erroneous impression that RFC 5303, (and the  "Neighbor System 
ID", and "Neighbor Extended Circuit ID" defined therein) is not mandated 
for PPP links.

That said, I appreciate that this draft should not unnecessarily 
re-state every requirement of the base TRILL spec

5) Section 3, bullet 3

The discussion of the issue that there may be no MAC address as a
possible source for a unique system ID is out of place
in this draft. It is not a direct consequence of using either PPP or TRILL.
It is a situation which may arise in any usage of IS-IS where there is 
no MAC
address available to source the system ID. It seems arbitrary to
reference [8] in this context, particularly since [8] has not been 
submitted as an IS-IS WG document.




     Thanks,

     Mike