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

From: Don Goodspeed <[email-masked]>
Date: Fri, 18 Oct 2002 18:53:22 -0400

OK.  I've had more time to think about this, and I withdraw
my earlier suggestions.  Listing the DR would lead to routing
loops (between DR and BDR) and/or blackholes (where the DR is
not a TE-capable router).

I also do not suggest we withdraw the TE LSAs when there are
two or more routers on a multi-access network.  It's better to
just ignore the TE LSAs that do not have a remote IP than to
flood, withdraw, flood again, etc.

Had anyone ever suggested the concept of a TE-capable DR?
It could generate a TE version of a Network LSA listing the
TE-capable routers on a link.  TE applications would then
be able to use the link for non-bandwidth TE uses.

Let me know if this has been tried and knocked down...
-don

 --- On Fri 10/18, Acee Lindem  wrote:
From: Acee Lindem [mailto: [email-masked]]
To: [email-masked]
Date: Fri, 18 Oct 2002 00:12:09 -0400
Subject: Re: Comments on draft-katz-yeung-traffic-08.txt

> Hi Kireeti,
>
> Kireeti Kompella wrote:
>
> > Hi Acee,
> >
> > On Thu, 17 Oct 2002, Acee Lindem wrote:
> >
> >
> >>Comments:
> >>
> >>     - The LSA Header Diagram in section 2.3.1 does not reflect
> >>       the fact that the instance has been extended to 24 bits.
> >>
> >
> > Thanks.  Someone else also pointed this out.
> >
> >
> >>     - 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."
> >>
> >
> > Any objections?  If not, I will make this change.
> >
> >
> >>     - 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.
>
>
> 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
> > and is running code, so changing the spec to omitting this TLV at
> > this point would cause more problems than it would solve.
>
>
> 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.
>
>
> >
> >
> >>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.
> >>
> >
> > 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.
>
>
> 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.
>
>
> >
> > 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 ....
>
>
> We're working towards that goal.
>
> Thanks,
>
>
> >
> > Kireeti.
> >
> >
>
>
> --
> Acee
>

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 19 Oct 2002 01:29:47 -0700

>Let me know if this has been tried and knocked down...
isn't it much easier to just generate a single Network LSA with all routers
and then apply
a reverse check for the TE capability ? Otherwise you'll probably need a
different router priority for TE DR than normal DR, split LANs with 2
different DRs and all such complicated jazz ?

    -- tony

---

From: Rohit Dube <[email-masked]>
Date: Fri, 18 Oct 2002 19:37:30 -0400

On Fri, 18 Oct 2002 18:53:22 -0400 Don Goodspeed writes:
[snip]
=>I also do not suggest we withdraw the TE LSAs when there are
=>two or more routers on a multi-access network.  It's better to
=>just ignore the TE LSAs that do not have a remote IP than to
=>flood, withdraw, flood again, etc.

Don,

Unless I misunderstand you completely, one cannot ignore TE LSAs
which don't have a remote-ip TLV. This is because there are already
implementations out there which don't send the TLV.

Withdrawing the TE LSAs if more than one neighbor is detected is
not that much work and is beneficial to nodes down/upstream from
where this condition is detected. To answer your question from
the previous mail, one could disable the link for TE till an operator
intervenes or resend the TE LSA when the neighbor count comes back to 1.
Either operation would be correct.

Best,
--rohit.

---

From: Naiming Shen <[email-masked]>
Date: Fri, 18 Oct 2002 23:07:55 -0700

there is no need to withdraw TE LSAs while more than two routers
start to exist on the multi-access network. the TE draft says
clearly there will be limitations(verses the p2p link), but this
does not at all mean you can not run TE on that multi-access link
with multiple-routers. it's perfectly "fine" to setup TE tunnels
with multiple routers over the same multi-access link.

will this cause problem in terms of congestion? yes, it can. but

 - even over p2p TE links, we only reserve the bandwidth for
   the TE links, we can still "overbook" the bandwidth and congest
   the p2p TE links.

 - TE is usually used to route traffic for the purpose of saving
   cost in the long-haul p2p links. those multi-router/multi-access
   link usually is close to the edge of the network. even there is
   congestion going on, there probably is not much you can do to
   route around them. If there is congestion, simple add more
   bandwith there and the cost should be low.

