Subject: Comments on draft-katz-yeung-traffic-08.txt

From: Acee Lindem <[email-masked]>
Date: Thu, 17 Oct 2002 16:02:15 -0400

Comments:

     - The LSA Header Diagram in section 2.3.1 does not reflect
       the fact that the instance has been extended to 24 bits.

     - Section 2.4.1 - Replace "but for obvious reasons this..."
       with "but this nomenclature is avoid here since the
       OSPF router ID is not necessarily a routable address."

     - Section 2.5.4 - Why 0.0.0.0 for the remote address for
       multiaccess links? It seems the TLV should either be
       omitted or set to the single neighbor address (since
       section 1.2 limits traffic engineering to multiaccess
       networks with 2 devices).

Suggestion:

       - Include "Implications on Graceful Restart" section
         similar to draft-ietf-ccamp-ospf-gmpls-extensions-08.txt.
         Explicitly state that the goal is to maintain
         existing traffic engineered paths while discouraging
         any new ones until reservation state is obtained.

Thanks,
--
Acee

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 17 Oct 2002 13:36:23 -0700

Hi Acee,

>        the fact that the instance has been extended to 24 bits.

Thanks.  Someone else also pointed this out.

>        OSPF router ID is not necessarily a routable address."

Any objections?  If not, I will make this change.

>        networks with 2 devices).

While this document doesn't work ideally for multipoint links with
more that 2 devices, it is used.  Also, this has been implemented
and is running code, so changing the spec to omitting this TLV at
this point would cause more problems than it would solve.

>          any new ones until reservation state is obtained.

Instead, how about specifying explicitly in the ospf gmpls draft
that the text there applies to the base TE doc as well as the GMPLS
extensions?  Otherwise, draft-katz-yeung-traffic-08.txt will need
the graceful restart doc as a normative reference.  Note that the
TE doc has been around for many years, with interoperable
implementations etc., while graceful restart for OSPF much more recent.

BTW, can we start to progress the graceful restart (aka hitless
restart) document?  There are interoperable implementations now, and
while this doc is not as mature as TE, it certainly seems ready ....

Kireeti.

---

From: Rohit Dube <[email-masked]>
Date: Thu, 17 Oct 2002 16:43:32 -0400

Kireeti,

On Thu, 17 Oct 2002 13:36:23 -0700 Kireeti Kompella writes:
[snip]
=>
=>>      - Section 2.5.4 - Why 0.0.0.0 for the remote address for
=>>        multiaccess links? It seems the TLV should either be
=>>        omitted or set to the single neighbor address (since
=>>        section 1.2 limits traffic engineering to multiaccess
=>>        networks with 2 devices).
=>
=>While this document doesn't work ideally for multipoint links with
=>more that 2 devices, it is used.  Also, this has been implemented
=>and is running code, so changing the spec to omitting this TLV at
=>this point would cause more problems than it would solve.

One major commercial implementation that I am aware of does omit this
TLV. Another commercial implementation sets it to the originating routers
IP address. IMHO, this point could use a cleanup along the lines that
Acee suggested to further interoperability.

Best,
--rohit.

---

From: Acee Lindem <[email-masked]>
Date: Fri, 18 Oct 2002 00:12:09 -0400

Hi Kireeti,

Kireeti Kompella wrote:

> more that 2 devices, it is used.

Should a router withdraw it's TE LSA for the link if it
detects > 2 routers on a multi-access network?

> Also, this has been implemented

I don't see how there could be any problems since the all zeros
address can't be of much use and section 2.4.2 says only the
Link Type and Link ID TLVs are mandatory.

> implementations etc., while graceful restart for OSPF much more recent.

That sounds like a great idea. I still think it should be explicitly
stated that the goal is to maintain existing traffic engineered paths while
discouraging any new ones until reservation state is obtained.

> while this doc is not as mature as TE, it certainly seems ready ....

We're working towards that goal.

Thanks,

--
Acee

---

From: Rohit Dube <[email-masked]>
Date: Fri, 18 Oct 2002 10:04:42 -0400

Acee,

On Fri, 18 Oct 2002 00:12:09 -0400 Acee Lindem writes:
=>> While this document doesn't work ideally for multipoint links with
=>> more that 2 devices, it is used.
=>
=>
=>Should a router withdraw it's TE LSA for the link if it
=>detects > 2 routers on a multi-access network?

I think this is a good idea as this will prevent non-adjacent nodes from
(potentially) getting confused.

Best,
--rohit.

---

From: Acee Lindem <[email-masked]>
Date: Tue, 22 Oct 2002 16:28:38 -0400

Kireeti,

