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

[Thomas Narten <narten@us.ibm.com>]

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? Will inter-area work indeed be tackled?

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

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

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

Thomas