[Isis-wg] Re: 3way draft questions

[Rajesh Saluja]

Tony,
Thanks for bringing it up. I was assuming that these issues will be
reflected in the latest draft. Basically section 3.2,Elements of
Procedure
of the three way handshake draft will change to include the
modifications 
suggested by me. I can work with Dave to update the draft to reflect
these changes. I will wait for Dave to tell us what he thinks.

Best regards,
Rajesh

Tony Przygienda wrote:
> 
> Rajesh Saluja wrote:
> 
> > Dave,
> > I can think of the following sequence while processing the received
> > Point-to-Point Hello  packets:
> > - If  Adjacency exists and the option is present, examine
> > Neighbor System ID and Neighbor Extended Local Circuit ID.
> > If they are present and there is a mismatch,
> > PDU should be discarded.  ( as explained in 3way draft )
> > - 8.2.4.2 a
> > - 8.2.4.2 b
> > - if action is UP or ACCEPT as a result of 8.2.4.2 a and b then
> >     if option is not present
> >                   8.2.4.2c
> >                   8.2.4.2d
> >    otherwise if option is present
> >                   implement state table as given in 3way draft
> > - 8.2.4.2e
> >
> > Also, in the state table,  Other than the previous suggestion ( If Adj State
> > is Down and Received State is Initializing, final  state should be UP ),
> > I am not convinced with one more transition: If Adj State is "Down"
> > and  Received State is "UP", why should the final state be "Down"
> > and not "Initializing".
> >
> > One more thing. I assume that CSNP should be sent whenever the state
> > transitions to "UP" state and CSNP should be processed even if the state
> > is "Initializing" ( otherwise CSNP can get lost ).  It will be nice if this can
> > be  elaborated in the spec.
> >
> 
> did I just get swamped with my e-mail or was there no follow-up (on the list)
> on these issues ? Newest version of the draft (-01) still doesn't seem to reflect any of that
> and any of the things below ?
> 
>     thanks
> 
>     -= tony



> >
> > Dave Katz wrote:
> >
> > >    I am concerned about the case when one endpoint supports this
> > >    and other does not.
> > >    The draft says :"If the system ID of the neighboring system is
> > >    known ( in state Initializing or Up), it shall be reported in the
> > >    Neighbor system ID field, and the neighbor's Extended Local
> > >    Circuit ID shall be reported in the Neighbor's Extended Circuit
> > >    Id field".
> > >    Suppose A supports 3way  ( point-to-point Adjacency State
> > >    option) and B does not. When A receives first Hello from B, it
> > >    will know  about the System ID of B and not about the Extended
> > >    Circuit ID.  What should A do out of following 3 options:
> > >    1. Do not send  this TLV any more since B does not support this.
> > >    2. Send this TLV with adjacency state, Extended Local Circuit ID
> > >    and Neighbor System Id.
> > >    3. Send this TLV with adjacency state and Extended Local Circuit
> > >    ID.
> > >
> > > Yep, you identified a small hole.  The short answer is that it doesn't
> > > matter in the least what it sends since the other guy is ignoring
> > > the fields anyhow.  The spec should be more explicit, however.
> > >
> > >    Is the following ordering correct:
> > >    1. Do PDU acceptance tests.
> > >    2. If the option is present, implement state table as described in 3way
> > >    draft.
> > >    3. If option not present or if the state as result of 2 is "UP" do the
> > >    following:
> > >    -  Check for Area Address Mismatch  and implement state tables  as
> > >          described in the spec ( table 5,6 or 7 ) ( 8.2.4.2.a  and b)
> > >    - If the action is "UP" or "Accept", calculate circuitID status. ( 8.2.4.2 c)
> > >    - If the action is "Accept" and circuit ID status is different, delete
> > >        adjacency ( 8.2.4.2.d)
> > >    - If action is "UP" or "Accept", update other fields.
> > >
> > >    My questions on this  ordering are:
> > >    1. If the result of item 2 is "INITIALIZING", you hear Hello from a neighbor
> > >    for the first time, isn't it necessary to check for 8.2.4.2 a and b? The 3way
> > >    draft suggests to do nothing but I think that 8.2.4.2 should be processed.
> > >
> > >    2. Even if result of item 2 is "UP", it is possible that adjacency can fail
> > >    because
> > >    of 8.2.4.2 a or b. Then why should you first look into TLV and then verify the
> > >
> > >    header?  ( I mean Area Address mismatch, Circuit Type )
> > >
> > > I see what you're getting at, I think.  If there is a level or area address
> > > mismatch, it will take a couple of packets to detect this, and an adjacency
> > > will be created and then destroyed.  Yeah, I guess I need to revisit this
> > > verbiage (which of course bears no resemblance to any code in two different
> > > implementations, which is why it's slightly broken...)
> > >
> > >    3. Since  option processing will take care of circuit ID changes, why should
> > >    you
> > >    again process 8.2.4.2 c and d?
> > >
> > > This is indeed redundant but I was trying not to take apart the existing
> > > verbiage too much.  Obviously I need to rework this.
> > >
> > >    I have one more question on 3way draft state table:
> > >    If Adj State is Down and Received State is "Initializing", why should the new
> > >    state be "Initializing" and not "Up" because  receiving state  "Initializing"
> > >    implies that the receiver has heard Hello from this system.
> > >
> > > It is this way because I copped it straight from NLSP four years ago and
> > > didn't think about it too much.  I think you're right, it's a bit more
> > > conservative than it needs to be (and turns it into a four way handshake).
> > > I'll convince myself that it won't break anything, and then change it.
> > >
> > > --Dave
> 
> --
>         thanks
> 
>         --- tony

-- 

-------------------------------------------------------------
Rajesh Saluja
Nortel Networks Inc 600 Technology Park Billerica, MA  01821
Ph: (978) 288-7791      Fax: (978) 670-8760
--------------------------------------------------------------