Can we close on the remaining issues?

   1. With respect to the Remote Interface IP Addres TLV, is
      there really any reason to include it with a value of 0.0.0.0
      for a multi-access link? I can't see how there could be
      a compatibility issue since the rough count on the list
      revealed more implementations that omitted the TLV
      altogether.

   2. With respect to more than two routers on a multi-access
      network, it seems there is considerable support for
      allowing this even though it is not fully specified.
      Could you add something along these lines to the second
      paragraph of the limitations section:

      "Operation over multiaccess links with more than two
       devices is not specifically prohibited. TE operation
       and the use of reservation state is a matter for
       further study".

Thanks,
Acee

--
Acee

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 22 Oct 2002 14:10:30 -0700

Hi Acee,

> Can we close on the remaining issues?

I have a question.  Last Call (for the nth time) finished on Oct 14.
Is there ever an end to this process?

>       revealed more implementations that omitted the TLV

This is a nitpick.  Is there a real problem being solved here?  It's
been specified, perhaps not optimally, but wasting 4 bytes is not a
burning issue.  Besides, the memo doesn't say that the Remote Address
TLV is mandatory.  As you say, some implementations use this, some skip
this, and they all interoperate.

I really would prefer not to make any changes here unless there is a
good reason.

>        and the use of reservation state is a matter for

Another nitpick.  The current text states that "The reservation
state of multiaccess links is not accurately reflected" ... what
the new wording accomplish?  The current text does not prohibit
use if there are more than two devices; it states the limitations.

However, if you think that the new wording is preferable, I will
change this to "Operation over multiaccess links with more than two
devices is not specifically prohibited.  More accurate description of
the reservation state of multi-access networks is for further study."

The change I'll make for sure is updating the figure in 2.3.1.

Kireeti.

---

From: Acee Lindem <[email-masked]>
Date: Tue, 22 Oct 2002 17:33:29 -0400

Hi Kireeti,

> Is there ever an end to this process?

I don't expect to have any comments on IETF wide last call.

> This is a nitpick.

Have you ever met a programmer who didn't?

> Is there a real problem being solved here?  It's

I was just thinking that a document going to proposed standard would
be better served with a single way of handling multi-access links. If
I'm the only one with this concern then I'll relent.

> the reservation state of multi-access networks is for further study."

There was considerable discussion on this topic and I believe
this a good addition.

--
Acee

---

From: Rohit Dube <[email-masked]>
Date: Tue, 22 Oct 2002 17:45:33 -0400

Kireeti,

On Tue, 22 Oct 2002 17:33:29 -0400 Acee Lindem writes:
=>>>   1. With respect to the Remote Interface IP Addres TLV, is
=>>>      there really any reason to include it with a value of 0.0.0.0
=>>>      for a multi-access link? I can't see how there could be
=>>>      a compatibility issue since the rough count on the list
=>>>      revealed more implementations that omitted the TLV
=>>>      altogether.
=>>>
=>>
=>> This is a nitpick.
=>
=>
=>Have you ever met a programmer who didn't?
=>
=>> Is there a real problem being solved here?  It's
=>> been specified, perhaps not optimally, but wasting 4 bytes is not a
=>> burning issue.  Besides, the memo doesn't say that the Remote Address
=>> TLV is mandatory.  As you say, some implementations use this, some skip
=>> this, and they all interoperate.
=>>
=>> I really would prefer not to make any changes here unless there is a
=>> good reason.
=>
=>
=>I was just thinking that a document going to proposed standard would
=>be better served with a single way of handling multi-access links. If
=>I'm the only one with this concern then I'll relent.
[snip]

I think the clarification is worth making - it is a small addition
in terms of the actual edit but it serves to warn an implementor to
be "liberal" in accepting this TLV.

Something like "For multi-access networks, the remote-ip TLV can be
omitted or the remote-ip set to 0.0.0.0". (This was previously suggested
on the mailing list).

Regards,
--rohit.

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 23 Oct 2002 11:19:49 -0700

Hi Acee,

> I don't expect to have any comments on IETF wide last call.

Can I hold you to that?  :-)

> Have you ever met a programmer who didn't?

None that I respect :-)

> I'm the only one with this concern then I'll relent.

It wouldn't be better served changing something *that works and
interoperates* at the last minute.

New wording (the part after the semicolon is new):

| If the Link Type of the link is Multiaccess, the Remote
| Interface IP Addess is set to 0.0.0.0; alternatively, an implementation
| MAY choose not to send this sub-TLV.

> There was considerable discussion on this topic and I believe

Done.  New wording:

| The reservation state of multiaccess
| links may not be accurately reflected, except in the special case that
| there are only two devices in the multiaccess subnetwork.  Operation
| over multiaccess networks with more than two devices is not specifically
| prohibited.  More accurate description of the reservation state of
| multi-access networks is for further study.

Note one other minor change: "reservation state ... is not ..." to
"reservation state ... may not be ..."

Can we ship this out now?

Kireeti.

---

From: Acee Lindem <[email-masked]>
Date: Wed, 23 Oct 2002 14:22:39 -0400

Sounds good to me.

--
Acee