Subject: [Pals] Mirja Kühlewind's Discuss on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-08: (with DISCUSS and COMMENT)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Tue, 05 Jul 2016 09:38:46 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-pw-over-bidir-lsp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I think the protocol specification is not complete:

- What happens if none of the two S and C bits are set?

- What happens if more the one sub-TLV is present?

Actually I think that the protocol design is more complicated than needed
and simplifying it would resolve these error cases. But as that's not a
DISCUSS reason, please see more detailed comments below!

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A few questions/comments:

1) The shepherd writeup says: "An IPR discolusure has been filed and the
WG has not remarked on this."
    Does this mean the wg is not aware of it or it is aware and nobody
commented?

2) Acronym: I found a few acronyms that where not spelled out, e.g. FEC
as well as LDP and TE in the abstract. One can argue if that's needed but
usually I think it helps. Further there are quite a few acronyms that are
introduced somewhere and then never used again (e.g. Point-to-Point
(P2P); that makes it actually harder to read, so I would recommend to
remove them.

3) I think I don't understand the following MUST: "PSN Tunnel Binding TLV
is an optional TLV and MUST be carried in the Label Mapping message
[RFC5036] if PW to LSP binding is required." and again later "To perform
PSN binding, the Label Mapping messages MUST carry a PSN Tunnel Binding
TLV". Maybe just remove it?

4) Why is there a "MUST be zero" and a "Reserved" field? Shouldn't this
all just be a large "Reserved" field? And the "Reserve" field is not
discussed.

5) On the T (Tunnel Representation) bit: Why is that an extra bit?
Usually you can simply use the length field here and then either have the
LSP Number fields in the sub-TLV or not.

6) Why are there two bits for C and S if they are mutual exclusive and
one of them has to be set? In this case you should use one bit and say
e.g. 0 means S(trict) and 1 means C(o-routed path). This would also avoid
the error case when both are set! (Otherwise if it should be possible to
not set both flags, this case is not described  in the draft and must be
added.)

7) Sub-TLV: I'm not an LDP expert but I assume having sub-TLV is not a
general concept that is widely used this way but something introduced in
this document. If that's the case, I have a couple of questions/remarks:

   - Given that the PSN Tunnel Binding TLV already has a length field
that includes the sub-TLV, why do you need another length field in the
sub-TLV?
  - Why is there another 'Reserved' field in the sub_TLV (that is also
not discussed)?
  - If you already have different types of sub-TLVs here, why don't you
simply define some with or without the the LSP Number fields instead of
the T bit?
  - And finally do you really need these sub-TLVs  or would a flag be
enough to indicate IPv4 or IPv6 (or again just use the length field to
distinguish)?
 - And this should be normative "Each PSN Tunnel Binding TLV can only
have one such sub-TLV." -> "Each PSN Tunnel Binding TLV MUST have only
one such sub-TLV." and you must specify what happen if more then one is
presented (if you actually want to use sub-TLVs).

8) There are a couple of MUSTs basically twice in the document (once in
section 2 and another time in sections 4 and 5). I would recommend to
avoid these duplications and subsequent redundancy and really state it
only once to avoid any future confusions.

---

From: Mach Chen <[email-masked]>
Date: Wed, 6 Jul 2016 06:12:40 +0000

Hi Mirja,

Thanks for your "DISCUSS and COMMENT"!

Please see some replies inline...

> -----Original Message-----
> From: Mirja Kuehlewind [mailto:[email-masked]]
> Sent: Wednesday, July 06, 2016 12:39 AM
> To: The IESG
> Cc: [email-masked]; Stewart Bryant;
> [email-masked]; [email-masked]; [email-masked]
> Subject: Mirja Kühlewind's Discuss on
> draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-08: (with DISCUSS and COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 

Indeed, this is not explicitly stated in the document. One way is to clarify what happens if none of the two S and C bits are set. Another way is to along your suggestion below. After consideration, I think your suggestion is better and we will accept your suggestion. 

Then now, C bit will be omitted, and only the S bit will be left and it's definition as below:

"S (Strict) bit: This instructs the PEs with respect to the handling of the underlying LSPs. When the S bit set, the remote PE MUST use the tunnel/LSP specified in the PSN Tunnel Sub-TLV as the PSN tunnel on the reverse direction of the PW, or the PW will fail to be established. When the S bit cleared, the remote T-PE/S-PEs SHOULD select co-routed LSP (as the forwarding tunnel) as the reverse PSN tunnel. If there is no such tunnel available, it may trigger the remote T-PE/S-PEs to establish a new LSP."

And correspondingly, the some text in the Operation section will modified accordingly. 

> - What happens if more the one sub-TLV is present?

How about:

OLD:
"Each PSN Tunnel Binding TLV can only have one such sub-TLV."

NEW
"Each PSN Tunnel Binding TLV MUST only have one such sub-TLV. When sending, only one sub-TLV MUST be carried. When received, if there are more than one sub-TLVs carried, only the first sub-TLV MUST be used, the rest sub-TLVs MUST be ignored."

Hope this addresses the DISCUSS.

> 
> Actually I think that the protocol design is more complicated than needed and
> simplifying it would resolve these error cases. But as that's not a DISCUSS
> reason, please see more detailed comments below!
> 
> 
> 1) The shepherd writeup says: "An IPR discolusure has been filed and the WG
> has not remarked on this."

I think it's the latter.

> 2) Acronym: I found a few acronyms that where not spelled out, e.g. FEC as
> well as LDP and TE in the abstract. One can argue if that's needed but usually I
> think it helps. Further there are quite a few acronyms that are introduced
> somewhere and then never used again (e.g. Point-to-Point (P2P); that makes it
> actually harder to read, so I would recommend to remove them.

Sure, will look through the document and expand the acronyms when needed and remove never used acronyms.

> 
> 3) I think I don't understand the following MUST: "PSN Tunnel Binding TLV is an
> optional TLV and MUST be carried in the Label Mapping message [RFC5036] if
> PW to LSP binding is required." and again later "To perform PSN binding, the
> Label Mapping messages MUST carry a PSN Tunnel Binding TLV". Maybe just
> remove it?

The "MUST" applies when "PW to LSP binding is required". Since there are "MUST in the Operation sections, I will remove the one in the TLV definition section. How about:

OLD:
"PSN Tunnel Binding TLV is an optional TLV and MUST be carried in the Label Mapping message [RFC5036] if PW to LSP binding is required."

NEW:
"PSN Tunnel Binding TLV is an optional TLV."

> 
> 4) Why is there a "MUST be zero" and a "Reserved" field? Shouldn't this all just
> be a large "Reserved" field? And the "Reserve" field is not discussed.

The "MUST be zero" and the allocated flags belong to the Flag field. The "Reserved" filed is just as its name, it is reserved for future use. Maybe some text can be added to clarify this. For example : " The Reserved field is 2 octets in length and is left for future use."

> Usually you can simply use the length field here and then either have the LSP
> Number fields in the sub-TLV or not.

Currently, there are two sub-TLVs, one is for IPv4 and the other is for IPv6, if we use the length to imply sub-TLV types, then the sub-TLVs will become four. And we have to guarantee that the four sub-TLVs have their own unique length, otherwise, a receiver cannot parse the packet. In addition, there may be more sub-TLVs introduced in the future, seems it's difficult or impossible to make sure that all sub-TLVs have different length.

> 
> 6) Why are there two bits for C and S if they are mutual exclusive and one of
> them has to be set? In this case you should use one bit and say e.g. 0 means
> S(trict) and 1 means C(o-routed path). This would also avoid the error case
> when both are set! (Otherwise if it should be possible to not set both flags, this
> case is not described  in the draft and must be
> added.)

Will keep the S bit and remove the C bit.

> 
> 7) Sub-TLV: I'm not an LDP expert but I assume having sub-TLV is not a general
> concept that is widely used this way but something introduced in this document.
> If that's the case, I have a couple of questions/remarks:

No, having sub-TLV is general concept for LDP and is widely used.

> 
>    - Given that the PSN Tunnel Binding TLV already has a length field that
> includes the sub-TLV, why do you need another length field in the sub-TLV?

Since a sub-TLV is also a TLV, it has a length field. The length of the sub-TLV seems a bit "redundant" just because the PSN Tunnel Binding TLV can carry only one sub-TLV, otherwise the length is necessary. In addition, a sub-TLV may be reused in another TLV that may carry more than one sub-TLVs. I tend to keep this length.

