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

From: Loa Andersson <[email-masked]>
Date: Thu, 16 Jun 2011 22:00:35 +0200

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: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: binny jeshan <[email-masked]>
Date: Fri, 17 Jun 2011 11:34:28 +0530

Hello,

In this new draft version section 2.3.2., where the AGI field is newly
added, my question is - shouldn't the AGI Type and Length also be included
in the FEC TLV structure?

Also, wouldn't it be clear if the usage of EXP bits in (PHB consideration)
is also explicitly defined somewhere around the responder procedures?

Thanks,
Binny.

On 17 June 2011 01:30, Loa Andersson <[email-masked]> wrote:

> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Rolf Winter <[email-masked]>
Date: Thu, 23 Jun 2011 20:00:44 +0000

Hi,

some comments/questions:

In section 3.3. you say: "The On-demand CV payload MUST directly follow the ACH header (and any ACH TLVs)" but the document does not allow ACH TLVs as per the IANA section.

The static LSP target FEC stack sub-TLVs is 22 not 24 octets long I believe and the PW one 32 (table section 2.3).

Can we live without any ICC-based IDs in the draft to function in all environments?

Which return code to send when identifiers are wrong (Malformed echo request received?) or drop the packet.

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/

Best,

Rolf

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Loa Andersson
> Sent: Donnerstag, 16. Juni 2011 22:01
> To: [email-masked]; [email-masked]; Ross
> Callon; George Swallow; MPLS-TP ad hoc team
> Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv
> 
> Working Group.
>

---

From: Eric Gray <[email-masked]>
Date: Fri, 24 Jun 2011 16:41:14 -0400

Rolf,

	See lines beginning with "EG >" below...

--
Eric 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rolf Winter
Sent: Thursday, June 23, 2011 4:01 PM
To: [email-masked]; [email-masked]
Subject: Re: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv

Hi,

some comments/questions:

EG > WE can remove the parenthetic phrase.  I don't think this
EG > was identified in last call, and this period is not meant
EG > to be an extension of last call.  Strictly speaking this
EG > parenthetical statement is not incorrect (it is, however,
EG > not useful either).

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!

EG > Apparently.

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.

EG > Thanks.

Best,

Rolf

---

From: Loa Andersson <[email-masked]>
Date: Sat, 25 Jun 2011 10:17:49 +0200

Working Group,

this verification call has ended, there has been a few comments, could
the authors please evaluate the comments and take the actions required.

/Loa

--

---

From: Rolf Winter <[email-masked]>
Date: Mon, 27 Jun 2011 09:05:31 +0000

Hi Eric,

> 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

> 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?
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> London W3 6BL | Registered in England 2832014
> 
>

---

From: Eric Gray <[email-masked]>
Date: Mon, 27 Jun 2011 06:41:48 -0400

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:[email-masked]] 
Sent: Monday, June 27, 2011 5:06 AM
To: Eric Gray; [email-masked]; [email-masked]
Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv
Importance: High

Hi Eric,

Best,

Rolf

---

From: Eric Gray <[email-masked]>
Date: Mon, 27 Jun 2011 08:16:29 -0400

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:[email-masked]] 
Sent: Monday, June 27, 2011 7:04 AM
To: Eric Gray; [email-masked]; [email-masked]
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

> From: Eric Gray [mailto:[email-masked]]
> Sent: Montag, 27. Juni 2011 12:42
> To: Rolf Winter; [email-masked]; draft-ietf-mpls-tp-on-demand-
> [email-masked]
> 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
> 
> 
> > > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of
> > > Loa Andersson

---

From: Rolf Winter <[email-masked]>
Date: Mon, 27 Jun 2011 11:04:02 +0000

Best,

Rolf

---

From: Rolf Winter <[email-masked]>
Date: Mon, 27 Jun 2011 11:04:02 +0000

Best,

Rolf