[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Addressing doc
Hi Dimitri,
Comments inline.
> -----Original Message-----
> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com]
> Sent: Wednesday, April 20, 2005 3:12 AM
> To: Richard Rabbat
> Cc: Dimitri.Papadimitriou@alcatel.be; 'Igor Bryskin';
> 'Kireeti Kompella'; ccamp@ops.ietf.org
> Subject: 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
>
Good. There's agreement on this.
> > 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
>
I understand there may be confusion. I suggest to make it a WG draft and you
have a commitment from the authors to address the issue you raised in the
next update to that. After all, this is work in progress :-)
I hope this is satisfactory.
> 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-ext
ensions-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
>
>