Subject: Re: PW Frame-relay encapsulation...

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 22 Sep 2004 17:42:43 -0400

Luca,

As a FR encaps co-author, I heartily agree that this is necessary.

A bit of background for relative newcomers to the WG - this change was made 
when we made the FR encapsulation draft a WG draft, and was discussed at 
length on the WG exploder.  The purpose for the change was to align the 
order of the bits in the control word with the bits in the FR 
header.  However, almost all existing implementations (and all of those 
that have been demonstrated to interoperate) still use the original 
draft-martini encapsulation.  Thus a mechanism is needed to allow an 
orderly transition to the PWE3 encapsulation on operational networks.

I personally also favor option B.

Thanks,
Andy

----------

At 9/22/2004 02:37 PM -0600, Luca Martini wrote:
>WG,
>
>It has been brought to my attention that we have a problem with the 
>Frame-relay PW. The encapsulation of the frame-relay FECN/BECN bit into 
>the control word is reversed in the latest PWE3 draft, with respect to the 
>original draft-martini design.
>The draft-martini bit ordering has been implemented, and deployed, using 
>exactly the same PW type and FEC as the latest PWE3 frame-relay/control 
>protocol draft.
>
>To ensure backward compatibility we have to somehow ensure that we flag 
>the difference using the control, and maintenance protocol ( LDP )
>
>I have 2 possible solutions in mind:
>
>a) create an interface parameter flag , that would be set in the PWE3 
>implementations to flag that encapsulation MUST be as follows:
>
>  0                   1                   2                   3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|  Res  |F|B|D|C|I|L|  Length   | Sequence Number               |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>b) Change the PW type for the PWE3 encap type to a new number ( currently 
>0x0001 )
>    Next available is 0x0019
>
>
>For reference the deployed implementations use :
>  0                   1                   2                   3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Rsvd  |B|F|D|C|    Length     |        Sequence Number        |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>( the Length field is not an issue , as it will always have the 2 MSB as 0 )
>
>
>Opinions ?
>
>( I tend to favor b )
>
>Luca
_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 23 Sep 2004 04:40:34 -0400

Yes, given where we are now this is a very practical thing to do.

b) sounds like the cleaner way to do it in the protocol. The only negative 
side-effect I could envision for this vs. the flag method is that an 
implementation that uses the PW Type as part of its provisioning/management 
model might not allow a box that can do only one type of encap (be it "martini" 
only now or "pwe3 only" some time in the future) to interoperate seamlessly with 
a box that supports both encap types without making a special case for the two 
FR PW Types at the provisioning/management level.

- Mark

Luca Martini wrote:

> the control word is reversed in the latest PWE3 draft, with respect to 
> the original draft-martini design.
> b) Change the PW type for the PWE3 encap type to a new number ( 
> currently 0x0001 )
>    Next available is 0x0019
> 
>

---

From: Luca Martini <[email-masked]>
Date: Thu, 23 Sep 2004 09:43:26 -0600

Yes, , but a new implementation can automatically adapt to an old one , 
by using the new Pw type as the default , but watching for the old pw 
type advertisement ..... and negotiating.

One open question is the ITU definition, I believe that it used 0x0001 
with the new frame-relay implementation.
Can somebody verify this ?

Thanks.
Luca

W. Mark Townsley wrote:

> b) sounds like the cleaner way to do it in the protocol. The only 
> negative side-effect I could envision for this vs. the flag method is 
> that an implementation that uses the PW Type as part of its 
> provisioning/management model might not allow a box that can do only 
> one type of encap (be it "martini" only now or "pwe3 only" some time 
> in the future) to interoperate seamlessly with a box that supports 
> both encap types without making a special case for the two FR PW Types 
> at the provisioning/management level.
>
> - Mark
>
> Luca Martini wrote:
>
>> WG,
>>
>> Frame-relay PW. The encapsulation of the frame-relay FECN/BECN bit 
>> into the control word is reversed in the latest PWE3 draft, with 
>> respect to the original draft-martini design.
>> The draft-martini bit ordering has been implemented, and deployed, 
>> using exactly the same PW type and FEC as the latest PWE3 
>> frame-relay/control protocol draft.
>>
>> To ensure backward compatibility we have to somehow ensure that we 
>> flag the difference using the control, and maintenance protocol ( LDP )
>>