Subject: Re: [Isis-wg] Protocols Supported field in pseudonode LSP

From: Jonathan Sadler <[email-masked]>
Date: Mon, 26 Nov 2001 17:57:28 -0600

Jeff, et al. -

ITU-T SG15 recently consented G.7712/Y.1703 (nee G.dcn) which defines
DCN requirements.  A good amount of this document includes requirements
for IP in the DCC/DCN.

The document includes IS-IS related requirements, including the
"mandatory" support for IS-IS (see sec 7.1.10) for both IP and OSI and
the requirement that an adjacency not be established when the Protocols
Supported field does not match in an IIH (see sec. 7.1.10.1).

What is not included in the document, but remains under consideration in
Q14 of SG15, is a submission from the United Kingdom (UK) to use the
Protocols Supported field when running SPF to automatically determine if
a tunnel should be established to pass packets between 2 OSI-only
islands that are connected via an IP-only network.  (Of course
dual-nodes are used at the points where the OSI and IP networks meet.) 
This is specifically designed to allow more liberal node deployments
than specified in RFC 1195.

The UK submission further requires support for separate IP and OSI DISes
(similar to the separate DISes required for L1 and L2) on LANs to
eliminate implied adjacencies between OSI-only and IP-only nodes on the
LAN.

It should be noted that the approach contained in the UK submission is
general enough so that it can be applied to any network that has islands
of X-protocol to be connected through an Y-protocol based network, where
X and Y could be IPv4, IPv6, or OSI.

The following message was sent through formal Liaison channels from
ITU-T to the IETF and provides a pointer to the consented document. 
Unfortunately, the UK submission is only available to ITU members at
this time.

Jonathan Sadler

-------------- Forwarded Mail ----------------

Scott, Kireeti, and Lyndon,
I am pleased to inform you that we finally have some concensus
within ITU-T that gives us a way to share the files related to
the Study Group 15 communications statements with IETF participants.
This mechanism will likely evolve in the future (more about this
below), but at least for now we have a way to share these files
with IETF participants.

The relevant communications include two to ccamp:
- SDH Signal and Group Structures
- New Recommendations for Automatically Switched Optical Netorks
and one to sigtran:
- Draft Recommendation G.799.1 on interconnecting GSTN and IP Networks

The information may be accessed via a web browser using the following
URL (from an ITU-T ftp server):

ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/index.html

In the future, the Telecommunications Standardization Bureau will likely
provide a way for IETF participants who wish to collaborate with ITU-T
to request their own logins and passwords to access this site, but for
now, all can access the information using the common ID and password
that
you see embedded in the URL.

The structure of the information is as follows:

Main Page
   |
   |-->ccamp-->copyright---->Communication on SDH Signal Structures
   |                      |
   |                      -->Communication on ASON Recs
   |                                |
   |                                |-->G.8080_Y.1304.pdf
   |                                |-->G.7713_Y.1704.pdf
   |                                |-->G.7714_Y.1705.pdf
   |                                --->G.7712_Y.1703.pdf
   |
   --->sigtran-->copyright-->Communication on G.799.1 (GSTN and IP)
                                    |
                                    --->G.799-1-DRAFT-V6.pdf

Please request that your members enter at the main page - this will
help insure that those who access the documents will be aware of the
ITU-T copyright restrictions.

Jeff Learman wrote:
> 
> Dave,
> 
> SONET network management uses OSI with ISIS, and are planning (last I
> heard) to use integrated IP & OSI networks using RFC 1195.  For more
> information, please contact T1.X1.
> 
> But we better work out these rules anyway, because IPV6 will raise
> them yet again.
> 
> Regards,
> Jeff
> 
> At 05:52 PM 11/26/2001, Dave Katz wrote:
> >   But this only happens in networks that don't follow the deployment rules.
> >   SO: Do people follow the rules?
> >
> >I guess this begs the question, are there any OSI-only routers out there?
> >There are the goofy ADMs, I suppose
> >
> >There are plenty of IP-only routers running ISIS, which leads one to
> >believe that mixed networks are extremely rare.
> 
> _______________________________________________
> Isis-wg mailing list  -  [email-masked]
> http://external.juniper.net/mailman/listinfo/isis-wg
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: "Ken Larmer" <[email-masked]>
Date: Tue, 27 Nov 2001 10:31:30 -0500

