Re: [Isis-wg] AD review of draft-ietf-isis-mi-bis-01

[Alia Atlas <[e-mail]>]

Hi Les,

On Fri, Mar 17, 2017 at 1:57 PM, Les Ginsberg (ginsberg) <[e-mail]
> wrote:

> Alia –
>
>
>
> Thanx for meticulous review.
>
> Inline.
>
>
>
> *From:* Alia Atlas [mailto:[e-mail]]
> *Sent:* Friday, March 17, 2017 8:47 AM
> *To:* [e-mail]; [e-mail]
> *Subject:* AD review of draft-ietf-isis-mi-bis-01
>
>
>
> As is customary, I have done my AD review of draft-ietf-isis-mi-bis-01.
> First, I would like to thank the authors - Les, Stefano, and Wim - for
> their work on this document.
>
>
>
> I do have a few minor issues that need to be fixed ASAP.   I will,
> however, go ahead and issue a 3 week IETF Last Call for it so that, if the
> authors act promptly, it can be on the April 13 telechat.
>
>
>
>
>
> 1) This draft pretty clearly should obsolete RFC 6822, but the header
> claims to merely
>
> update it.
>
>
>
> *[Les:] OK*
>
>
>
>  2) Sec 2.6.2: " Point-to-point adjacency setup MUST be done through the
> use of the
>          three-way handshaking procedure as defined in [RFC5303] in order
> to
>          prevent a non-MI capable neighbor from bringing up an adjacency
>          prematurely based on reception of an IIH with an IID-TLV for a
> non-
>          zero instance."
>
>      While obviously the 3-way handshake in RFC5303 is fine, given that
> different MAC addresses are used, I don't see how a non-MI capable neighbor
> would receive and process an IIH with an IID-TLV where IID != 0.
>
>
>
> *[Les:] Section 2.6.2 is only talking about true pt-pt media – hence MAC
> multicast addresses are not relevant. In Section 2.6.1 we discuss the case
> of operating in Pt-Pt mode on a broadcast circuit:*
>
>
>
> *“When operating in point-to-point mode on a broadcast circuit*
>
> *   [RFC5309]…”*
>

Thanks - you are completely correct.


 3) In Appendix A:" Clarification that the IID-TLV is only included in
> Pt-Pt IIHs
>
>    associated with non-zero instances has been added.  This addresses
>    Errata ID #4519."
>
>    In Sec 2.6.2, it says "The presence or absence of the IID-TLV in an IIH
> indicates that the
>    neighbor does or does not support this extension, respectively.
>    Therefore, all IIHs sent on a point-to-point circuit by an MI-RTR
>    MUST include an IID-TLV.  This includes IIHs associated with IID #0."
> which is a direct
>
>    contradiction and needed since the IID-TLV is used as a capability
> indication.  The
>
>    simplest solution is to remove the claim from the Appendix.
>
> *[Les:] Again, you are confusing Pt-Pt media with Pt-Pt operation on a
> Broadcast media. Errata 4519 is concerned with Pt-Pt operation on a LAN –
> and some modest clarifications in Section 2.6.1 were made to more
> completely cover the latter case.*
>
> *In the Pt-Pt operation on a LAN case it IS illegal to send IID-TLV in
> hellos for the zero instance – which Section 2.6.1 explicitly states.*
>
>
>
> *Perhaps the Appendix should say:*
>
>
>
> *“Clarification that when operating in point-to-point mode on a broadcast
> circuit the IID-TLV is only included in Pt-Pt IIHs*
>
> *   associated with non-zero instances has been added. ..”*
>
>
>
> *Will this address your concern?*
>

Yes, I didn't go and look up Errata ID #4519 to catch the context of
pt-to-pt on broadcast only.   That would make it more of a nit than a minor
issue, of course.

This all does imply that:
   a) IIH with IID=0 is a capability advertisement for pt-to-pt links but
not pt-to-pt on broadcast.
   b) It is never ok (discarded by receiver) to send an IIH with IID=0 on a
pt-to-pt on broadcast.
   c) The capability indicator for being an MI-RTR on a pt-to-pt on
broadcast link is whether or not the ALLL1MI-IS or ALLL2MI-IS is listened
to or sent on.

I know there is real code and deployments behind this - but that's a bit
confusing for trouble-shooting & it would be nice to have it more clearly
articulated.


> 4) In the IANA considerations, the references should be updated to point
> to this document, and most particularly if it obsoletes RFC 6822.
>
>
>
> *[Les:] Agreed. I did not think I had to state that – I assumed IANA would
> just do that – but I am happy to add a line in IANA section stating that
> all references to RFC 6822 should be updated to point to this document.*
>

Yes - we need to do that.


Incidentally, on another reread (checking the above issues) is there a
reason that
"The destination multicast address is one of the two new addresses
 and the PDU contains an IID-TLV with a zero value for the IID or
 has no IID-TLV."

doesn't simply name the addresses (ALLL1MI-IS or ALLL2MI-IS)?  I think
that'd be clearer - but this is definitely nit.



> *Let me know if the above changes will suffice and I will spin a new
> version.*
>

Sounds good.

Thanks,
Alia



> *   Les*
>
>
>
> Regards,
>
> Alia
>