RE: Addressing doc

["[e-mail]" <[e-mail]>]

I am also in favor of progress of the document as a WG draft
not because it is just an iterest of the WG, but because
I think we can make progress with promised modification,
as well as the quickness is a key here considering that
the contents are reflecting real experiences.

Ichiro Inoue


At 23:26 05/04/19 -0400, 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."
>
>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.
>
>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.
>
>Richard.
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On 
>Behalf Of [e-mail]
>Sent: Sunday, April 17, 2005 10:11 AM
>To: Igor Bryskin
>Cc: [e-mail]; Kireeti Kompella; [e-mail]
>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 <[e-mail]>
>Sent by: [e-mail]
>04/17/2005 05:50 MST
>
>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>cc: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Kireeti Kompella 
><[e-mail]>, [e-mail]
>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
>--- [e-mail] 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
> >
> > --- [e-mail] 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>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>http://travel.yahoo.com/p-travelguide
> >
> >
> >
> >
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam?  Yahoo! Mail has the best spam protection around
><http://mail.yahoo.com>http://mail.yahoo.com