Re: [mpls] Poll for Adoption draft-andersson-mpls-moving-iana-registries-00

[Loa Andersson <[e-mail]>]

Carlos,

go to http://www.iana.org/protocols

look for:

Multiprotocol Label Switching Architecture (MPLS)

you the "heading" it has no link attach to it,

Under that you find something like 16 name spaces each with one or more
registries.

/Loa

On 2013-08-15 14:07, Carlos Pignataro (cpignata) wrote:
> Loa,
>
> Thanks for the response -- please see inline.
>
> On Aug 15, 2013, at 7:33 AM, Loa Andersson <[e-mail]>
>   wrote:
>
>> Carlos,
>>
>> I'm not against the idea of moving all mpls-gach allocation registry.
>>
>> Since you ask where the GACh registries in the LSP Ping name space goes,
>> the draft says:
>>
>>    These registries are now moved into a new name space under the
>>    "Multiprotocol Label Switching Architecture" (MPLS) heading called
>>    "MPLS Generic Associated Channel Parameters".
>>
>
> Thanks. I read that but it was not clear to me if you meant a new group of registries in a new location -- since you are not really requesting the creation of a "new namespace".
>
> I do not believe there is a "Multiprotocol Label Switching Architecture" heading.

There is https://www.iana.org/assignments/mpls-label-values and

  https://www.iana.org/assignments/mpls-id-type, the first with one 