>   - Why is there another 'Reserved' field in the sub_TLV (that is also not
> discussed)?

This is to make the sub-TLV 4-octet alignment. 

>   - If you already have different types of sub-TLVs here, why don't you simply
> define some with or without the the LSP Number fields instead of the T bit?

This is a design choice, your suggested is an alternative way. 

>   - And finally do you really need these sub-TLVs  or would a flag be enough to
> indicate IPv4 or IPv6 (or again just use the length field to distinguish)?

There may be other ways, but IMHO, as said above, sub-TLV-based mechanism is common for LDP and widely used. 

>  - And this should be normative "Each PSN Tunnel Binding TLV can only have
> one such sub-TLV." -> "Each PSN Tunnel Binding TLV MUST have only one such
> sub-TLV." and you must specify what happen if more then one is presented (if
> you actually want to use sub-TLVs).

OK. 

> 
> 8) There are a couple of MUSTs basically twice in the document (once in section
> 2 and another time in sections 4 and 5). I would recommend to avoid these
> duplications and subsequent redundancy and really state it only once to avoid
> any future confusions.

OK, will go though the document and make the usage consistent. 

Best regards,
Mach

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 6 Jul 2016 09:27:56 +0200

Hi Mach,

thanks! Suggested changes sound good to me. Will wait for the new revision!

One further question on the „MUST be zero“ part: Isn’t this effectively also a „Reserved“ field, in the sense that is could be used in future? „MUST be zero“ sounds like it must be zero for ever and ever (because there is a technical reason to have zeros there); I don’t think that’s the case, right?

Mirja

> Am 06.07.2016 um 08:12 schrieb Mach Chen <[email-masked]>:
> 
> Hi Mirja,
>

---

From: Mach Chen <[email-masked]>
Date: Wed, 6 Jul 2016 07:43:40 +0000

Hi Mirja,

Thanks for your prompt response!

Indeed, the "MUST be zero" part is also a Reserved part, but it is reserved only for Flag usage. 

In section 2.1 there is text (as below) about the Flag field definition:
"The Flag field is 2 octets in length, two flags are defined in this document. The rest unallocated flags MUST be set to zero when sending, and MUST be ignored when received."

Do you think this is enough? Or Maybe I could change the "MUST be zero" to "unallocated flags".

Best regards,
Mach

