Subject: [Iptel] Route Capability question(s)

From: "Rick W. Porter" <[email-masked]>
Date: Thu, 5 Dec 2002 15:34:49 -0500

I came across some interesting situations while testing TRIP that seem to beg some clarification of the negotiated Route Capability. I assume that TRIP peers internal to an ITAD can have different route capabilities.

My basic questions is what the negotiated route capabilities applies to? 

If it means that nothing that passes thru that connection contains a route type outside the negotiated route capabilities, your LS topology can create situations where the ITAD is segmented. This violates the premise that all internal peers have the same info. Additionally, an LS will likely burn many CPU cycles when during flooding it must tailor a received message to each internal peer.

If it applies to the peer LS (not just the connection), I have questions arising from a couple scenarios... First, what do you do for a peer who is not directly connected to you (you never establish a peering session and negotiate route capabilities with them)? Second, let's assume that an LS can be (mis)configured to negotiate different route capabilities with different peers. What is the correct behavior when there are multiple "paths" to get between two peers with different negotiated route capabilities? Do you assume the lowest common denominator of negotiated route capability?

One thought that I had is revising the spec to eliminate route capability negotiation within an ITAD. I'm open to other suggestions, but at a glance it seems to me the best thing to do. I understand this does create potential memory allocation problems if you must store all route types (even those you have no use for).

Below are a few RFC 3219 points of interest.
 
later,
Rick

Section 4.2.1.1.1: "An LS MUST NOT use route types that are not supported by the peer LS in any particular peering session."  If someone is not directly connected to you, then you have no peering session.

Section 5.2.5: "The ReachableRoutes attribute is recomputed at each LS except where flooding is being used (e.g., within a domain)."  Implies the same message forwarded to everyone.

Section 6.3: "The error checks in this section MUST be performed by each LS upon receipt of every UPDATE message.  These error checks MUST occur before flooding procedures are invoked with internal peers." No mention is made of checking for unsupported route types.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Dec 2002 16:48:06 -0500

Rick W. Porter wrote:
> I came across some interesting situations while testing TRIP that seem 
> to beg some clarification of the negotiated Route Capability. I assume 
> that TRIP peers internal to an ITAD can have different route capabilities.

What is the motivation for such an assumption? That seems pretty 
counter-intuitive to me.

> If it means that nothing that passes thru that connection contains a 
> route type outside the negotiated route capabilities,

THis is what I thought.

> your LS topology 
> can create situations where the ITAD is segmented. This violates the 
> premise that all internal peers have the same info. 

Only because you are assuming LS's in the ame ITAD can have different 
route capabilities.

> Additionally, an LS 
> will likely burn many CPU cycles when during flooding it must tailor a 
> received message to each internal peer.

Again, only if you make this assumption.

>  
> If it applies to the peer LS (not just the connection), I have questions 
> arising from a couple scenarios... First, what do you do for a peer who 
> is not directly connected to you (you never establish a peering session 
> and negotiate route capabilities with them)?

Then they are not a peer:

> Peers: Two LSs that share a logical association (a transport
>    connection).  If the LSs are in the same ITAD, they are internal
>    peers.  Otherwise, they are external peers.  The logical association
>    between two peer LSs is called a peering session.

> Second, let's assume that 
> an LS can be (mis)configured to negotiate different route capabilities 
> with different peers. What is the correct behavior when there are 
> multiple "paths" to get between two peers with different negotiated 
> route capabilities? Do you assume the lowest common denominator of 
> negotiated route capability?

Sounds like the answer is "dont do that".

>  
> One thought that I had is revising the spec to eliminate route 
> capability negotiation within an ITAD. I'm open to other suggestions, 
> but at a glance it seems to me the best thing to do. I understand this 
> does create potential memory allocation problems if you must store all 
> route types (even those you have no use for).

I just assumed all LS in an ITAD had to support the same route capabilities.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Iptel mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/iptel

---

From: "Rick W. Porter" <[email-masked]>
Date: Tue, 17 Dec 2002 09:57:15 -0500

Hi Jonathan,

Thank you for taking the time to respond.

