[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,
Kindly clarify me on the following:
1. Is Link verification has to be done before Link property correlation
procedure. Because with Link verification procedure only ( out of fiber case )
the neighbour interface mappings can be identified. But in Link property
correlation procedure it is given that Link Property correlation MUST be done
before the link is brought UP and MAY be done when the link is UP and not in the
verification process. Here a Link will be brought UP only when TEST messages are
sent through the data link ( out of fiber case ). If so during the first
LinkSummary message we cannot identify the interface mappings right, only the TE
links parameters are exchanged. Am i right. Kindly clarify me.
2. Is that a data link between the two neighbours must participate as a member
of any of the TE link? if not how it will be tested.
3. In the BeginVerify message, there are LOCAL_LINK_ID class and Begin verify
class. It is given that
"To limit the scope of Link Verification to a particular TE Link, the
LOCAL_LINK_ID SHOULD be non-zero. If this field is zero, the data
links can span multiple TE links and/or they may comprise a TE link
that is yet to be configured. "
IF local link id field is ZERO means the data link can span multiple TE link. So
how to test this Data Link. Because in the BeginVerify Class, the Flags filed
cointains
" 0x01 Verify all Links
If this bit is set, the verification process checks all
unallocated links; else it only verifies new ports or
component links that are to be added to this TE link. "
If this bit is set means it will check all unallocated datalinks of the Node
right. if not set means the port or component links that are to be added to this
TE LINK ( means Local Link ID present ) has to be verified.
If this is the case how a data link that span multiple TE link can be tested. or
a datalink that does not participate in any TE link ( if possible ) can be
tested . Kindly clarify me.
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.
> > >> >> > >
> > >> >> > >
> > >> >>
> > >> >>
> > >> >
> > >>
> > >
> >