> From: Mirja Kuehlewind (IETF) [mailto:[email-masked]]
> Sent: Wednesday, July 06, 2016 3:28 PM
> To: Mach Chen
> Cc: The IESG; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Mirja Kühlewind's Discuss on
> One further question on the „MUST be zero“ part: Isn’t this effectively also a
> „Reserved“ field, in the sense that is could be used in future? „MUST be
> zero“ sounds like it must be zero for ever and ever (because there is a technical
> reason to have zeros there); I don’t think that’s the case, right?
> 
> 
> Mirja
> 
> >> Cc: [email-masked]; Stewart
> >> Bryant; [email-masked]; [email-masked]; [email-masked]
> >> email addresses included in the To and CC lines. (Feel free to cut
> >> this introductory paragraph, however.)
> >>
> >>
> >> Please refer to
> >> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > Indeed, this is not explicitly stated in the document. One way is to clarify
> what happens if none of the two S and C bits are set. Another way is to along
> your suggestion below. After consideration, I think your suggestion is better
> and we will accept your suggestion.
> >
> > "S (Strict) bit: This instructs the PEs with respect to the handling of the
> underlying LSPs. When the S bit set, the remote PE MUST use the tunnel/LSP
> specified in the PSN Tunnel Sub-TLV as the PSN tunnel on the reverse direction
> of the PW, or the PW will fail to be established. When the S bit cleared, the
> remote T-PE/S-PEs SHOULD select co-routed LSP (as the forwarding tunnel) as
> the reverse PSN tunnel. If there is no such tunnel available, it may trigger the
> remote T-PE/S-PEs to establish a new LSP."
> >
> > "Each PSN Tunnel Binding TLV MUST only have one such sub-TLV. When
> sending, only one sub-TLV MUST be carried. When received, if there are more
> than one sub-TLVs carried, only the first sub-TLV MUST be used, the rest
> sub-TLVs MUST be ignored."
> >
> >> Actually I think that the protocol design is more complicated than
> >> needed and simplifying it would resolve these error cases. But as
> >> that's not a DISCUSS reason, please see more detailed comments below!
> >>
> >>
> >> 1) The shepherd writeup says: "An IPR discolusure has been filed and
> >> the WG has not remarked on this."
> >> 2) Acronym: I found a few acronyms that where not spelled out, e.g.
> >> FEC as well as LDP and TE in the abstract. One can argue if that's
> >> needed but usually I think it helps. Further there are quite a few
> >> acronyms that are introduced somewhere and then never used again
> >> (e.g. Point-to-Point (P2P); that makes it actually harder to read, so I would
> recommend to remove them.
> >
> >> 3) I think I don't understand the following MUST: "PSN Tunnel Binding
> >> TLV is an optional TLV and MUST be carried in the Label Mapping
> >> message [RFC5036] if PW to LSP binding is required." and again later
> >> "To perform PSN binding, the Label Mapping messages MUST carry a PSN
> >> Tunnel Binding TLV". Maybe just remove it?
> >
> > The "MUST" applies when "PW to LSP binding is required". Since there are
> "MUST in the Operation sections, I will remove the one in the TLV definition
> section. How about:
> >
> > OLD:
> > "PSN Tunnel Binding TLV is an optional TLV and MUST be carried in the Label
> Mapping message [RFC5036] if PW to LSP binding is required."
> >
> > NEW:
> >> 4) Why is there a "MUST be zero" and a "Reserved" field? Shouldn't
> >> this all just be a large "Reserved" field? And the "Reserve" field is not
> discussed.
> >
> > The "MUST be zero" and the allocated flags belong to the Flag field. The
> "Reserved" filed is just as its name, it is reserved for future use. Maybe some
> text can be added to clarify this. For example : " The Reserved field is 2 octets
> in length and is left for future use."
> >
> >>
> >> Usually you can simply use the length field here and then either have
> >> the LSP Number fields in the sub-TLV or not.
> >
> > Currently, there are two sub-TLVs, one is for IPv4 and the other is for IPv6, if
> we use the length to imply sub-TLV types, then the sub-TLVs will become four.
> And we have to guarantee that the four sub-TLVs have their own unique length,
> otherwise, a receiver cannot parse the packet. In addition, there may be more
> sub-TLVs introduced in the future, seems it's difficult or impossible to make
> sure that all sub-TLVs have different length.
> >
> >>
> >> 6) Why are there two bits for C and S if they are mutual exclusive
> >> and one of them has to be set? In this case you should use one bit
> >> and say e.g. 0 means
> >> S(trict) and 1 means C(o-routed path). This would also avoid the
> >> error case when both are set! (Otherwise if it should be possible to
> >> 7) Sub-TLV: I'm not an LDP expert but I assume having sub-TLV is not
> >> a general concept that is widely used this way but something introduced in
> this document.
> > Since a sub-TLV is also a TLV, it has a length field. The length of the sub-TLV
> seems a bit "redundant" just because the PSN Tunnel Binding TLV can carry only
> one sub-TLV, otherwise the length is necessary. In addition, a sub-TLV may be
> reused in another TLV that may carry more than one sub-TLVs. I tend to keep
> this length.
> >
> >>  - If you already have different types of sub-TLVs here, why don't
> >> you simply define some with or without the the LSP Number fields instead of
> the T bit?
> >
> > There may be other ways, but IMHO, as said above, sub-TLV-based
> mechanism is common for LDP and widely used.
> >
> >> have one such sub-TLV." -> "Each PSN Tunnel Binding TLV MUST have
> >> only one such sub-TLV." and you must specify what happen if more then
> >> one is presented (if you actually want to use sub-TLVs).
> >
> > OK.
> >
> >>
> >> 2 and another time in sections 4 and 5). I would recommend to avoid
> >> these duplications and subsequent redundancy and really state it only
> >> once to avoid any future confusions.
> >

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 6 Jul 2016 09:34:50 +0200

Hi again,

