Re: Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

>>7. Sec. 7.2, I tend to agree with Adrian that (ideally) it
>>would seem it should be enough for the head-end to signal the
>>function/service it wants and not the underlying method used
>>by nodes further in path to provide that service. If, as you
>>mention, this is a requirement expressed by many SPs, it would
>>be good to understand why it is so, and for the document to
>>explain a bit about it.
>
>Actually I don't really understand the objection on that point.
>The requirement seems clear for me. If there are several methods
>supported in my network, I want to select the method on a per
>LSP basis in order to have entire control on how the LSP is
>signaled. This will ease LSP management.

But WHY do you want to control the method?

Is it because you believe one of the methods is (may be) sub-functional? If that is the
case, why do we standardise it?

Is it because the methods have different applicability? That is, the methods are suitable
to different functional service requests? If so, why don't you specify the service request
and leave the network to provide the service.

> Basically there won't be hundreds of methods but just two or three
> (contiguous, stiching, nesting..).

Yes. Hopefully :-)

> So it seems quite relevant to have the ability to signal the desired method.

It would really help  to give an example where not being able to control the method would
break the ability to provide the requested service.
(Hint: I think I found one while looking at inter-domain protection paths. But that is a
fairly extreme situation.)

I have serious concerns that allowing this approach means that we risk inter-operability
disconnects.

> Let's have a look at the FRR draft: There are two modes defined, and the
> desired mode (one-to-one or bypass) is signaled on a per-LSP basis (within
> the FRR object). I did not see any objection on that.

I don't think holding the FRR draft up as a shining example is particularly wise.

Given that two solutions were included in the document (because the authors/WG could not
agree on a single solution?) and given that those solutions impacted the service provided
to the service requester it was necessary to allow the requester to control the solution.
In this case, controling the solution is equivalent to controling the service.

Note that this feature raises interoperability questions for FRR-enabled networks.

If, as I say, you are able to demonstrate that the inter-domain solutions impact the
service, then you may be on to something.

>>9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to
>>underscore Adrian's point on specifying the scaling
>>requirements themselves (with respect to areas, amount of
>>flooded info. etc.) rather than the realization of those
>>requirements (by not adding any info. to the LSAs, for example).
>
>It seems that you are OK with 5.3 (no comments)
>"Containment of routing information MUST not be compromised to allow inter-area traffic
>   engineering. Information propagation for path-selection MUST continue
>   to be localized.".
>Thus you should also be OK with 7.4

Or conversely? :-)

> Basically we want to preserve IGP hierachy concept, are there
> objections to that point ?

None has been vocalised.

> This means, for ISPs contributing to this draft, "no leaking of any
> topology related info accross areas".
> Of course, this does not preclude the addition of info to the LSA,
> provided that it is not topology related.

So, for example, you would not be opposed to an LSA that described "aggregated TE
reachability information"?

Enjoy,
Adrian