Subject: [Isis-wg] How hard would it be to get a NLPID for TRILL IS-IS?

From: Radia Perlman <[email-masked]>
Date: Thu, 19 Mar 2009 11:04:44 -0700

As an additional way of ensuring that TRILL IS-IS and layer 3 IS-IS 
messages don't get confused with each other,
it seems like it would be a good idea to have a different NLPID. 
Especially because on Ethernet, the
way to tell the difference between layer 3 IS-IS (natively transmitted 
on the first and last hops) and layer 2 IS-IS
is the destination address in the Ethernet header.....but not all links 
(e.g., PPP) have Ethernet headers. So
it seems like it would be good to use a different NLPID for TRILL IS-IS.

How does one get a new NLPID value? Are they scarce? Anyone have a 
reason why it would be bad to
have a different NLPID? Or anyone think it's a good idea to try to get one?

Thanks,

Radia

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 19 Mar 2009 15:16:41 -0400

I think this is a good idea but the NLPID seems to commonly be an ID
for the type of address on which you are routing. So perhaps what is
wanted is an MAC-48 NLPID.

Note the following cut and pasted from the now obsoleted
draft-eastlake-trill-rbridge-isis-02:

   "Since no NLPID (Network Layer Protocol Identifier) has been allocated
   by the ISO/IEC TR 9577 Registry for the Ethernet protocol or MAC-48
   address type or TRILL, there is no way to indicate support of IS-IS
   routing for these in a Protocols Supported TLV (TLV #129)."

Donald

On Thu, Mar 19, 2009 at 2:04 PM, Radia Perlman <[email-masked]> wrote:
> As an additional way of ensuring that TRILL IS-IS and layer 3 IS-IS messages
> don't get confused with each other,
> it seems like it would be a good idea to have a different NLPID. Especially
> because on Ethernet, the
> way to tell the difference between layer 3 IS-IS (natively transmitted on
> the first and last hops) and layer 2 IS-IS
> How does one get a new NLPID value? Are they scarce? Anyone have a reason
> why it would be bad to
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
>

-- 
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 19 Mar 2009 16:00:43 -0400

Thanks. It wasn't clear to me that a different IS-IS frame NLPID was
what was being suggested.

Donald

On Thu, Mar 19, 2009 at 3:47 PM, James Carlson <[email-masked]> wrote:
> Donald Eastlake writes:
> I think that might be missing the point.
>
> There are two uses of NLPIDs in play here.  One is the NLPID used by
> the Protocols Supported TLV.  That's where we would put the CLNS NLPID
> or IP NLPID if we were routing those things.
>
> However, this discussion is about the IS-IS NLPID on the packet itself
> (hex 83), not the types of addresses we're routing.
>
> Currently, TRILL IS-IS packets on Ethernet are sent with only a
> distinguishing Outer.MacDA.  There's no Ethertype (because they're
> 802.3 messages), the LLC SSAP and DSAP are hex FE (indicating ISO
> traffic; same as regular IS-IS), and the NLPID that follows is hex 83
> (indicating plain IS-IS).
>
> The suggestion Radia is making is to make these packets a little more
> distinct from plain old IS-IS (more than just the MAC destination
> address on Ethernet), so that there's no mistaking them.
>
> (Sure, we could have a "MAC48" NLPID for the Protocols Supported TLV,
> but that's a separate issue from the one at hand.)
>
> --
> James Carlson, Solaris Networking              <[email-masked]>
> Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
>

---

From: stefano previdi <[email-masked]>
Date: Thu, 19 Mar 2009 21:14:59 +0100

> wanted is an MAC-48 NLPID.

I my not get the full picture but if you need to distinguish between
isis instances/packets another option could be MI-ISIS.

s.

---

From: mike shand <[email-masked]>
Date: Fri, 20 Mar 2009 10:24:58 +0000

Radia,
    I think the major problem is that nobody knows how to get these 
allocated any more. However TR 9577 (which is also  ITU-T Rec. X.263) 
does say

"This Recommendation | Technical Report is for use by ITU-T Study 
Groups, ISO/IEC Technical Committees and other authorities in applying 
the principles contained in clause 4, and in selecting an unused value 
or values from the range of values permitted in clauses 5 or 6, as 
appropriate. When a new value is selected, that value and its usage 
should be brought to the attention of ITU-T Study Group 7 or ISO/IEC JTC 
1 SC6 so that this Recommendation | Technical Report can be amended."

I can't believe that it is (or even should be) as simple as that. I 
would expect there to be some approval process before that could be 
accepted. In the old days that would of course have been ISO/IEC JTC1 
SC6/WG2, but I have no idea how they function these days, if at all. 
Perhaps somebody does.

On the desirability of this. There clearly are available code points 
which could be used (but the obvious hex 84, although unassigned as an 
IPI, is currently assigned as an SPI for ISO/IEC 8878, which although 
causing no technical confusion, may yet be conceptually confusing). I 
guess it all hinges on whether TRILL IS-IS is regarded as a different 
protocol to IS-IS (in which case a new NLPID would be reasonable), or a 
variant of the same protocol (in which case it would not). I rather 
think all the work so far has focussed on it being a simple variant.

As Stefano pointed out, it might be possible to use MI (i.e. add an MI 
TLV in each PDU) to perform this function. In the case of MI itself that 
is the natural approach, since the multiple instances are definitely NOT 
a different protocol, and it would consume an excessive number of 
codepoints to give each instance a new NLPID.

But how necessary is all this? I thought we already had belt and braces. 
Do we really need a padlock as well?

    Mike

Radia Perlman wrote:
> is the destination address in the Ethernet header.....but not all 
> links (e.g., PPP) have Ethernet headers. So

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 20 Mar 2009 11:02:48 -0700

I would also point out that this same discussion occurred in the context
of the MI work i.e. whether in addition to the use of a unique set of
multicast addresses it was also necessary/prudent to have a different
NLPID.

The conclusion at that time was that it was not necessary - and I see no
reason why the requirements in this case are any different.

   Les

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Mike Shand (mshand)
> Sent: Friday, March 20, 2009 3:25 AM
> To: Radia Perlman
> Cc: [email-masked]
> Subject: Re: [Isis-wg] How hard would it be to get a NLPID for TRILL
IS-
> IS?
> > have a different NLPID? Or anyone think it's a good idea to try to
get
> > one?

---

From: Radia Perlman <[email-masked]>
Date: Fri, 20 Mar 2009 20:34:31 -0700

Well, if the standards body that "owns" IS-IS is not there to negotiate 
with about things like this, perhaps it's time
to "clone" the protocol into a "new protocol" that IETF controls. It 
seems weird to have a constraint because of not
having a standards body to negotiate with.

Or we could try negotiating with Digital -- it was after all their 
protocol first. :-)

