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

From: Don Goodspeed <[email-masked]>
Date: Fri, 18 Oct 2002 14:35:15 -0400

All,

What would be the implications of stating that all non-DR routers
on a multi-access network list the DR, and the DR should list the
BDR.  Of course, what happens when only one router is DR-eligible?

If we went with the scheme below, I assume we would then re-adver-
tise the TE LSA when the # of other routers reaches 1 or 0?

-don

 --- On Fri 10/18, Rohit Dube  wrote:
From: Rohit Dube [mailto: [email-masked]]
To: [email-masked]
Date: Fri, 18 Oct 2002 10:04:42 -0400
Subject: Re: Comments on draft-katz-yeung-traffic-08.txt

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

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

---

From: "Naidu, Venkata" <[email-masked]>
Date: Fri, 18 Oct 2002 22:09:49 -0400

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

  Regardless of all these discussions about "Representing a
  BC network (more specifically shared media nets)" in the
  control plane and exchanging such information with other
  routers, the more important and yet unresolved issues are
  related to QoS in shared media. No one yet resolved how
  to reserve bw (even worst case of best-effort) in shared
  media and dynamically adjusting the forwarding plane to
  scale well for connection oriented or connectionless tunnels.

  I think the draft is under specified. (Kireeti already
  knows my concern very well :) - so my take is a strict
  specification inorder to remove unnecessary future
  interoperability issues.

  Finally, forwarding plane requirements should drive
  representation of control plane. Definitely not other way.
  May be we can resolve some TE issues by these suggestions
  but can't guarantee a specific service.

  It is not a good idea to say that "We can do TE when 2 routers
  are in the LAN but we can't quarantee anything after that".
  Instead it is better to say "We will give you a *complete*
  specification/design when all issues/requirements are clear".

  Hope you all agree. Thank You!

--
Venkata.

---

From: "Li, Ke Qin (Peter)" <[email-masked]>
Date: Tue, 22 Oct 2002 10:21:55 +0800

Hi,

In my opinion, when there are more than 2 routers on a multi-access link, it
is difficult (if not impossible) to define and update Maximum bandwidth,
Maximum reservable bandwidth and Unreserved bandwidth between each pair of
routers. At the same time, the main concern of MPLS, which is the user of TE
LSDB, is point-to-point link. Thus, I think more than 2 nodes on
multi-access link should not be allowed. Or even multi-access link should
not be described in TE LSAs.

Keqin Li

> -----Original Message-----
> From: Rohit Dube [mailto:[email-masked]]
> Sent: Tuesday, October 22, 2002 7:14 AM
> 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: "Naidu, Venkata" <[email-masked]>
Date: Tue, 22 Oct 2002 10:34:03 -0400

Sina,

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

 very unnatural. MPLS-TE as it stands now considers links
 characteristics (mostly bw) to do source routing. If you want
 to do TE without considering any reservations, how are you
 planning to signal the source computed path ? RSVP-TE as
 it stands now, is not tailored to run on non-p2p shared medias
 (neither the label distribution not label signaling are
 specified in RSVP-TE when more than 2 router are in the LAN).

 At least, tell me how are you planning to do TE (fine, without
 any QoS) once you distributed control plane topology information
 using OSPF ? How will you signal the path once you got the
 topology info for all the routers (> 2) in broadcast net ?
 please don't tell me you will do static TE, manual tunnels
 after all :)

 We are trying to specify things in routing protocols where
 there is no support in other modules. Maybe, we are trying to do
 backward engineering - first specify topology in OSPF-TE then
 research on how to computer path using CSPF then kludge TE
 (without QoS, without mapping qos bits to layer 2 headers)
 then think about how to distribute labels using signaling
 protocols then think about problems in forwarding plane etc etc
 - every thing is backward-engineered :)

--
Venkata.

---

From: Don Goodspeed <[email-masked]>
Date: Wed, 23 Oct 2002 14:53:26 -0400

With these changes, I have no further issues.  Looks good!.
-don

 --- On Wed 10/23, Acee Lindem  wrote:
From: Acee Lindem [mailto: [email-masked]]
To: [email-masked]
Date: Wed, 23 Oct 2002 14:22:39 -0400
Subject: Re: Comments on draft-katz-yeung-traffic-08.txt

> Sounds good to me.
>
> Kireeti Kompella wrote:
>
> > Hi Acee,
> >
> > On Tue, 22 Oct 2002, Acee Lindem wrote:
> >
> >
> >>I don't expect to have any comments on IETF wide last call.
> >>
> >
> > Can I hold you to that?  :-)
> >
> >
> >>>This is a nitpick.
> >>>
> >>Have you ever met a programmer who didn't?
> >>
> >
> > None that I respect :-)
> >
> >
> >>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.
> >>
> >
> > 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.
> >
> >
> >>>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."
> >>>
> >>
> >>There was considerable discussion on this topic and I believe
> >>this a good addition.
> >>
> >
> > 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.
> >
> >
>
>
> --
> Acee
>