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

From: Jeff Learman <[email-masked]>
Date: Mon, 26 Nov 2001 15:03:36 -0500

First of all, a pseudonode represents the media, not a real router,
as Tony pointed out.  For that reason, it can be assumed to support
all protocols that are supportable on that media type, and the LSP
options are not necessary for this purpose.

Furthermore, we cannot require OSI-only routers that do not support
1195 to include a "protocols supported" option identifying
IP in their pseudonode LSPs.

We should figure out whether an IP-capable router "should" include the
IP protocol-supported option.  However, there are (allegedly)
implementations that are IP-capable which don't put the option in
their pseudonode LSPs.  Therefore, it's good idea to treat pseudonode
LSPs without the option as supporting both IP and OSI.

Once again, this would only be an issue in a network that doesn't
meet the deployment requirements (e.g., in a mixed area, all L1 routers
must be dual-capable).  As I understand it, in networks that follow
the deployment rules, there is no need to check the protocols-supported
option in LSPs when running SPF.  Checking it is an optimization: if
an LSP doesn't support IP, then there's no need to look for IP
addressing info in the LSP, because it won't be there.

Regards,
Jeff

At 12:01 PM 11/26/2001, Chan, Chung Ming (Adtech ENG) wrote:
>All,
>
>        Another role for the inclusion of "Protocols Supported" field is to
>signal the other routers that the router originated the LSP is IP capable (
>As I understood it from RFC 1195 Section 5.2, paragraph 2.) 
>        Would it be from this point of view that the "Protocols Supported"
>field is necessary since "logically" pseudo-node LSP is from the
>Designated-Router to all of its neighbors?
>The field tells all of its neighbors that it is IP capable.
>
>        Thanks,
>
>
>Ming Chan
>
>
>-----Original Message-----
>From: Les Ginsberg [mailto:[email-masked]]
>Sent: Monday, November 26, 2001 2:23 AM
>To: 'Jeff Learman'; Tony Li
>Cc: Chan, Chung Ming (Adtech ENG); [email-masked]'
>Subject: RE: [Isis-wg] Protocols Supported field in pseudonode LSP
>
>
>It is true that RFC 1195 does not explicitly direct ISs to reject
>adjacencies with neighbors who do not match protocols supported. In most
>cases we would be better off w/o such a neighbor - it would prevent needless
>flooding of LSPs which contained no useable routing information. However, on
>a "misconfigured" LAN, if some combination of IP only and OSI-only routers
>exist - the fact that all routers will form adjacencies is a benefit in that
>only a single DIS will be elected. The unfortunate part is that LSPs from
>OSI-only routers will take up resources in IP-only routers and vice-versa.
>
>This makes it important to check the protocols supported option in
>non-pseudo-node LSPs so as to avoid using an OSI-only router as a transit
>router for IP traffic (and vice versa...). LSPs from a router which does not
>advertise support for a particular protocol should be ignored during SPF.
>
>The same check in pseudo-node LSPs, as Tony has pointed out, is not
>important since the pseudo-node LSP only has information about routers
>connected to the LAN, not what destinations are reachable via those routers.
>
>This raises the point that an alarm associated with the formation of an
>adjacency with a protocol-wise incompatible neighbor as well as an alarm
>associated with reception of a non-pseudo-node LSP with incompatible
>protocols would be helpful. (Jeff Parker - are you listening?)
>
>   Les
>
>> -----Original Message-----
>> From: Jeff Learman [mailto:[email-masked]]
>> Sent: Sunday, November 25, 2001 6:21 PM
>> To: Tony Li
>> Cc: Chan, Chung Ming (Adtech ENG); [email-masked]'
>> Subject: Re: [Isis-wg] Protocols Supported field in pseudonode LSP
>>
>>
>>
>> I agree with Tony.  There are some additional things to consider,
>> though.
>>
>> In accordance with RFC 1195, an implementation doesn't need
>> to consult an LSP's supported protocols option when running SPF
>> except for links to end systems, and a pseudonode LSP should have
>> only links between intermediate systems.  (Rather than relying on
>> the protos supported option, RFC 1195 relies on the deployment
>> rules.)
>>
>> My understanding is that some routers do take the protos-supported
>> option when running SPF.  This allows some relaxation of the
>> deployment
>> rules.  There is no interoperability problem, because any strict
>> implementation won't work anyway, in situations where this
>> modification
>> helps.
>>
>> However, in networks where this modification is being used, and
>> mixed networks don't meet the deployment requirements in 1195,
>> will it be important to make sure the designated router is a dual
>> router?  I can't find anything in 1195 that says to check protos-
>> supported when bringing up an adjacency.  If for any reason a
>> system would not form an adjacency with a router with which it
>> shared no protocols, that would cause a problem in the pseudonode
>> LSPs.  Hopefully this isn't a problem.
>>
>> Regards,
>> Jeff
>>
>> PS:  I don't work in IS-IS at Cisco.  My comments do not necessarily
>> reflect Cisco's opinions and I have no detailed knowledge of the Cisco
>> IS-IS implementation.
>>
>>
>>
>>
>> At 08:06 PM 11/25/2001, Tony Li wrote:
>>
>> > | I found out that in one vendor's pseudonode LSPs, there
>> is no "Protocols
>> > | Supported" field included; but it includes the field in
>> the non-pseudonode
>> > | LSPs.
>> > |
>> > | Shall the Protocols Supported field MUST be included in
>> pseudonode LSP
>> > | according to RFC 1195?
>> > |
>> > | Not sure if there is any reason for that particular
>> vender for doing it.
>> > |
>> > | Could someone please verify this ?
>> > |
>> > | RFC 1195 Section 3.1, paragraph 3:
>> > | "IP-capable (i.e., all IP-only and dual) routers need to
>> know what network
>> > | layer protocols are sup-ported
>> > | by other routers in their area. This information is made
>> available by
>> > | inclusion of a "proto-cols
>> > | supported" field in all IS-IS Hello and Link State
>> Packets. This field makes
>> > | use of the NL-PID
>> > | (Network Layer Protocol Identifier), which is a one-octet
>> value assigned by
>> > | ISO to identify
>> > | network level protocols. NLPID values have been assigned
>> to ISO 8473 and to
>> > | IP."
>> >
>> >
>> >Interesting question.
>> >
>> >Well, the pseudonode LSP is really there to represent the
>> broadcast medium,
>> >not any particular router.  And since the broadcast medium
>> is presumably
>> >protocol independent, it doesn't seem like it actually
>> conveys any useful
>> >information.
>> >
>> >Thus, IMHO, it would make sense if implementations ignored
>> the Procotols
>> >Supported TLV in a pseudonode LSP and not require it be present.
>> >
>> >Tony
>> >_______________________________________________
>> >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
>>

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Jeff Parker <[email-masked]>
Date: Mon, 26 Nov 2001 15:43:46 -0500