Radia

mike shand wrote:
> should be brought to the attention of ITU-T Study Group 7 or ISO/IEC 
> JTC 1 SC6 so that this Recommendation | Technical Report can be amended."
>
> protocol to IS-IS (in which case a new NLPID would be reasonable), or 
> a variant of the same protocol (in which case it would not). I rather 
> TLV in each PDU) to perform this function. In the case of MI itself 
> that is the natural approach, since the multiple instances are 
> definitely NOT a different protocol, and it would consume an excessive 
> number of codepoints to give each instance a new NLPID.
>
> But how necessary is all this? I thought we already had belt and 
> braces. Do we really need a padlock as well?
>
>    Mike
>
>
>
>
>
>
> Radia Perlman wrote:
>> way to tell the difference between layer 3 IS-IS (natively 
>> transmitted on the first and last hops) and layer 2 IS-IS
>> get one?

---

From: Tony Li <[email-masked]>
Date: Fri, 20 Mar 2009 09:03:46 -0700

mike shand wrote:
> allocated any more. 

By the rationale from the liaison agreement that we've been using to 
allocate code points internal to IS-IS, it would seem reasonable that we 
simply set up an IANA registry for NLPIDs and populate it with the known 
code points plus the additional one for TRILL.

This seems straightforward.  This is orthogonal to whether or not it's a 
good idea.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 24 Mar 2009 11:21:27 -0700

In digging around in the old thread in MI, I noticed that one of the
recommendations that came out of that discussion was that the non-zero
instance(s) SHOULD use a different systemid than it uses for the zero
instance. This provides additional protection because even if a (broken)
legacy implementation processes PDUs from a non-zero instance, it
guarantees that the two-way connectivity check will fail between the
non-zero instance and any system reachable by the legacy implementation
- so routing will not be affected.

This strategy is equally applicable to TRILL IS-IS - and provides one
more reason why a new NLPID is not necessary.

Note that the systemid used is still subject to the normal constraints
i.e. it must be unique within the area/domain - as well as unique among
the different instances - in this case L2IS-IS vs. L3IS-IS.

We overlooked adding such language to the MI draft - that will be
corrected in the next update.

   Les

Behalf
> Of Les Ginsberg (ginsberg)
> Sent: Friday, March 20, 2009 11:03 AM
> To: Mike Shand (mshand); Radia Perlman
> Cc: [email-masked]
IS-
> JTC
> a
> that
> transmitted