since there will be a need to do TE with multiple routers on a LAN,
i think specifying the remote ip of 0.0.0.0 is OK, the draft probably
should say "or this TLV can be omitted". specifying a real IP address
even in the case of only two routers on the LAN does not sound right.
for p2p link, you have to specify the neighbor IP address, since
otherwise, in the case of parallel p2p links, there will be no
other indication to flag the match at both ends. for LAN, you have
the DR interface address to tie them ends together.

thanks.

 ] On Fri, 18 Oct 2002 18:53:22 -0400 Don Goodspeed writes:
 ] [snip]
 ] =>I also do not suggest we withdraw the TE LSAs when there are
 ] =>two or more routers on a multi-access network.  It's better to
 ] =>just ignore the TE LSAs that do not have a remote IP than to
 ] =>flood, withdraw, flood again, etc.
 ]
 ] Don,
 ]
 ] Unless I misunderstand you completely, one cannot ignore TE LSAs
 ] which don't have a remote-ip TLV. This is because there are already
 ] implementations out there which don't send the TLV.
 ]
 ] Withdrawing the TE LSAs if more than one neighbor is detected is
 ] not that much work and is beneficial to nodes down/upstream from
 ] where this condition is detected. To answer your question from
 ] the previous mail, one could disable the link for TE till an operator
 ] intervenes or resend the TE LSA when the neighbor count comes back to 1.
 ] Either operation would be correct.
 ]
 ] Best,
 ] --rohit.

- Naiming

---

From: Rohit Dube <[email-masked]>
Date: Sat, 19 Oct 2002 14:02:10 -0400

Hello Naiming,

Thanks for your thoughtful comments. There are two ways one can
look at TE over multi-access links -

a) Only 2 devices are allowed. This was my interpretation based
   on section 1.2. My take is that if the condition is violated
   (ie there are more than 2 devices) one needs to spell out
   how to react to this.
b) More than 2 devices are allowed which can work given the
   limitations you list below. If this is allowed, we need
   to explicitly say so and indicate any additional procedures
   in the draft.

Either way, I think the item needs to be clarified.

Best,
--rohit.

On Fri, 18 Oct 2002 23:07:55 -0700 Naiming Shen writes:
=>there is no need to withdraw TE LSAs while more than two routers
=>start to exist on the multi-access network. the TE draft says
=>clearly there will be limitations(verses the p2p link), but this
=>does not at all mean you can not run TE on that multi-access link
=>with multiple-routers. it's perfectly "fine" to setup TE tunnels
=>with multiple routers over the same multi-access link.
=>
=>will this cause problem in terms of congestion? yes, it can. but
=>
=> - even over p2p TE links, we only reserve the bandwidth for
=>   the TE links, we can still "overbook" the bandwidth and congest
=>   the p2p TE links.
=>
=> - TE is usually used to route traffic for the purpose of saving
=>   cost in the long-haul p2p links. those multi-router/multi-access
=>   link usually is close to the edge of the network. even there is
=>   congestion going on, there probably is not much you can do to
=>   route around them. If there is congestion, simple add more
=>   bandwith there and the cost should be low.
=>
=>since there will be a need to do TE with multiple routers on a LAN,
=>i think specifying the remote ip of 0.0.0.0 is OK, the draft probably
=>should say "or this TLV can be omitted". specifying a real IP address
=>even in the case of only two routers on the LAN does not sound right.
=>for p2p link, you have to specify the neighbor IP address, since
=>otherwise, in the case of parallel p2p links, there will be no
=>other indication to flag the match at both ends. for LAN, you have
=>the DR interface address to tie them ends together.
=>
=>thanks.

---

From: Sina Mirtorabi <[email-masked]>
Date: Mon, 21 Oct 2002 11:26:43 -0700

Rohit,

> -----Original Message-----
> From: Mailing List [mailto:[email-masked]]On Behalf Of Rohit
> Dube
> Sent: Saturday, October 19, 2002 11:02 AM