registry, the second with two.
>
> In summary, if you are suggesting the creation of, say https://www.iana.org/assignments/mpls-gac-parameters/ with a heading of "Multiprotocol Label Switching Architecture (MPLS) Generic Associated Channel Parameters" to include all the GACh registries, then I think it makes more sense to do it all at once.
>
>> I wonder if we can agree on this strategy
>>
>> - go ahead with the current draft as it is, it simplicity makes if easy
>>   to move through wgls and iesg to create the new registry and move the
>>   existing GACh registries there.
>> - as soon as we have that registry (or whenever the current draft is
>>   sufficiently well advanced) we start up a new draft proposing what you
>>   say below.
>
> This would still leave out the GACh registries from https://www.iana.org/assignments/mpls-oam-parameters/. Is that a 3rd RFC in this strategy? Or leave these fragmented?
>
>>   One reason that I want this two step strategy is that there is much
>>   more of pwe3 registries (yes I know that registries are common) and
>>   that there are several RFCs that needs to be updated in the second
>>   step. That second draft should possibly also be a pwe3 wg document,
>>   so we should work with someone from the pwe3 wg.
>>
>
> To me, like I said, the appropriate strategy is to do all of this at once (or not bother). Most definitely PWE3 needs to be on the critical path, but my take is that these are MPLS registries as a superset (now) of PWE3, with MPLS WG docs (co-called on PWE3). Frankly, the top-level anchor point for all these registrations is the "Pseudowire Associated Channel Types" (that maybe RFC 5586 should have moved) -- why not start there?
>
>> Is this a way forward?
>>
>
> It would be useful to see what others think -- to me this is not the most efficient and effective way forward, just as one opinion.
>
> Thanks,
>
> -- Carlos.
>
>> /Loa
>>
>> On 2013-08-14 18:59, Carlos Pignataro (cpignata) wrote:
>>> Loa,
>>>
>>> Yes, what I already suggested: get all the mpls-gach allocations
>>> together in a new registry (from
>>> mpls-lsp-ping-parameters, pwe3-parameters, and mpls-oam-parameters, into
>>> a new one).
>>>
>>> Basically you have hierarchical allocations, that should be together:
>>> there are registries created for many individual values of G-ACH Type
>>> ("Pseudowire Associated Channel Type"). They should follow.
>>>
>>> If you are moving 4 registries from mpls-lsp-ping-parameters, where do
>>> you propose they'd end up?
>>>
>>> BTW: These are the full G-ACH numbers for GACH:
>>>
>>>   * Pseudowire Associated Channel Types
>>>   * Associated Channel Header TLV Registry // empty to be removed
>>>       o MPLS Fault OAM Message Type Registry
>>>       o MPLS Fault OAM Flag Registry
>>>       o MPLS Fault OAM TLV Registry
>>>       o MPLS PSC Request Registry
>>>       o MPLS PSC TLV Registry
>>>       o G-ACh Advertisement Protocol Application Registry
>>>       o G-ACh Advertisement Protocol TLV Registry
>>>       o G-ACh Advertisement Protocol: Ethernet Interface Parameters
>>>       o CC/CV MEP-ID TLV Registry
>>>       o Measurement Timestamp Type
>>>       o Loss/Delay Measurement Control Code: Query Codes
>>>       o Loss/Delay Measurement Control Code: Response Codes
>>>       o MPLS Loss/Delay Measurement TLV Object
>>>
>>> Thanks,
>>>
>>> -- Carlos.
>>>
>>> On Aug 14, 2013, at 12:37 PM, Loa Andersson <[e-mail] <mailto:[e-mail]>>
>>>   wrote:
>>>
>>>> Carlos,
>>>>
>>>> as long as we move them out of the LSP Ping registry and we can find a
>>>> place where we have consensus that we should move them, I fine with
>>>> that.
>>>>
>>>> Any suggestions?
>>>>
>>>> /Loa
>>>>
>>>> On 2013-08-14 18:25, Carlos Pignataro (cpignata) wrote:
>>>>> Hi, Loa,
>>>>>
>>>>> Please see inline.
>>>>>
>>>>> On Aug 14, 2013, at 2:25 AM, Loa Andersson <[e-mail]
>>>>> <mailto:[e-mail]>> wrote:
>>>>>
>>>>>> Carlos,
>>>>>>
>>>>>> While I tend to agree that someone (hint) should write-up a document
>>>>>> fixing the G-ACh registries, that is not the purpose of the current
>>>>>> documents. It is looking to clean up the LSP Ping registries.
>>>>>>
>>>>>
>>>>> The title of the current document is "Moving Generic Associated
>>>>> Channel registries to a new name space".
>>>>>
>>>>> This in itself sets up a broader goal than tossing namespaces outside
>>>>> LSP Ping registry over the wall.
>>>>>
>>>>>> We have tried the approach "fixing everything" and failed to get our
>>>>>> heads around it, decided to take a stepwise approach. If we now stumble
>>>>>> on the first step (or rather second, since cleaning up the LSP registy
>>>>>> structure was the first) I'm afraid that nothing will be done.
>>>>>>
>>>>>
>>>>> I wouldn't say "fix everything", but I would say "fix consistently"
>>>>> or "fix atomically". I do understand now that your goal is to clean
>>>>> up the LSP Ping registry. However, since you are "Moving Generic
>>>>> Associated Channel registries to a new name space", "fix modularly"
>>>>> can mean coalesce all the GACH registries, from LSP Ping as well as
>>>>> from the other 2-3 registries. In other words, fix two (LSP Ping and
>>>>> GACH) with potentially very small additional incremental effort.
>>>>>
>>>>>> Since you say (below) "solves a small part" I hope we can do this and
>>>>>> go ahead and do the rest as soon as we have the cycles.
>>>>>>
>>>>>
>>>>> My humble view is that just moving these four falls short of
>>>>> meaningful change.
>>>>>
>>>>> This is just a datapoint, my opinion, and I was too optimistic with
>>>>> "solves a small part".
>>>>>
>>>>> I tried to present a proposal along with my comments that, to me, has
>>>>> more return on cycles: coalesce the G-ACH registries, currently in
>>>>> LSP Ping, PWE3, and MPLS OAM. Since you gave me a "hint" above, I'd
>>>>> be happy to help out with this if the WG consensus is that the work
>>>>> makes sense.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -- Carlos.
>>>>>
>>>>>
>>>>>> /Loa
>>>>>>
>>>>>> On 2013-08-14 04:53, Carlos Pignataro (cpignata) wrote:
>>>>>>> I believe that fixing and organizing misplaced number registrations is
>>>>>>> useful and worthwhile as it prevents future confusion, and typically
>>>>>>> welcome clean-ups.
>>>>>>>
>>>>>>> However, I do not support adoption
>>>>>>> of draft-andersson-mpls-moving-iana-registries-00 in its current form.
>>>>>>>
>>>>>>> The document solves a small part of the potential source of confusion,
>>>>>>> and, to me, it should fix all potential inconsistencies or leave things
>>>>>>> as-is.
>>>>>>>
>>>>>>> Specifically:
>>>>>>>
>>>>>>> * draft-andersson-mpls-moving-iana-registries proposes only to move
>>>>>>>    four namespaces currently in [1] from [RFC6374] into a new heading
>>>>>>>    (registry).
>>>>>>>
>>>>>>>
>>>>>>> However, there's still the following potential inconsistencies,
>>>>>>> with all
>>>>>>> these protocol elements from the G-ACH in different places:
>>>>>>>
>>>>>>> * The G-ACH Channel Types namespace, although now it's a superset of
>>>>>>>    the original PW-ACH, is still titled "Pseudowire Associated Channel
>>>>>>>    Types" and is hosted in the pwe3-parameters registry. [2]
>>>>>>> * Other G-ACH namespaces and assignments from [RFC6427]
>>>>>>>    and [RFC6378] reside in their own mpls-oam-parameters page [3]
>>>>>>> * G-ACh Advertisement Protocol namespaces are in the pwe3-parameters
>>>>>>>    registry [4] [5] [6], although these are not PWE3.
>>>>>>> * CC/CV MEP-ID TLV namespace with pwe3-parameters [7]
>>>>>>>
>>>>>>>
>>>>>>> I would suggest that either things are left as they are, or all these
>>>>>>> G-ACH/PW-ACH namespaces are moved under a main "Generic Associated
>>>>>>> Channel (G-ACH)" registry *if* there's consensus for the clean-up.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -- Carlos.
>>>>>>>
>>>>>>> [1]
>>>>>>> http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml#measurement-timestamp
>>>>>>> [2]
>>>>>>> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#pwe3-parameters-11
>>>>>>> [3]
>>>>>>> https://www.iana.org/assignments/mpls-oam-parameters/mpls-oam-parameters.xhtml
>>>>>>> [4]
>>>>>>> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gach-application
>>>>>>> [5]
>>>>>>> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gach-tlv
>>>>>>> [6]
>>>>>>> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gach-ethernet
>>>>>>> [7]
>>>>>>> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#cc-cv-mep-id
>>>>>>>
>>>>>>>
>>>>>>> On Aug 13, 2013, at 2:23 PM, Ross Callon <[e-mail]
>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>
>>>>>>>> This is to start a "two week" poll on adopting
>>>>>>>> draft-andersson-mpls-moving-iana-registries-00
>>>>>>>> as an MPLS working group document.
>>>>>>>> Please send your comments (support/not support) to the mpls working
>>>>>>>> group mailing list ([e-mail] <mailto:[e-mail]>).
>>>>>>>> This poll will end August 28, 2013.
>>>>>>>> Thanks, Ross
>>>>>>>> _______________________________________________
>>>>>>>> mpls mailing list
>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> mpls mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>> Loa Andersson                        email: [e-mail]
>>>>>> <mailto:[e-mail]>
>>>>>> Senior MPLS Expert [e-mail] <mailto:[e-mail]>
>>>>>> Huawei Technologies (consultant)     phone: [phone]
>>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Loa Andersson                        email: [e-mail]
>>>> <mailto:[e-mail]>
>>>> Senior MPLS Expert [e-mail] <mailto:[e-mail]>
>>>> Huawei Technologies (consultant)     phone: [phone]
>>>
>>
>> --
>>
>>
>> Loa Andersson                        email: [e-mail]
>> Senior MPLS Expert                          [e-mail]
>> Huawei Technologies (consultant)     phone: [phone]
>

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]