Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4)

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 1 May 2003 09:21:09 +0300

Sasha, 

> Just for the reference: Axerra develops, produces and sells 
> an edge device that handles multiple PW types. Some of the supported PWs use RTP and 
> some don't. And, so far, we have not experienced any problem due to
> different encapsulations. 

Yes, I know that you have such capabilities.
However, the fact that a problem CAN be addressed using a certain
set of constraints, doesn't mean that these constraints are useful.

For example, as we all know CESoPSN uses a completely
different control word from the "standard" one used in atm-encap, fr-encap, etc.

Now, assuming that your device really handles multiple PWE encap types 
(and not, for instance, simply transporting frame relay inside a TDM timeslot
which really isn't handling multiple PWE types)
then you have to first "know" which PWE type the incoming packet is,
before handing it off to the appropriate encap handler.
This knowledge is apparently in the configuration based on the label
or IP destination address, or some other non-PWE layer.

So although your device may handle multiple PWE types,
your use of different CWs forces you to handle them separately,
needlessly duplicating hardware and software.
 
> I do not see why supporting multiple encapsulations in a "PWE3 chip" 
> would be different in any way.  Granted, I am not an ASIC expert. 
> But Ron and Tim are. 

Once again, this is not the point.
Given an engineering constraint I am sure that Ron and Tim
can come up with a solution. But we are trying
to do architecture DESIGN here, not live with arbitrary constraints.

In pure terms, a "PWE chip" should be able to receive
a packet containing any PWE type (or at least any type it
was designed to handle) and be able to process it.
By processing I mean, at very leaast to be able to 
strip and check the CW, performing sequencing, timing, 
errorr detection, etc. as relevant. It would then send the payload to wherever.

By using multiple CW types, multiple placements for the CWs,
and not using consistent PIS, we make the clean design
of such a "PWE chip" impossible. We now need
an ATM-encap chip, a fr-encap chip, a tdm-encap chip, 
and a controller chip which uses info in other layers to
relegate the processing to the appropriate chip.

Of course, these chips could be forced onto a single
substrate, but they are still logically distinct.

> IMO,  an attempt to insert a (possibly suppressed)
> RTP header between the CW and the payload would
>  make such a chip really complicated.

Quite the contrary.

Some PWs need RTP, others don't.
We need to first uniquely determine that the packet is
a PWE packet (that should determined by the "type" in the previous layer,
i.e. MPLS PID, IP type, etc). Then this packet would be passed
to the "PWE chip". This chip must first determine which PWE type
we have and handle all common PWE functionality. 

Only then, if the PWE type supports RTP, and RTP is determined
to be in use, should the RTP information be extracted and used.

Any other order is not only more complex,
it is a clear layer violation (more on that in another email).

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 1 May 2003 10:15:41 +0200

Yaakov,
Please see some comments inline.
Hopefully they will clarify the situation.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Thursday, May 01, 2003 8:21 AM
> To: Sasha Vainshtein
> Cc: [email-masked]; Ron Cohen; Tim Frost (E-mail); Andrew 
> G. Malis; [email-masked]
> Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4)
> 
> 
> Sasha, 
> 
I agree and I am happy to see that you accept this principle. 
E.g., the fact that TDM traffic CAN be carried across a PSN
a an AAL1 cell stream does not mean that the AAL1-imposed 
constrains (like inability to work with packetoization delay that 
is a multiple of 125 mirocseconds etc.) are useful. IMO, they are not,
> which really isn't handling multiple PWE types)
I can assure you that the Axerra device really carries FR,
HDLC and Ethernet frames in the corresponding PWs.
> or IP destination address, or some other non-PWE layer.
This is exactly the function of the demultilexing layer in the PWE
protocol stack. That is what the VC label/L2TPv3 Session ID etc.
exist. Please note that this function is required regardless of multiple
PW types/encpaulations (sorry for having to state an obvious fact).
As the result, each incoming packet is forwarded to its specific
IWF instance for further processing (Sequencing, Synchronization, playout
etc.)
> needlessly duplicating hardware and software.
I think that different services require different IWF logic. In particular,
I do not think that you need jitter buffer and clock recovery for FR or
HDLC, while these blocks are necessary for TDM PWs.   
... snipped ...
> By processing I mean, at very least to be able to 
> error detection, etc. as relevant. It would then send the 
> payload to wherever.
>
Since requirements for these functions are quite different, pushing
their implementation in one monolothic block looks like a very
bad design decision indeed. 
... snipped ...
> i.e. MPLS PID, IP type, etc). Then this packet would be passed
I am not sure I understand what "IP Type" you refer to. 
And, IMHO you have lost completely the meaning of  MPLS PID.
It is NOT used by the PEs - only by the core routers to distinguish
between IPv4/IPv6 and non-IP packets. That is why the PEs MAY be configured
to omit it if the core routers are known not to use ECMP.
Once the packet has reached the PE, it is switched to the appropriate
upper layers according to one of several demultiplexing mechanisms:
o In case of an MPLS demultiplexing layer - according to the VC label
o In case of IP/L2TPv3 (as defined by the Protocol Type in the IPv4 header)
-
  - according to the Session ID value
