The MPLS WG Archive

[Danny McPherson <danny@ambernetworks.com>]

Some comments here, some technical, some not so technical.  
I tried to suppress others that have already been addressed 
on the list, though I'd really like to see responses to 
outstanding issues brought up in Robin's message from 
20 December.

Also, I think considering merging this draft with the 
transport draft would be a good thing, I'm not sure why
they're separate documents.  I could understand this if
each one explained a particular L2 service type.

---------------------------------------
Section 3:

"The next 16 bits are the sequence number that is used to guarantee
ordered packet delivery."

I believe you mean this:

"The next 16 bits are the sequence number that is used to detect
out-of-order packets."

And here:

"PDUs carrying the control word MUST NOT be delivered out of order.   
They may be discarded or reordered."

I think something more along these lines would be clearer:

"If PDUs carrying the control word arrive out-of-order, they MAY
be discarded or reordered, they MUST NOT be delivered."

Section 4:

"If a packet length, once it has been encapsulated on the
ingress LSR, exceeds the LSP MTU, it MUST be dropped."

How is the "LSP MTU" known here?  Presumably, you weren't
referring to the Black LDP MTU draft.

"If an egress LSR receives a packet on a VC LSP with a length, 
once the label stack and sequencing control word have been popped, 
that exceeds the MTU of the destination layer 2 interface it MUST 
be dropped."

Wouldn't something more graceful be of benefit here?  Perhaps 
exchanging the egress interface MTU via LDP?


Section 5.1:

"A Frame Relay PDU is transported in its entirety, including the Frame
Relay header.  The sequencing control word is OPTIONAL."

Presumably, you don't actually intend to carry the FCS as well?

Regarding this:  "The BECN and FECN signals are carried unchanged",
perhaps bits or indicators would be more appropriate than 'signals'?

"The Label Edge Routers", what's a label edge router?  Presumably, 
you mean Edge LSRs?

Here:

"The Label Edge Routers that implement this document MAY, when either 
adding or removing the encapsulation described herein, change a zero 
to a one in either or both of these bits in order to reflect congestion 
in the MPLS network that is known to the LERs."   

There's that LER thing again, though the acronym isn't defined (Anywhere).
Also, I guess disucssion of how an 'LER' knows about "congestion in the 
MPLS network" is beyond the scope of the document?

Regarding this:

"The ingress LSR MAY consider the DE bit of the Frame Relay header
when determining the value to be placed in the EXP fields of the MPLS
label stack. In a similar way, the egress LSR MAY consider the EXP
field of the VC label when queuing the packet for egress."

Shouldn't you say something about "the DE value of the encapsulated FR 
frame MUST be copied to the DE field of the reconstructed packet before
transmission to the CE (for lack of a better term)".  I guess this 
would equally apply yo C/R, EA, FECN/BECN, etc..

Perhaps simply providing some wording regarding how the egress LSR
handles decap, etc.. would be useful?

Also, shouldn't something be said regarding the inability to fully
support Frame Relay EA with this model?

Section 5.2:

Presumably, you're removing the FCS from the CPCS-PDU before 
encapsulation?  

Also, shouldn't you at least mention that you removed the 1 octet
HEC from the ATM cell header before encapsulation?  

"If ATM cells, or a combination of ATM cells and AAL5 CPCS-PDUs, 
are to be transported the sequencing control word is required."

A combination?  

Section 5.2.1:

I think you should probably scope this sentence:  "A router that does 
not support transport of OAM cells MUST discard incoming MPLS frames 
on an ATM VC LSP that contain an ATM cell with the high-order bit of 
the PTI field set to 1."  Perhaps you should use "egress LSR" rather
than "a router"?

Also, how would this work if multiple cells were in the MPLS frame?

Here: "If an F5 end-to-end OAM cell is received from a VC by an LSR 
with a loopback indication value of 1 and the LSR has a label mapping 
for the VC, the LSR must decrement the loopback indication value and 
loop back the cell on the VC. Otherwise the loopback cell must be 
discarded by the LSR." I think you should scope this to "egress LSR",
per simple use of the term 'VC' here soesn't explicitly imply this.
For that matter, defining 'VC' in this context would probably be 
useful as well...

Hrmm, this seems to differ from the model suggested for Frame Relay:
"The egress LSR MAY consider the value of the EXP field of the VC
label when determining the value of the ATM CLP bit."  There you only
talk of "when queuing the packet for egress".  Consistency would be
good here, the correct model is probably obvious.

And again, providing exact label decap/cell reconstructing details
would be of benefit here as well.

Also, why no talk of ATM and FR (I)LMI interaction on the access 
side?

Section 5.3:

"For an ethernet 802.1q VLAN the entire ethernet frame without the
preamble or FCS is transported as a single packet. The sequencing
control word is OPTIONAL. If a packet is received out of sequence it
MUST be dropped."  I think the out of sequence packet should only 
be dropped IF the sequencing control word is used.  You could merge
these sentences and provide a bit of clarity.  Also, you should 
tighten up your use of Ethernet/IEEE 802.3/802.1q wording here.

"The 4 byte VLAN tag is transported as is, and MAY be overwritten by 
the egress LSR." this seems loose.  Handling by the egress LSR
could be tightened up here.

"The ingress LSR MAY consider the user priority field [4] of the VLAN
tag header when determining the value to be placed in the EXP fields
of the MPLS label stack. In a similar way, the egress LSR MAY
consider the EXP field of the VC label when queuing the packet for
egress."  Why just when queuing, not mapping to the 3-bit P field?
This falls into consistency issue as with ATM and FR. 

"Ethernet packets containing hardware level CRC, Framing
errors, or runt packets MUST be discarded on input."  Does
this really belong in this document?

Section 5.4:

5.4. Ethernet

"As in the Ethernet VLAN case, ethernet packets with hardware level 
CRC, framing, and runt packets MUST be discarded on input."  I really
don't believe this belongs here either.

Also, should RFC2469 be mentioned here somewhere?

Finally, perhaps some consideration on Spanning Tree is in 
order here?  Or at least providing similar functionality?