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

From: Jari Arkko <[email-masked]>
Date: Tue, 24 May 2011 12:23:59 +0200

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.

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

Also, for the record, as James is both the WG chair and the author, I 
have reviewed the discussion in the mailing list and believe that the 
Working Group has consensus to move the document forward.

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?

Section 2.2:

> 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.
>
> A summary of this format is provided below:
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | V | R |M|Op-Length| Hop Count | Egress (RB2) Nickname         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Ingress (RB1) Nickname        | Inner Destination MAC ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>
> 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.

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

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

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

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

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

> OUI

Expand the acronym

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

Jari

---

From: James Carlson <[email-masked]>
Date: Tue, 24 May 2011 11:12:36 -0400

> it really needs to be out of scope and dealt in ISIS WG, if they think

Thanks!

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

Will do.

> some were defined? But if so, what does LCP code numbers have to do with

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.

> Please add a reference to the document and Section where these fields

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

> that specifies the IS-IS payload used in this context.

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

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

> in this specification fails and no TRILL is used for the PPP link.

Yes; will update.

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

> section of [1] so that the reader knows for sure which messages you are

OK.

> Expand the acronym

OK.

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

OK.

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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 24 May 2011 22:54:14 +0200

James ,

OK.

> Encapsulation."  Will add.

OK

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

OK

> of RFC 1142 rather than the PDF.

Ah, I was.

>   Any suggestions on how to handle the

I have no solution for you... I guess we'll have to live with this issue.

>> in this specification fails and no TRILL is used for the PPP link.

OK

> ... but I can make it explicit.

OK. Sorry for asking you to clarify many similar things. Some of these 
things are obvious to you, but may help other readers.

Jari

---

From: William Allen Simpson <[email-masked]>
Date: Wed, 25 May 2011 12:55:44 -0400

Hey, I told him he needed more references....  Anyway, the way I usually
deal with the section is to use the name, not the numbers.  Numbers can
change during formatting, and people scan for names more easily.