this is not how I would interpret.
section 1.2 of the draft states:

"The extensions specified in this document capture the reservation state of
point-to-point links. The reservation state of multiaccess links is not
accurately _reflected_, except in the special case that there are only two
devices in the multiaccess subnetwork."

>    to explicitly say so and indicate any additional procedures

yes this is how I would read the draft...
as far as for additional procedure, what else is needed to define a TE over
multi-acess link having more than two attached routers? ( given the
limitation for reservation state )

since 'Maximum Reservable Bandwidth' is configurable it is up to the
operator to set a value that reflect a bit better the number of routers
attached to the multi-acess network for example if there are N routers
attached and we do not want to oversubscribe one could set

Maximum Reservable Bandwidth <= Maximum Bandwidth / ( N-1 )
where N is the number of routers attached to multi-acess link

Sina

---

From: Rohit Dube <[email-masked]>
Date: Mon, 21 Oct 2002 18:17:47 -0400

Hi Sina,

Some comments inline [..]

On Mon, 21 Oct 2002 11:26:43 -0700 Sina Mirtorabi writes:
=>Rohit,
=>
=>> -----Original Message-----
=>> From: Mailing List [mailto:[email-masked]]On Behalf Of Rohit
=>> Dube
=>> Sent: Saturday, October 19, 2002 11:02 AM
=>> To: [email-masked]
=>> Subject: Re: Comments on draft-katz-yeung-traffic-08.txt
=>>
=>>
=>> Hello Naiming,
=>>
=>> Thanks for your thoughtful comments. There are two ways one can
=>> look at TE over multi-access links -
=>>
=>> a) Only 2 devices are allowed. This was my interpretation based
=>>    on section 1.2. My take is that if the condition is violated
=>>    (ie there are more than 2 devices) one needs to spell out
=>>    how to react to this.
=>
=>this is not how I would interpret.
=>section 1.2 of the draft states:
=>
=>"The extensions specified in this document capture the reservation state of
=>point-to-point links. The reservation state of multiaccess links is not
=>accurately _reflected_, except in the special case that there are only two
=>devices in the multiaccess subnetwork."

Fair enough. However when I read the draft the first time, my conclusion
was "since reservation state is not accurately reflected for more than two
nodes, it would be dangerous to use more than two nodes on a multi-access
networl". Some other folks that I know interpreted it similarly.

=>
=>
=>> b) More than 2 devices are allowed which can work given the
=>>    limitations you list below. If this is allowed, we need
=>>    to explicitly say so and indicate any additional procedures
=>>    in the draft.
=>>
=>
=>yes this is how I would read the draft...
=>as far as for additional procedure, what else is needed to define a TE over
=>multi-acess link having more than two attached routers? ( given the
=>limitation for reservation state )
=>
=>since 'Maximum Reservable Bandwidth' is configurable it is up to the
=>operator to set a value that reflect a bit better the number of routers
=>attached to the multi-acess network for example if there are N routers
=>attached and we do not want to oversubscribe one could set
=>
=>Maximum Reservable Bandwidth <= Maximum Bandwidth / ( N-1 )
=>where N is the number of routers attached to multi-acess link
[snip]

This will not require defining anything new, but it does require
being a bit more verbose in dealing with multi-access networks.
If the draft says nothing more, some implementors will likely force two
nodes and others will allow more than two. The two types of implementations
in the same network will provide surprising and undocumented results.
Adding a small section on the topic is a small price to pay to avoid such
problems down the road.

Regards,
--rohit.

---

From: Sina Mirtorabi <[email-masked]>
Date: Mon, 21 Oct 2002 15:58:06 -0700

Rohit,

> Adding a small section on the topic is a small price to pay to avoid such

thanks for the comments, personally I do not see any text in the draft
stating that more than two routers on the multi-access network is not
allowed as the draft just talk about " reflecting reservation state ".

If you think that this need to be explicitly mentioned probably section 2.1
could be rephrased in order to state that TE over multi-access link having
more than two attached routers, does not require any additional information
to the described document however the reservation state of multi-access
links will not be accurately reflected.