> eliminate implied adjacencies between OSI-only and IP-only nodes on the

	Is there a need for separate DISes at this point or is there a need for
separate Pseudonode LSPs from a single DIS? If we generate separate
Pseudonode LSPs with the Protocols Supported field advertising the types of
protocols supported for the LAN adjacencies contained within the associated
LSP, won't that resolve this issue?

	I.e. only build an OSI SPF tree for OSI adjacencies advertised in
Pseudonode LSPs without a Protocols Supported field versus only build an IP
SPF tree for IP adjacencies advertised in the Pseudonode LSP (LSP Number =
0) possessing a Protocols Supported field = 0xcc. The draw back as I see it
to implementing multiple Pseudonode LSPs is that, when we support more
protocols within IS-IS, other than OSI and IP, this mechanism will break
because we only check for the presence of the Protocols Supported field in
LSPs with LSP number = 0. Of course, the RFC could be amended in this area
to resolve this issue?

Cheers,
Ken Larmer

---

From: mike shand <[email-masked]>
Date: Thu, 29 Nov 2001 11:42:24 +0000

It seems to me that it is a VERY bad idea to have multiple DRs on a LAN at 
the same level. This is not just a pseudonode issue, but also affects the 
role of the DR in providing error recovery for the flooding (update) 
process. Unlike the level 1/2 case, there are NOT distinct sets of LSPs 
carrying protocol A and protocol B information (indeed a single LSP can 
carry both sets of information). SO there is no sense in which the update 
process is partitioned between the two DRs.

Or is the intention here that one of the DRs does the normal DR functions 
and generates a pseudonode for protocol A, while the other ONLY generates a 
pseudonode for protocol B?

But in any case, I don't see the need for separate pseudonodes. If we are 
running separate SPFs for protocol A and B, then the pseudonode is simply 
treated as a node which is both A and B capable. A protocol A (only) 
capable Node will not use a link to a protocol B (only) capable node even 
though it passes via the pseudonode which appears to be protocol A and B 
capable.

So why don't we just form adjacencies on the LAN irrespective of the 
protocols supported? And then use multiple SPFs to sort out the mess. i.e. 
if you  only have single SPF capable routers you MUST follow the deployment 
rules. If you want mixed A,AB,B capable routers, then you MUST run multiple 
SPFs for A and B.

The only issue I can see is the case where the SPF indicates a node on the 
LAN as a next hop, but the first node doesn't (currently) have an adjacency 
to that node. The 10589 required behaviour in that case is to forward that 
packet to the DR (since the DR MUST have an adjacency otherwise it wouldn't 
have advertised it in its pseudonode). Clearly, this could fail if the DR 
wasn't in fact capable of forwarding the protocol in question.

But this is an obscure case (and was really only there for the case of OSI 
end-systems, which because of their relatively long ES-IS timers may take a 
while to form adjacencies with all routers in the face of packet loss).

A simple work around would be to give preference in the DR election to 
routers which were all protocol capable (either algorithmically, or by the 
simple expedient of giving them the highest priority).

But in any case this should only be a transient condition.

I don't think it warrants the complexity of multiple DR elections.

or am I missing something?

         Mik

---

From: "Ken Larmer" <[email-masked]>
Date: Thu, 29 Nov 2001 10:37:30 -0500

Hi Mike,

	Very good point about the election possibilities of a DR which does not
support both OSI and IP protocols on the same LAN! I agree with your
proposed resolution for this issue by giving DR election preference to ISs
which support both OSI and IP protocols. The only problem I see is that the
Protocols Supported field is not present in an OSI-only node's PDUs. So if
you have a Dual-OSI/IP IS versus an IP-Only IS, we will not be able to
differentiate between them from their LAN IIH PDUs. One resolution would be
to define the Protocols Supported field (which is currently defined in
RFC-1195) in ISO-10589 and provide a value for OSI.

	Am I out to lunch or will your recommendation with the above modifications,
along with the separate Pseudonode LSPs for OSI versus IP adjacencies
resolve this issue?

Cheers,
Ken Larmer
CommSense Networks

---

