whether could it be multi-hops away between CE and FE in one NE?

Hi,Weiming,

It is a good idea. 

When I read the draft "ForCEs Intra-NE Topology Discovery", there is one word involving this issue in section 3 "Topology Discovery Mechanism" ,page 5, here it is "It is up to the ForCES association protocol to determine how to setup the ForCES channel between the CE and FE if they are multiple hops away.". 

If we really allow this scenario, we may have to update the related drafts to eliminate all inconsistencies. And I believe that allowing that it can be multi-hops away along the way from CE to FE does not incur any more serious problems with an exception of congestion. However, this problem still exists even in the single-hop case.

If someone can give some comments, We will really appreciate.

Best,

Huaiyuan,Ma &
Zengjie,Kou

 



----- Original Message ----- 
From: "Wang,Weiming" <[email protected]>
To: "Michael" <[email protected]>
Sent: Friday, August 18, 2006 3:16 PM
Subject: Re: TML events: what events we need?


> Michael,
> 
> I did not intensively read the applicability draft  before, but as far as I
> know, the single-hop /multi-hops issue has already been solved with a consencus
> that both cases are all allowed. I'm not sure why they write the applicability
> in this way. I do suggest that you propose this question to list for more
> discussions.
> 
> Thanks,
> Weiming
> 
> ----- Original Message ----- 
> From: "Michael" <[email protected]>
> Subject: Re: TML events: what events we need?
> 
> 
>> Hi, Weiming,
>>
>> In fact here we  just ensure one case: whether there are multi-hops away along
> the path from CE to FE is legal in the Forces framework, because when we read
> draft "ForCES Applicability Statement " ,  there is a statement as below, please
> check it:
>>
>>    ForCES is applicable in localities consisting of control and
>>    forwarding elements which are either components in the same physical
>>    box, or are separated at most by one local network hop (historically
>>    referred to as "Very Close" localities).
>>
>>    5.2.    Localities
>>
>>    ForCES protocol was intended to work within the localities described
>>    in the last section.  Outside these boundaries, care must be taken
>>    or the protocol may not work right.  Examples of localities where
>>    ForCES was not originally intended to be used:
>>
>>    o    Localities where there are multiple hops between CE and FE.
>>
>>    o    Localities where hops between the CE and FE are dynamically
>>    routing using IP routing protocols.
>>
>>    o    Localities where the loss of the CE-FE link is of non-
>>    negligible probability.
>>
>> It is confusing for us, we just want to confirm this with you, that is all.
>>
>> Best,
>>
>> Huaiyuan,Ma  &
>> Zengjie,Kou
>>
>>
>> ----- Original Message ----- 
>> From: "Wang,Weiming" <[email protected]>
>> To: <[email protected]>
>> Sent: Wednesday, August 16, 2006 5:11 PM
>> Subject: Re: TML events: what events we need?
>>
>>
>> > Hi Huaiyuan,
>> >
>> > The case of Multi-hops is not excluded by ForCES. There are related
> descriptions in rfc3654, 3746, and in the working group charter.
>> >
>> > Actually the congestion problem happens even if it is a single-hop ethernet
> media between CEs and FEs.
>> >
>> > thanks,
>> > weiming
>> > ----- Original Message ----- 
>> > From: "Michael" <[email protected]>
>> > Subject: Re: TML events: what events we need?
>> >
>> >
>> >> Hi, Weiming,
>> >>
>> >> you mentioned that the paths might be multi-hops away along the paths from
> FE to CE, but in the RFC3746, all CEs and FEs in one NE are only one-hop away,
> shall we consider this senario in FORCES?
>> >>
>> >> Huaiyuan,Ma &
>> >> Zengjie,Kou
>> >>
>> >>
>> >>
>> >> ----- Original Message ----- 
>> >> From: "Wang,Weiming" <[email protected]>
>> >> To: <[email protected]>
>> >> Sent: Monday, August 14, 2006 5:30 PM
>> >> Subject: Re: TML events: what events we need?
>> >>
>> >>
>> >> > Joel,
>> >> >
>> >> > Thanks again for the comments.
>> >> >
>> >> > In reply, we may have to take some thing that we discussed before. I
> don't think we should expect TML to completely solve the congestion problem.
> Even if we the ForCES use things like DCCP, we should not expect that there will
> be no congestion along the paths between CE and FE, especially when the paths
> are multi-hops away. A simple case is, in the multi-hops path, there is one UDP
> payload which is from non ForCES element and wich will then still congest other
> payloads over the path.
>> >> >
>> >> > One more thing is, as we discussed before, we really should not exclude
> the TCP+UDP TML.
>> >> >
>> >> > Let's put aside what name of congestion events we should define.  I just
> think that we at least must have one event that can let TML tell PL that the TML
> is in some trouble of transporting PL control messages caused by congestion.
> Notified by the information, PL may then be able to use things like redirect
> data rate controller in the FE forwarding plane to deal with it. I remembered
> that in our discussion before, you also mentioned using such way to avoid the
> TML congestion. Whereas without the congestion notification from TML, how can
> such rate controller properly work to copy with the CE-FE control message
> transmission problem?
>> >> >
>> >> >> I would expect a list of events along the following lines:
>> >> >> 1) Arrival of a TML control message
>> >> >> 2) Arrival of a TML data message
>> >> > Why should we differenciate control message and data message here? PL can
> recognize it very easily by the message type.
>> >> >
>> >> >> 3) Completion of an asynchronous TML request
>> >> > This may be useful for things like asynchronous TML configuration and TML
> send.
>> >> >
>> >> >> 4) TML detected error condition
>> >> > Yes, that looks better and more universal than the TML failure event.
>> >> >
>> >> > Thanks,
>> >> > Weiming
>> >> >
>> >> > ----- Original Message ----- 
>> >> > From: "Joel M. Halpern" <[email protected]>
>> >> >
>> >> >> I would hope that we do not need to include congestion events.
>> >> >> There are several issues that concern me with regard to defining such
> events:
>> >> >> 1) Many standard stacks do not expose that information
>> >> >> 2) What level of congestion would be required to trigger a notification
>> >> > Individual TMLs will define this.
>> >> >> 3) What would a PL do with such a notification.
>> >> >
>> >> >>
>> >> >> It is the TMLs job to cope with congestion.
>> >> >>
>> >> >> Similarly, since DoS attack is not a well defined condition, I have
>> >> >> trouble with having an event for it.
>> >> >>
>> >> >> I would expect a list of events along the following lines:
>> >> >>
>> >> >> 1) Arrival of a TML control message
>> >> >> 2) Arrival of a TML data message
>> >> >> 3) Completion of an asynchronous TML request
>> >> >> 4) TML detected error condition
>> >> >>
>> >> >> Item 3 could be used to handle the first two. My mild preference is
>> >> >> to separate them, because incoming messages are such a common case,
>> >> >> and must be notified even if transmissions are synchronous.
>> >> >> Item 3 would also include the error termination, e.g. when an
>> >> >> asychronous write fails.
>> >> >> Item 4 should be just for errors which cause the termination of the
>> >> >> TML connection.
>> >> >> I think these are the same as the first 2 items on your list, with a
>> >> >> little more detail.
>> >> >>
>> >> >> Yours,
>> >> >> Joel M. Halpern
>> >> >>
>> >> >> At 01:52 AM 8/11/2006, Wang,Weiming wrote:
>> >> >> >Hi,
>> >> >> >
>> >> >> >We are discussing on TML events on how they are notified to PL and
>> >> >> >we'l continue the discussion till it is solved.
>> >> >> >
>> >> >> >One more important issue for TML events is what TML events we need
>> >> >> >to define for PL-TML interactions. We have currently defined the
>> >> >> >following TML events:
>> >> >> >
>> >> >> >   1) TML failure event
>> >> >> >   2) ForCES Message arrival event
>> >> >> >   3) ForCES Control messages congestion event
>> >> >> >   4) ForCES Redirect messages congestion event
>> >> >> >   5) DoS attack alert event
>> >> >> >
>> >> >> >I'd like to solicit  for comments on necessity and adequacy of above
> events!
>> >> >> >
>> >> >> >Thanks,
>> >> >> >Weiming
>> >> >>
> 
>