> As I understand it, in networks that follow
> the deployment rules, there is no need to check the 
> protocols-supported option in LSPs when running SPF.  
> Checking it is an optimization: if an LSP doesn't 
> support IP, then there's no need to look for IP
> Jeff [L]

Jeff -
	I thought this was an issue, due to transitive
closure.  You don't have any IP addresses, but you 
present an attractive route to a router that does
have IP addresses.  If I don't check your protocols
supported, I might use you on a path.  Since
you don't forward IP packets, we have a black hole
if all routers ignore protocol supported in SPF, or 
a routing loop if some check and some do not.  

- jeff parker

---

From: Jeff Parker <[email-masked]>
Date: Mon, 26 Nov 2001 16:10:39 -0500

> This raises the point that an alarm associated with the 
> formation of an adjacency with a protocol-wise incompatible 
> neighbor as well as an alarm associated with reception of 
> a non-pseudo-node LSP with incompatible

Les -
	Yes, I am listening. 
 
	To recap MIBstory, version .06 of the MIB is on the IETF 
site.  I have been circulating a draft version of version .07, 
which includes Traps, to those who have expressed interest.

	The two events above seem like natural additions to
the list of Traps (Notifications).  Will add and send your way.    

	Most of the traps have a "edge triggered" text suggesting
that we send one of these traps the -first- time we see the
event so the manager doesn't get flooded.  

- jeff parker
- axiowave networks

---

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

Though mixed networks are likely to come with the new focus on GMPLS
functionality...

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.