RE: Inter-area requirements draft
"Ash, Gerald R (Jerry), ALABS" <[email protected]> Tue, 4 Nov 2003 10:13:23 -0600
| Newsgroups | gmane.ietf.tewg |
|---|---|
| Message-ID | <9473683187ADC049A855ED2DA739ABCA0201EF03@KCCLUST06EVS1.ugd.att.com> |
Jim, > I believe the only comment I have heard on my draft: > > draft-boyle-tewg-interarea-reqts-00.txt > > Is that it shouldn't cover interas (from the interas draft authors). I made this comment (among others) to the list on 6/27: 'I agree that both inter-area TE and inter-AS TE should be progressed together, and would not favor progressing inter-AS TE without also progressing inter-area TE.' It doesn't matter so much that inter-AS and inter-area requirements are progressed in 1 or 2 I-Ds, but it does matter that *both* are progressed. > I had meant to remove those portions from the draft and re-issue > prior to the meeting, but I did not get around to it. > > I have a question though, if I contained the scope to inter-area, do > folks believe it serves a need? Yes, as above. > If so, I would like to do this re-issue directly after the meeting. > Then of course the next questions would be if I should do it as a WG > document, and if there are other comments folks have. WG document OK with me. I also made a few other specific comments in my posting on 6/27: 1. Some of the functionality's in Section 1.1 should be more specific, e.g., - what bandwidth specification: Tspec parameters? overbooking considerations? 'reserved bandwidth' as per DSTE? - what priorities: setup priority? holding priority? preemption priority as per DSTE? 2. Section 3.1: "when the source is more than one area away from the destination, the destination's border router may send back a Path Error. Ideally, the source's border router would try another border router into the destination's area, however with current protocol, the Path Error will propagate to the source." sounds like a requirement for [crankback] functionality http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-07.txt 3. Section 3.4: " Diffserv TE should be directly translatable at border-routers, as the class-type of an LSP is explicit for class-types greater than 0 and not-existent in the path message for class-type 0." Are you proposing to standardize class-type 0 to mean best effort? Section 1.4 also refers to 'conventions' for class-types 0, 1, and 2. Thanks, Jerry