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