Subject: Issue #54 - Tom

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 27 Mar 2019 21:28:04 +0000

Hi Tom, for TLVs the following are defined in the current draft (answering the questions you raised).

Q: What happens if a node doesn't understand a TLV type?
A: It is skipped

Q: Can a TLV type appear more than once? Do nodes have to process all TLVs?
A: Yes

Q: Are there any limits to the number of TLVs?
A: Yes, they must not exceed the hdr ext len.

Q: Alignment requirements of TLVs?
A: In a source routing model, the source is always able to engineer the SRH to meet its requirements. This principal also applies to the specific example of TLV alignment.
There are various ways that can be imagined to provide alignment of TLVs.

  *   One way is to always order TLVs to achieve the required alignment.
  *   Another method would be to add intermediate pad tlvs to match the alignment requirements.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 27 Mar 2019 21:40:29 -0000

> A: In a source routing model, the source is always able to engineer the
> SRH to meet its requirements. This principal also applies to the specific
> example of TLV alignment. 
> - One way is to always order TLVs to achieve the required alignment.
> - Another method would be to add intermediate pad tlvs to match the
>  alignment requirements.

Well, currently "no" to the second of these because...

      When present, a single Pad0 or PadN TLV MUST appear as the last
      TLV.  More than one Padding TLV MUST NOT appear in the SRH.  The
      Padding TLVs are used to align the SRH total length on the 8 octet
      boundary.

So, if you want the TLVs in the SRH to be aligned you had better hope that they are specified to be aligned or to allow internal padding to align them.

(Or you can change the SRH spec ;-)

Adrian

---

From: Tom Herbert <[email-masked]>
Date: Wed, 27 Mar 2019 23:23:57 +0100

> example of TLV alignment.
Darren

That contradicts the robustness principle "be conservative in what you
send". It is up to the sender to format packets in a manner that is most
easily consumable by receivers. Maintaining 4 byte alignment of fields is
common in other TLVs and IP protocols-- I don't see why SR would be special
in this regard.

Tom

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 27 Mar 2019 23:32:57 +0000

Tom and Adrian.

Tom, I’m saying that we do align TLVs, however Adrian had a good observation that we needed to include padding when necessary to meet alignment requirements but current text doesn’t permit that.

Let’s resolve that with the following text in section 2.1.1.

<OLD>

Padding TLVs are used to pad the TLVs to a multiple of 8 octets.

boundary.

Padding TLVs are ignored by a node processing the SRH TLV, even if

more than one is present.

Padding TLVs are ignored during ICV calculation.

<NEW>

Padding TLVs are used to pad the SRH to a multiple of 8 octets.

Padding TLVs are used for alignment.

Padding TLVs are ignored by a node processing the SRH TLV.

Padding TLVs are ignored during ICV calculation.

On 2019-03-27, 6:24 PM, "Tom Herbert" <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Mar 27, 2019, 10:28 PM Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tom, for TLVs the following are defined in the current draft (answering the questions you raised).

That contradicts the robustness principle "be conservative in what you send". It is up to the sender to format packets in a manner that is most easily consumable by receivers. Maintaining 4 byte alignment of fields is common in other TLVs and IP protocols-- I don't see why SR would be special in this regard.

Tom

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 27 Mar 2019 23:37:34 -0000

That works, although you should probably explicitly say “Multiple Padding TLVs MAY be used in one SRH.” That makes it a bit clearer what to expect.

I think that we got to the current <=1 situation because we didn’t want two consecutive Pad0 TLVs when we could use one PadN

So you could also have “MUST NOT have two consecutive Padding TLVs.”

A

From: Darren Dukes (ddukes) <[email-masked]> 
Sent: 27 March 2019 23:33
To: Tom Herbert <[email-masked]>; Adrian Farrel <[email-masked]>
Cc: 6MAN <[email-masked]>
Subject: Re: Issue #54 - Tom

Tom and Adrian.

<OLD>

boundary.

<NEW>

 

On 2019-03-27, 6:24 PM, "Tom Herbert" <[email-masked] <mailto:[email-masked]> > wrote:

On Wed, Mar 27, 2019, 10:28 PM Darren Dukes (ddukes) <[email-masked] <mailto:[email-masked]> > wrote:

A: It is skipped

A: Yes

Darren

Tom

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 27 Mar 2019 23:51:33 +0000

Adrian...

<OLD>

boundary.

<NEW>

Multiple Padding TLVs MAY be used in one SRH.

MUST NOT have two consecutive padding TLVs.

On 2019-03-27, 7:37 PM, "Adrian Farrel" <[email-masked]<mailto:[email-masked]>> wrote:

A

Tom and Adrian.

<OLD>

boundary.

<NEW>

Tom

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 27 Mar 2019 23:53:24 -0000

Cool

A

From: Darren Dukes (ddukes) <[email-masked]> 
Sent: 27 March 2019 23:52
To: [email-masked]; 'Tom Herbert' <[email-masked]>
Cc: '6MAN' <[email-masked]>
Subject: Re: Issue #54 - Tom

Adrian...

<OLD>

boundary.

<NEW>

 

On 2019-03-27, 7:37 PM, "Adrian Farrel" <[email-masked] <mailto:[email-masked]> > wrote:

A

From: Darren Dukes (ddukes) <[email-masked] <mailto:[email-masked]> > 
Sent: 27 March 2019 23:33
To: Tom Herbert <[email-masked] <mailto:[email-masked]> >; Adrian Farrel <[email-masked] <mailto:[email-masked]> >
Cc: 6MAN <[email-masked] <mailto:[email-masked]> >
Subject: Re: Issue #54 - Tom

Tom and Adrian.

<OLD>

boundary.

<NEW>

 

 

A: It is skipped

A: Yes

Darren

Tom

---

From: Tom Herbert <[email-masked]>
Date: Thu, 28 Mar 2019 08:23:27 +0100

> Padding TLVs are ignored during ICV calculation.
That is inconsistent with HBH and DO options. Also, it's not clear what
ignore means for auth, see RFC8200 description of zeroing fields like data
in mutable TLVs.

> MUST NOT have two consecutive padding TLVs.
This is also inconsistent with RFC8200 Besides that, a MUST to send is
ineffective if the receiver accepts it anyway. A receiver can impose
sensible limits, like won't accept padding that covers more than 7 bytes.

I still don't understand why TLVs SR need to be defined differently than
HBH and DO options. It seems much easier to reuse existing protocol both in
defining the new protocol and implementation.

Tom

>
>
>
> On 2019-03-27, 7:37 PM, "Adrian Farrel" <[email-masked]> wrote:
>
>
>
> That works, although you should probably explicitly say “Multiple Padding
> TLVs MAY be used in one SRH.” That makes it a bit clearer what to expect.
>
>
>
> I think that we got to the current <=1 situation because we didn’t want
> two consecutive Pad0 TLVs when we could use one PadN
>
> *From:* Darren Dukes (ddukes) <[email-masked]>
> *Sent:* 27 March 2019 23:33
> *To:* Tom Herbert <[email-masked]>; Adrian Farrel <
> [email-masked]>
> *Cc:* 6MAN <[email-masked]>
> *Subject:* Re: Issue #54 - Tom
>
>
>
> Tom and Adrian.
>
>
>
> Tom, I’m saying that we do align TLVs, however Adrian had a good
> observation that we needed to include padding when necessary to meet
> alignment requirements but current text doesn’t permit that.
>
>
>
> On 2019-03-27, 6:24 PM, "Tom Herbert" <[email-masked]> wrote:
>
>
>
>
>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 28 Mar 2019 22:38:59 +0000

Tom, I removed the MUST Adrian wanted and you disputed (below)

I also resolve your issue where you wanted limits on number of TLVs an implementation may process.

Also reuse the alignment requirement from RFC8200 (xn+y).  where  pad tlvs have no padding requirement and HMAC has 8n .

<NEW>
An implementation MAY limit the number and/or length of TLVs it processes based on local configuration.

</NEW>

<NEW>
All TLVs specify their alignment requirements using an xn+y format. The xn+y format is defined as per RFC8200. The SR Source nodes use the xn+y alignment requirements of TLVs and padding TLVs when constructing an SRH.
</NEW>

<OLD>

boundary.

 </OLD>

<NEW>

</NEW>

On 2019-03-28, 3:23 AM, "Tom Herbert" <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Mar 28, 2019, 12:51 AM Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>> wrote:

Adrian...

<OLD>

boundary.

<NEW>

Padding TLVs are ignored during ICV calculation.
That is inconsistent with HBH and DO options. Also, it's not clear what ignore means for auth, see RFC8200 description of zeroing fields like data in mutable TLVs.

MUST NOT have two consecutive padding TLVs.
This is also inconsistent with RFC8200 Besides that, a MUST to send is ineffective if the receiver accepts it anyway. A receiver can impose sensible limits, like won't accept padding that covers more than 7 bytes.

I still don't understand why TLVs SR need to be defined differently than HBH and DO options. It seems much easier to reuse existing protocol both in defining the new protocol and implementation.

Tom

A

From: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>
Sent: 27 March 2019 23:33
To: Tom Herbert <[email-masked]<mailto:[email-masked]>>; Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Cc: 6MAN <[email-masked]<mailto:[email-masked]>>
Subject: Re: Issue #54 - Tom

Tom and Adrian.

<OLD>

boundary.

<NEW>

Tom

---

From: Tom Herbert <[email-masked]>
Date: Fri, 29 Mar 2019 10:31:48 +0100

On Thu, Mar 28, 2019, 10:39 PM Darren Dukes (ddukes) <[email-masked]>
wrote:

> Also reuse the alignment requirement from RFC8200 (xn+y).  where  pad tlvs
> have no padding requirement and HMAC has 8n .
>
>
>
> <NEW>
>

Please add a reference to RFC8504 section 5.3.

Thanks,
Tom

>
> <NEW>
>
> All TLVs specify their alignment requirements using an xn+y format. The
> xn+y format is defined as per RFC8200. The SR Source nodes use the xn+y
> alignment requirements of TLVs and padding TLVs when constructing an SRH.
>
> </NEW>
>
>
>
> <OLD>
>
> On 2019-03-28, 3:23 AM, "Tom Herbert" <[email-masked]> wrote:
>
>
>
>
>