Re: Two questions on draft-dimitri-ccamp-gmpls-ason-routing-ospf draft

Igor Bryskin <i_bryskin@yahoo.com> Fri, 09 March 2007 15:17 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 1HPgqY-0005Js-Mz for ccamp-archive@ietf.org; Fri, 09 Mar 2007 10:17:30 -0500
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPgqG-0003PF-HK for ccamp-archive@ietf.org; Fri, 09 Mar 2007 10:17:30 -0500
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1HPgem-000Hcs-Md for ccamp-data@psg.com; Fri, 09 Mar 2007 15:05:20 +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_MESSAGE autolearn=ham version=3.1.7
Received: from [209.191.85.57] (helo=web36806.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.63 (FreeBSD)) (envelope-from <i_bryskin@yahoo.com>) id 1HPgeV-000Hac-R6 for ccamp@ops.ietf.org; Fri, 09 Mar 2007 15:05:16 +0000
Received: (qmail 93338 invoked by uid 60001); 9 Mar 2007 15:05:02 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Y9KUu5NBZ5aqMZp+atovJzV27nS9W9Sq82gqbwp4aD2TAMmUR5S8zlNo1yEv0Ari6qe2ZgD4Bymcm1pX0vbeXdqw9hGO8GVVsRKv9ZwsMv4n9TST96AyB0H4cBP3Yf56+OX5EygEHdzzI1/G9z+sf0jmrrZuMQUTYXsckfCYD8s= ;
Message-ID: <20070309150502.93330.qmail@web36806.mail.mud.yahoo.com>
X-YMail-OSG: I6vRA64VM1kaBj3bDzWFuGza4h8.jna5KXCjpL.3WgVpPmVv7wc9P1q2iMmA2cuc5OBFkN9hrdYd7oqDFhVElLem.IRjXRRb_RN9kFgjPMMi4mhETBKrX58BGizk2xDvTgI.m2AVjeT4T6lPbUn5Og--
Received: from [67.102.145.11] by web36806.mail.mud.yahoo.com via HTTP; Fri, 09 Mar 2007 07:05:02 PST
Date: Fri, 09 Mar 2007 07:05:02 -0800
From: Igor Bryskin <i_bryskin@yahoo.com>
Subject: Re: Two questions on draft-dimitri-ccamp-gmpls-ason-routing-ospf draft
To: Dimitri.Papadimitriou@alcatel-lucent.be
Cc: ccamp@ops.ietf.org, "Brungard, Deborah A, ALABS" <dbrungard@att.com>
In-Reply-To: <OFFD93731B.C8EDB717-ONC1257298.007EB707-C1257298.007F4BB5@netfr.alcatel.fr>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-421440143-1173452702=:92923"
Content-Transfer-Encoding: 8bit
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.5 (/)
X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771

  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 &#8220;identifies the other end of the link&#8221;. 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:

&#8220;

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.