RE: Addressing doc

["Rajiv Papneja" <rpapneja@isocore.com>]

Hi Diego,
 Please see inline

/Rajiv

> -----Original Message-----
> From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com]
> Sent: Wednesday, April 20, 2005 9:00 AM
> To: ccamp
> Subject: Re: Addressing doc
>
>
> Some comments/question on the ID.
>
> First all think that this work is very useful in order to understand how
> the different implementation of GMPLS interpret the ID/RFC.
>
> I'd like to have, if it is possible, an explanation of the incoming and
> outgoing terms, my understanding of that terms is the following one.
>
>             +-------+                     +-------+
>             |       |      Path-->        |       |
>             |       |=====================|       |=============
>             |       |                    /|       |\
>             +-------+                   / +-------+ \
>                                Incoming/             \OutGoing
>
>
This is the correct understanding.

> I understood from the Lyndon mail that the ID is the result of the ISOCORE
> tests, my question, w.r.t. the ERO processing, is: TNEs that implements
> option 3 are able to interoperate with TNE that implements option 4?  More
> generally was possible to have interworking between the variuos options?

Typically we have used one or the other kind options defined
during the tests. This eliminates the confusion of interpretations.

>
> What exactly means the term encapsulating in the following sentence
> (section 4.0)
> "...
> Mandating that TE Router ID be a reachable IP address eliminates the need
> of the mentioned above module ?
Please see the first paragraph of Section 4. See also Igor's message:
https://psg.com/lists/ccamp/ccamp.2005/msg00381.html.
"  Generally speaking there is a need for a module/protocol that discovers
and manages control plane/data plane address bindings for the address spaces
to be completely separated.  In this case, the TE Router ID could be just a
network unique number.  Mandating that TE Router ID be a reachable IP
address eliminates the need of the mentioned above module ・the next hop
data plane TE Router ID could be used as a destination for IP packets
encapsulating the LSP setup (RSVP Path) message.  Note that every TE
link ID could always be resolved to the link originating TE Router
ID."

> next hop data
> plane TE Router ID could be used as a destination for IP packets
> encapsulating the LSP setup (RSVP Path) message.
> ..."
IP Packet that carries the RSVP-TE message.
>
> Moreover my understunding is that LMP can be the module that manages, on a
> hop by-hop basis of course, control plane/data plane address binding; why
> LMP is not referenced by the ID?  IMHO LMP is an important part of the
> GMPLS protocols suite.
We do not mean to exclude LMP. We'll add words to that effect.
>
> Regards
>
> Diego
>
>
>
>
>
>
>
>
>
>