Re: Draft 2: Summary of discussion on draft-katz-yeung

[Alex Zinin <zinin@psg.com>]

Thomas,

Thanks for the comments, see below.

Monday, January 06, 2003, 12:15:19 PM, Thomas Narten wrote:
> Hi Alex.

> Looks good  overall. Also, I think it is good that you are doing
> this.

> Misc comments... More FYI, you may (or may not) want to tweak words.

> Alex Zinin <alex.zinin@alcatel.com> writes:
>> > Please see my comments below. I would not
>> > recommend using this draft as the basis for building further
>> > TE-extensions to inter-area and mixed networks.

>> Design of the mechanisms for TE in inter-area scenarios is work in
>> progress and subject to the IETF consensus rules. Suresh is welcome to
>> participate in this process.

> Question: is there any expectation that this document will be a basis
> for inter-area work?

The doc will continue to be used for the intra-area part,
as for the inter-area part--it is really not clear what
folks will agree on.

> Will inter-area work indeed be tackled?

>From my knowledge, CCAMP is supposed to have this topic in
its charter at some moment.

> I.e., if it's clear that this document will be the basis for the
> future works, brushing off his concerns seems harder. If this is far
> from clear, saying something to that effect might be better (and less
> confrontational).

I think it is far from clear.

>> > The draft apparently evolved over time with no requirements
>> > document to guide it. The vendors and implementors behind the
>> > draft may have been guided by different set of requirements
>> > and motivations, such as having some working code. Unfortunately,
>> > this ad-hoc approach has a cost. Any new requirements are having 
>> > to be met in a reactive mode and having to be provided as fixes 
>> > on top of this "working" code. This is not right and doesnt bode 
>> > well for the future of the protocol.

>> As Kireeti mentioned, RFC2702 describes some requirements for MPLS TE.
>> Suresh argued though that it does not describe the requirements for
>> the IGP extensions that would satisfy the MPLS TE requirements. I
>> would like to note, however, that this document has been in the WG for
>> a very long time, passed the WG last call, and there is a consensus
>> that the described mechanism is adequate for the intra-area TE task.

> It is not required to have a requirements document. But, a WG does
> need to have requirements, even if they are implicit. Where his too
> late? ignored? rejected? If they were just ignored, that is not good.
> But if they were rejected, that might be citable.

I guess he just wasn't there when this all started. It was a long
time ago, there was an undocumented consensus on what was needed
and the draft documents the consensus on how this should be done.

The funniest thing with this draft is that it is _really_ old, and has
been _very_ widely implemented and deployed. If whatever process we
have followed the development and deployment cycles, the draft would
have been at least at the DS level...

>> > 2. It is confusing to refer an opaque LSA with with a
>> >    specific sub-type as "TE LSA". It makes it sound like a 
>> >    stand-alone OSPF LSA with a distinct LSA type - which 
>> >    is is not. OSPF LSAs define the flooding scope. TE LSA
>> >    does not.
>> >    
>> >    One suggestion would be to refer Opaque LSAs with specific 
>> >    sub-type 1 as "TE-type Opaque LSA".

>> I believe that this is a question of editorial preferences.
>> Changing this terminology wouldn't substantially increase
>> clarity or readability of the document.

> I'll note that I've seen plenty (too many..) documents that aren't
> precise in their terminology. I generally prefer preciseness, but I'd
> let the authors/WG make the call here too. 

>> The consensus within the WG was to use Opaque LSAs to distribute
>> TE information and not change the underlying flooding mechanisms
>> that are critical for the protocol to operate correctly. Given
>> this, I will agree with Kireeti that the draft does not have to
>> spell out what is already natural to the protocol and is not
>> changed. Mentioning this will do no harm, however.

> Note: the above leaves it somewhat ambiguous as to whether you think
> the change should be made or not, and who makes the call. I.e., do you
> want to just leave it up to the authors?

Thanks, I'll add that I'd leave this up to the authors.

Alex