RE: LMP Doubt

[Jonathan Lang <jplang@calient.net>]

Ramesh,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: S Ramesh [mailto:rashanmu@npd.hcltech.com]
> Sent: Thursday, April 18, 2002 2:45 AM
> To: ccamp@ops.ietf.org
> Cc: OIF; S R a m e s h
> Subject: LMP Doubt
> 
> 
> Hi,
> 
> Can anybody explain me the need of Interface id to be of type IPv4, v6
> and unnnumbered. Why do we need this kind of classification to a number
> which is assigned to a port or component link.
Component links can themselves be numbered or unnumbered (see link bundling
draft). The distinction is required in the Interface_ID object of signaling.

> 
> In the case of Neighbour discovery, it is going to be used to find the
> data plane connectivity and verify it. Just a 32 bit number is enough
> for that right. Why do we need a classification with different C-Types
> for this interface id.
see comment above.

> But the Test messages also in most of the cases
> it is IP encapsulated, i dont think we need to use this Interface ID as
> the destination IP address for the Test messages, because this is unique
> Node-wide only. If so we can use the Node ID as the destination IP
> address ( since data links are directly connected ) and send the Test
> message which contains the Interface ID.
The LMP spec does not say to use the destination IP address for the Test
messages. The Node Id is what you should be using.

> 
> Also in OIF UNI 1.0 agreement, in Service Discovery messages, they use
> Interface ID as 32bit number ( may be IPv4 or un numbered ). For other
> Interface ID related messages which are used in Verification procedure,
> they refered IETF LMP draft.
> 
> At this point of time am putting Kireeti's  comments on a discussion
> like this
> 
> "I see that the OIF UNI comes up over and over.  The OIF UNI is *NOT*
> specified by CCAMP; hence "required by OIF OUNI" has little official
> meaning to CCAMP. However, if what the OIF UNI needs comes for free (as
> in this case), that's fine."
> 
> Am accepting the point , but however, i could not understand the reasons
> for the extensions to such a classification with 3 C-Types for Interface
> ID. If it is functionality wise required for a protocol in future means
> its upto the OIF to upgrade or  we can know the specific reason for
> making a difference ( which i could not understand the usage or future
> use of those classication ) from OIF UNI which "comes for free"
> otherwise. Kindly explain on this regard.
see above comment.

> 
> Thanks,
> Ramesh
> 
>