I was picturing a network where network elements within an ITAD support
different protocols or address families. For example, some network elements
support H323-Q931 and SIP, while other network elements support just SIP.  I
thought this may be desirable due to geographic concerns and installed
protocol bases. As you add protocols to a network, it may also be desirable
to have a non-homogeneous Route Capability within an ITAD (at least as a
transient effect).

IMHO, if TRIP only supports homogeneous Route Capability within an ITAD, it
should probably be noted somewhere. I guess I raise the point b/c it was not
clear to me--if no one else finds it confusing, great. If you want to
mandate that ITADs have homogeneous Route Capability, then all my issues go
away you can stop reading my response... Otherwise, I responded to a couple
other points below.

Thanks,
Rick

----- Original Message -----
> >    between two peer LSs is called a peering session.

My understanding was that TRIP does not require a full mesh (as does BGP),
so two LSs in the same ITAD could learn each others routes without being
directly connected. Below, I depict the simplest such situation within an
ITAD.

LS A <---> LS B <---> LS C

I believe you would still want LS A to learn LS C's routes (and vice versa).
And, according to Section 10.1, "When an LS receives an UPDATE message from
an internal peer, the LS floods the new information from that message to all
of its other internal peers."  I understand this to mean that LS B would
send all new LS A routes to LS C (and vice versa).

