Re: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv

[Eric Gray <[e-mail]>]

Rolf,

	Now that you point this out, the way that we specify
the TLV length is inconsistent with the way that RFC 4379
specifies length in other TLVs.

	This was not previously obvious, since all previously
defined DSMAP/DDMAP TLVs naturally align on 32-bit word 
boundaries.  Also, there are no similar examples in the
DDMAP draft (draft-ietf-mpls-lsp-ping-enhanced-dsmap - which
deprecates the DSMAP TLV in favor of a detailed-DSMAP TLV).
DDMAP TLVs contain sub-TLVs and there is no explicit mention
of alignment with word boundaries in that draft (in fact, a
search for "align" does not find any match, and "word" only 
matches references to RFC 2119).

	Note that I say "inconsistent", not "incorrect."

	In our draft, the "Must be Zero" field is not called
"padding" explicitly.  We specify the contents of the TLV,
and hence we could (as RFC 4379 appears to do) include just
the meaningful value fields in the length, or we could use
the correct length.

	I maintain that the use of length in RFC 4379 is not
correct.  In fact, it probably causes some implementation
issues, since - as TLV length is specified in RFC 4379 - it
is necessary for an implementer to "correct" the length of
these TLVs by adding the length of the PAD, in order to be
able to find the start of the next TLV.

	I suspect that doing this for each such TLV may be 
more complex than dealing with TLVs that are not aligned.

	Or, it could be simple enough if the implementation
assumes that all TLVs (for RFC 4379 TLVs at least) are word
aligned.

	I also note that one cannot assume at this time that
TLVs always will be word aligned in the general case.  The 
requirement for word alignment of field contents went out 
the window, with the inception of 64 bit processors (since 
nobody has AFAIK ever intended to do 64-bit double word 
alignment).

	At that time, many folks then participating in IETF
activities pointed out that 32-bit boundaries are not all
that convenient for hardware processing (particualrly for
hardware processing the information in serial bit-stream
format).

	Word alignment of TLVs, in particular, is problematic
as that means there may be wasted space in every TLV in a
message - adding greatly to message sizes.

	Padding in the case of TLVs that contain sub-TLVs can
be worse in several ways.

	But - even if we insist on word alignment - the TLV
length should include the required pad bits so that it is
easier to go from TLV to TLV.

	Finally, you should consider that in general, some
TLVs do not need to be understood (meaning I may not need
to recognize the type) for some applications.  That is 
clearly not the case in RFC 4379, but - for robustness -
it should always be the case that I can directly find all
TLVs and then parse them for type information, etc.  If
you have first to correct the TLV length based on the TLV
type, then this doesn't work.

	In any case, I just talked to one of the WG chairs.
The draft has been re-posted, and will be forwarded to the
IESG for publication.  We can re-visit this in IETF last
call, or the issue can be resolved either way in IESG
review.

--
Eric

-----Original Message-----
From: Rolf Winter [mailto:[e-mail]] 
Sent: Monday, June 27, 2011 7:04 AM
To: Eric Gray; [e-mail]; [e-mail]
Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv
Importance: High

I think that's OK, since the value is not beyond but within the TLV. Taken from 4379:

Types are defined below; Length is the length of the Value field in
octets.  The Value field depends on the Type; it is zero padded to
align to a 4-octet boundary.

That means the length is the length of the actual value (excluding the padding). So the beginning of the next TLV is determined by the length plus a value that makes it align on a 4-octet boundary (which of course can be 0). I cannot follow your argument why this is not correct. I am sure I am missing something trivial, so sorry for spamming the list. But all information is encoded in the packet (plus the simple rule quoted above). Otherwise, a node needs to understand the internal structure of each TLV to extract the value instead of applying the simple rule above. 


Best,

Rolf


NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 


> -----Original Message-----
> From: Eric Gray [mailto:[e-mail]]
> Sent: Montag, 27. Juni 2011 12:42
> To: Rolf Winter; [e-mail]; draft-ietf-mpls-tp-on-demand-
> [e-mail]
> Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-
> cv
> 
> IMO, that would be a problem with RFC 4379.  Perhaps there is
> an errata?
> 
> TLVs are meant to follow each other, where the beginning of the
> next TLV is determined by the length of the current TLV - hence
> it is not correct to specify any content as having any value at
> all if it is beyond the end of the TLV.
> 
> -----Original Message-----
> From: Rolf Winter [mailto:[e-mail]]
> Sent: Monday, June 27, 2011 5:06 AM
> To: Eric Gray; [e-mail]; draft-ietf-mpls-tp-on-demand-
> [e-mail]
> Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-
> cv
> Importance: High
> 
> Hi Eric,
> 
> just one more to follow up. You say:
> 
> > EG > 24 is correct for the Static LSP Sub-TLV (it is 6 words long,
> > EG > even if the last two octets "Must be Zero").  The length of
> > EG > the Static Pseudowire Sub-TLV - on the other hand - was made
> > EG > longer by the addition of the 2-word AGI.  Nice catch!
> 
> In RFC 4379, section 3.2, the MUST be Zero parts don't seem to be
> included in the length of the sub-TLVs. Why are they included here?
> 
> Best,
> 
> Rolf
> 
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> London W3 6BL | Registered in England 2832014
> 
> 
> >
> > EG > Apparently.
> >
> > Which return code to send when identifiers are wrong (Malformed echo
> > request received?) or drop the packet.
> >
> > EG > Drop the packet, probably log the error, possibly run off
> > EG > screaming into the night.  What does one do when one gets
> > EG > something either not recognizably intended for one, or not
> > EG > from a source that one recognizes?  From a security point
> > EG > of view, we cannot require an implementation to reply to
> > EG > the requester in this case (this is an attack vector for
> > EG > all kinds of hate and discontent).  Nor can we forbid it.
> >
> > Using the per-interface model and say the DSMAP TLV did not match the
> > ingress IF identifier, then should this request frame be dropped?
> > Should we reply to the requestor? Can this way two answers be
> > generated?
> >
> > Nit (section 2.1): s/mpls/MPLS/
> >
> > EG > Thanks.
> >
> >
> > Best,
> >
> >
> >
> > Rolf
> >
> >
> >
> >
> >
> >
> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> > London W3 6BL | Registered in England 2832014
> >
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On
> Behalf
> > Of
> > > Loa Andersson
> > > Sent: Donnerstag, 16. Juni 2011 22:01
> > > To: [e-mail]; [e-mail];
> > Ross
> > > Callon; George Swallow; MPLS-TP ad hoc team
> > > Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-
> cv
> > >
> > > Working Group.
> > >
> > > the authors of draft-ietf-mpls-tp-on-demand-cv have updated the ID
> > > after wg last call and published version -04 of the document.
> > >
> > > A document detailing how the comments have been addressed will be
> > > found at:
> > > http://www.pi.nu/~loa/comments-on-03.xls
> > >
> > > This is to start a working group call to verify that all comments
> > > been adequately addressed. Please send your comments to the
> > > mpls working group mailing list before June 24th.
> > >
> > > Loa
> > > on behalf of the MPLS wg co-chairs
> > >
> > > --
> > >
> > >
> > > Loa Andersson                         email:
> > [e-mail]
> > > Sr Strategy and Standards Manager            [e-mail]
> > > Ericsson Inc                          phone: [phone]
> > >                                               [phone]
> > > _______________________________________________
> > > mpls mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/mpls
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls