Subject: [rbridge] Question about the future work 1: Trill over IP

From: xuxiaohu 41208 <[email-masked]>
Date: Mon, 08 Nov 2010 14:54:23 +0800

Hi all,

My question about this future work is why not go step further to encapsulate Ethernet over IP directly, rather than encapsulate Ethernet over Trill and then encapsulate Trill over IP?

Consider a future scenario where all edge Rbridges (i.e., ingress and egress Rbridges) are connected across an IP network and Trill over IP is used, do we need to write a new draft describing how to compress/eliminate the Trill header at that time?

My feeling of the current TRILL WG work is copying more fields, options and even OAM tools from IP to Trill. So if there is no abvious disadvantage for using the IP header to replace the Trill header, why not give up the trill header extensions/optimizations and consider to use the existing IP encapsulation and other mechanisms directly ?

Best regards,

Xiaohu
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 07 Nov 2010 23:52:49 -0800

On 11/ 7/10 10:54 PM, xuxiaohu 41208 wrote:
> Hi all,
>
> My question about this future work is why not go step further to
> encapsulate Ethernet over IP directly, rather than encapsulate
> Ethernet over Trill and then encapsulate Trill over IP?

Can you explain where you would carry the ingress nickname, egress 
nickname, the multi-destination bit, etc in that case?

The RBridges need those fields to be able to correctly forward the frames.

    Erik

> Consider a future scenario where all edge Rbridges (i.e., ingress and
> egress Rbridges) are connected across an IP network and Trill over IP
> is used, do we need to write a new draft describing how to
> compress/eliminate the Trill header at that time?
>
> My feeling of the current TRILL WG work is copying more fields,
> options and even OAM tools from IP to Trill. So if there is no
> abvious disadvantage for using the IP header to replace the Trill
> header, why not give up the trill header extensions/optimizations and
> consider to use the existing IP encapsulation and other mechanisms
> directly ?
>
> Best regards,
>
> Xiaohu _______________________________________________ rbridge
> mailing list [email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 08 Nov 2010 01:37:24 -0800

On 11/ 8/10 01:32 AM, xuxiaohu 41208 wrote:
> 
> 
> ----- 原邮件 -----
> 发件人: Erik Nordmark<[email-masked]>
> 日期: 星期一, 十一月 8日, 2010 下午3:53
> 主题: Re: [rbridge] Question about the future work 1: Trill over IP
> 收件人: xuxiaohu 41208<[email-masked]>
> 抄送: [email-masked]
> 
> Can't we use the source IP address and destination IP address to fill the role of the ingress nickname and egress nickname? Is there any neccessary and vital features that the trill header encapsulation can support while the IP header encapsulation can not?

TRILL is based on the nicknames being assigned randomly and then checked
for duplicates using IS-IS. That doesn't match how IP addresses are
normally assigned.

Even if you somehow modify how the IP addresses would be assigned to
match TRILL's expectations, you'd still need a way to carry other
information that is in the TRILL header. For example, the
multi-destination bit is a key part which affects how RBridges forward
frames.

   Erik

---

From: "Shah, Himanshu" <[email-masked]>
Date: Mon, 8 Nov 2010 04:45:39 -0500

I am guessing that part of this work will include
IP address (of PE) <-> trill nickname DB?
Next stop - Trill VPLS, Trill PW and on and on?
/himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Erik Nordmark
Sent: Monday, November 08, 2010 2:53 AM
To: xuxiaohu 41208
Cc: [email-masked]
Subject: Re: [rbridge] Question about the future work 1: Trill over IP

The RBridges need those fields to be able to correctly forward the
frames.

    Erik

---

From: xuxiaohu 41208 <[email-masked]>
Date: Mon, 08 Nov 2010 17:32:12 +0800

----- 原邮件 -----
发件人: Erik Nordmark <[email-masked]>
日期: 星期一, 十一月 8日, 2010 下午3:53
主题: Re: [rbridge] Question about the future work 1: Trill over IP
收件人: xuxiaohu 41208 <[email-masked]>
抄送: [email-masked]

BR,
Xiaohu

>    Erik
> 
> > Consider a future scenario where all edge Rbridges (i.e., ingress 
> and> egress Rbridges) are connected across an IP network and Trill 
> over IP
> > header, why not give up the trill header extensions/optimizations 
> and> consider to use the existing IP encapsulation and other 
> mechanisms> directly ?
> >
> > Best regards,
> >

---

From: xuxiaohu 41208 <[email-masked]>
Date: Mon, 08 Nov 2010 18:34:58 +0800

----- 原邮件 -----
发件人: Erik Nordmark <[email-masked]>
日期: 星期一, 十一月 8日, 2010 下午5:46
主题: Re: 回复:Re: [rbridge] Question about the future work 1: Trill over IP
收件人: xuxiaohu 41208 <[email-masked]>
抄送: [email-masked]

> > Can't we use the source IP address and destination IP address to 
> fill the role of the ingress nickname and egress nickname? Is there 
> any neccessary and vital features that the trill header 
> encapsulation can support while the IP header encapsulation can not?
> 
> TRILL is based on the nicknames being assigned randomly and then 
> checkedfor duplicates using IS-IS. That doesn't match how IP 
> addresses are
> normally assigned.
> 

Can't the class D IP addresses and the PIM protocol fill the multicast function that trill does?

Anything else which is important to trill?

Best regards,
Xiaohu

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 8 Nov 2010 06:15:02 -0500

Hi Xiaohu,

Use of IP as a direct link protocol between RBridge ports has nothing
to do with any possible change in the TRILL Header. You have brought
up all these points about the TRILL Header before quite recently. See
the thread with subject "A question about the Rbridge ID" in
http://www.postel.org/pipermail/rbridge/2010-August/date.html and
http://www.postel.org/pipermail/rbridge/2010-September/date.html

Please top bringing up the same subject when it has already been disposed of.

Thanks,
Donald

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 08 Nov 2010 17:14:28 -0800

> Anything else which is important to trill?

I think you are talking about a protocol which isn't TRILL.

What was discussed in the future work presentation was how to carry
TRILL over what could be viewed as a (virtual) port that uses IP
encapsulation, analogous to how TRILL is carried over Ethernet or PPP.
Nothing in that would change the approved draft-ietf-trill-rbridge-protocol.

What you seem to be talking about is a different protocol that
draft-ietf-trill-rbridge-protocol which does not use nicknames or many
of the other TRILL concepts.

Given that the working group as well as the IESG approved
draft-ietf-trill-rbridge-protocol, such a change seems completely out of
scope.

As I think Donald has pointed out earlier, the WG did discuss different
forms of encapsulation in the early days of the WG, and settled on the
TRILL header (and related concepts).

Regards,
   Erik

---

From: xuxiaohu 41208 <[email-masked]>
Date: Tue, 09 Nov 2010 09:38:02 +0800

----- 原邮件 -----
发件人: Erik Nordmark <[email-masked]>
日期: 星期二, 十一月 9日, 2010 上午9:14
主题: Re: 回复:Re: 回复:Re: [rbridge] Question about the future work 1: Trill over IP
收件人: xuxiaohu 41208 <[email-masked]>
抄送: [email-masked]

> >> multi-destination bit is a key part which affects how RBridges 
> forward>> frames.
> > 

Yes.

> Nothing in that would change the approved draft-ietf-trill-rbridge-

I understood.

> of the other TRILL concepts.

Yes.

Best regards,
Xiaohu

> As I think Donald has pointed out earlier, the WG did discuss 
> differentforms of encapsulation in the early days of the WG, and 
> settled on the