Subject: A clarification on component link advertisement

From: Tony Li <[email-masked]>
Date: Fri, 19 Nov 2010 16:05:10 +0900

Hi all,

In subsequent conversations, it has become apparent that there is some confusion between advertising information about component links in the IGP and actually creating IGP adjacencies across those component links.

To be crystal clear, what I was suggesting was purely the former: we would inject specific information about the component links into the IGP.  This would contain things like delay and bandwidth only.  There would be only 1 IGP adjacency on the composite link, it would not matter which link it ran over (but see below), and we would use some other mechanism (e.g., BFD) to ensure liveness on each component link.  This insures that the IGP hello mechanisms and flooding mechanisms scale with the number of the composite links, even if the IGP's link state database scales with the number of component links.

Nit/Question:  It would be very nice to be able to allow the IGPs on neighboring boxes to form an asymmetric adjacency over the composite link, wherein one of them may transmit protocol packets on one component and its L3 neighbor could transmit protocol packets on a different component of the same composite link.  If we have achieved an appropriate level of abstraction, this _should_ just work.

However, there's a hitch: do we allow a composite link to have components which have different models?  Can we put a point-to-point link into the same composite link as a broadcast network?  If we do, then IS-IS at least, runs differently on the two models and would probably not work in an asymmetric manner in this situation.  I suspect we need a clarification of requirements here.

Regards,
Tony

---

From: Yong Lucy <[email-masked]>
Date: Fri, 19 Nov 2010 10:35:53 -0600

Hi Tony,

Thank you very the clarification. It is very helpful. See inline.

Regards,
Lucy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tony Li
> Sent: Friday, November 19, 2010 1:05 AM
> To: [email-masked]
> Subject: A clarification on component link advertisement
> 
> 
> Hi all,
> 
> In subsequent conversations, it has become apparent that there is some
> confusion between advertising information about component links in the IGP
> and actually creating IGP adjacencies across those component links.
> 
> To be crystal clear, what I was suggesting was purely the former: we would
> inject specific information about the component links into the IGP.  This
> would contain things like delay and bandwidth only.  There would be only 1
> IGP adjacency on the composite link, it would not matter which link it ran
> over (but see below), and we would use some other mechanism (e.g., BFD) to
> ensure liveness on each component link.  
[LY] Very clear description. This is the objective.
>This insures that the IGP hello
> mechanisms and flooding mechanisms scale with the number of the composite
> links, 
[LY] You mean component link here.
>even if the IGP's link state database scales with the number of
> component links.
[LY] Yes.
> 
> Nit/Question:  It would be very nice to be able to allow the IGPs on
> neighboring boxes to form an asymmetric adjacency over the composite link,
> wherein one of them may transmit protocol packets on one component and its
> L3 neighbor could transmit protocol packets on a different component of
> the same composite link.  If we have achieved an appropriate level of
> abstraction, this _should_ just work.
[LY] Agree the approach.
> 
> However, there's a hitch: do we allow a composite link to have components
> which have different models?  
[LY] There are three kinds of component links in the framework draft. What
model do you refer here?
Can we put a point-to-point link into the
> same composite link as a broadcast network?  
[LY] IMHO: an interface is either an IGP link or a component link in a
composite link, but not both. Operator view on this is necessary.
>If we do, then IS-IS at least,
> runs differently on the two models and would probably not work in an
> asymmetric manner in this situation.  I suspect we need a clarification of
> requirements here.
> 
> Regards,
> Tony
> 
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: "So, Ning" <[email-masked]>
Date: Fri, 19 Nov 2010 22:27:19 +0000

Tony,

Thanks for the clarification.  As discussed, I agree to the approach
that does not aggregate component link BW and latency if it does not
impact the IGP adjacency.

One more question for you.  Could you please elaborate on "put a
point-to-point link into the same composite link as a broadcast
network"?  I am not sure I understand what you mean. 

Best regrads,
 
Ning So
Network Evolution Planning
Verizon, Inc.
(office) 972-729-7905
(Cell) 972-955-0914

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tony Li
Sent: Friday, November 19, 2010 1:05 AM
To: [email-masked]
Subject: A clarification on component link advertisement