I agree that LS A and LS C do not have a peering session, but what would be
the relationship between LS A and LS C (given they're in the same ITAD)?  My
understanding is that they would be still be internal peers, but have no
peering session. You would determine "connectivity" with them using the ITAD
Topology attributes.

If they are internal peers, what route capabilities would LS A allow for LS
C?  If they are not internal peers, would LS A treat LS C routes (learned
via the peering session with LS B) as routes from an external peer?

> Sounds like the answer is "dont do that".

I agree that this gets very messy, very quickly. That is why I proposed
eliminating the Route Capability negotiation within an ITAD.

---

From: "Hussein Salama" <[email-masked]>
Date: Tue, 17 Dec 2002 22:28:22 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Rick W. Porter
> Sent: Tuesday, December 17, 2002 4:57 PM
> To: Jonathan Rosenberg
> Cc: IPTEL
> Subject: Re: [Iptel] Route Capability question(s)
> 
> 
> Hi Jonathan,
> 
> I was picturing a network where network elements within an 
> ITAD support different protocols or address families. For 
> example, some network elements support H323-Q931 and SIP, 
> while other network elements support just SIP.  I thought 
> this may be desirable due to geographic concerns and 
> installed protocol bases. As you add protocols to a network, 
> it may also be desirable to have a non-homogeneous Route 
> Capability within an ITAD (at least as a transient effect).
> 
> IMHO, if TRIP only supports homogeneous Route Capability 
> within an ITAD, it should probably be noted somewhere. I 
> guess I raise the point b/c it was not clear to me--if no one 
> else finds it confusing, great.

What if some LSs support H323-Q931 only while other LSs in the same ITAD
support both H323-Q931 and SIP? This could happen for example when
migrating from one call control technology to another.

For correctness, it is sufficient that all internal LSs that support a
common route capability to synchronize the TRIBs corresponding to that
capability. For example, if two LSs, LS1 supports H323-Q931 only and LS2
supports both SIP and H323-Q931, then the two LSs must only synchronize
their H323-Q931 TRIBs. LS1 shouldn't be required to create a SIP
TRIB.Hence, I think that the restriction should be that all internal LSs
that support a common route capability should form a coonected network.

Thanks

Hussein

> If you want to mandate that 
> ITADs have homogeneous Route Capability, then all my issues 
> go away you can stop reading my response... Otherwise, I 
> responded to a couple other points below.
> 
> Thanks,
> Rick
> 
> > > If it applies to the peer LS (not just the connection), I have 
> > > questions arising from a couple scenarios... First, what 
> do you do 
> > > for a peer who is not directly connected to you (you 
> never establish 
> > > a peering session and negotiate route capabilities with them)?
> >
> My understanding was that TRIP does not require a full mesh 
> (as does BGP), so two LSs in the same ITAD could learn each 
> others routes without being directly connected. Below, I 
> depict the simplest such situation within an ITAD.
> 
> I believe you would still want LS A to learn LS C's routes 
> (and vice versa). And, according to Section 10.1, "When an LS 
> receives an UPDATE message from an internal peer, the LS 
> floods the new information from that message to all of its 
> other internal peers."  I understand this to mean that LS B 
> would send all new LS A routes to LS C (and vice versa).
> 
> I agree that LS A and LS C do not have a peering session, but 
> what would be the relationship between LS A and LS C (given 
> they're in the same ITAD)?  My understanding is that they 
> would be still be internal peers, but have no peering 
> session. You would determine "connectivity" with them using 
> the ITAD Topology attributes.
> 
> If they are internal peers, what route capabilities would LS 
> A allow for LS C?  If they are not internal peers, would LS A 
> treat LS C routes (learned via the peering session with LS B) 
> as routes from an external peer?
> 
> >
> >
> > > an LS can be (mis)configured to negotiate different route 
> > > capabilities with different peers. What is the correct 
> behavior when 
> > > there are multiple "paths" to get between two peers with 
> different 
> > > negotiated route capabilities? Do you assume the lowest common 
> > > denominator of negotiated route capability?
> >
> I agree that this gets very messy, very quickly. That is why 
> I proposed eliminating the Route Capability negotiation 
> within an ITAD.
> 
>

---

From: "Rick W. Porter" <[email-masked]>
Date: Wed, 18 Dec 2002 08:13:31 -0500

Thanks Hussein for your input. It sounds to me like you agree that an ITAD
may need to have network elements with different Route Capabilities. Your
proposed restriction that all internal LSs that support a common route
capability should form a connected network sounds perfectly reasonable to
me, and it stops the ITAD from becoming segmented. However, there are
implications for message processing--mainly the flooding, which I explore
below.

We'll assume that negotiated route capability applies to the peer session
(connection), which seems a logical assumption to me. Let's take a simple
scenario illustrated below where LS1 and LS2 support SIP and H323-Q931,
while LS3 only supports H323-Q931.

LS1 <---> LS2 <---> LS3

When LS2 receives a SIP route from LS1, what happens to it? I believe that
according to current flooding rules, it would get flooded in it's entirety
to LS3.  Do you propose that LS2 tailors the message to forward only
negotiated route types to LS3?

If LS2 filters out the unnegotiated route types for each peer, it would not
be a big issue in this scenario. Messages from LS1 that contain only SIP
routes would be completely dropped, and messages from LS1 that contain both
SIP and H323-Q931 routes would have the SIP routes filtered out so only
H323-Q931 routes would be forwarded. Although not a big deal here, the
center of a star configuration with many peers may burn lots of CPU cycles
tailoring messages during flooding. Does that defeat the purpose of
flooding?Maybe a release note for an LS product would be sufficient, but it
seems to me to be more a protocol issue than an implementation issue. I
understand that an intelligent implementation may minimize the impact by
"grouping" connections by negotiated route types so the message could be
tailored to a group instead of tailoring it to individual peers.

If LS2 does not filter out unnegotiated routes (as currently seems to be
suggested), it would forward the message in its entirety to LS3.  Does LS3
ignore out the unsupported (SIP) route type? Possibly send a notification
message (potential error code=0x306)? If there were an LS4 connected only to
LS3, would LS3 then filter the SIP routes before flooding? Ignoring and
flooding the unnegotiated route type would seem to be the simplest from an
implementation standpoint. Then, why did we negotiate a route capability for
the connection?

Thanks,
Rick

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 23 Dec 2002 02:21:10 -0500

I have no problem with enterprises that have LSs that speak different 
protocols. However, I would model that as multiple logical ITADs, rather 
than a single ITAD. Each logical ITAD would have homogeneous 
capabilities amongs the elements. LS's at the border of one logical 
ITADF to another would be responsible for propagating only the 
appropriate routes from one to the other. I see no need to make this 
more complicated.

-Jonathan R.