[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Addressing doc

hi richard,

Richard Rabbat wrote:

We mentioned in the discussion in Minneapolis that the objective was *NOT*
to standardize broken implementations interwork with the correct
implementations.
Agree with Igor's and your comments.

In the introduction, we said:
For the purposes of this document it is assumed that there is a one-to-one
correspondence between control plane and data plane entities.
I think we covered this well. As we mentioned in the draft, "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."

the main comment indeed refers to the issue generated by last part of the last sentence "TE Router ID could be used as a destination for IP packets encapsulating the LSP setup (RSVP Path) message" i.e. what i pointed out is that by recommending only this behaviour, a capability provided by the GMPLS protocol suite is not taken into account and this independently of the reachable behaviour of the TE router ID i.e. not using the TE Router ID for encapsulating the packets does not mean that the TE Router ID could be just a number - as its definition is invariant

We will update the draft to show that we are inclusive of both the simple
case and the more complex case that requires the mapping that we discussed
above.


ok, this would help

Based on that, why not to progress it to WG draft? Moving it to WG draft
means that the WG is interested in the topic and wants to address the topic.

afaik, changes can not be provided when moving the status of document and there were already too much confusions in the past concerning these information elements and processing to afford yet another issue to be solved

thanks,
- dimitri.

Richard.

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf
Of Dimitri.Papadimitriou@alcatel.be
Sent: Sunday, April 17, 2005 10:11 AM
To: Igor Bryskin
Cc: Dimitri.Papadimitriou@alcatel.be; Kireeti Kompella; ccamp@ops.ietf.org
Subject: Re: Addressing doc



igor, i mentioned this because when some implement - for whatever purpose -
a subset of capabilities and draw recommendations from this partial set,
these should not by any means retrofit to the complete set of capabilities
this protocol suite delivers or imply recommendations that would prevent
from using its full set

coming to the below you have been mentioned on what this so-called
separation does imply is that for constructing - and LMP can be used in
helping this construction but this is also not mandatory - the TE topology
make use of the TE router ID for the identification unnumbered interfaces
and (abstract) nodes, (numbered interfaces are also part of this class of
information - but obviously does not require the use of the TE Router ID)
afterwards any control plane message exchange can make use of the IP control
plane topology as long as these messages are exchanged between control plane
entities that have initially advertized (i.e. as owner of) this information

hope this clarifies,

- dimitri.

Igor Bryskin <i_bryskin@yahoo.com>
Sent by: owner-ccamp@ops.ietf.org
04/17/2005 05:50 MST

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Kireeti Kompella
<kireeti@juniper.net>, ccamp@ops.ietf.org
bcc:
Subject: Re: Addressing doc




Dimitri,

I think we are in agreement here. The only thing I
disagree with is your statement that the document is
not ready to be WG document for the reasons you have
provided. I am not the author of this document and I
let the authors tell what they think. However, the
whole point of the document, as far as I understand
it, is not to mandate something, rather, to provide a
set of recommendations based on the interop tests
experience, so that interoperability between different
vendors would be easier to achieve. Hence, they do not
need to spell out word RECOMMEND in every clause.

WRT TE Router ID. Of course, IFF there is some
knowledge or mechanism to translate TE addresses into
control plane IP addresses, any of next hop IP
addresses could be used as destination in RSVP Path
message IP packet. In this case IHMO  Te Router ID
does not even have to be routable, and full separation
between TE and control plane name spaces could be
achieved. I think LMP could help to do this. However,
one cannot mandate using LMP for every link in every
layer, especially, for IP/MPLS layer(s).

Igor

--- Dimitri.Papadimitriou@alcatel.be wrote:


igor, my point is that if you recommend

"  A Path message is sent to the next hop node. It
is RECOMMENDED that
  the TE router ID of the next hop node be used as
an IP destination
  address in the packet that carries the RSVP-TE
message. "

and

"  ... an unnumbered link is identified by the
combination of TE Router
 ID and a node-unique Interface ID."

then it is clear that the following occurs

" The reason why the TE Router ID must be a
reachable IP address is
 because in GMPLS, control and data plane
names/addresses are not
 completely separated. "

and the only change that needs to be done in this
document in section 4.3

"It is RECOMMENDED that a stable
  control plane IP address of the next/previous hop
node be used as an
  IP destination address in RSVP-TE message.

  A Path message is sent to the next hop node. It
is RECOMMENDED that
  the TE router ID of the next hop node be used as
an IP destination
  address in the packet that carries the RSVP-TE
message."

is to remove the second paragraph, as there is
nothing that mandates that
communication between adjacent controllers should
achieved through TE
router ID (note: reading the document you will see
that the section 5.2.1
is indeed
not completed just for this reason)

in fact, this boils down to say that the TE router
ID is not mandatorily
used for hop-by-hop exchange of control messages as
i can build adjacencies
between neighboring nodes using the base IP routing
topology, (by the way
from where all restrictions that are pointed here
below come from ?)

thanks,
- dimitri.
---

Dimitri,

Suppose a controller has just received an RSVP Path
message that contains an ERO describing a path
computed on the head-end (properly modified, of
course, along the path). ERO is specified in terms
of
numbered or/and unnumbered TE links (and not IP
addresses). Now the processing controller needs to
forward the message to the controller that manages
first non-local ERO sub-object. The question is what
to set as destination in the IP header of the RSVP
Path message? You are saying that it should a stable
IP address of the controller managing the next hop.
Where the processing controller is supposed to get
this stable IP address from? All that it has is a
numbered or unnumbered next hop TE link ID. It is
not
guaranteed that numbered TE link ID is a routable
address, however, it could be easily resolved to TE
Router ID. In case of unnumbered TE link the TE
Router
ID is a part of the link ID. It is also guaranteed
that TE Router ID is a stable routable IP address of
the controller advertising the TE link. Hence, the
recommendation makes a lot of sense to me ? extract
TE
Router ID from unnumbered link ID ERO subobject or
resolve numbered TE link ID into TE Router ID, set
it
as destination in IP header of the RSVP Path message
and forward the packet ?the message will arrive at
the
controller managing next hop no matter how many
actual
IP hops the packet will make. In fact, that's how
the
control plane and data plane separation needs to be
supported.

Cheers,
Igor

--- Dimitri.Papadimitriou@alcatel.be wrote:

this document is not ready as it prevents usage of
the control channel
separation as defined in Section 8 of RFC 3473


(but

also representation of
complex nodes)

i point out here the sentences from where this can
be deduced:

" A Path message is sent to the next hop node. 

It

is RECOMMENDED that
  the TE router ID of the next hop node be used


as

an IP destination
  address in the packet that carries the RSVP-TE
message. "

combined with the following statements

"  ... an unnumbered link is identified by the
  combination of TE Router ID and a node-unique
Interface ID."

"  It is RECOMMENDED that the IP tunnel endpoint
address in the Session
  Object [RFC3209] be set to the TE Router ID of
the egress since the
  TE Router ID is a unique routable ID per node."

[...]

"  It is RECOMMENDED that the IP tunnel sender
address in the Sender
  Template Object [RFC3209] specifies the TE


Router

ID of the ingress
  since the TE Router ID is a unique routable ID
per node."

therefore, usage of the TE Router ID should be
reviewed, such that it does
not recommends the source and destination of IP
packets to be the TE Router
ID but simply a stable reachable control plane IP
address of the
next/previous hop

also, there is a sentence in this document

"  The reason why the TE Router ID must be a
reachable IP address is
  because in GMPLS, control and data plane names
/addresses are not
  completely separated. "

my response to this is of course if you use it 

like

proposed in this
document this problem occurs

ps:

section 5.1.2 of this document is unclear wrt
section 1.1 of


<http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-19.txt







__________________________________
Do you Yahoo!?
Plan great trips with Yahoo! Travel: Now over 17,000
guides!
http://travel.yahoo.com/p-travelguide







__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com