thanks
Sina

---

From: Rohit Dube <[email-masked]>
Date: Mon, 21 Oct 2002 19:14:10 -0400

Hi Sina,

Just to clarify a bit more, there are two points here -
a) Should more than 2 nodes be allowed on multi-access links or
   not.
b) Be clear about the decision in (a) and reflect it appropriately
   in the document.

WRT (a), I am fine with either approach but prefer the former (at max
2 nodes) as TE with > 2 nodes on the same multi-access links seems
a bit un-natural when compared to the two node case. The two node
case is well understood and known to work.

Have you (or others) implemented OSPF-TE with more than two nodes?
Any experiences to share?

--rohit.

---

From: Sina Mirtorabi <[email-masked]>
Date: Tue, 22 Oct 2002 06:47:05 -0700

Rohit,

> Sent: Monday, October 21, 2002 4:14 PM

The current draft does Not prevent TE operation for having more than two
routers on multi-acess link.
I believe that the accuracy of 'reservation state' on multi-acess link Does
Not justify to disallow TE operation in case of more than two routers.

when you have a A-B-C-D path and say A-B path goes over multi-acess link,
what is un-natural if we have more than two routers attached on A-B or just
two ?
a link or segment is defined when you connect two point together, so I don't
see what is un-natural

of course as stated before, it is up to operator to maximize reservation
state in order to better reflect the number of attached router on the link.

> Any experiences to share?

I had a chat with Robert Raszuk and I quote below his thought

--
"Yes I agree with both your & Naming's observations and comments to the
list. Today it is very often that people start to use TE without any
reservations (for one to replace LDP, for second to apply just FRR with
not reservations). Also multiaccess topologies are very common in POPs a
usual place for the TE heads. Therefor I would highly vote not to tear
any TE LSPs when two router multiaccess turns into N router one."
--

Sina

---

From: Rohit Dube <[email-masked]>
Date: Tue, 22 Oct 2002 10:12:39 -0400

Sina,

On Tue, 22 Oct 2002 06:47:05 -0700 Sina Mirtorabi writes:
[snip]
=>The current draft does Not prevent TE operation for having more than two
=>routers on multi-acess link.

It doesn't say it is supported either.

=>I believe that the accuracy of 'reservation state' on multi-acess link Does
=>Not justify to disallow TE operation in case of more than two routers.

Correct. However the operational complexity (compared to just 2 nodes)
is adequate reason to consider the cost-benefit trade off allowing this.

=>
=>when you have a A-B-C-D path and say A-B path goes over multi-acess link,
=>what is un-natural if we have more than two routers attached on A-B or just
=>two ?
=>a link or segment is defined when you connect two point together, so I don't
=>see what is un-natural

Ok let me rephrase. It is not as "straight forward" as the 2 node case.

=>
=>of course as stated before, it is up to operator to maximize reservation
=>state in order to better reflect the number of attached router on the link.

Correct. And in case it didn't get across before - I am not neccessarily
saying this shouldn't be allowed. I am saying (a) there should be
adequate justification for this to be allowed and (b) if it is allowed,
the operation has to be adequately documented.

TE operation over multi-access links with more than 2 nodes is not obvious.
So I would rather not leave the part about how nodes are supposed to behave
in this case undocumented.

=>
=>
=>>
=>> Have you (or others) implemented OSPF-TE with more than two nodes?
=>> Any experiences to share?
=>
=>
=>I had a chat with Robert Raszuk and I quote below his thought
=>
=>--
=>"Yes I agree with both your & Naming's observations and comments to the
=>list. Today it is very often that people start to use TE without any
=>reservations (for one to replace LDP, for second to apply just FRR with
=>not reservations). Also multiaccess topologies are very common in POPs a
=>usual place for the TE heads. Therefor I would highly vote not to tear
=>any TE LSPs when two router multiaccess turns into N router one."
=>--

This is useful. Thanks for forwarding it.

=>
=>
=>Sina
=>
=>>
=>> --rohit.
___

--rohit.