o In case of IP/UDP  - according to the UDP destination port ec.
> it is a clear layer violation (more on that in another email).
I do not see any layer violation here. But I promise to read your next mail.

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 1 May 2003 11:47:47 +0300

> I do not see any layer violation here. But I promise to read 

There are many problems.

For example, take a look at Ron's ASCII art diagram.

Of the three sublayers of the encapsulation layer,
you can clearly see that the middle one (timing) 
has been farmed out to a lower layer.
This means that the timing performs a service
for the sequencing, and is performed before
this sequencing.

But the sequencing MUST be checked before
timing recovery is attempted, since packets may
be mssing or mis-ordered.

Additionally, between the PW demux layer and the
encapsulation layer, we now have a new layer.
As my previous email discussed,
it is not allowed to have direct connection between layers N and N+2,
and thus the RTP sunders the PW mechanisms.

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 1 May 2003 13:27:42 +0300

I agree that it CAN provide sequencing,
but the CW has a sequence number as well,
which is the standard PWE method of sequencing.

The use of RTP adds an additional NON-PWE sequence number,
and various suggestions have been given on how to align
the two numbers (e.g. use the LSBs, etc). Unfortunately,
the two are NOT alignable because of the standard PWE
sequence number processes (skipping zero)
so the problem remains.

Y(J)S

> From: Alexander Vainshtein 
> Sent: Thursday, May 01, 2003 2:20 PM
> To: Yaakov Stein
> Yaakov and all,
> Please note that RTP provides BOTH sequencing and
> synchronization services. This is why there is no layer
> violation in Ron's diagram.
> 
> With best regards,
>                                    Sasha Vainshtein
> > Sent: Thursday, May 01, 2003 10:48 AM
> > To: Sasha Vainshtein

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 1 May 2003 13:20:24 +0200

Yaakov and all,

With best regards,
                                   Sasha Vainshtein

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 1 May 2003 16:49:56 +0300

Akiva, 

>   AFAIK skipping zero in sequence number processing isn't mentioned in
> framework/architecture drafts.

Correct, but that is the way the non-RTP drafts handle it.
I have no problem with changing that,
but as the situation stands we have an incompatibility.

>    Support for sequencing depends on the payload type, and may be
>    omitted if not needed.  For example, Frame Relay always 
>    requires the preservation of packet order.  However, where the Frame 
>    Relay service is only being used to carry IP, it may be desirable to relax that
>    constraint in return for reduced per-packet processing cost.
> 
>    [RTP] or encapsulation-specific sequence numbers may be used for
>    sequencing.

That's great news, but unfortunately the FR draft does not use RTP,
so there is no way of using RTP sequence numbers either.

