Re: AD review of draft-ietf-pppext-trill-protocol

James ,

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

OK.

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

OK

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

OK

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

Ah, I was.

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

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

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

OK

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

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

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

Jari

_______________________________________________
Pppext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pppext