one more comment: I’m okay with the use of sub-TLVs if that is common and well-known design pattern that people are used to. However, as you only can have one sub-TLV at a time, please re-consider carefully, as this might add complexity with no gain (and therefore is only a source of potential errors, e.g. if more than one is present).

Mirja

> Am 06.07.2016 um 09:27 schrieb Mirja Kuehlewind (IETF) <[email-masked]>:
> 
> Hi Mach,
>

---

From: Mach Chen <[email-masked]>
Date: Wed, 6 Jul 2016 08:02:37 +0000

Hi Mirja,

Yes, this is a common and well-known design pattern in MPLS related TLV/sub-TLV definition. 

If we do not use sub-TLV pattern, then we need to define multiple top level TLVs. And if we go that way, it will bring fundamental changes to the document. I tend to keep the current design. 

In addition, from the implementation point of view, seems there is not too much difference.

Best regards,
Mach 

> Sent: Wednesday, July 06, 2016 3:35 PM
> To: Mach Chen
> one more comment: I’m okay with the use of sub-TLVs if that is common and
> well-known design pattern that people are used to. However, as you only can
> have one sub-TLV at a time, please re-consider carefully, as this might add
> complexity with no gain (and therefore is only a source of potential errors, e.g.
> if more than one is present).
> 
> Mirja
> 
> 
> > One further question on the „MUST be zero“ part: Isn’t this effectively also
> a „Reserved“ field, in the sense that is could be used in future? „MUST be
> >>> When responding, please keep the subject line intact and reply to
> >>> all email addresses included in the To and CC lines. (Feel free to
> >>> cut this introductory paragraph, however.)
> >>>
> >>>
> >>> Please refer to
> >>> 3) I think I don't understand the following MUST: "PSN Tunnel
> >>> Binding TLV is an optional TLV and MUST be carried in the Label
> >>> Mapping message [RFC5036] if PW to LSP binding is required." and
> >>> again later "To perform PSN binding, the Label Mapping messages MUST
> >>> carry a PSN Tunnel Binding TLV". Maybe just remove it?
> >>
> >>> Usually you can simply use the length field here and then either
> >>> have the LSP Number fields in the sub-TLV or not.
> >>
> >>> you simply define some with or without the the LSP Number fields instead
> of the T bit?
> >>
> >>> only one such sub-TLV." and you must specify what happen if more
> >>> then one is presented (if you actually want to use sub-TLVs).
> >>
> >> OK.
> >>
> >>>
> >>> these duplications and subsequent redundancy and really state it

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 6 Jul 2016 12:50:36 +0100

Mirja,

I would like to pick up a couple of points related to your discuss and 
comments.

> https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-pw-over-bidir-lsp/
Since the text specifically states that they are mutually exclusive, 
that would be
an implementation error. I don't think that it is within the scope of 
this draft to
state what should happen when there is an implementation error.

> - What happens if more the one sub-TLV is present?
As Mach says later in the thread that is an allowable construct. If the TLVs
conflict with each other that is also a protocol implementation error and
out of scope of the document.

> DISCUSS reason, please see more detailed comments below!

The PALS WG was satisfied with the original design, which is perfectly 
viable.

As you say that is not a valid reason to issue a discuss.

Our standard process is to ask the authors (requiring an explicit reply 
from each)
and to ask the WG (with no reply within a certain time an implicit 
negative) if they
need to declare any IPR that has not been already declared. This was 
last done here:

https://www.ietf.org/mail-archive/web/pals/current/msg00621.html

When IPR is disclosed secretariat notify the WG if the draft is a WG draft.

The Chairs do not point out correctly disclosed IPR, we assume that people
will read the list or check the datatracker.

The shepherd's note indicates that as far as I am aware, no one 
expressed any concern
about the IPR disclosure, either on list or to direct to a chair.

Best regards

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 6 Jul 2016 13:58:25 +0100

> state what should happen when there is an implementation error.

Thinking about this some more, we could say:

    Either the C-bit or the S-bit MUST be set.
    the C-bit and S-bit are mutually exclusive from each other, and 
cannot be
    set in the same message.  Otherwise, a Label Release message with
    status code set to "The C-bit and S-bit can not both be set" (TBD5)
    MUST be replied, and the PW will not be established.