I guess this misunderstanding has something to do with
Axerra's private architecture for PWE (universal RTP)
which has little in common with the WG-adopted one.
(Akiva - please forgive the jab - I couldn't resist).

<snip>

> Have i missed smth ?

No, I think that the IETF has missed something.

Had the MPLS WG ensured ordered delivery
(as would be logical from a purely architecural point of view)
we wouldn't be in such a fix, and wouldn't now be putting together
such strange structures.

The way it stands we HAVE to have a consistent sequencing method.

Y(J)S

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 1 May 2003 09:53:35 -0400

> From: Sasha Vainshtein [mailto:[email-masked]]
> 
> Yaakov and all,

It seems to me that the truth lies in the middle.
Some elements of the Control Word (the first nibble, fragmentation bits and sequence numbers) clearly belong to the PW layer and should immediately follow the PW Label. Other elements (protocol specific flags and pointers) clearly belong to the payload and should immediately preceed the payload. In case RTP is used, it should sit in between.

Lets call 'first nibble + fragmentation bits + sequence numbers': CW-PW,
and 'flags + pointers': CW-PL, and let's assume that RTP sits in between. Since RTP provides sequencing, the sequence numbers in CW-PW could be eliminated, which reduces CW-PW to the first nibble plus fragmentation bits. However, this would mean that CW-PW is practically identical to the MPLS PID.

Conclusion: The order MPLS PID - RTP Header - CW doesn't seem like a severe layer violation.

That said, I do think that the current drafts would benefit from a more narrow specification of the use of sequence numbers (i.e. I think that an encapsulation with two sequence numbers should be avoided) and fragmentation (it is still not clear to me whether it could be supported, as the architecture draft says, or not)

Peter

> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 01 May 2003 15:27:52 +0100

From Section 5.4.3:

Sequence number (Bit 16 to 31):
            If the sequence number is not used, it is set to zero by
            the sender and ignored by the receiver.  Otherwise it
            specifies the sequence number of a packet. A circular list
            of sequence numbers is used. A sequence number takes a value
            from 1 to 65535 (2**16-1).

Akiva Sadovski wrote:
> Hi, Yaakov and all,
> Framework:
> <quote>
> 3.5.2.2.  Sequencing
>    omitted if not needed.  For example, Frame Relay always requires the
>    preservation of packet order.  However, where the Frame Relay service
>    is only being used to carry IP, it may be desirable to relax that
> <endquote>
> Architecture:
> <quote>
> 5.2.1.  Sequencing
>    The sequencing function provides three services: frame ordering,
>    frame duplication detection and frame loss detection. These services
>    allow the emulation of the invariant properties of a physical wire.
>    Support for sequencing depends on the payload type, and MAY be
>   omitted if not needed.
> 
>    The size of the sequence-number space depends on the speed of the
>    emulated service, and the maximum time of the transient conditions in
>    the PSN.  A sequence number space greater than 2^16 may therefore be
>    needed to prevent the sequence number space wrapping during the
>    transient.
> <endquote>
> 
> Have i missed smth ?
> 
> thanks,
>   Akiva Sadovski
> 
> 
>>Sent: Thursday, May 01, 2003 12:28 PM
>>To: Sasha Vainshtein
>>>>it is not allowed to have direct connection between layers 
>>>
>>>N and N+2,
>>>

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 1 May 2003 17:34:15 +0300

Peter, 

> Some elements of the Control Word (the first nibble, 
> fragmentation bits and sequence numbers) clearly belong to 
> the PW layer and should immediately follow the PW Label. 
> Other elements (protocol specific flags and pointers) clearly 
> belong to the payload and should immediately preceed the 
> payload. In case RTP is used, it should sit in between.
> 
> Lets call 'first nibble + fragmentation bits + sequence 
> numbers': CW-PW, and 'flags + pointers': CW-PL, 
> and let's assume that RTP sits in between. 
> Since RTP provides sequencing, the sequence 
> numbers in CW-PW could be eliminated,

I would agree with this, 
were it not for the fact that most of the drafts do NOT use RTP.
So it makes more sense to eliminate the RTP sequence number.

> which reduces CW-PW to 
> the first nibble plus fragmentation bits. However, this would 
> mean that CW-PW is practically identical to the MPLS PID.

My conclusion exactly.

> like a severe layer violation.

But what if the sequence number IS there,
since we want to use a unified PWE mechanism
for which we build a single unifed "PWE chip" ?

> 
> That said, I do think that the current drafts would benefit 
> from a more narrow specification of the use of sequence 
> numbers (i.e. I think that an encapsulation with two sequence 
> numbers should be avoided) 

Conclusion:  RTP is impractical for PWs ?

> and fragmentation (it is still not 
> clear to me whether it could be supported, as the 
> architecture draft says, or not)

Probably not, and that's probably a good thing too.

Y(J)S

---

From: Shahram Davari <[email-masked]>
Date: Thu, 1 May 2003 07:38:01 -0700

>o In case of IP/L2TPv3 (as defined by the Protocol Type in the 

Sasha, I think it is you who has completely misunderstood the meaning of
MPLS PID word that should precede the CW. The proposed MPLS PID, carries the
Payload ID of the PW not just identifying it as being IP or not. 

If it was only meant for intermediate routers, then we would have set the
last bytes of the MPLS PID word to Reserved not to PPP-PID or Ethertype or
anything else. But it seems that people want to define a proper MPLS PID
that would be used by PEs. In fact only the first nibble of MPLS PID word is
used by intermediate routers, which effectively does not carry any PID info.

-Shahram

---

From: Shahram Davari <[email-masked]>
Date: Thu, 1 May 2003 07:54:08 -0700

>Would it be so, the MPLS PID would be mandatory for all the PWs.
>Since it is not, your reasoning looks faulty. 
>>

MPLS PID being mandatory or optional does not change the fact the
the actual protocol identifier of MPLS PID is used by PEs and not
intermediate routers. So I am not sure what is faulty here?

Besides I think it should be made mandatory for PWE3 (i.e, non IP payload), 
because you never know for sure whether a PW may cross an ECMP network
or not.

-Shahram

-Shahram

---

From: Akiva Sadovski <[email-masked]>
Date: Thu, 1 May 2003 16:38:08 +0200

Hi, Yaakov and all,

Framework:
<quote>
3.5.2.2.  Sequencing

Architecture:

<quote>
5.2.1.  Sequencing

Have i missed smth ?

thanks,
  Akiva Sadovski

---

From: Akiva Sadovski <[email-masked]>
Date: Thu, 1 May 2003 17:26:28 +0200

Yaakov, Sasha and all,
short comments inline...

Best,
  Akiva

> Sent: Thursday, May 01, 2003 3:50 PM
> To: Akiva Sadovski; Sasha Vainshtein

  I agree with you.
    So:
	those who don't use RTP (FR, ATM, HDLC, Ethernet) may use any
suitable sequence number processing 
	(f.ex. zero skipping)

	those who use RTP have no problem with RTP and CW sequence numbers
synchronisation;

   therefore RTP can be considered as a valid Sequencing layer  (for those
who use RTP, sure)
 
> Axerra's private architecture for PWE (universal RTP)

   As far as i'm familar with Axerra's implementation there's no universal
RTP there. Frame Relay is RTP-free 
and we have no problems with it.

---

From: Alik Shimelmits <[email-masked]>
Date: Thu, 1 May 2003 17:34:37 +0200

...snipped

> (Akiva - please forgive the jab - I couldn't resist).

Yaakov, 
first, I have to say that you are NOT familiar with the Axerra architecture.
(that what I would expect because you do NOT work in Axerra.) 
Just for the reference - Axerra does not use and never used RTP to carry 
frame relay (as well as ATM and ethernet). 
second, it is amazing that, being a strong pusher for universal
RTP suppression, you invest so much effort into discussion of placement 
of the RTP header.
(forgive the jab ...) 

	Alik

<snip>

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 1 May 2003 17:43:02 +0200

Sharham,
Please see a brief comment inline.

With best regards,
                                   Sasha Vainshtein

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Thursday, May 01, 2003 4:38 PM
> To: Sasha Vainshtein; 'Yaakov Stein'
... skipped to the end ...

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 1 May 2003 18:17:12 +0200

Shahram,
Please see inline.

With best regards,
                                   Sasha Vainshtein

> Sent: Thursday, May 01, 2003 4:54 PM
I have been taught that, when facts contradict a theory, the facts win,
and the theory is faulty.
Since the MPLS PID issue in PWs is about 1 month old, and MPLS PWs are 
already implemented and deployed, I conclude that PEs neither need nor use 
the PID information.

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 1 May 2003 19:19:33 +0300

> I have been taught that, when facts contradict a theory, the 
> facts win, and the theory is faulty.
> Since the MPLS PID issue in PWs is about 1 month old, and 
> MPLS PWs are already implemented and deployed, I conclude that PEs neither 
> need nor use the PID information.

I have been taught that many schemes seem to work at first,
but then get bogged down.

I teach that it is better to think things through first,
rather than build a new system that will become
burdened with problems within a few years.

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 1 May 2003 19:17:04 +0300

> first, I have to say that you are NOT familiar with the 

Never claimed to be.

I just assumed that, based on vehement past support of RTP.

> Just for the reference - Axerra does not use and never used 
> RTP to carry frame relay (as well as ATM and ethernet). 
> RTP suppression, you invest so much effort into discussion of 
> placement of the RTP header.
> (forgive the jab ...) 

touche

Y(J)S

---

From: Shahram Davari <[email-masked]>
Date: Thu, 1 May 2003 14:06:26 -0700

>already implemented and deployed, I conclude that PEs neither 

Sasha, You are missing the point. The point is that if MPLS PID exists, then PEs
identify the payload by PID in the MPLS PID word. If not then they have to rely on
the signaled PID. 

-Shahram

---

From: Akiva Sadovski <[email-masked]>
Date: Sun, 4 May 2003 14:06:51 +0200

Hi, Shahram,

  a short naive question inside...

thanks,
   Akiva

> Sent: Thursday, May 01, 2003 11:06 PM
> To: Sasha Vainshtein
> G. Malis; [email-masked]; 'Yaakov Stein'
> MPLS PWs are 
> identify the payload by PID in the MPLS PID word. 

   Why do we need to identify the payload ? Are we going to support multiple
types of payloads per PW (f.ex. mix of Ethernet, ATM and TDM) ?
As draft-ietf-pwe3-arch states: "An inner MPLS label is used to provide 
the PW demultiplexing function". So the inner label identifies PW, do we
need
additional identifier for the Payload-IN-PW ?

If not then 
> they have to rely on

---

From: [email-masked]
Date: Mon, 5 May 2003 11:10:50 +0100

Akiva Sadovski wrote 04 May 2003 13:07
>   a short naive question inside...
<snipped>
> additional identifier for the Payload-IN-PW ?

Akiva....It's not a naive question since it has importnat architectural
consequences.  Let me try and answer you.

There is a fundamantal requirement to distinguish an OAM pkt from a traffic
pkt.  But this should be done *within* the specification of the layer
network technology in question and not using a PID.

In a properly specified technology this requirement is sorted up-front and
is part of the general data-plane pkt overhead.  So a PID is only really
required when (as you say) we are muxing different *client* layer signals
into a common *server* layer trail.  Note that the OAM of the server layer
trail is *constant/consistent* for any clinet layer carried (inc the muxed
case) and is a function of, and only of, the server layer.....each of the
clients should have their own independent OAM.

PWs are *not* layer networks, though this is effectively what PWE3 are
unneccessarily creating ....and something we don't want to see.  So, to
repeat, I am *not* advocating the use of PID for OAM/traffic differentiation
in the PW.....though I suspect some will be.  

Finally, the client/server cases of X/MPLS or X/IP are *not* the same cases
architecturally.  This architecturally incorrect 'assumption' that they are
the same case is partially responsible for why we are seeing functions
appearing in the PW 'in-between' layer that are strictly not required....the
other reason is poor specification of either the client or server layers per
se.

regards, Neil

---

From: Akiva Sadovski <[email-masked]>
Date: Mon, 5 May 2003 16:27:34 +0200

Neil,
  thanks for your thorough explanation;
so, you suppose, the only use of PID in PWs will be to
differentiate the PWs OAM from traffic ?

thanks,
   Akiva
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, May 05, 2003 12:11 PM
> To: Akiva Sadovski; [email-masked]; Sasha Vainshtein
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]

---

From: Shahram Davari <[email-masked]>
Date: Mon, 5 May 2003 06:54:47 -0700

Akiva,

Have a look at:

http://www.ietf.org/internet-drafts/draft-allan-mpls-pid-00.txt

The short answer is yes, we might want to multiplex multiple protocols
in the same PW. These protocols may include ICMP PING, GTTP, Y.1711,
LSP-PING, etc. (not ATM, TDM, FR, ...).

-Shahram 

>From: Akiva Sadovski [mailto:[email-masked]]
>Sent: Sunday, May 04, 2003 8:07 AM
>To: Shahram Davari; Sasha Vainshtein
>Cc: [email-masked]; Ron Cohen; Tim Frost (E-mail); Andrew G. Malis;
>[email-masked]; 'Yaakov Stein'

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 5 May 2003 18:21:58 +0300

> LSP-PING, etc. (not ATM, TDM, FR, ...).

We might also want to multiplex "sub-modes" on a single PW,
e.g. changing from AAL1 to AAL2 submodes of TDM for congestion mitigation,
or changing to single ATM VCC cell mode for ATM OAM cells.

This is what I suggested in section 5 of
http://www.ietf.org/internet-drafts/draft-stein-pwe3-controlword-00.txt

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 5 May 2003 19:59:12 +0200

Shahram,
Can you please explain what would be the expecting result of sending ICMP
echo/echo reply on a PW?

With best regards,
                                   Sasha Vainshtein

> Sent: Monday, May 05, 2003 3:55 PM

---

From: Shahram Davari <[email-masked]>
Date: Mon, 5 May 2003 10:18:52 -0700

You can find your answer in these 2 drafts:

 http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-vccv-00.txt
    
draft-allan:
    
    "Originators of ICMP echo request
    messages use the any address in the non-routable 127./8 address
    range as a destination address. Originators of ICMP echo reply
    messages substitute their own PSN loopback address for the 127./8
    when replying."

draft-nadeau:

   " When ICMP packets are used, the source address should be set
   to the source address of the LDP session and the destination
   address to the destination of the LDP session.  The Identifier
   and Sequence Number fields of the ICMP Echo Request / Echo
   Reply messages are used to track what VCs are being tested.
   These fields are only interpreted by the sending PE.  Specific
   use of these fields is an implementation matter."

-Shahram

>From: Sasha Vainshtein [mailto:[email-masked]]
>Sent: Monday, May 05, 2003 1:59 PM
>To: Shahram Davari
>[email-masked]; 'Yaakov Stein'; Akiva Sadovski

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 5 May 2003 20:31:29 +0200

Shahram,
Thank you for a prompt response.
Please see some feedback inline.
In addition: AFAIK, Y.1711 does NOT require any MPLS PID as it uses a
reserved OAM label at the bottom of the stack.
Did I miss something? And why do we need two different methods for
identifying maintenance packets on a PW?

With best regards,
                                   Sasha Vainshtein

> Sent: Monday, May 05, 2003 7:19 PM
> To: Sasha Vainshtein
> G. Malis; [email-masked]; 'Yaakov Stein'; Akiva Sadovski
I seem to remember that this has been strongly objected when the draft was
discussed. 
>    use of these fields is an implementation matter."
AFAIK, draft-nadeau proposes its own method of identifying in-band
Connectivity Verification
messages.

---

From: Shahram Davari <[email-masked]>
Date: Mon, 5 May 2003 11:00:47 -0700

Sasha,

>Did I miss something?

The proposal by David Allan is to amend Y.1711 with an option that
uses MPLS PID.

>And why do we need two different methods for

Because some ICMP implementations may hash the reserved label, and 
therefore cause the OAM packets to take a different path than
user packets.

>Connectivity Verification

Correct, but it only works for some PW types, i.e., those that have a reserved bit
in their CW. For example it can't be used with SONET/SDH PW or even CESoPSN. Also it permits running only a single management protocol over the PW, i.e., either ICMP or LSP-ping, or ...

-Shahram

---

From: [email-masked]
Date: Tue, 6 May 2003 09:22:33 +0100

Hi Akiva....Effectively yes, but to be absolutely clear what my point is:

-	in a client/server relationship between 2 layer network technologies
X/Y, X and Y should be functionally independent, and the mapping of the
client into the server payload should be simple adaptation, ie do not create
(what are starting to look like) 'in-between' layer networks by defining
functions which are part of the adaptation;

-	if the client is consistent over the life of the server trail than I
agree with you there is no need for a server layer PID.......note carefully
the words *server layer PID*, because that is where this function should
reside (if it exists) and *not* in some 'in-between' layer.  So a PW PID is
a 'bad thing' per se IMO.

-	functions are starting to appear in the adaptation and creating an
'in-between' PW layer as a consequence of (i) not recognising/accepting that
X/IP and X/MPLS are not the same architecturally, and (ii) trying to
compensate for deficiencies in either the client or server layer functional
specification.

-	The PID has emerged IMO to fix an MPLS problem (LDP and
ECMP).....not an IP problem.  Right answer is to fix the MPLS layer and not
bodge the adaptation.

-	a related concern is that someone may use the PID to identify 'PW
OAM'.....I have seen proposals for this.  This reinforces my point about
creating an in-between layer with unnecessary functional
components.......and this is why I responded to you the way I did in the
mail below.

Hopefully you can piece all these observations together and understand why I
have some serious architectural concerns about where all this stuff is
heading.

regards, Neil

> Sent: 05 May 2003 15:28
> To: Harrison,N,Neil,IKL2 R; [email-masked]; Sasha
> Vainshtein
> [email-masked];
> [email-masked]; [email-masked]; [email-masked]

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 6 May 2003 12:45:53 +0300

Neil, 

> client into the server payload should be simple adaptation, 
> ie do not create (what are starting to look like) 'in-between' layer networks 
> by defining functions which are part of the adaptation;

While I agree in principle, sometimes such functions are absolutely required,
as for example, if the server is missing a facility that the client requires.
Taking the TDM over MPLS case (and I am aware that you do not like such mode conversions),
MPLS does not have timing transport capabilities, and so these must be added,
just as ATM AAL1 adaptation was augmented by such mechanisms
(and RTP was added to UDP/IP for that matter).

> -	if the client is consistent over the life of the server trail

That is precisely the IF. 
For various reasons the client may desire or be forced
to change its protocol mid-stream. 
Tear-down and new set-up procedures tend to be expensive,
the addition of a PW PID control mechanism saves that overhead,
without mangling the architecture to badly.

Such mechanisms are very useful and becoming more prevalent.
For example, the new (AMR) speech compression
for GSM/3GPP cellular networks supports 8 bit rates,
from 4.75 Kbps to 12.2 Kbps.
The bit rate can be changed (e.g. when needed because of congestion)
on a packet-by-packet basis because of a three-bit "coder PID". 

Would you advocate tearing down the users call,
or blocking his service for the time needed to signal the change?
I doubt it.

> functions are starting to appear in the adaptation and creating an
> X/IP and X/MPLS are not the same architecturally,

It is not a matter of not recognizing the differences between
connectionless IP and connection-oriented MPLS.
It is a matter of designing a layer that is functionally
independent of the layer beneath it.
That is NOT what PWE has BECOME,
it was part of its charter from the beginning
Quote :
  Tunnels for PWE3 encapsulations will use IP (both versions), L2TP,
  or MPLS.  PWE3 will coordinate closely with the L2TP WG and its
  technologies.  .  PWE3 pseudo wires will have the same specification
  for all underlying PSNs (i.e. there will not be specific adaptation
  of a pseudo wire technology for MPLS that is distinct from what is
  used for IP and L2TP, or differences will be the minimum necessary
  and will be called out clearly).       

We all acknowledge that IP and MPLS are different,
and that MPLS is the better medium for most of our work
(note how much of PWE work has focused on MPLS,
and how little on IP).

However, there is a lot of IP out there, and a lot of people
who want these mechanisms to work over vanilla IP.

Will it work as well ?  Frankly no.
Obviously we can't give the QoS that we need,
however, it is a matter of paying for QoS.

Those who are willing to pay will get the SLA,
those who aren't will have to put up with best-effort.

> ECMP).....not an IP problem.  Right answer is to fix the MPLS 
> layer and not bodge the adaptation.

I agree that the ideal answer would be to fix the MPLS
(I would settle for MPLS promising not to mis-order packets ...)
However, I doubt we can accomplish this.

So the old adage about engineering being accomplishing
what we need to accomplish with the tools at our disposal
comes into play again.

Y(J)S

---

From: [email-masked]
Date: Tue, 6 May 2003 20:19:01 +0100

Hi Yaakov.....please see below.  regards, Neil
> as for example, if the server is missing a facility that the 
NH=> I think to be strictly accurate (in what follows) its the application's
adaptation to the *immediately adjacent* layer network that requires the
functionality (and not the server per se)....which is why one adapts a CBR
application to an ATM layer network via AAL1.  Hope you see the subtle point
I am making here.  So the adaptation: application=>AAL1=>MPLS would do the
job fine.

> like such mode conversions),
NH=> Not strictly true for case given.  The co cct-sw mode over a co pkt-sw
mode is possible (eg ATM)....its the transport over a cnls mode that is the
cause for concern.  And which is why I say X/MPLS is not the same as
X/IP.....I don't really understand why people are so afraid to acknowledge
this.

