[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 11:35 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,
>
> 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.
To understand the text, remember that the Link Verification procedure is
optional for LMP, whereas Link property correlation procedure is mandatory
for LMP. As a practical matter, Link Verification (when supported) would
happen before Link Property correlation.
>
> 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.
A data link that hasn't yet been assigned to a TE Link can be tested using
TE Link Id =0.
>
> 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.
To clarify, I propose the following text:
To limit the scope of Link Verification to a particular TE Link, the
LOCAL_LINK_ID MUST 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. In the special case where the LOCAL_LINK_ID field is zero, the
"Verify all Links" flag of the BEGIN_VERIFY object is used to distinguish
between data links that span multiple TE links and those that not yet been
assigned to a TE Link. Specifically, verification of data links that span
multiple TE links is indicated by setting the LOCAL_LINK_ID field to zero
and setting the "Verify all Links" flag. Verification of data links that
have not yet been assigned to a TE Link is indicated by setting the
LOCAL_LINK_ID field to zero and clearing the "Verify all Links" flag.
>
> 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.
> > > >> >> > >
> > > >> >> > >
> > > >> >>
> > > >> >>
> > > >> >
> > > >>
> > > >
> > >
>