[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)
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. 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.
Also Jonathan as i already said 14.evdcDown is possible in Test/Pasv Test state.
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.
> > >> >> > >
> > >> >> > >
> > >> >>
> > >> >>
> > >> >
> > >>
> > >
> >