FW: IESG review draft-ietf-ccamp-gmpls-routing-08.txt

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Answers to the comments/discusses raised.
Pls check if that makes you change your vote

Thanks,
Bert 

-----Original Message-----
From: Kireeti Kompella [mailto:kireeti@juniper.net]
Sent: donderdag 16 oktober 2003 16:08
To: adrian@olddog.co.uk; bwijnen@lucent.com; kireeti@juniper.net;
yakov@juniper.net
Cc: zinin@psg.com
Subject: Re: IESG review draft-ietf-ccamp-gmpls-routing-08.txt


> IESG comments up till now. Pls respond asap so we can use
> it during IESG conf call.
> 
> Steve Bellovin:
> Comment:
> Why is draft-ietf-ccamp-gmpls-routing Proposed instead of Informational?
> (It's clear why the other document in the ballot is Proposed.)

gmpls-routing describes the functionality, gmpls-ospf just describes
the bit formats in OSPF LSAs.  The former is a normative ref in the
latter.

> Ted Hardie:
> Comment:
> Reading through gmpls-routing-08, I kept feeling like something was
> missing--essentially the description of how the routing decisions get
> made in the presence of the new data about Shared Risk Link Groups,
> protection information, and interface switching.  About the only I
> thing that seemed to relate to that was the "if you're looking for
> diverse paths, choose links with different SRLGs" statement.  I then
> decided it was probably in the OSPF doc, but it doesn't seem to be
> in OSPF-gmpls-extensions either.  Is there some other doc that talks
> about how implementors should consider the interactions among these
> pieces of data?  For example, what should you do when one link is
> listed as protected, but in the same SRLG, where another link is a
> different SRLG but unprotected?  Is deterministic behavior on this not
> something which is important?

Detailed descriptions of how TE information is used have never been
given (see for example RFC 3630).  This was a conscious decision.
To take your example, it is up to an implementation (local decision)
how to use SRLG values, or protection characteristics.

I did write an ID describing some of this, but I was told that it had
to be Informational, and it kind of floated among WGs.  I let it drop.
I could resurrect it, if needed.

As for deterministic behaviour, it is not clear this is a must,
or even a nice-to-have.  Finding disjoint paths, or good protection
paths is in many cases hard computationally, so much of this comes
down to heuristics -- not something you can mandate.

> Russ Housley:
> Discuss:
> DISCUSS on draft-ietf-ccamp-ospf-gmpls-extensions-11:
>
> Need a normative reference for IEEE floating point format.

It's in RFC 3630, which is a normative reference here.

> Comment:
> COMMENT on draft-ietf-ccamp-gmpls-routing-08:
>   
>   The Abstract is very weak.  I propose:
> 
>       This document specifies routing extensions in support of carrying
>       link state information for Generalized Multi-Protocol Label Switching
>       (GMPLS).  This document enhances the routing extensions required to 
>       support MPLS Traffic Engineering (TE).
> 
>   Move the single paragraph in section 1 to the top of section 2.  This
>   will turn section 2 into a very good introduction.
> 
>   Spell out first use of SPF.

Okay.

> COMMENT on draft-ietf-ccamp-ospf-gmpls-extensions-11:
> 
>   Move the single paragraph in section 1 to the top of section 2.  This
>   will turn section 2 into a very good introduction.

Okay.

Kireeti.