[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4)
Ramesh,
Please see inline.
Thanks,
Jonathan
> -----Original Message-----
> From: S Ramesh [mailto:rashanmu@npd.hcltech.com]
> Sent: Wednesday, November 21, 2001 9:50 PM
> To: Jonathan Lang
> Cc: 'George Young'; ccamp@ops.ietf.org
> Subject: Re: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4)
>
>
> Hi Jonathan,
>
> As editorially speaking since Test/Pasv Test state is sending or receiving
Test
> messages alone event 2:ecdcDown is not needed in the state.
agreed.
> But in Test/Pasv
> Test state event 7:evTestfail and 8:evPsvTestFail are possible. Actually
these
> two events need a control channel in order to receive a TestStatusFailure
> message or EndVerify message in the first case ( Test sate ) and to
receive a
> EndVerify in the later case also ( PasvTest state ). So a control channel
is
> needed in these states even we send or receive a Test message alone ( as
per
> editorial definition of these states ). If this is the case then event
> 2:evCCdown is possible in these two states and hence the resulting state
will be
> down.
new definitions for events 7 & 8 should cover this. (see email exchange
below)
>
> Also Jonathan as i already said 14.evdcDown is possible in Test/Pasv Test
state.
Why wouldn't this be covered in event 7 & 8?
>
> Thanks,
> Ramesh
>
>
>
>
>
> Jonathan Lang wrote:
>
> > George,
> > Event 2 can be removed. We will need to reword events 7
> & 8. My proposal
> > below:
> >
> > 7 :evTestFail: Link verification returned negative results.
> > This could be because (a) a TestStatusFailure message was
> received, or (b)
> > the
> > Verification procedure has ended without receiving a
> > TestStatusSuccess or TestStatusFailure message for the data link.
> >
> > 8 :evPsvTestFail:Link verification returned negative results. This
> > indicates that a Test message was not detected and either (a) the
> > VerifyDeadInterval has expired or (b) the Verification
> > procedure has ended and the VerifyDeadInterval has not yet expired.
> >
> > -Jonathan
> >
> > > -----Original Message-----
> > > From: George Young [mailto:george.young@meriton.com]
> > > Sent: Wednesday, November 21, 2001 5:41 AM
> > > To: Jonathan Lang
> > > Cc: ccamp@ops.ietf.org
> > > Subject: RE: Two week Last Call on LMP (Sections 12.3.3
> and 12.3.4)
> > >
> > >
> > > Hello Jonathan,
> > >
> > > See below:
> > >
> > > Regards,
> > > George R. Young
> > > Meriton Networks Inc.
> > > 329 March Rd., Kanata, ON, Canada, K2K 2E1
> > > phone: +1 613-270-9279 Ext 287
> > > fax: +1 613-270-9268
> > >
> > >
> > > >-----Original Message-----
> > > >From: Jonathan Lang [mailto:jplang@calient.net]
> > > >Sent: Tuesday, November 20, 2001 11:49 AM
> > > >To: George Young
> > > >Cc: ccamp@ops.ietf.org
> > > >Subject: RE: Two week Last Call on LMP (Sections 12.3.3
> and 12.3.4)
> > > >
> > > >
> > > >George,
> > > > Please see inline.
> > > >
> > > >Thanks,
> > > >Jonathan
> > > >
> > > >> -----Original Message-----
> > > >> From: George Young [mailto:george.young@meriton.com]
> > > >> Sent: Tuesday, November 20, 2001 8:34 AM
> > > >> To: Jonathan Lang
> > > >> Cc: ccamp@ops.ietf.org
> > > >> Subject: RE: Two week Last Call on LMP (Sections
> 12.3.3 and 12.3.4)
> > > >>
> > > >>
> > > >> Hello Jonathan,
> > > >>
> > > >> Comments/question below. Also please note, edgeFlow has
> > > >> changed its name
> > > >> to Meriton Networks Inc., and as a result the email address
> > > >changes to
> > > >> george.young@meriton.com.
> > > >>
> > > >> Regards,
> > > >> George R. Young
> > > >> Meriton Networks Inc.
> > > >> 329 March Rd., Kanata, ON, Canada, K2K 2E1
> > > >> phone: +1 613-270-9279 Ext 287
> > > >> fax: +1 613-270-9268
> > > >>
> > > >>
> > > >> >-----Original Message-----
> > > >> >From: Jonathan Lang [mailto:jplang@calient.net]
> > > >> >Sent: Monday, November 19, 2001 5:21 PM
> > > >> >To: 'S Ramesh'; George Young
> > > >> >Cc: ccamp@ops.ietf.org; Jonathan Lang
> > > >> >Subject: RE: Two week Last Call on LMP (Sections 12.3.3
> > > and 12.3.4)
> > > >> >
> > > >> >
> > > >> >Ramesh,
> > > >> > Please see inline.
> > > >> >
> > > >> >Thanks,
> > > >> >Jonathan
> > > >> >
> > > >> >> -----Original Message-----
> > > >> >> From: S Ramesh [mailto:rashanmu@npd.hcltech.com]
> > > >> >> Sent: Thursday, November 15, 2001 11:15 PM
> > > >> >> To: George Young
> > > >> >> Cc: ccamp@ops.ietf.org
> > > >> >> Subject: Re: Two week Last Call on LMP (Sections 12.3.3
> > > >and 12.3.4)
> > > >> >>
> > > >> >>
> > > >> >> Hi Young,
> > > >> >>
> > > >> >> 1. Yeah events 1.evCCup and 2.evCCDown has to be
> added in the
> > > >> >> Data Link FSM's in the down state also. Agreed.
> > > >> >I would actually propose that we remove the degraded state
> > > >> >altogether from
> > > >> >the data link fsms. This is already captured at the TE
> > > link level.
> > > >> >Comments?
> > > >>
> > > >> If I understand your response to messrs Ramesh and moi,
> > > transition 10
> > > >> should be retained from Deg to Down.
> > > >> If you then remove the Deg state, implying that in the
> > > Up/Alloc state
> > > >> you may not have a control channel, where would
> transition 10 go?
> > > >>
> > > >> Transition 13 'fault localization' seems to need a
> control channel.
> > > >> Without the Deg state, how would you represent the idea that
> > > >sometimes
> > > >> transition 13 can't take place?
> > > >What I'm proposing is that we decouple the notion of a control
> > > >channel with
> > > >the data link FSMs. As Ramesh said in an email, some of these
> > > >events can be
> > > >generated through management interface also. For active data
> > > >link, the FSM
> > > >would be:
> > > >
> > > > +------+
> > > > | |<-------+
> > > > +--------->| Down | |
> > > > | +----| |<-----+ |
> > > > | | +------+ | |
> > > > | |5b 3| ^ | |
> > > > | | | |2,7 | |
> > > > | | v | | |
> > > > | | +------+ | |
> > > > | | | |<-+ | |
> > > > | | | Test | |11 | |
> > > > | | | |--+ | |
> > > > | | +------+ | |
> > > > | | 5a| 3^ | |
> > > > | | | | | |
> > > > | | v | | |
> > > > |2,12 | +---------+ | |
> > > > | +-->| |14 | |
> > > > | | Up/Free |----+ |
> > > > +---------| | |
> > > > +---------+ |
> > > > 9| ^ |
> > > > | | |
> > > > v |10 |
> > > > +---------+ |
> > > > | |13 |
> > > > |Up/Alloc |------+
> > > > | |
> > > > +---------+
> > > >
> > >
> > > Removing the Deg state simplifies the Link FSM as it's present in
> > > the TE FSM. Editorially then (I think), transition 2
> would not take
> > > place from Test/PasvTest to Down.
> > >
> > > >
> > > >>
> > > >> >
> > > >> >>
> > > >> >> 2. Transtition 10:evLnkDealloc can be possible know even in
> > > >> >the degraded
> > > >> >> state. Yeah a control channel is needed, but this event
> > > >> can also be a
> > > >> >> external event know, from the user or a network management
> > > >> >event. If this
> > > >> >> is possible then this event is required in this
> state. Kindly
> > > >> >> clarify me.
> > > >> >agreed.
> > > >> >
> > > >> >>
> > > >> >> 3. Also event 14.evdcDown can also possible in Test/Pasv
> > > >> >Test state. Since
> > > >> >> to send a Test message or to receive a Test message we
> > > need a data
> > > >> >channel.
> > > >> >> If you see both the FSM's ( Data link ) event 3 & 4 will
> > > >> >pose the next
> > > >> >> state to Test & Pasv Test state from Up/Free state.
> So the event
> > > >> >> 14.evdcDown is also possible on both the states and
> hence the
> > > >> >> next state in both the case will be down.
> > > >> >ok.
> > > >> >
> > > >> >>
> > > >> >> Thanks,
> > > >> >> Ramesh
> > > >> >>
> > > >> >> George Young wrote:
> > > >> >>
> > > >> >> > Looking at the Data Link FSMs in Sections 12.3.3
> and 12.3.4 of
> > > >> >> > draft-ietf-ccamp-lmp-02.txt:
> > > >> >> >
> > > >> >> > 1) It appears that in the Down state, the control channel
> > > >> >> can be either
> > > >> >> > up or
> > > >> >> > down. That being the case, there should be transitions
> > > >> for events 1
> > > >> >> > :evCCUp:
> > > >> >> > and 2 :evCCDown: from Down to Down.
> > > >> >> >
> > > >> >> > 2) Transition 10:evLnkDealloc: from Deg to Down would
> > > >> appear to be
> > > >> >> > impossible,
> > > >> >> > as there is no control channel available, and the control
> > > >> >channel is
> > > >> >> > required to coordinate taking the channel down at both
> > > >> >> ends. I believe
> > > >> >> > this
> > > >> >> > transition should be removed.
> > > >> >> >
> > > >> >> > With these changes, the FSMs would look like:
> > > >> >> >
> > > >> >> > 12.3.3. Active Data Link FSM Description
> > > >> >> >
> > > >> >> > Figure 5 illustrates operation of the LMP active data
> > > >> >> link FSM in a
> > > >> >> > form of FSM state transition diagram.
> > > >> >> >
> > > >> >> > 1,2
> > > >> >> > +------+
> > > >> >> > | |
> > > >> >> > | +------+
> > > >> >> > +-->| |<-------+
> > > >> >> > +--------->| Down | |
> > > >> >> > | +----| |<-----+ |
> > > >> >> > | | +------+ | |
> > > >> >> > | |5b 3| ^ | |
> > > >> >> > | | | |2,7 | |
> > > >> >> > | | v | | |
> > > >> >> > | | +------+ | |
> > > >> >> > | | | |<-+ | |
> > > >> >> > | | | Test | |11 | |
> > > >> >> > | | | |--+ | |
> > > >> >> > | | +------+ | |
> > > >> >> > | | 5a| 3^ | |
> > > >> >> > | | | | | |
> > > >> >> > | | v | | |
> > > >> >> > |2,12 | +---------+ | |
> > > >> >> > | +-->| |14 | |
> > > >> >> > | | Up/Free |----+ |
> > > >> >> > +---------| | |
> > > >> >> > +---------+ |
> > > >> >> > 9| ^ |
> > > >> >> > | | |
> > > >> >> > v |10 |
> > > >> >> > +-----+ 2 +---------+ |
> > > >> >> > | |<--------| |13 |
> > > >> >> > | Deg | |Up/Alloc |------+
> > > >> >> > | |-------->| |
> > > >> >> > +-----+ 1 +---------+
> > > >> >> >
> > > >> >> > Figure 5: Active LMP Data Link FSM
> > > >> >> >
> > > >> >> > 12.3.4. Passive Data Link FSM Description
> > > >> >> >
> > > >> >> > Figure 6 illustrates operation of the LMP passive data
> > > >> >> link FSM in a
> > > >> >> > form of FSM state transition diagram.
> > > >> >> >
> > > >> >> > 1,2
> > > >> >> > +------+
> > > >> >> > | |
> > > >> >> > | +------+
> > > >> >> > +-->| |<------+
> > > >> >> > +---------->| Down | |
> > > >> >> > | +-----| |<----+ |
> > > >> >> > | | +------+ | |
> > > >> >> > | |5b 4| ^ | |
> > > >> >> > | | | |2,8 | |
> > > >> >> > | | v | | |
> > > >> >> > | | +----------+ | |
> > > >> >> > | | | PasvTest | | |
> > > >> >> > | | +----------+ | |
> > > >> >> > | | 6| 4^ | |
> > > >> >> > | | | | | |
> > > >> >> > | | v | | |
> > > >> >> > |2,12 | +---------+ | |
> > > >> >> > | +--->| Up/Free |14 | |
> > > >> >> > | | |---+ |
> > > >> >> > +----------| | |
> > > >> >> > +---------+ |
> > > >> >> > 9| ^ |
> > > >> >> > | | |
> > > >> >> > v |10 |
> > > >> >> > +-----+ +---------+ |
> > > >> >> > | | 2 | |13 |
> > > >> >> > | Deg |<--------|Up/Alloc |-----+
> > > >> >> > | |-------->| |
> > > >> >> > +-----+ 1 +---------+
> > > >> >> >
> > > >> >> > Figure 6: Passive LMP Data Link FSM
> > > >> >> >
> > > >> >> > Regards,
> > > >> >> > George R. Young
> > > >> >> > edgeflow Inc.
> > > >> >> > 329 March Rd., Kanata, ON, Canada, K2K 2E1
> > > >> >> > phone: +1 613-270-9279 Ext 287
> > > >> >> > fax: +1 613-270-9268
> > > >> >> >
> > > >> >> > >-----Original Message-----
> > > >> >> > >From: Kireeti Kompella [mailto:kireeti@juniper.net]
> > > >> >> > >Sent: Monday, November 12, 2001 9:00 PM
> > > >> >> > >To: ccamp@ops.ietf.org
> > > >> >> > >Subject: Two week Last Call on LMP
> > > >> >> > >
> > > >> >> > >
> > > >> >> > >Hi All,
> > > >> >> > >
> > > >> >> > >This is to announce a two week Last Call on the
> LMP draft:
> > > >> >> > >draft-ietf-ccamp-lmp-02.txt. This Last Call ends COB
> > > >> Wed Nov 28.
> > > >> >> > >
> > > >> >> > >Please send questions, comments and requests for
> > > clarifications
> > > >> >> > >to the CCAMP list.
> > > >> >> > >
> > > >> >> > >Kireeti.
> > > >> >> > >
> > > >> >> > >
> > > >> >>
> > > >> >>
> > > >> >
> > > >>
> > > >
> > >
>