We could introduce an additional error message, but it's probably 
adequate to
say:

    Either the C-bit or the S-bit MUST be set.
    The C-bit and S-bit are mutually exclusive from each other, and 
cannot be
    set in the same message.  In the case of either error, a Label 
Release message with
    status code set to "The C-bit and S-bit error" (TBD5)
    MUST be replied, and the PW will not be established.

If parametrised messages are allowed I would say:

"The C-bit and S-bit error [<C-bit>, <S-bit>]"

Since zero or two bits are clearly an implementation error, I am not
convinced that we need to do more than flag it up sufficiently that
the an implementer can figure out what they got wrong.

Stewart

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wed, 6 Jul 2016 15:34:55 +0000

I agree with Stewart - for the two bits to be set would be an implementation error. Not an operational error. The use of the two bits has been stable from the -00 version of the draft. There are always multiple ways to do a protocol design. And various tradeoffs. There are also operational positives for having two bits. Sub-TLVs are very common (PW, MPLS, GMPLS). The extra bit in an optional sub-TLV used when setting up a path is not going to break any bandwidth bank:-)

As Stewart noted on his other email, PALS followed the Routing Area process of asking on IPR at the time of Last Call. We don't require positive confirmation that no one has concerns, only if they have concerns.

Much thanks Mirja for your interest and very comprehensive review - let us know if Stewart's proposal is acceptable to clear your discuss.

Deborah

-----Original Message-----
From: iesg [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Wednesday, July 06, 2016 8:58 AM
To: Mirja Kuehlewind <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-08: (with DISCUSS and COMMENT)

Stewart

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 6 Jul 2016 22:56:34 +0200

Hi Deborah, hi Stewart, hi all,

see below.

> Am 06.07.2016 um 17:34 schrieb BRUNGARD, DEBORAH A <[email-masked]>:
> 

I personally think having these two bits here is really bad protocol design practice (and has no gain but can cause errors) but that’s not what my discuss is on. This design decision is the decision of the wg and I only made a proposal in the comments. However, the document makes unfortunately the impression to me that there was actually not enough wg discussion about this doc and the protocol design itself.

My discuss is on the part that the spec is not fully specified. Having both bits set or not set is not only an implementation error, this can also happen on the path. So how to react to these situations at receiver side should still be specified. Further, the case where both bits are set is specified as an error case while both bits unset is not; that just doesn’t make sense…

These things can be easily fixed (with probably 2 extra sentences) but MUST be fixed before publication.

In case the authors decide to actually change the protocol design (based on my suggestions) as Mach indicated earlier, the chairs and the AD have to decide if this doc has to go back to the wg.

> As Stewart noted on his other email, PALS followed the Routing Area process of asking on IPR at the time of Last Call. We don't require positive confirmation that no one has concerns, only if they…

This was just a clarification question because I’ve read this sentence in the shepherd write-up and it was not fully clear to me what this was supposed to say. Thanks for the clarification! That’s all good.

Mirja

---

From: Gmail <[email-masked]>
Date: Thu, 7 Jul 2016 00:44:12 +0100

Sent from my iPad

> On 6 Jul 2016, at 21:56, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 
> Having both bits set or not set is not only an implementation error, this can also happen on the path.

Mirja,

I assume that you know that LDP is normally carried over TCP?

Stewart

---

From: Mach Chen <[email-masked]>
Date: Fri, 8 Jul 2016 01:43:55 +0000

Hi Deborah, Stewart and Mirja,

After considering and discussing this with the co-authors and some implementers. I realized that change to one bit may not a good idea at this stage, since there may be some implementations out there. Thus, I agree with Stewart and Deborah that we do not need to do a fundamental change to the document given that the current design works fine. And Stewart's new text should cover the corner case.

Best regards,
Mach
> From: BRUNGARD, DEBORAH A [mailto:[email-masked]]
> Sent: Wednesday, July 06, 2016 11:35 PM
> To: Stewart Bryant; Mirja Kuehlewind; The IESG
> Subject: RE: Mirja Kühlewind's Discuss on
> I agree with Stewart - for the two bits to be set would be an implementation
> error. Not an operational error. The use of the two bits has been stable from
> the -00 version of the draft. There are always multiple ways to do a protocol
> design. And various tradeoffs. There are also operational positives for having
> two bits. Sub-TLVs are very common (PW, MPLS, GMPLS). The extra bit in an
> optional sub-TLV used when setting up a path is not going to break any
> bandwidth bank:-)
> 
> As Stewart noted on his other email, PALS followed the Routing Area process of
> asking on IPR at the time of Last Call. We don't require positive confirmation
> that no one has concerns, only if they have concerns.
> 
> Much thanks Mirja for your interest and very comprehensive review - let us
> know if Stewart's proposal is acceptable to clear your discuss.
> 
> Deborah
> 
> > that would be an implementation error. I don't think that it is within
> > the scope of this draft to state what should happen when there is an
> > implementation error.
> 
>     the C-bit and S-bit are mutually exclusive from each other, and cannot be
> We could introduce an additional error message, but it's probably adequate to
> say:
> 
>     The C-bit and S-bit are mutually exclusive from each other, and cannot be
>     set in the same message.  In the case of either error, a Label Release
> message with
> Since zero or two bits are clearly an implementation error, I am not convinced
> that we need to do more than flag it up sufficiently that the an implementer
> can figure out what they got wrong.
> 
> Stewart