> (and RTP was added to UDP/IP for that matter).
NH=> Exactly my point above.  So let's use AAL1 over any co pkt-sw
mode....makes lots of sense to me.....even stops having to have gateways at
the *application* interfacing level.
<snipped>

> those who aren't will have to put up with best-effort.
NH=> I think you answered your own observation as to why a consistent
'in-between' layer cannot do what it is alledged to do.....so OK, it looks
like it does as a sop (we are in the IETF right, so it must have a solution
in IP too else its not palatable.....though no such qualms when dealing with
a co cct-sw mode such as SDH in GMPLS is there?).  My interpretation of this
is: 'let's agree to delude ourselves in the case of MPLS'.
> (I would settle for MPLS promising not to mis-order packets ...)
NH=> That would be a very good start....but, if this Seq No stuff lives-on,
then we can't really leave the defect behaviour 'open-ended' as I have
explained in previous mails.....at some stage consequent actions are
required, so entry and exit criteria ought to be (consistently) specified.

> However, I doubt we can accomplish this.
NH=> It's not that hard.....its not really a question of 'adding' stuff, but
taking stuff 'away' IMO.  The only hard bit is letting the bad stuff go I
guess.
> what we need to accomplish with the tools at our disposal
NH=> I know....sigh.....but one would think we really ought to learn as we
go along.  

regards, Neil