Subject: [rbridge] text on hop-count in updated charter

From: jaihyung at etri.re.kr (조재형)
Date: Fri, 11 Mar 2005 08:33:48 +0900

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/rbridge/attachments/20050311/282f6961/attachment.html

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 10 Mar 2005 16:26:03 -0800

??? wrote:
>  
> 
> Dear Joe Touch
> 
>  
> 
> please read followings
> 
> 
> 
> | Hopcounts are required where routing is locally updated; in those cases,
> | the global routing state may temporarily pass through configurations
> | that have transient routing loops.
> 
>  
> 
> 
> I believe you are confining applicable routing technology just in
> link-status protocols.

No; I am assuming that TRILL will not _force_ a single specific interior
routing protocol, but would still like to have a common encapsulation
header.

> I thought TRILL is still open to *the third way* of
> distributing routing information. If the charter doesn't limit the choice of
> routing algorithm, there are some different routing algorithms we can
> consider.
> 
> I am wondering..., if TRILL may give up link-status algorithm and
> willing to experiment yet unknown routing algorithm, .. if there is a
> clear benefit from new solution.

That seems unlikely, IMO. The point of TRILL, at least last I checked
(things seem to be in flux, though) was to enable the use of
well-understood routing protocols as an alternative to just
spanning-tree. While new protocols may also be used, it isn't clear that
a single one needs to be fixed a-priori; that could be negotiated.

> ... or is there a reason people stick to IS-IS?> 
> if it is not...., I think  (routing update = looping)  is not always
> correct assumption to all routing method.
> 
> | ATM-MPLS is a circuit-oriented technology (on both counts). The current
> | charter doesn't want to assume only circuits inside an rbridge campus,
> 
> which part of charter specifically exclude circuit technology inside the 
> rbridge?

"does not want to assume only circuits" does not exclude their use; it
excludes their EXCLUSIVE use. I.e., it assumes we may want to support
others, which is already true (IS-IS, as you mention).

That means either the encapsulation protocol is routing-protocol
specific (which seems unnecessarily complex) or it has a TTL (which
seems a small overhead to pay for flexibility, as well as providing a
safety check if circuits get misconfigured).

> MPLS is also a circuit-oriented technology.
> 
> Is MPLS style bridge control being excluded ?
> 
> I believe employing MPLS forwarding technique within rbridge might be
> useful for layer-2 traffic engineering, although it may possibly
> conflict with CCAMP.
> 
> If some *virtual circuit* technology can be considered, there are
> several loop prevention/detection techique we can discuss.

See above; I don't think this is relevant to whether TTLs need to be
supported.

> |and we expect that the rbridge header will not depend on the routing
> |protocol used. As a result, since packet forwarding may be used (in
> |fact, IMO is more likely to be used), hopcounts are necessary.
> 
> I think this is irrelevant issue. No one proved dependancy of
> routing algorithm and hopcount.

This is well-known for some routing protocols, notably any hop-by-hop
protocols that do not require global synchronization for routing updates.

> |(unless you know of a better or different way to enforce loop detection
> |that does not depend on the routing protocol used).
> 
> perhapse, we may.....
> 
> 
> Dr. Jaihyung Cho
> ETRI, Korea
> phone :       042) 860-5514
> oversea: +82-42-860-5514
> fax:         +82-42-861-5550
> 
> 
> 
> 
> 
> Web Bug from MailScannerWebBug
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050310/650f73cc/signature.bin