Re: [L2tpext] [Fwd: draft-ietf-l2tpext-pwe3-fr-05.txt]

Mark,

Great. Thanks for the two follow-ups and Thank you again for the reviews
and all comments !!

--Carlos.

Circa 6/3/2005 7:19 AM, Mark Lewis said the following:
> 
> Carlos,
> 
> Please see inline.
> 
> 
> 
>>>
>>It was brought up by George Wilkie that FRF specs only support 2-octet
>>and 4-octet headers, and take the approach of saying "3-octet address
>>format is outside scope". Consequently, an "outside of the scope of this
>>document" was added in reference to 3-octet FR Headers.
>>
>>
> 
> Aaaaaaaahhh. I knew that had to be a good reason that it wasn't added in the first place. I also stand corrected (at least as far as FRF is concerned!).
> 
> 
> 
> 
>>>
>>>
>>>And another thing (!), I notice in section 6.1 that the PW type 
>>
>>is specified as 0x0001. The L2TPv3 number space is separate to 
>>that in draft-ietf-pwe3-iana-allocation-09.txt, but it seems that 
>>L2TP PW types conform to draft-ietf-pwe3-iana-allocation-09.txt 
>>anyway (unless it's an incredible coincidence!). So, wouldn't it 
>>be a good idea to use the PW type 0x0019 as 0x0001 corresponds to 
>>(legacy) martini DLCI mode, doesn't it? Or is there a good reason 
>>to stick with 0x0001??
>>
>>The PW type 0x0019 was added because of the FECN/BECN order reversal in
>>the control word for use over an MPLS PSN, problem that does not exist
>>in L2TPv3 (and cannot exist as the FR header is transported); as such,
>>it seems to me that there is no need to define a new L2TPv3 PW Type and
>>obsolete 0x0001, because there is only one FR DLCI PW Type for L2TPv3:
>>There is no "new" and "legacy" for L2TPv3 FR DLCI PW Type, and like you
>>say it's a separate number space. In addition, 0x0001 has been in the
>>draft for quite some time, and the value of 0x0001 had been requested to
>>IANA for allocation months ago. L2TPv3 FR DLCI PW Type does not need to
>>"match" with 0x0019 because the difference with 0x0001 (applicable only
>>to MPLS PWs) does not exist for L2TPv3 (it is equally similar and
>>different to both), and making such change this late would create more
>>confusion and potential problems.
>>
> 
> 
> Yep, I was aware that the 0x0001/0x0019 difference was just a switch of the F/B bits in the CW. I just thought I'd throw it in for fun :)
> So, you don't think that going through a long-drawn-out process, creating confusion, and potential problems is worthwhile :) Okay, I vote we stick with 0x0001!
> 
> Regards,
> 
> Mark
> 

-- 
--Carlos.
Escalation RTP - cisco Systems

_______________________________________________
L2tpext mailing list
L2tpext@ietf.org
https://www1.ietf.org/mailman/listinfo/l2tpext