Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf

From: Ross Callon <[email-masked]>
Date: Mon, 6 Apr 2015 00:10:29 +0000

This working group last call has now ended.

There was one public response (to the MPLS working group) in support. I also got private responses of support from two of the authors. Otherwise there were no responses (neither in favor nor opposed). This is not sufficient to constitute "rough consensus". As such the working group last call has failed.

My inclination is to wait for the July IETF (in Prague), and give the authors an opportunity to present and solicit additional support. Depending upon the response there, we may then repeat the WGLC.

Thanks, Ross
(as WG co-chair)

From: mpls [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Tuesday, March 10, 2015 4:46 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf

Working Group,

This is to initiate a working group last call on draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-09.
Because this WGLC will span the IETF in Dallas, it will be extended to just over three weeks.

Please send your comments to the mpls wg mailing list ([email-masked]<mailto:[email-masked]>).

There are no IPR disclosures against this document. All the authors have stated that they
are not aware of any IPR that relates to this draft (two of the responses were private to
the WG chairs).

This working group last call ends Thursday  April 2, 2015.

Ross
for the MPLS WG chairs

---

From: "Nobo Akiya" <[email-masked]>
Date: Sun, 5 Apr 2015 18:10:26 -0700

Hi Ross,

My apologies for being late.

I skipped over all the PM details, but read rest of the document. This
document defines an important functionality for TP OAM, and I do support its
progress.

I did spot few things which should be addressed in the document (especially
#1 and #4).

1. Section 2.2

      - BFD Configuration sub-TLV, which MUST be included if either the
      CC, the CV or both OAM Function flags being set in the OAM
      Function Flags Sub-TLV [RFC7260].

I'm guessing that above is a copy & paste error/leftover. MPLS OAM Function
TLV is defined in the section 2.2 of the
draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf document, and the TLV has MPLS OAM
TLV Flags defined. We would want to refer to the MPLS OAM TLV Flags in the
MPLS OAM Function TLV instead of OAM Function flags in the OAM Function
Flags Sub-TLV defined in RFC7260.

And if above is true (and the text is corrected), then the reference to
RFC7260 can also be removed (as it is not mentioned anywhere else in this
document).

2. Section 2.2

      This sub-TLV MUST carry a "BFD
      Local Discriminator sub-TLV" and a "Timer Negotiation Parameters
      sub-TLV" if the N flag is cleared.  The "Source MEP-ID sub-TLV"
      MUST also be included.  If the I flag is set, the "BFD
      Authentication sub-TLV" MAY be included.

I think above should be removed, as it is a subset (and a bit confusion
subset) of what is better described at the end of Section 2.2.1 anyways.

3. Section 2.2.1

         In this case an updated
         Negotiation Timer Parameters sub-TLV, containing values
         supported by the egress node, is returned to the ingress.

Above is probably a good place to reference RFC7419 to prevent problematic
interop of multiple devices.

4. Section 2.2.4

There needs to be some synchronicity between AuthType/AuthKeyID to specified
in "this" MPLS echo request message and AuthType/AuthKeyID being used by BFD
control packets. For example:

- If BFD control packets using "new" auth is received by the egress LSR
before MPLS echo request with new "auth" is received, all BFD control
packets using "new" auth will be dropped.
- To take that a step further, if BFD control packets using "new" auth is
received by the egress LSR before "this" MPLS echo request is received by
the egress LSR and corresponding BFD session is updated to point to the
"new" auth , all BFD control packets using "new" auth will be dropped.
- If BFD control packets using "new" auth is only sent X time after sending
the MPLS echo request with new "auth", then it is not guaranteed that the
egress LSR will still be accepting BFD control packets with "old" auth for X
amount of time.
- And of course there's the error case of the egress LSR not being able to
support the specified the "new" auth specified in received MPLS echo
request, but the ingress LSR starts using the "new" auth before it receives
back NOSUP from the egress LSR via MPLS echo reply.

I suspect if sufficient details are not defined, we would likely run into
some inter-op issues with this aspect.

Thanks!

-Nobo

> -----Original Message-----
> Sent: April-05-15 5:10 PM
> To: [email-masked]
> Cc: Ross Callon; [email-masked];
draft-ietf-mpls-lsp-ping-mpls-tp-
> [email-masked]
> Subject: Re: [mpls] working group last call for
draft-ietf-mpls-lsp-ping-mpls-tp-
> oam-conf
> There was one public response (to the MPLS working group) in support. I
also
> got private responses of support from two of the authors. Otherwise there
were
> no responses (neither in favor nor opposed). This is not sufficient to
constitute
> “rough consensus”. As such the working group last call has failed.
> 
> My inclination is to wait for the July IETF (in Prague), and give the
authors an
> opportunity to present and solicit additional support. Depending upon the
> response there, we may then repeat the WGLC.
> 
> Thanks, Ross
> (as WG co-chair)
> 
> Subject: [mpls] working group last call for
draft-ietf-mpls-lsp-ping-mpls-tp-oam-
> conf
> 
> Working Group,
> 
> This is to initiate a working group last call on
draft-ietf-mpls-lsp-ping-mpls-tp-
> oam-conf-09.
> Because this WGLC will span the IETF in Dallas, it will be extended to
just over
> three weeks.
> 
> Please send your comments to the mpls wg mailing list ([email-masked]).
> 
> There are no IPR disclosures against this document. All the authors have
stated
> that they
> are not aware of any IPR that relates to this draft (two of the responses
were
> private to

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 7 Apr 2015 21:57:34 +0100

Hi Ross,
 
Apologies for a late review from me, as well (my excuses is that as AD
I didn't participate in WG last calls, and since Dallas I've been sick).
 
I have no objection to this document and it addresses a specific
requirement to provide a mechanism to enable MPLS OAM features that is
independent from the control plane, but that nevertheless does not
require the MCN either.
 
I wonder whether the various bit flag arrays (such as Figure 1/Table 1,
Figure 2, Figure 7) should be managed by IANA? In any case, it would be
helpful to use some more consistent language to say that unassigned bits
MUST be transmitted as zero and ignored on receipt - currently this is
deduced from the figures through a variety of language.
 
My final thought is to ask why this document doesn't share data 
structures with draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext. Of course, it
doesn't need to, but it is probably turning on and off exactly the same
OAM function, so it might save some text to use the same structures.
 
Cheers,
Adrian
 
From: mpls [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: 06 April 2015 01:10
To: [email-masked]
Cc: Ross Callon; [email-masked];
[email-masked]
Subject: Re: [mpls] working group last call for
draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf

There was one public response (to the MPLS working group) in support. I also got
private responses of support from two of the authors. Otherwise there were no
responses (neither in favor nor opposed). This is not sufficient to constitute
"rough consensus". As such the working group last call has failed.
 
My inclination is to wait for the July IETF (in Prague), and give the authors an
opportunity to present and solicit additional support. Depending upon the
response there, we may then repeat the WGLC. 
 
Thanks, Ross
(as WG co-chair)
 
From: mpls [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Tuesday, March 10, 2015 4:46 PM
To: [email-masked]
Cc: [email-masked];
[email-masked]
Subject: [mpls] working group last call for
draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf
 
Working Group,
 
This is to initiate a working group last call on
draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-09. 
Because this WGLC will span the IETF in Dallas, it will be extended to just over
three weeks. 

There are no IPR disclosures against this document. All the authors have stated
that they 
are not aware of any IPR that relates to this draft (two of the responses were
private to 
the WG chairs).

Ross
for the MPLS WG chairs

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 8 Apr 2015 16:00:45 +0000

Hi Nobo,
greatly appreciate your review and thoughtful comments. I'll send another note to propose resolutions by next week (digging out of two-weeks of e-mail).

	Kind regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Nobo Akiya
Sent: Sunday, April 05, 2015 6:10 PM
To: 'Ross Callon'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf

Hi Ross,

I skipped over all the PM details, but read rest of the document. This document defines an important functionality for TP OAM, and I do support its progress.

1. Section 2.2

I'm guessing that above is a copy & paste error/leftover. MPLS OAM Function TLV is defined in the section 2.2 of the draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf document, and the TLV has MPLS OAM TLV Flags defined. We would want to refer to the MPLS OAM TLV Flags in the MPLS OAM Function TLV instead of OAM Function flags in the OAM Function Flags Sub-TLV defined in RFC7260.

And if above is true (and the text is corrected), then the reference to
RFC7260 can also be removed (as it is not mentioned anywhere else in this document).

2. Section 2.2

3. Section 2.2.1

         In this case an updated

Above is probably a good place to reference RFC7419 to prevent problematic interop of multiple devices.

4. Section 2.2.4

There needs to be some synchronicity between AuthType/AuthKeyID to specified in "this" MPLS echo request message and AuthType/AuthKeyID being used by BFD control packets. For example:

- If BFD control packets using "new" auth is received by the egress LSR before MPLS echo request with new "auth" is received, all BFD control packets using "new" auth will be dropped.
- To take that a step further, if BFD control packets using "new" auth is received by the egress LSR before "this" MPLS echo request is received by the egress LSR and corresponding BFD session is updated to point to the "new" auth , all BFD control packets using "new" auth will be dropped.
- If BFD control packets using "new" auth is only sent X time after sending the MPLS echo request with new "auth", then it is not guaranteed that the egress LSR will still be accepting BFD control packets with "old" auth for X amount of time.
- And of course there's the error case of the egress LSR not being able to support the specified the "new" auth specified in received MPLS echo request, but the ingress LSR starts using the "new" auth before it receives back NOSUP from the egress LSR via MPLS echo reply.

I suspect if sufficient details are not defined, we would likely run into some inter-op issues with this aspect.

Thanks!

-Nobo

also
were
constitute
authors an
> opportunity to present and solicit additional support. Depending upon 
> the response there, we may then repeat the WGLC.
> 
> Thanks, Ross
> (as WG co-chair)
> 
just over
stated
were
> This working group last call ends Thursday  April 2, 2015.

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

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 8 Apr 2015 16:09:02 +0000

Hi Adrian,
hope everything is well and getting better.
Many thanks for taking time to review this document and share your comments. I'll need more time to think how to address them and will send another mail perhaps in a week. In the meantime, I've a question. You've suggested:
"... unassigned bits MUST be transmitted as zero and ignored on receipt ..."
in another discussion, it was pointed to me that "transmitted as zero and ignored on receipt" for reserved fields or bits/flags is falling out of favor as accepted form of expression. Would appreciate suggestions on how to improve it.

                Regards,
                                Greg

From: mpls [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Tuesday, April 07, 2015 1:58 PM
To: 'Ross Callon'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf

Hi Ross,

Cheers,
Adrian

From: mpls [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Ross Callon
Sent: 06 April 2015 01:10
To: [email-masked]<mailto:[email-masked]>
Cc: Ross Callon; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf

Thanks, Ross
(as WG co-chair)

From: mpls [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Ross Callon
Sent: Tuesday, March 10, 2015 4:46 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf

Working Group,

Ross
for the MPLS WG chairs

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 8 Apr 2015 19:56:50 +0100

Hi Greg,

[snip]

> You've suggested:
>       ". unassigned bits MUST be transmitted as zero and ignored on receipt ."
> in another discussion, it was pointed to me that "transmitted as zero and 
> ignored on receipt" for reserved fields or bits/flags is falling out of favor
as
> accepted form of expression. Would appreciate suggestions on how to
> improve it.

I guess I'm old so stuff I like falls out of favor all the time, but it doesn't
change my opinion :-)

Firstly, there is a difference between truly reserved fields, and fields that
are currently unassigned but which you expect to possibly assign one day.

In the former case, no-one really cares how the fields are set and, of course
(?) no-one will look at such fields.

In the latter case you need to be forward compatible. 
That means that an implementation that can process some new meaning of the
previously unused field must receive a value form a legacy implementation that
it will not misinterpret. The easiest way to handle this is to require legacy
implementations to transmit zero - then the new meaning of the field can include
"zero means not supported".
Similarly, a legacy implementation that receives a non-setting (from a new
implementation) needs to not barf. The easiest way is to simply ignore the
fields that are believed to be unused.

None of this means that a legacy implementation should police the setting of
zero in an unused field it received. Indeed, although it could police the
sender's adherence to "MUST be zero" is should not do so because it is not
supposed to look at the field at all.

Maybe you need to be asking the person who suggested that the concept is falling
out of favor. They might have a suggestion.

A

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 17 Apr 2015 01:38:02 +0000

Hi Nobo,
finally got to address your comments (greatly appreciate your help).
Please find in-line and tagged GIM>>.

	Kind regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Nobo Akiya
Sent: Sunday, April 05, 2015 6:10 PM
To: 'Ross Callon'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf

Hi Ross,

1. Section 2.2

GIM>> Indeed, cut-paste. New text will be:
      - BFD Configuration sub-TLV, which MUST be included if either the
      CC, the CV or both MPLS OAM Function flags being set in the MPLS
      OAM Functions TLV .
And the Table 1 caption will be not to MPLS OAM TLV Flags but to  MPLS OAM Functions Flags.

2. Section 2.2

GIM>> Agree to remove.

3. Section 2.2.1

         In this case an updated

GIM>> Agreed. Updated with the reference:
         - the N flag is cleared and the S flag is set, and the
         Negotiation Timer Parameters sub-TLV received by the egress
         contains unsupported values.  In this case an updated
         Negotiation Timer Parameters sub-TLV, containing values
         supported by the egress node [RFC7419], is returned to the
         ingress.

4. Section 2.2.4

GIM>> I agree, more details should be provided. How about a new paragraph added to the section:
   If BFD Authentication sub-TLV used for a BFD session in Up state then
   the Sender of the MPLS LSP Echo Request SHOULD ensure that old and
   new modes of authentication, i.e. combination of Auth.Type and Auth.
   Key ID, used to send and receive BFD control packets until the
   Sender can confirm that its peer had switched to the new
   authentication.

Thanks!

-Nobo

also
were
constitute
authors an
just over
stated
were

---

From: Nobo Akiya <[email-masked]>
Date: Sat, 18 Apr 2015 10:45:58 -0700

Hi Greg,

Snipping out ones concluded (thanks for addressing them!).

> 4. Section 2.2.4
>
> There needs to be some synchronicity between AuthType/AuthKeyID to
> specified in "this" MPLS echo request message and AuthType/AuthKeyID being
> used by BFD control packets. For example:
>
> - If BFD control packets using "new" auth is only sent X time after
> sending the MPLS echo request with new "auth", then it is not guaranteed
> that the egress LSR will still be accepting BFD control packets with "old"
> auth for X amount of time.
IMO, I think there are couple of critical aspects which have to be
described.

1. Sender:
  a. Sender of BFD authentication change via MPLS echo request must not
start using the new authentication type/key until it receives back the
acknowledgement via MPLS echo reply.
  b. BFD authentication must change to the new authentication type/key
within a reasonable time after receiving back acknowledgement via MPLS echo
reply.

2. Receiver:
  a. Receiver of BFD authentication change in MPLS echo request must setup
the BFD receive path to accept both old & new authentication type/key for
the session before sending back the acknowledgement via MPLS echo reply.
  b. Old authentication type/key can get unassociated from the session once
the BFD session starts receiving the new authentication type/key.

Still there is one gotcha, which is that MPLS echo reply is unreliable
(i.e., typically an IP routed UDP packet). So there is a chance that MPLS
echo reply can get lost in transit. In addition, we need the receiver to
setup the SW/HW path (in step 2a above). That means the receiver may not be
able to send MPLS echo reply immediate (i.e., ping times out). To protect
from these, we probably want the sender to resent the BFD authentication
change in MPLS echo request if corresponding MPLS echo reply is not
received back.

Note, don't take above texts as is ... sort of wrote this email in a hurry.

Thanks!

-Nobo