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

From: James Carlson <[email-masked]>
Date: Tue, 31 May 2011 12:52:52 -0400

Stewart Bryant wrote:
> 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.

It lacks the reference to Bill's draft, which I understood to be a
minimal requirement of the agreement we'd reached.

I expect that to provoke trouble, but I'll try passing it by the PPPEXT
list to see what happens.

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 02 Jun 2011 19:41:36 +0300

James, Mike, et al,

Thank you Mike for the review!

Yes, we absolutely have to update the document for the right reference.

Re: systemID issue. I'd love to throw that text out. In my AD review I 
already attempted to make it clear that Simpson's draft is just one 
proposal. If you and perhaps others agree that the systemID discussion 
belongs entirely in ISIS WG then I would be very happy to say remove all 
that text.

James:

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

Really? IIRC it was only Simpson, was it others as well? We don't need 
unanimous agreement...

Jari

> mike shand wrote:
>   
>> 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.
>>     
>
> Not a problem; I'll update this and the references to sections of the draft.
>
>   
>> 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?
>>     
>
> Yes, that's correct, and I'll clarify the text.
>
>   
>> 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.
>>     
>
> You're right; the intent was to conform with 1661, but this text doesn't
> manage to do that.  I'll repair it.
>
>   
>> 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.
>>     
>
> I can recast to avoid the use of "MAY" in this instance.
>
>   
>> 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
>>     
>
> 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.
>
>   
>> 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.
>>     
>
> 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.)
>
>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 02 Jun 2011 19:43:14 +0300

>> manufacture of an Ethernet interface.

I like this.

> list to see what happens.

I'm not sure it was others than Bill. His opinion may be in the rough.

Jari