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

Mark L.,

Thank you for the follow-up comments. Please see inline.

Circa 6/2/2005 12:26 PM, Mark Lewis said the following:
> Carlos, Mark, all,
> 
> Please see comments inline..
> 
> 
>>>
>>>1.
>>>
>>>Is it worth mentioning in the introduction that, ‘LCCEs
>>>supporting Frame Relay DLCI pseudowires perform Frame Relay
>>>PVC switching and MAY (must?) participate in LMI with
>>>connected CE devices.’
>>
>>Please see my comments to this on item #2.
>>
>>
>>>Also, might it be worth mentioning in the introduction
>>>that, ‘Frame Relay traffic may also be transported between
>>>LCCEs using an HDLC pseudowire [draft-ietf-l2tpext-pwe3-
>>>hdlc]. When Frame Relay traffic is transported over an HDLC
>>>pseudowire, however, LCCEs do not perform Frame Relay PVC
>>>switching, and do not participate in LMI.’ ??
>>
>>I agree, a small sentence in Section 1. referencing a "port mode FR"
>>using HDLC PW would definitely help. I think however that the PVC
>>granularity and LMI considerations of such case should be covered (as
>>you already suggested) in the HDLC draft directly and not in the FR one.
>>
>>
> 
> 
> I agree - how about a sentence in the introduction along the following lines (just a suggestion):
> 
> 'Note that another approach to the transport of Frame Relay traffic over L2TPv3 pseudowires (port mode Frame Relay transport) is described in [draft-ietf-l2tpext-pwe3-hdlc].'

Yes. A similar sentence was added to Section 1. (Introduction).

> 
> Short, succinct, and not too granular?!
> 
> Carlos: by the way, is it worth putting a very brief explicit reference to the term 'port mode Frame Relay transport' in draft-ietf-l2tpext-pwe3-hdlc-05.txt? Possibly just in parenthesis somewhere? 

Agree. Done. A parenthetical reference was added in Section 4.1 of
draft-ietf-l2tpext-pwe3-hdlc.

> 
> 
>>>2.
>>>
>>>In section 3, might it be worth stating that, ‘LCCEs MAY
>>>[must?] participate in FR Local Management Interface [LMI].
>>>An LCCE MAY transmit an SLI message indicating a change in
>>>the status of the local PVC as the result of the reception of
>>>an LMI message. Similarly, an LCCE receiving an SLI
>>>indicating a change in status of a FR PVC (on a remote LCCE)
>>>MAY send a corresponding LMI message to its connected CE
>>>device indicating this status change.’
>>
>>I personally think that the ACTIVE/INACTIVE states and associated PVC
>>transitions cover the more generic case, and should be generally used.
>>However, a small mention reference of FR_LMI <-> FR_PW high level
>>interaction could help; OTOH, trying to add too many details could end
>>up causing more confusing when coupled with DCE/DTE or NNI LMIs. So
>>maybe a single paragraph in Section 3. would work. I also unsure if
>>LCCEs participating in LMI is a MUST or more likely a MAY.
>>
>>
> 
> I definately agree about not being too presciptive with regard to LMI and its interaction with SLI.
> 
> How about something along the following lines:
> 
> 'LCCEs MAY participate in FR Local Management Interface [LMI]. If an LCCE participates in LMI then there MAY be some interaction between LMI and pseudowire status signaling (the transmission and reception of SLI messages).'
> 
> 

A similar generic description was added to Section 3., with some more
details in Section 3.3 (L2TPv3 Session Maintenance). When emulating a FR
service, *if* LMI is used between LCCE and the attached Remote System
(and it MAY be turned off), the LCCE MUST participate in LMI. This is
also inline with Section 6.9 of draft-ietf-pwe3-frame-relay-05.txt as a
reference.

> 
> 
> 
>>>4.
>>>
>>>
>>>In section 4.1 support for 2 and 4 byte FR headers are
>>>discussed. Off the top of my head, isn’t there is also a 3
>>>byte header format(Q.922)? Might it be an idea to state why
>>>the 3 byte header format is not supported (or why it is
>>>irrelevant in this context?).
>>
>>Yes, there is also a 3 byte header format in Q.922. I don't think it's
>>unsupported or irrelevant (perhaps it is uncommon though). But as long
>>as the LCCEs agree on the FR Header length it is fine (2, 3 or 4 bytes),
>>the complete header is transported.
>>I agree including also the 3-octet header format should be a good
>>addition for completeness, it would need to be added at the end of
>>Section 3.5 as well.
>>
>>
> 
> 
> How about something along the following lines (possible additions indicated by asterisks):
> 
> In section 3.5:
> 
>    'The Frame Relay Header Length Type is a 2-octet unsigned integer with
>    the following values defined in this document:
> 
>       2 - Two-octet Frame Relay Header
> ***   3 - Three-octet Frame Relay Header    ***
>       4 - Four-octet Frame Relay Header'
> 
> 
> In section 4.1:
> 
> '
> 
>    The FR header is defined in [Q922], however the notation used differs
>    from that used in IETF specifications. For reference the FR header in
>    IETF notation is:
> 
>     0                   1
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | hi dlci   |C|0|lo dlci|F|B|D|1|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Two-octet FR Header
> 
> ***********
> 
>     0                   1                   2 
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | hi dlci   |C|0| dlci  |F|B|D|0| dlci_lo   |0|1|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Three-octet FR Header
> 
> ***********
> 
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | hi dlci   |C|0| dlci  |F|B|D|0|   dlci      |0| dlci_lo   |0|1|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Four-octet FR  Header
> 
> 

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.

> 
> 
>>>Also, (and I am admittedly being pedantic here!) the
>>>words ‘FR header’ obviously (I think!) refer to the FR
>>>Address field. Would it be a good idea to change ‘FR header’
>>>to ‘FR header (Address Field)’ at least the first time it
>>>appears (again, this may well be too pedantic/utterly
>>>unnecessary!).
>>
>>`FR Header' does refer to the `Q.922 Address field'. This clarification
>>would possibly be helpful in the second paragraph of Section 4.1, where
>>the FR Header is referenced in (as stated) "IETF notation".
>>
> 
> 
> 
> Here's a suggestion for section 4.1:
> 
> 'The FR header is defined in [Q922], however the notation used differs
>    from that used in IETF specifications. ****Note that in [Q922], the FR header is refered to as the Address Field.****
>    For reference the FR header in IETF notation is:'
> 

Done. Thanks.

> 
> 
> 
> 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.

Thanks again !

--Carlos.

> 
> Hope that helps,
> 
> Mark
> 
> 
> 
> 
> 
>  
> 

-- 
--Carlos.
Escalation RTP - cisco Systems

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