The MPLS WG Archive

[George Swallow <swallow@cisco.com>]

> 1) Clarification of Mandatory vs. Optional TLVs
> 
> The draft is unclear about which TLVs are mandatory
> and which are optional.  It is also unclear about
> the format of the TLV "type" field.
> 
> On one hand, the draft suggests that each TLV has
> a type (i.e. Target FEC TLV is type 1) which determines
> whether or not that TLV is optional or mandatory.
> This determination is based on whether the TLV
> type is above or below 32768.
> On the other hand, for example, the draft suggests that the
> Target FEC TLV is mandatory in an echo request and
> optional in an echo response.
> Another example is the Vendor Enterprise TLV.  The
> draft says that to determine if the Vendor Enterprise
> TLV is mandatory/optional, one must look at the
> values in Message Type, Reply Mode, Return Code and
> Return Subcode.

I think a chief problem is that we've used Mandatory/Optional in two
different senses and haven't been clear on which we're talking about.  

The Type code indicates whether the TLV is Mandatory or Optional to
*process*.  That is, if you encounter one of these, then an
implementation much either process it or return an error code saying it
doesn't understand the TLV.

We've been less diligent on saying what TLVs are Mandatory/Optional in
the messages.  We've also spread that text about the draft.  So if
there's a general feeling that this is getting too complicated, I'm
willing to put in some BNR message descriptions a la RSVP.

> It would seem that one can not rely only on the high
> order bit in the TLV type to determine if the TLV is
> mandatory/optional.

Actually, with the above clarification, you can.

> 2) Vendor Enterprise Code TLV
> 
> Section 3.6 of the draft describes the Vendor Enterprise Code TLV.
> However, that section is not totally complete.  There is extra
> information in section 7.1 regarding which fields can contain
> values in the vendor private range.  It would be better to include
> more information in section 3.6 or else reference section 7.1.

I'll add the forward reference.

> 3) Addition of DS Flags in Downstream Mapping TLV
> 
> It seems strange to have a flag inside the Downstream
> Mapping TLV which indicates a request to have an
> Interface and Label TLV included in the echo reply.
> 
> Is there a better way to do this?
> 
> Would it make more sense to use the Global Flags inside the
> fixed fields for this purpose?

We went back and forth on this.  Our conservatism lead us toward not
wasting the global flag space.

> 4) NIL FEC
> 
> Why do we need more than one label in the Nil FEC TLV?
> My understanding is that each FEC stack sub-TLV corresponds
> to one label in the label stack.
> Is this for the case where there are multiple back-to-back
> reserved labels in the label stack?  Is the intent to be
> able to represent those back-to-back labels in one single
> Nil FEC sub-TLV?
> Would it be simpler to just have one label in each Nil FEC
> sub-TLV?  This way, each FEC sub-TLV always corresponds to
> a single label in the label stack.

I support your proposed change.  Other opinions?

> 5) CR-LDP FEC Appendix A.1
> 
> There appears to be a typo here.  The length of the CR-LDP
> FEC should be 8 instead of 6.

I'll fix it if we don't drop it altogether.

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls