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

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

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? 

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

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

> > 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:'

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

Hope that helps,

Mark

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