From: mike shand <[email-masked]>
Date: Thu, 29 Nov 2001 16:02:01 +0000

>RFC-1195) in ISO-10589 and provide a value for OSI.

I don't care about the hellos, I do care about the LSPs. But either way I 
THOUGHT that it was permissible to put any value of NLPID (as defined by 
ISO TR 9577) in the protocols supported field,  and hence we could put one 
for OSI. So

No protocols supported = OSI only
IP + OSI protocols supported = dual
IP protocols supported = IP only

or is my memory failing me?

Of course there are backwards compatibility issues in all this.

         Mike

---

From: "Ken Larmer" <[email-masked]>
Date: Thu, 29 Nov 2001 12:09:46 -0500

Hi Mike,

> I don't care about the hellos, I do care about the LSPs.

I mentioned the hellos for 2 reasons, first we can not differentiate between
the protocols which are running on an IS unless there is an entry in the
Protocols Supported field of a LAN IIH PDU. Consequently, when running the
DR election process, we could not give proper preference to those ISes which
support Dual routing (i.e. there is currently no method for differentiating
between a Dual IS and an IP-Only IS). So, this field in a hello also needs
to possess the correct value advertising it as a Dual IS versus an IP-Only
IS.

Secondly to stay in compliance with RFC-1195, we must abide by the following
statement extracted from RFC-1195:

Dual routers must operate in a dual fashion on every link in the routing
domain over which they are running IS-IS. Thus, the value of the "protocols
supported" field must be identical on every link (i.e., for any one router
running IS-IS, all of the Hellos and LSPs transmitted by it must contain the
same "protocols supported" values).

> But either way I THOUGHT that it was permissible to put any value of NLPID
(as defined by
> IP protocols supported = IP only

This makes a great deal of sense and I agree completely!

Cheers,
Ken Larmer
CommSense Networks

---

From: mike shand <[email-masked]>
Date: Thu, 29 Nov 2001 17:19:05 +0000

>to possess the correct value advertising it as a Dual IS versus an IP-Only

Yes, you are right - you do need it to give dual capable nodes preference 
in an election. And maybe that is what you have to do for backwards 
compatibility reasons, but what I was saying (and this is completely off 
the wall) is that you could simply ignore the protocols supportedness in 
the hellos and always form an adjacency. In that case there would be no 
need to do anything special with the DR election, since by definition the 
DR (and hence the pseudonode) would have adjacencies to all routers on the 
LAN even if it didn't itself support the required protocol.

Then we would just leave it to the (separate) SPFs to actually figure out 
which W"next hops" to use (either natively, or doing some kind of 
autotunnel if necessary).

But maybe I've got this all wrong. I don't think what I'm "proposing" (and 
I use the word very loosely) has very good backwards compatibility 
properties in any case.

         Mike

---

From: "Ken Larmer" <[email-masked]>
Date: Thu, 29 Nov 2001 15:32:58 -0500

> I use the word very loosely) has very good backwards compatibility

Doesn't the fact that most vendors do not support forming adjacencies with
an IS who possesses a different IP subnet (even though RFC-1195 clearly
states to form an adjacency with such an IS and forward between subnets) and
the following statement extracted from the Dijkstra Calculation and
forwarding section of RFC-1195, create some problems?

What if the DR is an OSI-Only IS?

C.1.4 The Algorithm
...
8) Now add systems to which the local router does not have adjacencies, but
which are mentioned in neighboring pseudonode LSPs. The adjacency for such
systems is set to that of the designated router...

	In order to relax the configuration rules, I believe the following MAY work
fine?

1. Give the DR Election preference to ISes which serve as a Dual-IS.

2. Place the NLPID in the Pseudonode LSP for the supported entries contain
within (i.e. 0xcc = IP capable neighbors).

3. DR generation of multiple Pseudonode LSPs for each protocol supported.

4. Creation of additional definitions for future NLPIDs. (IPv6, toaster
protocol...)

5. Relax the restriction on checking for the NLPID in LSP #0 only LSPs.

	The only problem I can see with this scenario is when you have a mixed LAN
and there are IP-Only or OSI-Only ISes which can serve as the DR. Though, I
suppose you could really break any protocol if it were miss configured
sufficiently?

Cheers,
Ken Larmer
CommSense Networks