Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt

From: [email-masked]
Date: Sun, 11 Jan 2015 16:18:22 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

        Title           : Configuration of Pro-Active Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using LSP Ping
        Authors         : Elisa Bellagamba
                          Gregory Mirsky
                          Loa Andersson
                          Pontus Skoldstrom
                          Dave Ward
                          John Drake
	Filename        : draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt
	Pages           : 25
	Date            : 2015-01-11

Abstract:
   This specification describes the configuration of pro-active MPLS-TP
   Operations, Administration, and Maintenance (OAM) Functions for a
   given LSP using a set of TLVs that are carried by the LSP-Ping
   protocol.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 12 Jan 2015 00:24:42 +0000

Dear All,
this update addresses comments we received from Nobo.  Also it reflects work authors done with  sister document draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext addressing AD and GEN-Art review comments.

Your comments, questions and suggestions always welcome and greatly appreciated.

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Sunday, January 11, 2015 4:18 PM
To: [email-masked]
Cc: [email-masked]
Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

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

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 13 Jan 2015 22:06:49 +0000

Hello Greg,

Thanks for incorporating my comments, and I've verified that all my comments are addressed in the updated document.

I did come across one more thing that's worth being raised.

In Section 2.2.4:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    BFD Auth. sub-type (103)   |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Auth Type   |  Auth Key ID  |         Reserved (0s)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Yes it's true that RFC5880 defined all the "Auth Key ID" to be 8 bits. Newer BFD authentication documents, like draft-ietf-bfd-generic-crypto-auth (expired), attempted to increase the "Auth Key ID" field to be 16 bits. I am no security expert, but I would guess someone out there thought 255 keys isn't sufficient.

One approach is to say that current definition is ok since it covers RFC5880. Another approach is to add a text stating that the length of the Auth Key ID field depends on the value of the Auth Type field ... or something equivalent to be forward compatible.

Now, I do realize the above comment is also applicable to the companion document draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext. And you already had to jump through hoops to apply some changes to that recently. If the door is already closed (or too much hassle to get things in the door), then perhaps moving forward as is the path that makes most sense.

My primary intent is to raise this so that folks are aware when somebody defines BFD authentication key ID field > 8 bits :)

Thanks!

-Nobo

> From: mpls [mailto:[email-masked]] On Behalf Of Gregory Mirsky
> Sent: Sunday, January 11, 2015 7:25 PM
> To: [email-masked]
> Subject: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-
> 08.txt
> 
> Dear All,
> this update addresses comments we received from Nobo.  Also it reflects
> work authors done with  sister document draft-ietf-ccamp-rsvp-te-mpls-tp-
> oam-ext addressing AD and GEN-Art review comments.
> 
>         Title           : Configuration of Pro-Active Operations, Administration, and
> Maintenance (OAM) Functions for MPLS-based Transport Networks using
> LSP Ping
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.ietf.org.
>

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 13 Jan 2015 22:33:32 +0000

Hi Nobo,
many thanks for your always thoughtful comments.
There will be new updates to RSVP-TE document and if we, as community, decide that the particular aspect must be update, we'll take care of that in both documents.
As for the case of Authentication sub-TLV, we may just need to hint that Reserved field MAY be of variable length, not just 16 bits long. Thus, new Auth Type would have to define its sub-TLV format.

	Regards,
		Greg

-----Original Message-----
From: Nobo Akiya (nobo) [mailto:[email-masked]] 
Sent: Tuesday, January 13, 2015 2:07 PM
To: Gregory Mirsky; [email-masked]
Subject: RE: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt

Hello Greg,

In Section 2.2.4:

    0                   1                   2                   3

Thanks!

-Nobo

> Subject: [mpls] FW: I-D Action: 
> draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-
> 08.txt
> 
> Dear All,
> this update addresses comments we received from Nobo.  Also it 
> reflects work authors done with  sister document 
> draft-ietf-ccamp-rsvp-te-mpls-tp- oam-ext addressing AD and GEN-Art review comments.
> 
> Subject: [mpls] I-D Action: 
> draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-08.txt
> 
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 13 Jan 2015 22:45:46 +0000

Hello Greg,

Thanks for very quick reply!

Please see in-line.

> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: Tuesday, January 13, 2015 5:34 PM
> To: Nobo Akiya (nobo); [email-masked]
> There will be new updates to RSVP-TE document and if we, as community,
> decide that the particular aspect must be update, we'll take care of that in
> both documents.

Sounds good.

> As for the case of Authentication sub-TLV, we may just need to hint that
> Reserved field MAY be of variable length, not just 16 bits long. Thus, new
> Auth Type would have to define its sub-TLV format.

Or add Auth Key ID Length field and let Auth Ken ID field size be variable?

Thanks!

-Nobo

> Thanks for incorporating my comments, and I've verified that all my
> comments are addressed in the updated document.
> 
> Yes it's true that RFC5880 defined all the "Auth Key ID" to be 8 bits. Newer
> BFD authentication documents, like draft-ietf-bfd-generic-crypto-auth
> (expired), attempted to increase the "Auth Key ID" field to be 16 bits. I am
> no security expert, but I would guess someone out there thought 255 keys
> isn't sufficient.
> 
> One approach is to say that current definition is ok since it covers RFC5880.
> Another approach is to add a text stating that the length of the Auth Key ID
> field depends on the value of the Auth Type field ... or something
> equivalent to be forward compatible.
> 
> Now, I do realize the above comment is also applicable to the companion
> document draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext. And you already had
> to jump through hoops to apply some changes to that recently. If the door is
> already closed (or too much hassle to get things in the door), then perhaps
> moving forward as is the path that makes most sense.
> 
> My primary intent is to raise this so that folks are aware when somebody
> defines BFD authentication key ID field > 8 bits :)
> 
> Thanks!
> 
> -Nobo
>