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

From: "Chan, Chung Ming (Adtech ENG)" <[email-masked]>
Date: Mon, 26 Nov 2001 07:01:52 -1000

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: Tony Li <[email-masked]>
Date: Mon, 26 Nov 2001 11:48:50 -0800

| 	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.

Well, that would certainly be one interpretation of the spec.  However,
that would seem to be less interoperable.

     "Be strict in what you send and liberal in what you receive."
				     - Jon Postel

Accordingly, putting a Protocols Supported field in the pseudonode LSP is
not something that I interpret as being required by the spec.

Tony