Subject: RE: [PWE3] RE: draft-ietf-pwe3-cesopsn-03.txt and draft-ietf-pwe3 -satop-02.t xt

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 27 Jul 2005 18:37:49 +0300

Skip and all,
Please note that SAToP and CESoPSN do NOT use the L2TPv3-specific
L2-sublayer
when operated over L2TPv3. Instead, they use the same MPLS-compatible
control
word. 

draft-ietf-pwe3-vccv-05 explicit states in Section 7 that:

<quote>
    In order to carry VCCV messages within an L2TPv3 session data 
    packet, the default L2-Specific Sublayer MUST be present. 
<end quote>

On the other hand, it is always possible to use '0001' in the first nibble
of
the CW to distinguish VCCV packets from the SAToP/CESoPSN data packets.

Hence I think that the issue of order between RTP and CW for L2TPv3 is
orthogonal to usage of VCCV with SAToP/CESoPSN.

With best regards,
				Sasha

> -----Original Message-----
> From: Skip Booth [mailto:[email-masked]]
> Sent: Wednesday, July 27, 2005 4:55 PM
> To: Yaakov Stein
> Cc: Sasha Vainshtein; Bill Storer (bstorer); [email-masked]
> Subject: Re: [PWE3] RE: draft-ietf-pwe3-cesopsn-03.txt 
> anddraft-ietf-pwe3-satop-02.t xt
> 
> 
> 
> 
> Yaakov Stein wrote:
> > Sasha and Bill, 
> > 
> > I would like to add another reason for this strange situation. 
> > 
> >>From a layering point of view the PWE CW is the 
> > belongs right after the MPLS label stack,'
> > and under it there can be further service specific
> > headers that modify the PW charactersitics, e.g. RTP.
> > 
> > As Sasha said the CW being immediately after
> > the MPLS stack also has specific consequences,
> > but this is also the correct place for it.
> > 
> > However, for the UDP/IP case,
> > there is a long history of RTP being the way it is
> > and we should not try to change this.
> 
> That's certainly true for the UDP/IP case but not for the 
> L2TPv3 case.  The
> control word should immediately follow the L2TPv3 session 
> ID/cookie header and
> the RTP header should follow the CW.  Note only will this 
> allow for consistent
> PW encapsulation processing for L2TPv3 and MPLS (as well as 
> the actual CEM
> processing), but it will also allow for the use of VCCV over 
> L2TPv3 in CEM
> applications.  We need to ensure that VCCV packets can be 
> demultiplexed from
> data-packets as part of the PW decapsulation processing.  
> Either that or we need
> to define what the RTP header format should look like for 
> VCCV packets which
> AFAIK hasn't been done.
> 
> Cheers,
> -Skip
> 
> > 
> > Y(J)S
> > 
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> 

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

---

From: Skip Booth <[email-masked]>
Date: Wed, 27 Jul 2005 12:37:45 -0400

Sasha, thanks for your response.  See inline...

>     packet, the default L2-Specific Sublayer MUST be present. 

I've spoken with Tom about this and we agree the text needs to be modified.  It
should state something along the following lines:

"In order to carry VCCV messages within an L2TPv3 session data packet, either
the default L2-specific Sublayer must be present *OR* the non-default L2
sublayer MUST define a demultiplexing VCCV bit."

The point is VCCV is a general PWE3 requirement for both MPLS and L2TPv3
pseudowires and should not be precluded by using the non-default L2 sublayer.

> the CW to distinguish VCCV packets from the SAToP/CESoPSN data packets.

Sure - and that's what I would expect to happen here.  L2TPv3 can handle this
just fine.  I'd rather not have to look past the RTP header to glean this though
as that at a minimum could be inefficient and maybe impossible depending on how
the HW is built.

Also, I'm not sure what format the RTP header should look for VCCV packets in
the L2TPv3 mode.  Given that VCCV is locally generated/destined packet, I don't
think they should sequenced/timestamped with the rest of the circuit data.

The other issue here is whether a raw UDP mode needs to support VCCV and if so,
then both L2TPv3 and UDP modes have the same problem.

> orthogonal to usage of VCCV with SAToP/CESoPSN.

Clearly I don't see these as orthogonal issues, but maybe I'm still missing
something ;)

Cheers,
-Skip