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

From: jaihyung at etri.re.kr (조재형)
Date: Thu, 10 Mar 2005 22:22:58 +0900

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

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Thu, 10 Mar 2005 08:39:15 -0800

Well, the encapsulation is really link dependent. So on MPLS, indeed, as
you point
out, you don't need a hop count. We haven't written down exactly how RBridge
would work over MPLS, but I think no extra information is needed...an MPLS
header is stuck onto the frame by the ingress RBridge, and removed by the
egress RBridge. (Does anyone see any problem with that?)

For links which are shared media though, it's safer to ensure that temporary
loops won't cause a problem, rather than try to ensure there never will be
a temporary loop. Temporary loops can form no matter what if, for instance,
someone brings up a repeater.

Radia

Á¶ÀçÇü wrote:

> Dear All,
>
> I am new to this BOF and I found from Radia¡¯s paper, the approach
>
> and goal of rbridge is somewhat related to what I have researched for
>
> several years.
>
> I am very eager to share my idea with TRILL people.
>
> By the way, I briefly read initial draft of TRILL charter and felt
> obliged to
>
> express some worry on ¡®encapsulation¡¯ and ¡®TTL¡¯ part.
>
> I found following text in the charter draft :
>
> ¡°.. the packet header *should* have a hop count for robustness
>
> in the presence of temporary routing loops¡±
>
> I know TTL has been constantly an issue in TRILL. However,
>
> I do not understand why people think TTL as an indispensable part
>
> of routing from the first place.
>
> Although TTL is a simple, and proven method,
>
> TTL is not the only technology tackling looping problem.
>
> ATM-MPLS has done well without TTL. There are plenty of
>
> proposals preventing or examining loops. I am wondering if
>
> there has been enough discussion on other options before
>
> people reach the conclusion on TTL.
>
> By fixing the hop-count part in charter item, I think this may prevent
>
> any future anti-looping technology from consideration and justifying
>
> encapsulation overhead from the first. I think the motivation of
>
> rbridge is very attractive, however, if it is possible, people must find
>
> a way to achieve the goal without modifying current format.
>
> For the charter text, I think it is just enough to mention that
>
> ¡®Rbridge must have sufficient measure to prevent/detect
>
> possible looping ....¡¯ without mentioning new header.
>
> Hopefully, this may provide a good consideration.
>
> Thank you.
>
> Regards
>
> Dr. Jaihyung Cho
> ETRI, Korea
> phone : 042) 860-5514
> oversea: +82-42-860-5514
> fax: +82-42-861-5550
>
>------------------------------------------------------------------------
>
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 10 Mar 2005 10:29:33 -0800

??? wrote:
...
> ?.. the packet header *should* have a hop count for robustness
> in the presence of temporary routing loops?
> 

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.

ATM-MPLS is a circuit-oriented technology (on both counts). The current
charter doesn't want to assume only circuits inside an rbridge campus,
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.

(unless you know of a better or different way to enforce loop detection
that does not depend on the routing protocol used).

Joe
-------------- 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/f79daa3e/signature.bin

---

From: loa at pi.se (Loa Andersson)
Date: Thu, 10 Mar 2005 20:18:25 +0100

Radia,

I guess that there are several questions that has to be clarified:

- MPLS header, is this the MPLS label, and if so is it limited to
  one single label or is it possible to stack several
- "onto the frame" exactly where?
- "removed by the egress" would we like to PHP?
- is this the L3 label as specified in the RFC3032, or a "Ethernet
  label" as it will potentially be specified by the CCAMP working
  group

/Loa

Radia Perlman wrote:
>>I am new to this BOF and I found from Radia?s paper, the approach
>>
>>express some worry on ?encapsulation? and ?TTL? part.
>>
>>?Rbridge must have sufficient measure to prevent/detect
>>
>>possible looping ....? without mentioning new header.
>>

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  loa.andersson at acreo.se
                                           loa at pi.se

---

From: ho at alum.mit.edu (The Purple Streak, Hilarie Orman)
Date: Thu, 10 Mar 2005 12:30:35 -0700

> that does not depend on the routing protocol used).

In the literal sense, hopcounts don't detect loops.  There are many
ways to detect loops, the easiest being to collect the destination
addresses onto the packet itself.  So, in a technical sense, the
answer is, sure there's a better way.  But if the goal is to mitigate
the deleterious effects of loops, then a hopcount has a big advantage
in its simplicity.  That simplicity may be obviated by the effect of
(unlikely) persistent errors in handling the hop count field, though.

Hilarie