Hi all,

In subsequent conversations, it has become apparent that there is some
confusion between advertising information about component links in the
IGP and actually creating IGP adjacencies across those component links.

To be crystal clear, what I was suggesting was purely the former: we
would inject specific information about the component links into the
IGP.  This would contain things like delay and bandwidth only.  There
would be only 1 IGP adjacency on the composite link, it would not matter
which link it ran over (but see below), and we would use some other
mechanism (e.g., BFD) to ensure liveness on each component link.  This
insures that the IGP hello mechanisms and flooding mechanisms scale with
the number of the composite links, even if the IGP's link state database
scales with the number of component links.

Nit/Question:  It would be very nice to be able to allow the IGPs on
neighboring boxes to form an asymmetric adjacency over the composite
link, wherein one of them may transmit protocol packets on one component
and its L3 neighbor could transmit protocol packets on a different
component of the same composite link.  If we have achieved an
appropriate level of abstraction, this _should_ just work.

However, there's a hitch: do we allow a composite link to have
components which have different models?  Can we put a point-to-point
link into the same composite link as a broadcast network?  If we do,
then IS-IS at least, runs differently on the two models and would
probably not work in an asymmetric manner in this situation.  I suspect
we need a clarification of requirements here.

Regards,
Tony

---

From: Tony Li <[email-masked]>
Date: Sat, 20 Nov 2010 15:37:53 +0900

Hi Lucy,

> [LY] You mean component link here.

Yes, thank you.  Doh.

> [LY] There are three kinds of component links in the framework draft. What

You seem to be missing anything other than point-to-point components (e.g., Ethernet).  Do we support those?  The requirements don't seem to exclude those.

> composite link, but not both. Operator view on this is necessary.

That would seem to preclude recursion, where a composite link is also a component.  I'm not sure that this is useful, but it seems worthy of being explicitly considered.

Tony

---

From: Tony Li <[email-masked]>
Date: Sat, 20 Nov 2010 15:41:16 +0900

Hi Ning,

> network"?  I am not sure I understand what you mean. 

Can a point-to-point Ethernet be a component?

What about a switched Ethernet?

What about a switched Ethernet with other hosts on the Ethernet?

What happens if there are multiple switched Ethernets, with partially intersecting sets of other hosts?

I'm hoping that you're going to say that a component must be a logical point-to-point link, but I don't see that in the requirements.

Regards,
Tony

---

From: Yong Lucy <[email-masked]>
Date: Mon, 22 Nov 2010 14:35:01 -0600

Hi Tony,

> components
> You seem to be missing anything other than point-to-point components
(e.g.,
> Ethernet).  Do we support those?  The requirements don't seem to exclude
> those.

[LY] Thank you for the statement. IMO, we need to clarify about component
link definition in the draft. i.e. point-to-point connection.

> That would seem to preclude recursion, where a composite link is also a
> component.  I'm not sure that this is useful, but it seems worthy of being
> explicitly considered.
> 

[LY] A composite link can be one segment of a component link in another
composite link. But, IMHO: an IGP link should not be a component link as
well vice versa. It seems that the definitions are not precise yet.

Regards,
Lucy

---

From: "So, Ning" <[email-masked]>
Date: Tue, 23 Nov 2010 22:11:40 +0000

Tony,

Thank you for the clarification, and I agree with you that a component
link should be limited to a physical and/or logical point-to-point link.
Personally I do not see an application for the other types, and allowing
them will make solutions too complicated.  I can certainly make the
changes to the requirement draft if there is no objection.   

Best regrads,
 
Ning So

-----Original Message-----
From: Tony Li [mailto:[email-masked]] 
Sent: Saturday, November 20, 2010 12:41 AM
To: So, Ning
Cc: [email-masked]
Subject: Re: A clarification on component link advertisement

Hi Ning,

What happens if there are multiple switched Ethernets, with partially
intersecting sets of other hosts?

I'm hoping that you're going to say that a component must be a logical
point-to-point link, but I don't see that in the requirements.

Regards,
Tony