RE: Inter-area requirements draft

[Jim Boyle <jboyle@pdnets.com>]

Jerry - thanks for your comments, here's some answers to your questions.
>
> 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?

Yes, Tspec. Not considering any explicit overbooking, and assuming
that like most implementations reserved bw = Tspec.


> - what priorities: setup priority? holding priority? preemption priority as per DSTE?

Yes, I never liked that there are two, but in general they are the
same concept.  Do you think it is important to point this nuance out?


> 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

Yes, I think crankback could prove useful for inter-region LSP
establishment.  I'm not very familiar with draft-iwata in particular.


> 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.

Well, that is a good question, perhaps especially to the inter-as
requirements authors.  Within a multi-area IGP, I'd say that CT0 (or
CT1, 2, 3...) in one area probably is consistent in each area.  Across
AS boundaries, if you are allowing this, then I would expect for the
meaning to be made bi-laterly.

However, I don't think there is a real need to require that CT1 (for
instance) means anything in particular (e.g. AF).  If you really care
to let the folks along the way to know, you could always throw in a
diff-serv object.

thanks,

Jim

>


> Thanks,
> Jerry
>