---

From: Mach Chen <[email-masked]>
Date: Tue, 12 Jul 2016 07:42:27 +0000

Hi Mirja, all,

Usually unknown or unexpected TLVs are usually simply silently discarded in MPLS. Usually protocols designs we prefer not to be complicated for implementation errors ("too chatty"). As you say, though, we already noted for an error for "C-bit set and S-bit set" so we'll do the same for "C-bit clear and S-bit clear. If "both C-bit and S-bit" are set or "both C-bit and S-bit are clear" are received, we will use the error code "C-bit or S-bit unknown". This error code will also allow future extensions which may use those bits.

So, how about the following modification?

OLD:
" C-bit and S-bit are mutually exclusive from each other, and cannot be set in the same message. Otherwise, a Label Release message with status code set to "The C-bit and S-bit cannot both be set" (TBD5) MUST be replied, and the PW will not be established."

New:
"Either the C-bit or the S-bit MUST be set. The C-bit and S-bit are mutually exclusive from each other, and cannot be set in the same message. If "both C-bit and S-bit are set" or "both C-bit and S-bit are clear" are received, a Label Release message with status code set to "The C-bit or S-bit unknown" (TBD5) MUST be replied, and the PW will not be established."

Hope this addresses your DISCUSS!

Thanks,
Mach

> From: Pals [mailto:[email-masked]] On Behalf Of Mirja Kuehlewind (IETF)
> Sent: Thursday, July 07, 2016 4:57 AM
> To: BRUNGARD, DEBORAH A
> Cc: Stewart Bryant; [email-masked]; The IESG;
> Subject: Re: [Pals] Mirja Kühlewind's Discuss on
> > I agree with Stewart - for the two bits to be set would be an
> > implementation error. Not an operational error. The use of the two
> > bits has been stable from the -00 version of the draft. There are
> > always multiple ways to do a protocol design. And various tradeoffs.
> > There are also operational positives for having two bits. Sub-TLVs are
> > very common (PW, MPLS, GMPLS). The extra bit in an optional sub-TLV
> > used when setting up a path is not going to break any bandwidth
> > bank:-)
> 
> I personally think having these two bits here is really bad protocol design
> practice (and has no gain but can cause errors) but that’s not what my discuss
> is on. This design decision is the decision of the wg and I only made a proposal
> in the comments. However, the document makes unfortunately the impression
> to me that there was actually not enough wg discussion about this doc and the
> protocol design itself.
> 
> My discuss is on the part that the spec is not fully specified. Having both bits
> set or not set is not only an implementation error, this can also happen on the
> path. So how to react to these situations at receiver side should still be
> specified. Further, the case where both bits are set is specified as an error case
> while both bits unset is not; that just doesn’t make sense…
> 
> In case the authors decide to actually change the protocol design (based on my
> suggestions) as Mach indicated earlier, the chairs and the AD have to decide if
> this doc has to go back to the wg.
> 
> >
> > As Stewart noted on his other email, PALS followed the Routing Area process
> of asking on IPR at the time of Last Call. We don't require positive confirmation
> This was just a clarification question because I’ve read this sentence in the
> shepherd write-up and it was not fully clear to me what this was supposed to
> say. Thanks for the clarification! That’s all good.
> 
> Mirja
> 
> 
> 
> >
> > Cc: [email-masked];
> >> that would be an implementation error. I don't think that it is
> >> within the scope of this draft to state what should happen when there
> >> is an implementation error.
> >
> _______________________________________________
> Pals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pals

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 12 Jul 2016 09:45:42 +0200

