Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document?

[Donald Eastlake <[e-mail]>]

Hi Sam,

On Mon, May 14, 2012 at 4:29 PM, Sam Aldrin <[e-mail]> wrote:
> Hi Donald,
>
> Few questions inline.
>
> Sam
>
> Sent from my iPad
>
> On May 14, 2012, at 12:26 PM, Donald Eastlake <[e-mail]> wrote:
>
>> None of these arguments matter as our Area Director says that we need
>> to re-Charter to make TRILL over IP a WG draft. However, I will
>> respond a bit below:
> %sam- does this mean, the poll being undertaken is a moot point? If so, why to ask the WG for adoption?

Yes, it is moot. When the question was asked, this was not realized.

>> On Mon, May 14, 2012 at 3:06 PM, Tissa Senevirathne (tsenevir)
>> <[e-mail]> wrote:
>>> Hi Radia
>>>
>>> If we are discussing about TRILL over foo then this draft is not generic.
>>>
>>> If we are discussing about TRILL over IP then I begin to wonder why cannot we use existing pseudo-wire techniques.
>>
>> You can but the result is inferior, adding more layers of fuzz between
>> TRILL and actual transport protocol.
> %sam - are you saying, because it uses ip, it is superior technology than L2 technologies like PW? Ip has to use L2 anyway, so, the logic you are using doesn't make sense to me.

Not at all. I'm saying that when you design a native way of doing X
over Y, you typically get a better result that when you say "we will
do X over Y by just using the Generic over Y existing protocol and
doing X over Generic over Y". Let me give a specific example: GRE.
Lots of things use GRE but if you look at the GRE RFC 2784, it says:
   "In attempting to be more general, many protocol specific
   nuances have been ignored [in GRE]. The result is that this proposal
   may be less suitable for a situation where a specific "X over Y"
   encapsulation has been described."

Another specific example of something that can get fuzzed and produce
inferior results due to generic middle levels of protocol is MTU
handling.

On the other hand, it takes more work to to specify specific native
ways to do X over Y for lots of Ys. You don't always end up with the
same answer. TRILL over PPP (RFC6361) uses a native format designed
for TRILL. On the other hand, draft-yong-trill-trill-o-mpls for full
point to point connection of RBridges specifies using already
specified Ethernet or PPP MPLS pseudo-wires and recommends using the
PPP types because it saves bytes and is already specified.

>>> If we can use existing VPLS or L2VPN techniques to achieve required functionality, why do we need yet another solution to save 2 MAC address and a VLAN on outer Ethernet header.
>>
>> Maybe on a point-to-point link the main advantage is the savings you
>> mention. But on a multi-point technology like IP there are lots of
>> other factors in addition to saving a non-trivial number of bytes,
>> factors related to multi-destination traffic, security, etc.
> That is not true.

All I was trying to say was that multi-point (multi-access) link
technologies are more complicated than point-to-point so there are
more different factors in their performance. I continue to believe
that.

>Vpls is a multi point technology and is widely used in many network types. Which aspects of the technology makes ip better here?

Ubiquity? I'm really not interested in continuing to argue about
technology t1 versus technology t2 since I'm pretty certain that you
would eventually find out that t1 was better under some circumstances
and t2 was better under other circumstances. This does not mean that
you should standardize both t1 and t2 but if you believe the
circumstances where tx was best were common enough, you would want to
standardize tx.

>> The current L2VPN WG draft, to the extent it talks about
>> interconnecting TRILL islands, isn't TRILL over anything but, although
>> it connects the TRILL data planes, runs some new different more
>> loosely coupled control protocol between the islands.
> It is not entirely correct. The existing draft does encap trill frames with labels to be transferred over pw's. Whether it connects islands or something else is a matter of how you deploy the technology.

Last time I looked, I believe it only did that for TRILL Data frames,
not TRILL IS-IS frames.

Donald

> Sam
>>
>>> If we are discussing about TRILL over foo then WG need to have consensus on overall strategy before moving individual solutions to WG status. People may argue we should have a lower bar to enter documents to WG status, but side effect of that is we are over crowding the document set, hence taking focus away from agreed priority items.  Additionally, one may even argue TRILL over any other transport protocol should be part of L2VPN.
>>>
>>> Lastly, what is the rush to move this document to WG status ?
>>
>> That's no different than asking why the obstructionism about a draft
>> that has been presented and discussed and in which previously raised
>> objections have been, as far as I can tell, resolved. Sitting on your
>> hands is not a way to get standards done.
>>
>> Thanks,
>> Donald
>> =============================
>>  Donald E. Eastlake 3rd   [phone] (cell)
>>  155 Beaver Street, Milford, MA 01757 USA
>>  [e-mail]
>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Radia Perlman
>>> Sent: Monday, May 14, 2012 10:37 AM
>>> To: Erik Nordmark
>>> Cc: [e-mail]
>>> Subject: Re: [trill] Should we make draft-mrw-trill-over-ip-01 a WG document?
>>>
>>> I don't understand the controversy.  TRILL over IP is useful in several cases which are actually clearly explained in this document.
>>> And in general, the document seems well thought out and well written.
>>>
>>> So, I think it should be a WG document.
>>>
>>> Radia
>>>
>>> On Fri, May 11, 2012 at 5:38 PM, Erik Nordmark <[e-mail]> wrote:
>>>>
>>>> The document is at
>>>> https://datatracker.ietf.org/doc/draft-mrw-trill-over-ip/
>>>>
>>>> We've discussed this document in WG meetings and on the list in the past.
>>>>
>>>> Please send comments to the list.
>>>>
>>>>   Erik
>>>> _______________________________________________
>>>> trill mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/trill
>>> _______________________________________________
>>> trill mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/trill
>>> _______________________________________________
>>> trill mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/trill
>> _______________________________________________
>> trill mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/trill