Subject: [RTG-DIR] RtgDir review: draft-ietf-pppext-trill-protocol-06.txt

From: mike shand <[email-masked]>
Date: Tue, 31 May 2011 14:10:27 +0100

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

---

From: James Carlson <[email-masked]>
Date: Tue, 31 May 2011 10:15:24 -0400

> between RFC 1142 and the ISO standard.

Not a problem; I'll update this and the references to sections of the draft.

> correct, and if so, does it need clarification?

Yes, that's correct, and I'll clarify the text.

> So RFC 1661 requires a silent discard, whereas this draft encourages an

You're right; the intent was to conform with 1661, but this text doesn't
manage to do that.  I'll repair it.

> what is meant is that if TNP packets are sent, they MUST be encoded as

I can recast to avoid the use of "MAY" in this instance.

> re-state every requirement of the base TRILL spec

The text here is a response to previous concerns that the original draft
did not adequately describe the existing IS-IS mechanism for
point-to-point links.  In particular, some reviewers were confused about
the use of Neighbor IDs in Ethernet Hello messages.  To the extent
possible, I'd like to avoid duplicating that sort of text, but I do have
those concerns from other reviewers to deal with.

The text is not at all intended to preclude the use of a Neighbor System
ID as part of RFC 5303 or any other standard IS-IS extension.  I'll try
to recast this.

> submitted as an IS-IS WG document.

Unfortunately, I agree completely.  However, the reviewers in PPPEXT --
particularly Bill Simpson -- rather vehemently did not agree.

He argued at length that this had to be a normative reference, because
there were potential cases where IS-IS over PPP could not be used as
described.  I argued (as I think you do) that this is really a higher
level IS-IS system design issue, and is not peculiar to TRILL, PPP, or
anything in this draft, and should not be solved here.

The (lengthy) thread begins here:

http://www.ietf.org/mail-archive/web/pppext/current/threads.html#00484

The rough compromise we were able to achieve was to mention the
potential issue as a warning to implementors, and reference Bill's draft
as one possible solution as an informative reference only.

Though I agree with you that this issue is clearly out of scope, I'd
very much like to avoid re-opening that kettle of fish by removing the
text.  The outcome of a re-spin might end up being worse.

I could potentially add some text to note that this is not a special
problem with PPP or TRILL, and that it's true of any IS-IS
implementation with only point-to-point links.

(For what it's worth, we had similar problems with the security issues.
 There are no special security issues with the protocol itself, as an
implementation of it relies on existing security mechanisms, but Bill
felt an enumeration was required.)

-- 
James Carlson         42.703N 71.076W         <[email-masked]>

---

From: mike shand <[email-masked]>
Date: Tue, 31 May 2011 16:16:37 +0100

James,
     Thanks.

Regarding the last issue, perhaps one of the causes of confusion here is 
the common belief that the IS-IS spec specifies that the system ID be 
derived from a MAC address. In fact IS-IS is completely silent on HOW 
the system ID is assigned, and it simply states, in clause 7.1.4:-

    Each system in an area must have an unambiguous ID; that is, no two
    systems (IS or ES) in an area may use the same ID value.

and

    Each Level 2 Intermediate system within a routeing domain must have
    an unambiguous value for its ID field; that is, no two level 2 ISs
    in a routeing domain can have the same value in their ID fields.

It states:-

    It is the responsibility of the routeing domain administrative
    authority to enforce the requirements stated below in this clause
    and the rules stated above in 7.1.3.1. These requirements place
    specific constraints on the NSAP addresses and NETs of systems
    deployed in a routeing domain, when these systems operate the
    protocol defined in this International Standard. The protocol
    defined in this International Standard assumes that these
    requirements are met, but has no means to verify compliance with them.

The use of a MAC address to derive the system ID is simply a convenience 
that many vendors have adopted. There may be other ways to derive the 
ID, but their use or otherwise is out of scope of both  the present 
draft, and IS-IS itself.

Note that ISO/IEC 10589 permits the use of a system ID of any length 
between 1 and 8 octets, with the default length being 6 octets. I'm not 
aware of any current implementations using a size other than 6.

     Mike

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 31 May 2011 17:06:56 +0100

On 31/05/2011 16:41, James Carlson wrote:
> Understood.
> For what it's worth, I think that there is a second underlying concern
> here that's directly related to TRILL, and not just IS-IS in general:
> some of the reviewers (correctly, in my opinion) see great value in
> making sure that TRILL is always able to operate in a zero-configuration
> manner.
>
> Given that getting a System ID from a manually-configured parameter
> would negate that goal, they're willing to drive quite a distance out of
> the way in order to make sure that any methods based on manual
> configuration are just never required in practice.
>
> At least that part of the desire is, I think, well-intentioned.
> Unfortunately, the result of it is a strong compulsion to avoid any sort
> of "provided you meet these constraints, this part is entirely up to
> implementors" text, even if that's what the relevant standards allow,
> and even if it's perfectly reasonable.  Therein lay the problem.
>
> Personally, if I were designing a PPP-only system, I'd make sure that
> the hardware design includes a serialization number that can be used to
> construct a proper ID.  I wouldn't bother with any random-number tricks;
> I think they're a bunch of guff.
>
> But that -- overall system design -- is just so far out of scope that
> I'm not really interested in inserting text into any IETF Standards
> Track document to describe it.
>
> I'll try to do some rewording in this area, but given the constraints of
> the consensus we've gotten (and the painful difficulty in getting that
> far), I don't think I can just remove the text entirely.
>

How about saying something like:

ISO/IEC 10589 states that it is the responsibility of the routeing
domain administrative authority to enforce the uniqueness of the
system ID. In cases where a zero configuration system is
supplied the system manufacturer MUST install a suitable
unique identifier at manufacturing time. One way to achieve
this is for the manufacturer to use a unique IEEE MAC address
following the allocation procedures normally used in the
manufacture of an Ethernet interface.

Stewart

---

From: James Carlson <[email-masked]>
Date: Tue, 31 May 2011 11:41:17 -0400

Understood.