RE: Fwd: draft-ietf-iptel-trip-gw-00.txt has been posted
Dhaval Shah <[email protected]> Mon, 10 Jun 2002 18:15:24 -0700
| Newsgroups | gmane.ietf.iptel |
|---|---|
| Message-ID | <[email protected]> |
--=====================_36165873==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Anna, Please see comments inlined below.. At 02:34 PM 6/10/2002 -0400, Anna Cheung wrote: >Hi Dhaval, > >I have some questions after reading the trip-gw draft, and hope >you or somebody in the work group could clarify. > >Thanks >/Anna > > >1) Available Capacity (AC) is defined as non-transitive >in the draft. I'm just wondering if it should be transitive instead. >The reason being if the LS fronting the GW does not advertises >the AC of the route to other LS's in the core of the network, then there >could be cases where a route is selected with higher TotalCapacity but >lower available Capacity. (From the draft, it seems to be >the reason it is defined as non-transitive is due to the fact that >it might change frequently. But if the GW only advertises when >somethrehold is crossed, then the frequency might not be a big problem >for the LS ??) This would add another level of complexity and gets into tuning to avoid staleness etc. We analyzed this and thought of not including at this time. > >2) Section 4.4 prefix attribute, is it saying that the prefix attribute is >a conditional mandatory attribute for the trunk address family and CIC >address family? I'm a bit confused by the statement "conditional mandatory >(if reachable routes is present)" This means that if the reachableroutes attribute is present, then the prefix attribute must be present. A length of zero for the prefix attribute indicates a prefix that matches all prefixes for the respective address family type and application protocol. I thought I had included that statement in the draft but loox like it got removed while re-arranging the Prefix attributes section. Will add it in the next rev. >3) When a GW advertises a route of type trunk address family (or CIC address >family), if attribute prefix attribute is NOT present, does it mean the >advertised >trunk (or CIC) can be used to reach ANY prefix? No. Please see note above. > >4) Can you please clarify why carrier attribute must not be used with >trunk family >and trunk attribute must not be used with the CIC family ? Introduces hierarchy and complexity amongst other reasons and was not deemed important enough at this stage. We have noted it as a future issue. >5) Reading section 4.10.1, I'm under the impression that an LS may receive >alternative routes from the same gateway for a given destination. Is this >true? > Doesn't the subsequent advertisment of a given route from the same GW > just replaces >the previous advertisement? Section 4.10.1 tries to address the case where the LS may receive alternative routes for the same destination from *different* gateways. If the same gateway wants to advertise alternative routes for a given destination, then it can send them in one update to the LS. >6) When a GW advertise an update with the follows: >- trunk address family, >- trk value=trk1, >- prefix attribute=1613, >- nexthop = NH1 > >The update is saying that route trk1 and prefix 1613 is >reachable via NH1. Could we also interpret that 1613 >is reachable via NH1? Yes, if you don't care about trk1. Hope this helps. Thx, Dhaval > >-----Original Message----- >From: Dhaval Shah [mailto:[email protected]] >Sent: Sunday, June 09, 2002 2:20 PM >To: [email protected] >Subject: [IPTEL] Fwd: draft-ietf-iptel-trip-gw-00.txt has been posted > >Hi Folx, > >Just a follow-up to the draft posting. > >The main changes in this version are: >- Removed Carrier-Trunkgroup attribute and address family and > references to it. >- Added Terminology and Definitions section. >- Updated CallSuccess attribute. >- Added Prefix attribute. >- Added Carrier attribute. >- Added TrunkGroups attribute. >- Added TrunkGroup Address Family. >- Added Carrier Address Family. >- Added Route Consolidation section. >- Added some more references. > >A couple of open issues that come to mind are: >- International carrier ids >- Jonathan had a suggestion regarding having an update rate capability >that the LS would send >to the gateway. The purpose would be to have the gateway not send updates >at a rate higher than the >specified number. > >Thx, >Dhaval > > > > > > > >>Date: Fri, 07 Jun 2002 07:51:22 -0700 >>To: [email protected] >>From: Dhaval Shah <[email protected]> >>Subject: draft-ietf-iptel-trip-gw-00.txt has been posted >>Cc: [email protected], [email protected], [email protected], >>Rajneesh Kumar <[email protected]> >>Bcc: [email protected], [email protected], [email protected], >>[email protected], [email protected], [email protected], [email protected], >>[email protected], [email protected], [email protected] >> >>Hi Folx, >> >>The draft is now available on the ftp server: >>ftp://ftp-eng.cisco.com/dhaval/draft-ietf-iptel-trip-gw-00.txt >> >>If someone has problems retrieving it, please email directly and we will >>email a copy to you. >> >>Please let us know if you have any questions. >> >>Thx, >>Dhaval (for the trip-gw team) --=====================_36165873==_.ALT Content-Type: text/html; charset="us-ascii" <html> <font size=3>Hi Anna,<br> <br> Please see comments inlined below..<br> <br> At 02:34 PM 6/10/2002 -0400, Anna Cheung wrote:<br> </font><blockquote type=cite cite><font face="arial" size=2 color="#0000FF">Hi Dhaval, </font><font size=3><br> <br> </font><font face="arial" size=2 color="#0000FF">I have some questions after reading the trip-gw draft, and hope </font><font size=3><br> </font><font face="arial" size=2 color="#0000FF">you or somebody in the work group could clarify. </font><font size=3><br> <br> </font><font face="arial" size=2 color="#0000FF">Thanks</font><font size=3><br> </font><font face="arial" size=2 color="#0000FF">/Anna </font><font size=3><br> <br> <br> </font><font face="arial" size=2 color="#0000FF">1) Available Capacity (AC) is defined as non-transitive<br> in the draft. I'm just wondering if it should be transitive instead.<br> The reason being if the LS fronting the GW does not advertises<br> the AC of the route to other LS's in the core of the network, then there <br> could be cases where a route is selected with higher TotalCapacity but<br> lower available Capacity. (From the draft, it seems to be<br> the reason it is defined as non-transitive is due to the fact that<br> it might change frequently. But if the GW only advertises when<br> somethrehold is crossed, then the frequency might not be a big problem<br> for the LS ??)</font></blockquote><br> This would add another level of complexity and gets into tuning<br> to avoid staleness etc. We analyzed this and thought of not including at this time.<br> <br> <blockquote type=cite cite><font size=3> <br> </font><font face="arial" size=2 color="#0000FF">2) Section 4.4 prefix attribute, is it saying that the prefix attribute is<br> a conditional mandatory attribute for the trunk address family and CIC<br> address family? I'm a bit confused by the statement "conditional mandatory <br> (if reachable routes is present)" </font><font size=3><br> </font></blockquote><br> This means that if the reachableroutes attribute is present, then the prefix<br> attribute must be present. A <font size=3>length of zero for the prefix attribute indicates a prefix <br> that matches all prefixes for the respective address family type and application protocol.<br> I thought I had included that statement in the draft but loox like it got removed while re-arranging<br> the Prefix attributes section. Will add it in the next rev.<br> <br> </font><blockquote type=cite cite><font face="arial" size=2 color="#0000FF">3) When a GW advertises a route of type trunk address family (or CIC address <br> family), if attribute prefix attribute is NOT present, does it mean the advertised<br> trunk (or CIC) can be used to reach ANY prefix? </font></blockquote><br> No. Please see note above.<br> <br> <blockquote type=cite cite><font size=3> <br> </font><font face="arial" size=2 color="#0000FF">4) Can you please clarify why carrier attribute must not be used with trunk family <br> and trunk attribute must not be used with the CIC family ?</font></blockquote><br> Introduces hierarchy and complexity amongst other reasons and was not deemed important <br> enough at this stage. We have noted it as a future issue.<br> <font size=3> <br> </font><blockquote type=cite cite><font face="arial" size=2 color="#0000FF">5) Reading section 4.10.1, I'm under the impression that an LS may receive <br> alternative routes from the same gateway for a given destination. Is this true? </font><font size=3><br> </font><font face="arial" size=2 color="#0000FF"> Doesn't the subsequent advertisment of a given route from the same GW just replaces <br> the previous advertisement?</font></blockquote><br> Section 4.10.1 tries to address the case where the LS may receive alternative routes<br> for the same destination from *different* gateways. If the same gateway wants to advertise<br> alternative routes for a given destination, then it can send them in one update to the LS.<br> <br> <blockquote type=cite cite><font face="arial" size=2 color="#0000FF">6) When a GW advertise an update with the follows: <br> - trunk address family, <br> - trk value=trk1, <br> - prefix attribute=1613, <br> - nexthop = NH1</font><font size=3><br> <br> </font><font face="arial" size=2 color="#0000FF">The update is saying that route trk1 and prefix 1613 is<br> reachable via NH1. Could we also interpret that 1613 <br> is reachable via NH1? </font></blockquote><br> Yes, if you don't care about trk1.<br> <br> <font size=3>Hope this helps.<br> <br> Thx,<br> Dhaval<br> <br> <blockquote type=cite cite> </font> <dl><font face="tahoma" size=2> <dd>-----Original Message----- <dd>From:</b> Dhaval Shah [<a href="mailto:[email protected]" eudora="autourl">mailto:[email protected]</a>] <dd>Sent:</b> Sunday, June 09, 2002 2:20 PM <dd>To:</b> [email protected] <dd>Subject:</b> [IPTEL] Fwd: draft-ietf-iptel-trip-gw-00.txt has been posted<br> <br> </font><font size=3> <dd>Hi Folx,<br> <br> <dd>Just a follow-up to the draft posting.<br> <br> <dd>The main changes in this version are: <dd>- Removed Carrier-Trunkgroup attribute and address family and <dd> references to it. <dd>- Added Terminology and Definitions section. <dd>- Updated CallSuccess attribute. <dd>- Added Prefix attribute. <dd>- Added Carrier attribute. <dd>- Added TrunkGroups attribute. <dd>- Added TrunkGroup Address Family. <dd>- Added Carrier Address Family. <dd>- Added Route Consolidation section. <dd>- Added some more references.<br> <br> <dd>A couple of open issues that come to mind are: <dd>- International carrier ids <dd>- Jonathan had a suggestion regarding having an update rate capability that the LS would send <dd>to the gateway. The purpose would be to have the gateway not send updates at a rate higher than the <dd>specified number.<br> <br> <dd>Thx, <dd>Dhaval<br> <br> <br> <br> <br> <br> <br> <br> <blockquote type=cite cite> <dd>Date: Fri, 07 Jun 2002 07:51:22 -0700 <dd>To: [email protected] <dd>From: Dhaval Shah <[email protected]> <dd>Subject: draft-ietf-iptel-trip-gw-00.txt has been posted <dd>Cc: [email protected], [email protected], [email protected], Rajneesh Kumar <[email protected]> <dd>Bcc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]<br> <br> <dd>Hi Folx,<br> <br> <dd>The draft is now available on the ftp server: <dd><a href="ftp://ftp-eng.cisco.com/dhaval/draft-ietf-iptel-trip-gw-00.txt" eudora="autourl">ftp://ftp-eng.cisco.com/dhaval/draft-ietf-iptel-trip-gw-00.txt</a><br> <br> <dd>If someone has problems retrieving it, please email directly and we will <dd>email a copy to you.<br> <br> <dd>Please let us know if you have any questions.<br> <br> <dd>Thx, <dd>Dhaval (for the trip-gw team) </blockquote></font> </dl></blockquote></html> --=====================_36165873==_.ALT--