Subject: [mpls] LSP Ping DS Flags and Multipath Info Types

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 15 Nov 2013 00:06:28 +0000

Hi Kireeti, George, Nitin,

I'm reaching out to authors of RFC4379/RFC6424 as part of follow up to comments received for LSP ping for entropy label draft.

http://tools.ietf.org/html/draft-akiya-mpls-entropy-lsp-ping-00

Authors would like to extend DS Flags (add 2 flags) and extend Multipath Information Type (add 1 new type).

However, IANA does not maintain DS Flags nor Multipath Information Type, and wanted to check on background/thoughts with original authors of the LSP ping mechanism.

Should DS Flags and Multipath Information Types be maintained by IANA?

Thank you.

-Nobo

---

From: Loa Andersson <[email-masked]>
Date: Tue, 19 Nov 2013 14:54:27 -0500

Nobo,

My take on this is that when we now see that the authors of new drafts
will want to allocate code point from "name spaces" that are not
maintained by IANA.

When this is the case we need to move the earlier allocated code points
under IANA control.

There are two ways of doing this

- we can include the "old" allocations in the IANA section
   draft-akiya-mpls-entropy-lsp-ping;
   You will have create the "new/old" registries populated with the
   code points of both the new draft and what is in the old RFC.

- or we can write a new I-D that need be published as an RFC before
   draft-akiya-mpls-entropy-lsp-ping; the IANA section of this draft
   should only include the "old" allocations.
   An implication of choosing this alternative is that the IANA section
   of draft-akiya-mpls-entropy-lsp-ping will need to request code point
   allocation in the format "TBA1, TBA2, ..."

/Loa

On 2013-11-14 19:06, Nobo Akiya (nobo) wrote:
> I’m reaching out to authors of RFC4379/RFC6424 as part of follow up to
> comments received for LSP ping for entropy label draft.
>
> However, IANA does not maintain DS Flags nor Multipath Information Type,
> and wanted to check on background/thoughts with original authors of the
> LSP ping mechanism.
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 20 Nov 2013 14:31:59 +0000

Hi Loa,

I appreciate your guidance on this. I prefer the first approach suggested, and will plan to go with it unless I hear opposing comments.

-Nobo

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: Tuesday, November 19, 2013 2:54 PM
> To: Nobo Akiya (nobo); [email-masked]; George Swallow (swallow);
> Nitin Bahadur
> Cc: [email-masked]
> Subject: Re: [mpls] LSP Ping DS Flags and Multipath Info Types
> 
> Nobo,
> 
> My take on this is that when we now see that the authors of new drafts will
> want to allocate code point from "name spaces" that are not maintained by
> IANA.
> 
> > I'm reaching out to authors of RFC4379/RFC6424 as part of follow up to
> > Authors would like to extend DS Flags (add 2 flags) and extend
> > Multipath Information Type (add 1 new type).
> >
> > However, IANA does not maintain DS Flags nor Multipath Information
> > Type, and wanted to check on background/thoughts with original authors
> > of the LSP ping mechanism.
> >

---

From: Loa Andersson <[email-masked]>
Date: Wed, 20 Nov 2013 09:56:09 -0500

Nobo,

that works for me.

/Loa

--