RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf
Igor Bryskin <i_bryskin@yahoo.com> Sat, 10 March 2007 21:36 UTC
Return-path: <owner-ccamp@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ9En-0000zi-Gy for ccamp-archive@ietf.org; Sat, 10 Mar 2007 16:36:25 -0500
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQ9Ek-00073S-7b for ccamp-archive@ietf.org; Sat, 10 Mar 2007 16:36:25 -0500
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1HQ95B-0009AU-RA for ccamp-data@psg.com; Sat, 10 Mar 2007 21:26:29 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,HTML_10_20, HTML_MESSAGE autolearn=no version=3.1.7
Received: from [209.191.85.66] (helo=web36815.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.63 (FreeBSD)) (envelope-from <i_bryskin@yahoo.com>) id 1HQ957-0009AE-NW for ccamp@ops.ietf.org; Sat, 10 Mar 2007 21:26:27 +0000
Received: (qmail 96336 invoked by uid 60001); 10 Mar 2007 21:26:23 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=SSPni71BvW0FC/NxnBmqDr2VTHq6df1aOeFVYX92QVz1xPtQCTQN+XMz/p6KKaVmBd7fcwnxodtkPNwEuLn5h1tzo6K+flzQohcG/aqMnNDMwlNt50pt8kz6D0DOCfbyKTwBFHa82W0PnAd5Rlty/NZtxI+6oc7ZzNcXtxy0uQU=;
X-YMail-OSG: .JvuvmgVM1lwuKE85FdaHt3lDAHHQaazXMqge_5.dO9ivB1s1GUcUyxpUfabEOyWPKLa_Uoz1sNt5OZIHTAzujetvHuHbunYdhwWQtYLP2kYK_C99.h6FPSoSGEepl2F9m7E5DMOELLZrCPWWZe.Ug--
Received: from [70.177.176.223] by web36815.mail.mud.yahoo.com via HTTP; Sat, 10 Mar 2007 13:26:23 PST
Date: Sat, 10 Mar 2007 13:26:23 -0800
From: Igor Bryskin <i_bryskin@yahoo.com>
Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf
To: Dimitri.Papadimitriou@alcatel-lucent.be
Cc: ccamp@ops.ietf.org, "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Ong, Lyndon" <Lyong@Ciena.com>, owner-ccamp@ops.ietf.org
In-Reply-To: <OFB35EA62A.911CB291-ONC125729A.004A8D27-C125729A.004B70FB@netfr.alcatel.fr>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-611198405-1173561983=:91906"
Content-Transfer-Encoding: 8bit
Message-ID: <869181.91906.qm@web36815.mail.mud.yahoo.com>
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 5d188b91ff79eaa1be2a0e9635461d9a
Dimitri, I probably do not make myself clear, but you don't seem to see what I am saying. Let's continue the discussion in Prague. Hoefully, we will also hear what the authors of RFC3630 have to say. See you soon, Igor Dimitri.Papadimitriou@alcatel-lucent.be wrote: igor the first sentence is the disconnect, per 3630 "The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear exactly once." " The Link ID sub-TLV identifies the other end of the link. For point-to-point links, this is the Router ID of the neighbor." you wrote "TE links must be uniqely identifed either as numbered or unnumbered (combination of TERtrID and LinkID)." this is totally incorrect, there is a local/remote sub-TLV defined for numbered TE links in fact what the present document does is to define a sub-TLV to allow identification of unnumbered TE links (associated to the TE router ID rather than the Router ID) thanks, -d. Igor Bryskin 10/03/2007 14:10 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: ccamp@ops.ietf.org, "Brungard, Deborah A, ALABS" , "Ong, Lyndon" , owner-ccamp@ops.ietf.org Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf Dimitri, But who said that linkID must be unique per routerID? Of course, not. It must be unique per TE Router ID. The fact that the same RC manages several TE RTRs does not change a thing. The paths are computed on the network TE graph, built of vertices (TE RTRs) interconnected by edges (TE links). TE links must be uniqely identifed either as numbered or unnumbered (combination of TERtrID and LinkID). How the links are advertised - by separate RCs, the same RC or via no RC (statically configured) - is of no importance. Igor Dimitri.Papadimitriou@alcatel-lucent.be wrote: igor not an issue of TE router ID uniqueness, without this additional sub-TLV, an unnumbered local id may not be unique per router_id, hence the addition of this sub-TLV (TE Router ID being unique per router_id) -d Igor Bryskin 09/03/2007 22:36 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: ccamp@ops.ietf.org, "Brungard, Deborah A, ALABS" , "Ong, Lyndon" , owner-ccamp@ops.ietf.org Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf Dimitri, I don't see how we can manage the situation where TENodeIds are not unique. At the end of the day we must process EROs/RROs that are build of TENodeID/TELinkID pairs. If TELinkID has node-scope and TENodeID is not unique, how then we can identify the specified link? So what do you suggest we put in each of these two fields? Dimitri.Papadimitriou@alcatel-lucent.be wrote: igor but it doesn't solve the issue (and introduces different setting and processing of the link id value from rfc 3630) indeed, in ASON RC can be associated to multiple "nodes", each of these nodes can have overlapping id spaces (to identify the "links") for that reason the solution is that each TE link (top level) TLV has a new sub-TLV that associates the local and remote "node id" (the former and latter takes the TE Router ID as value) it is the substance of what i have been pointing to you in my initial e-mail (see Section 5.2 but also in RFC 4652 Section 5.7: "the routing protocol MUST be able to disambiguate the advertised TE links so that they can be associated with the correct TE Router ID.") -d. Igor Bryskin Sent by: owner-ccamp@ops.ietf.org 09/03/2007 20:29 To: "Ong, Lyndon" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: ccamp@ops.ietf.org, "Brungard, Deborah A, ALABS" , owner-ccamp@ops.ietf.org Subject: RE: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf Lyndon, Let me try to explain my point. Basically, we have two solutions to address the situation when the relationship between a router controller and data plane switches (TE nodes or TE routers) are 1:N, that is, when a single controller manages multiple TE routers. Solution 1 (suggested in the draft): Each TE Link advertising is extended with Local/Remote TE Router IDs pair. In this case, what is in the LinkID sub-TLV is not important really. Solution 2 (mine) The Router Address TLV is extended to advertise all TE Router IDs controlled by the advertising controller as routable addresses. The TE Link TLV is extended to advertise the local TE Router ID. However, there is no need to advertise the remote TE Router ID, because this is the function of the existing LinkID sub-TLV, which is to identify the remote end of the advertised TE link âââ‰â¬Å remote TE Router ID. Both these approaches solve the problem; however, an important question to answer is: Do we need the TE Router IDs to be routable addresses? The answer is YES according to draft-ietf-ccamp-gmpls-addressing-05.txt. For example, if the network is built of unnumbered TE links, than ERO signaled in RSVP-TE Path will contain path in a form of TE_RtrID/ifIndex pairs, and having TE_RtrID routable solves the problem how to signal the Path message along the provisioned path.. If you agree with this, than you will also agree that all TE Router IDs should be advertised within Router Address TLV Hope that this helps. Igor "Ong, Lyndon" wrote: Hi Dimitri, That was my understanding also, I don't see any issue with this. Cheers, Lyndon -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Dimitri.Papadimitriou@alcatel-lucent.be Sent: Friday, March 09, 2007 7:56 AM To: Igor Bryskin Cc: ccamp@ops.ietf.org; Brungard, Deborah A, ALABS; owner-ccamp@ops.ietf.org Subject: Two questions on draft-ietf-ccamp-gmpls-ason-routing-ospf igor the drafts says "Note: The Link ID sub-TLV that identifies the other end of the link (i.e. Router ID of the neighbor for point-to-point links) MUST appear exactly once per Link TLV. This sub-TLV MUST be processed as defined in [RFC3630]. " which is exactly what you are saying - when i say "it identifies the remote RC not the remote data plane "node" in case the remote RC is associate to n nodes" read "it is set to the router_id that identifies the remote RC..." in brief, we keep the semantic and add a discriminator (that does not apply in case of colocated 1:1 LSR) - this closes the first point - concerning the second point, since there is a possibility to have multiple associations in different LSAs i don't where the problem is ? thanks, -d. Igor Bryskin Sent by: owner-ccamp@ops.ietf.org 09/03/2007 16:05 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: ccamp@ops.ietf.org, "Brungard, Deborah A, ALABS" Subject: Re: Two questions on draft-dimitri-ccamp-gmpls-ason-routing-ospf draft Dimitri, > Is the LinkID is the same as Remote TE Router ID? no > LinkID unambiguosly identifies remote data plane node, no, it identifies the remote RC not the remote data plane "node" in case the remote RC is associate to n "nodes" IB>> No, I disagree. You see that's why it's so important to quote the RFCs/drafts, because people often interpret them differently. In RFC 3630 we read: " 2.5.2. Link ID The Link ID sub-TLV identifies the other end of the link. For point-to-point links, this is the Router ID of the neighbor. " Note that it does not say whether this is the advertising Router ID (identifying neighbor RC) or TE Router ID (identifying the neighbor TE node). However, it does say that it "identifies the other end of the link". Because a link is terminated by TE nodes (and not advertising routers) I conclude that LinkID identifies the remote TE node. Furthermore, earlier in RFC 3630 we read: " 2.4.1. Router Address TLV The Router Address TLV specifies a stable IP address of the advertising router that is always reachable if there is any connectivity to it; this is typically implemented as a "loopback address". The key attribute is that the address does not become unusable if an interface is down. In other protocols, this is known as the "router ID" I interpret that this is the same router ID as in the upper quote. It is advertised in the Router Address TLV, which is the only way today to advertise TE Router ID. Hence the router ID in the context of this RFC is the TE Router ID. The conclusion #1: the TE Link TLV, as it is today, always contains the ID of the remote TE node. The conclusion #2: there is a need to advertise several TE Router IDs supported by the same RC (advertising router), which, I think, should be proposed in your draft ps: second question is trivial, mathematical vs networking formulation (no real difference) IB>> Well, it changes one of the fundamental definitions of G.8080, and I am asking why is that in the draft which is supposed to define ways to support G.8080 Igor pps: if you want to put guidelines on e-mail responses probably directing your e-mail to the GEN AREA would be more suitable hope this helps, -d. Igor Bryskin 09/03/2007 00:03 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: ccamp@ops.ietf.org, "Brungard, Deborah A, ALABS" Subject: Re: Two questions on draft-dimitri-ccamp-gmpls-ason-routing-ospf draft Dimitri, no, it does not help. You didn't answer the first question, which is: Is the LinkID is the same as Remote TE Router ID? If no, what is the difference? If yes, why do you need the latter? Both your pointers explain why do you need advertising of the local TE Router ID (advertising router may cover multiple data plane nodes), However, LinkID unambiguosly identifies remote data plane node, and the need for the advertising of Remote TE Router ID is not obvious BTW, You didn't answer the second question either. Igor PS, I have a suggestion for the working group: Let us disallow responding to the comments/questions by just pointing to RFCs or drafts. In my view it is quite unfriendly. It is always possible to cut and paste a piece from the relevant RFC or draft confirming the points the writer is trying to make. Dimitri.Papadimitriou@alcatel-lucent.be wrote: igor pls use version (or 03 when available to make comments) in that version you will see in Section 5.2 " Note: The Link ID sub-TLV that identifies the other end of the link (i.e. Router ID of the neighbor for point-to-point links) MUST appear exactly once per Link TLV. This sub-TLV MUST be processed as defined in [RFC3630]. " now why this sub-TLV 17, well for the reason explained at the beginning of par.5.2 but also in RFC 4652 Section 5.7 hope this helps, -d. Igor Bryskin 08/03/2007 22:11 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: ccamp@ops.ietf.org, "Brungard, Deborah A, ALABS" Subject: Two questions on draft-dimitri-ccamp-gmpls-ason-routing-ospf draft Dimitri, I have a couple questions wrt the draft-dimitri-ccamp-gmpls-ason-routing-ospf draft. In 5.2 a TE Link sub-TLV is introduced for the purpose of advertising local and remote TE Router ID: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 17 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local TE Router Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote TE Router Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Although I do understand why there is a need for advertising the Local TE Router ID, I donÃÆÃâÃââÃÆâ'ÃâìÃÆâ"Ãâât understand why the Remote Te Router ID? IsnÃÆÃâÃââÃÆâ'ÃâìÃÆâ"Ãâât this is the same information that is carried in the Link ID sub-TLV? In 6. you write: ÃÆÃâÃââÃÆâ'ÃâìÃÆââ¬Â¦"A RA may contain smaller RAs inter-connected by links. The limit of the subdivision results in a RA that contains two sub-networks interconnected by a single link.ÃÆÃâÃââÃÆâ'ÃâìÃÆââ¬Å¡ÃâàIn G.8080 I read: ÃÆÃâÃââÃÆâ'ÃâìÃÆââ¬Â¦".... A routing area is defined by a set of subnetworks, the SNPP links that interconnect them, and the SNPPs representing the ends of the SNPP links exiting that routing area. A routing area may contain smaller routing areas interconnected by SNPP links. The limit of subdivision results in a routing area that contains ]one subnetwork.ÃÆÃâÃââÃÆâ'ÃâìÃÆââ¬Å¡ÃâàWhy is the discrepancy? Thanks, Igor [ Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. Get your own web address. Have a HUGE year through Yahoo! Small Business. 8:00? 8:25? 8:40? Find a flick in no time with theYahoo! Search movie showtime shortcut. Don't get soaked. Take a quick peek at the forecast with theYahoo! Search weather shortcut. --------------------------------- TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV.
- Next steps for draft-ietf-ccamp-mpls-graceful-shu… Zafar Ali (zali)
- Re: Next steps for draft-ietf-ccamp-mpls-graceful… Dimitri.Papadimitriou
- Two questions on draft-dimitri-ccamp-gmpls-ason-r… Igor Bryskin
- Re: Two questions on draft-dimitri-ccamp-gmpls-as… Dimitri.Papadimitriou
- Re: Two questions on draft-dimitri-ccamp-gmpls-as… Igor Bryskin
- Re: Two questions on draft-dimitri-ccamp-gmpls-as… Dimitri.Papadimitriou
- Re: Two questions on draft-dimitri-ccamp-gmpls-as… Igor Bryskin
- Two questions on draft-ietf-ccamp-gmpls-ason-rout… Dimitri.Papadimitriou
- RE: Two questions on draft-ietf-ccamp-gmpls-ason-… BRUNGARD, DEBORAH A, ATTLABS
- RE: Two questions on draft-ietf-ccamp-gmpls-ason-… Igor Bryskin
- RE: Two questions on draft-ietf-ccamp-gmpls-ason-… Ong, Lyndon
- RE: Two questions on draft-ietf-ccamp-gmpls-ason-… Igor Bryskin
- RE: Two questions on draft-ietf-ccamp-gmpls-ason-… Dimitri.Papadimitriou
- RE: Two questions on draft-ietf-ccamp-gmpls-ason-… Igor Bryskin
- RE: Two questions on draft-ietf-ccamp-gmpls-ason-… Dimitri.Papadimitriou
- RE: Two questions on draft-ietf-ccamp-gmpls-ason-… Igor Bryskin
- RE: Two questions on draft-ietf-ccamp-gmpls-ason-… Dimitri.Papadimitriou
- RE: Two questions on draft-ietf-ccamp-gmpls-ason-… Igor Bryskin
- RE: Next steps for draft-ietf-ccamp-mpls-graceful… Zafar Ali (zali)