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

From: Les Ginsberg <[email-masked]>
Date: Sun, 25 Nov 2001 23:23:19 -0800

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 Learman <[email-masked]>
Date: Mon, 26 Nov 2001 15:27:23 -0500

Les,

>advertise support for a particular protocol should be ignored during SPF.

Is this required by 1195?  As I understand it, it isn't, as the check
would be superfluous in any network that meets the deployment
requirements.  I think it's unfortunate that 1195 was written this
way, but wouldn't it be a mistake to assume any router does this
check?

If some routers do this and others don't, then there will be routing
loops.  Of course, if some routers don't do this in a network that
doesn't meet the deployment requirements, that network won't work
anyway.

---

From: Tony Li <[email-masked]>
Date: Mon, 26 Nov 2001 13:06:45 -0800

| At 02:23 AM 11/26/2001, Les  Ginsberg wrote:
 | >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. 
 | 
 | Is this required by 1195?  As I understand it, it isn't, as the check
 | would be superfluous in any network that meets the deployment
 | requirements.  I think it's unfortunate that 1195 was written this
 | way, but wouldn't it be a mistake to assume any router does this
 | check?

1195 specifically says that this check is not necessary.  However, that's
also making the grand assumption that the domain is following the
deployement requirements.  Unfortunately, humans make mistakes, so simply
assuming that the deployment requirements are met is likely to get an
implementor into a conflict with users.  Far better to be careful in the
computations and forward the traffic along a best effort path.

As an aside, one has to wonder if the authors of 1195 didn't expect such a
check.  If one does make the assumption that the deployment rules are being
followed, what is the point in the Protocols Supported TLV in the first
place? 

IMHO, doing the check is a trivial amount of overhead and seems to be well
worth the additional security.

 | If some routers do this and others don't, then there will be routing
 | loops.  Of course, if some routers don't do this in a network that
 | doesn't meet the deployment requirements, that network won't work
 | anyway.

If some routers do not make this check and are deployed in a dual
environment where the deployment rules are not followed, then those routers
may make an incorrect forwarding decision.  If the next hop is not protocol
capable, then the decision will be a black hole.  However, if the next hop
is a router that does make the SPF check, then there is the possibility of
a forwarding loop.

While forwarding loops are in many ways more painful than black holes, I
suspect that the benefits incurred by making this check and forwarding
along the best available path far outweigh the additional danger.

Of course, the cost for dual implementations that choose to support this is
a separate SPF per protocol type.

Tony

---

From: Jeff Learman <[email-masked]>
Date: Mon, 26 Nov 2001 16:55:32 -0500

>worth the additional security.

I agree wholeheartedly.

>may make an incorrect forwarding decision.

Incorrect?  Well, it's operating according to the RFC.  The RFC
is incorrect or the network is incorrect, not those routers.
(Yes, I know I'm being pedantic ;-)  I agree that those routers
forward the packets where we don't want them to go!

My point is simply that we must not assume that other systems make
the check.  Or, if we find that all known implementations do make the
check, then we could dramatically improve 1195 and make it mandatory,
and explain the new (relaxed) deployment rules.

Regards,
Jeff

>If the next hop is not protocol