Thanks, I clear my discuss. Please update the draft and resubmit.

Mirja

> Am 12.07.2016 um 09:42 schrieb Mach Chen <[email-masked]>:
> 
> Hi Mirja, all,
>

---

From: Mach Chen <[email-masked]>
Date: Tue, 12 Jul 2016 08:49:32 +0000

Hi Mirja,

Sure, thanks for your detailed review and valuable comments. Will update the document accordingly.

Best regards,
Mach 

> Sent: Tuesday, July 12, 2016 3:46 PM
> To: Mach Chen
> Cc: BRUNGARD, DEBORAH A; Stewart Bryant; [email-masked]; The IESG;
> > Usually unknown or unexpected TLVs are usually simply silently discarded in
> MPLS. Usually protocols designs we prefer not to be complicated for
> implementation errors ("too chatty"). As you say, though, we already noted for
> an error for "C-bit set and S-bit set" so we'll do the same for "C-bit clear and
> S-bit clear. If "both C-bit and S-bit" are set or "both C-bit and S-bit are clear" are
> received, we will use the error code "C-bit or S-bit unknown". This error code
> will also allow future extensions which may use those bits.
> >
> > " C-bit and S-bit are mutually exclusive from each other, and cannot be set in
> the same message. Otherwise, a Label Release message with status code set
> to "The C-bit and S-bit cannot both be set" (TBD5) MUST be replied, and the PW
> will not be established."
> >
> > New:
> > "Either the C-bit or the S-bit MUST be set. The C-bit and S-bit are mutually
> exclusive from each other, and cannot be set in the same message. If "both
> C-bit and S-bit are set" or "both C-bit and S-bit are clear" are received, a Label
> Release message with status code set to "The C-bit or S-bit unknown" (TBD5)
> MUST be replied, and the PW will not be established."
> >
> >>> There are also operational positives for having two bits. Sub-TLVs
> >>> are very common (PW, MPLS, GMPLS). The extra bit in an optional
> >>> sub-TLV used when setting up a path is not going to break any
> >>> bandwidth
> >>> bank:-)
> >>
> >> I personally think having these two bits here is really bad protocol
> >> design practice (and has no gain but can cause errors) but that’s not
> >> what my discuss is on. This design decision is the decision of the wg
> >> and I only made a proposal in the comments. However, the document
> >> makes unfortunately the impression to me that there was actually not
> >> enough wg discussion about this doc and the protocol design itself.
> >>
> >> My discuss is on the part that the spec is not fully specified.
> >> Having both bits set or not set is not only an implementation error,
> >> this can also happen on the path. So how to react to these situations
> >> at receiver side should still be specified. Further, the case where
> >> both bits are set is specified as an error case while both bits unset
> >> is not; that just doesn’t make sense…
> >>
> >> suggestions) as Mach indicated earlier, the chairs and the AD have to
> >> decide if this doc has to go back to the wg.
> >>
> >>>
> >> of asking on IPR at the time of Last Call. We don't require positive
> >> confirmation that no one has concerns, only if they have concerns.
> >>
> >> This was just a clarification question because I’ve read this
> >> sentence in the shepherd write-up and it was not fully clear to me
> >> what this was supposed to say. Thanks for the clarification! That’s all good.
> >>
> >> Mirja
> >>
> >>
> >>
> >>>
> >>>>> ------------------------------------------------------------------
> >>>>> --
> >>>>> --
> >>>>> DISCUSS:
> >>>>> ------------------------------------------------------------------
> >>>>> --
> >>>>> --
> >>>>>
> >>>> Since the text specifically states that they are mutually
> >>>> exclusive, that would be an implementation error. I don't think
> >>>> that it is within the scope of this draft to state what should
> >>>> happen when there is an implementation error.
> >>>