[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: questions in LMP (draft-ietf-ccamp-lmp-08)
[ post by non-subscriber. with the massive amount of spam, it is easy to miss
and therefore delete posts by non-subscribers. if you wish to regularly
post from an address that is not subscribed to this mailing list, send a
message to <listname>-owner@ops.ietf.org and ask to have the alternate
address added to the list of addresses from which submissions are
automatically accepted. ]
Sugadeesh,
> -----Original Message-----
> From: Gudipalli, Sugadeesh [mailto:sugadeeshg@netplane.com]
> Sent: Monday, April 07, 2003 9:55 PM
> To: 'Jonathan Lang'; ccamp@ops.ietf.org; 'jplang@ieee.org'
> Subject: RE: questions in LMP (draft-ietf-ccamp-lmp-08)
>
> Jonathan,
>
> Thanks for the quick response, The following sentence you
> sent is still not clear to me.
>
> "LMP link verification procedure is a mechanism that can be used to
> dynamically bind the local/remote identifiers."
> ^^^^^^^^^^^^^^^^^^^^^^^^^
> What identifiers, if they are component id,port id or interface id
there
> is
> no issue. I have an issue only regarding TE link id.
"identifiers" includes TE link id and Interface Id. (the latter often
refers to port ids or component ids)
>
> Thanks for clarifying that property correlation need not be done
> before link verification, then what is the use of "Link
> Verification Supported" flag in the linksummary message which is
> sent after the link verification procedures are already done for the
TE
> link.
Link verification can also be done after the LinkSummary exchange. E.g.,
support for this procedure can be added/removed after the TE link is
brought up.
>
> In 7.Message_Id Usage section there is no discussion of message id for
> BeginVerify Message but it has <MESSAGE_ID> field in it. Do we have to
> ignore the message id field. If not since this is TE link specific
> message, we will be needed to identify the local TE link for
> message id validation when a beginverify is received. If the mapping
is
> already not configured on the two nodes for TE links, the
identification
> of the local TE link id when beginverify arrives with no
> REMOTE_LINK_ID will be impossible.
Please reread Section 7 and Section 12.5 to see the discussion of
message id for BeginVerify message. Specifically, Section 7 states,
"for TE link specific messages, the Message_Id field is within the scope
of the LMP adjacency." Note that an "LMP adjacency" is formed between
two nodes when at least one bi-directional control channel is
established between them (see Section 2).
Thanks,
Jonathan
>
> Please clarify
>
> Regards
> Sugadeesh
>
> -----Original Message-----
> From: Jonathan Lang [mailto:Jonathan.Lang@RinconNetworks.com]
> Sent: Monday, April 07, 2003 10:22 PM
> To: 'Gudipalli, Sugadeesh'; ccamp@ops.ietf.org; jplang@ieee.org
> Subject: RE: questions in LMP (draft-ietf-ccamp-lmp-08)
>
>
> Sugadeesh,
>
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
> Behalf
> > Of Gudipalli, Sugadeesh
> > Sent: Monday, April 07, 2003 5:16 AM
> > To: 'ccamp@ops.ietf.org'; 'jplang@ieee.org'
> > Cc: Gudipalli, Sugadeesh
> > Subject: questions in LMP (draft-ietf-ccamp-lmp-08)
> >
> > Hi Lang and all,
> >
> > Are the link verification procedures required to generate
> automatic
> > remote TE link id and
> > local TE link ID mapping along with the local interface id and
remote
> > interface id mapping.
> LMP link verification procedure is a mechanism that can be used to
> dynamically bind the local/remote identifiers.
>
> > I got the above understanding from the following statement:
> >
> > "5. Verifying Link Connectivity In this section, an optional
procedure
> is
> > described that may be used
> > to verify the physical connectivity of the data links and
dynamically
> > learn (i.e., discover) the TE link and Interface_Id associations. "
> >
> >
> > From my understanding of the LMP spec the mapping of the remote and
> local
> > TE-link ID can't be discovered it needs to be configured,
> you misunderstand the procedure. See below.
>
> > due to the following points:
> >
> > i)
> > "Support for this procedure is indicated by setting the "Link
> > Verification Supported" flag in the TE_LINK object of the
> > LinkSummary message."
> The next sentence says:
> " If a BeginVerify message is received and link verification is not
> supported for the TE link, then a BeginVerifyNack message MUST be
> transmitted with Error Code indicating, "Link Verification
Procedure
> not supported for this TE Link."
> You do not need to send a LinkSummary message before you send a
> BeginVerify message.
>
> >
> > If the remote TE link ID is not mentioned in the link summary
message
> sent
> > to the remote node with the verification supported flag set,
> This is not allowed. See Section 13.11.
>
> > how will the
> > remote
> > node identify for which local TE-link id link verification procedure
> is
> > supported.
> > Since there is no 1 to 1 map between the control channel and TE
link,
> the
> > remote node has no way of identifying the TE-link for which this
link
> > summary message is addressed.
> >
> > ii)
> > "If the message is a LinkSummary message and the Message_Id value is
> > less than the largest Message_Id value previously received from
the
> > sender for the TE Link, then the message SHOULD be treated as
being
> > out-of-order."
> >
> > If the remote TE link ID is not mentioned in the link summary
message
> sent
> > to the remote node,
> This is not allowed. See Section 13.11.
>
> > how will the remote node identify for which local
> > TE-link id
> > the message id in the linksummary has to be verified.
> > Since there is no 1 to 1 map between the control channel and TE
link,
> the
> > remote node has no way of identifying the TE-link for which this
link
> > summary message is addressed. Also for sending the linksummaryack or
> > linksummarynack you need the message id specific to the local TE
link,
> > which
> > we can't identify if the remote link id is 0.
> >
> >
> > Can you please clarify.
> Hope this helps.
>
> -Jonathan
>
> >
> >
> > Regards
> > Sugadeesh