Re: [Pppext] AD review of draft-ietf-pppext-trill-protocol

[James Carlson <[e-mail]>]

On 05/24/11 06:23, Jari Arkko wrote:
> 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. For
> what it is worth, I'm happy with the resolution of the system ID issue;
> it really needs to be out of scope and dealt in ISIS WG, if they think
> its an issue.

Thanks!

> I'm expecting a new draft version. Then I can start an IETF Last Call.

Will do.

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

It means that if the Code number is set to 01, then this document
expects data in the Data field that's formatted in exactly the same way
as you would also expect for an LCP Configure-Request.  If it's set to
02, then it's formatted in the same way as LCP Configure-Ack.  And so on.

Of course, the point is somewhat moot in that there are no options as
yet.  But when (and if) they're defined, we're saying that this is the
proper format.

The reason this text is here is that implementations based on this draft
that receive unexpected options will (a) need to be able to send
properly-formatted Configure-Reject messages and (b) likely need to be
able to write appropriate debug log messages concerning the event.
Those things require an understanding of the format.  (Additionally,
network debugging tools such as 'ethereal' should be able to display the
format without necessarily understanding the options.)

I agree that the wording is unclear; I'll update it.

> Section 2.2:
> 
>> 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.

This would be reference [1] in section 4.1, "Ethernet Data
Encapsulation."  Will add.

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

Yes.  This is section 4.2.3, "TRILL IS-IS Frames."

>> 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
>> <http://tools.ietf.org/html/draft-ietf-pppext-trill-protocol-05#ref-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.

Section 9.3 of RFC 1142 is entitled "Point-to-Point IS to IS Hello PDU."
 That is the intended reference.

At a guess, you might be looking at the weirdly-formatted text version
of RFC 1142 rather than the PDF.  Any suggestions on how to handle the
odd differences in section numbering between these two formats?  My
understanding is that most people look at the PDF because it's somewhat
legible, which is a feature the text version sadly lacks.

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

Yes; will update.

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

It uses the LCP state machine.  This was implied by:

   Link State Protocol (TLSP) on a PPP link.  TNCP uses the same option
   negotiation mechanism as LCP.

... but I can make it explicit.

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

OK.

>> OUI
> 
> Expand the acronym

OK.

>> Resolving that issue is outside the
>> scope of this document, but see [8
>> <http://tools.ietf.org/html/draft-ietf-pppext-trill-protocol-05#ref-8>] for
>> one mechanism that should
>> be considered in this situation.
>>   
> 
> I would make this even clearer -- there's no official status yet for
> [8]. I'd use this:
> 
> Resolving that issue is outside the
> scope of this document. Solutions
> to this issue may be defined elsewhere in the future, see
> [8] for an example.

OK.

-- 
James Carlson         42.703N 71.076W         <[e-mail]>