RE: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel Type allocationpolicy

["BUSI ITALO" <[e-mail]>]

See my reply to the same question made by Stewart

Italo

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[e-mail]] 
> Sent: Thursday, October 02, 2008 2:13 PM
> To: BUSI ITALO; Vishwas Manral; Shahram Davari
> Cc: [e-mail]; BOCCI Matthew; [e-mail]; 
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel 
> Type allocationpolicy
> 
> 
> 
> 
> On 10/2/08 3:11 AM, "BUSI ITALO" <[e-mail]> wrote:
> 
> > Vishwas,
> > 
> > I think this is a good idea
> > 
> > Both this proposal and option 2 (fist-come-first-served) meet the
> > requirements to make the ACH mechanism extensible.
> 
>     How does the existing mechanism not meet the requirement 
> to make an ACH
> mechanism extensible?
> 
>     --Tom
> 
>  
> > The advantage of this approach is that we do not have to 
> worry about how
> > many codepoints we need to allocate for proprietary 
> extensions: we just
> > need one codepoint.
> > 
> > Italo
> > 
> >> -----Original Message-----
> >> From: [e-mail]
> >> [mailto:[e-mail]] On Behalf Of Vishwas Manral
> >> Sent: Wednesday, October 01, 2008 5:47 PM
> >> To: Shahram Davari
> >> Cc: [e-mail]; BOCCI Matthew; [e-mail];
> >> [e-mail]; [e-mail]; [e-mail]
> >> Subject: Re: [mpls-tp] [PWE3] FW: Changes to PW ACH Channel
> >> Type allocationpolicy
> >> 
> >> Hi Matthew,
> >> 
> >> I would like to propose another option if it is for vendor 
> proprietery
> >> "Channel Type" values in the ACH header. With the number 
> of values of
> >> the channel type being limited and the number of vendors actually a
> >> lot, I would think something in the lines of what the draft below
> >> talks about may make sense:
> >> 
> >> http://tools.ietf.org/draft-ietf-isis-proprietary-tlv-00
> >> 
> >> The idea is give a channel type value, for vendor specific
> >> implemntations and further define the structure of the next header
> >> value for such a "channel type" to actually have a Vendor 
> OUI value.
> >> 
> >> This will allow for unlimited innovation without affecting
> >> interoperability, unlike the other options you have mentioned.
> >> 
> >> Thanks,
> >> Vishwas
> >> 
> >> 
> >> On 10/1/08, Shahram Davari <[e-mail]> wrote:
> >>> Hi Mathew,
> >>> 
> >>> I support option 2, since a terminating node that doesn't
> >> understand the
> >>> VCCV channel type can always drop it. This would allow more
> >> innovation and
> >>> faster time to market.
> >>> 
> >>> Best regards,
> >>> Shahram
> >>> 
> >>> 
> >>> -----Original Message-----
> >>> From: [e-mail] [mailto:[e-mail]]
> >> On Behalf Of
> >>> BOCCI Matthew
> >>> Sent: September-30-08 12:23 PM
> >>> To: [e-mail]; [e-mail]; [e-mail]; 
> [e-mail];
> >>> [e-mail]
> >>> Subject: [PWE3] FW: Changes to PW ACH Channel Type 
> allocation policy
> >>> 
> >>> The PWE3 chairs would like feedback on proposed changes to the
> >>> allocation policy for the PW ACH codepoint registry. 
> Please see the
> >>> email below, and provide any feedback copying the PWE3 list.
> >>> 
> >>> Best regards
> >>> 
> >>> Matthew
> >>> 
> >>> -----Original Message-----
> >>> From: [e-mail] [mailto:[e-mail]]
> >> On Behalf Of
> >>> BOCCI Matthew
> >>> Sent: 25 September 2008 16:36
> >>> To: [e-mail]
> >>> Subject: [PWE3] Changes to PW ACH Channel Type allocation policy
> >>> 
> >>> 
> >>> 
> >>> The current IANA allocation policy for the PW associated
> >> channel type
> >>> registry is by IETF consensus. This policy was chosen in
> >> RFC 4385 based
> >>> on WG consensus that since the associated channel exists 
> in the data
> >>> path, and VCCV packets are typically processed by the
> >> control processor
> >>> on many PEs, it was prudent for the IETF to maintain strict
> >> control over
> >>> what types of channels were allocated and to ensure that
> >> they complied
> >>> to the PWE3 architecture.
> >>> 
> >>> However, a need has been identified to provide a more
> >> flexible approach
> >>> to allocating code points for VCCV channel types. This has
> >> partly arisen
> >>> from the MPLS-TP work, where MPLS would be deployed in a transport
> >>> network and where a much wider range of applications for the PW
> >>> associated channel is envisioned, and partialy from a
> >> desire to extend
> >>> the OAM capabilities for regular MPLS. We can support MPLS-TP and
> >>> general MPLS apps with the current policy which requires standards
> >>> action.
> >>> 
> >>> However we are receiving requests to allow proprietary OAM
> >> and signaling
> >>> protocols to be used in transport applications, and need to
> >> decide on
> >>> the best way forward. We considered providing extension mechanisms
> >>> within the standards track protocols, but believe that 
> the standards
> >>> track protocols would be much cleaner if the proprietary
> >> protocols ran
> >>> on their own ACH code points.
> >>> 
> >>> Note that we are talking about vendor protocols here. Other
> >> SDOs would
> >>> be required to publish an RFC and would only be allocated
> >> an ACH through
> >>> Standards Action.
> >>> 
> >>> There are two ways to address the requests for proprietary
> >> protocol ACH
> >>> code points:
> >>> 
> >>> 1) Allow a range of the associated channel type registry to
> >> be allocated
> >>> through expert review. Guidelines would be provided for the expert
> >>> reviewer to guide them in assessing the request, which
> >> would have to be
> >>> made in the form of an internet draft, while making sure that the
> >>> request is dealt with in a timely and fair manner. This 
> policy would
> >>> include hurdles with regard to security, congestion etc
> >> that would be
> >>> derived from those specified in the VCCV design.
> >>> 
> >>> 2) Allow a range of the associated channel type registry to
> >> be allocated
> >>> on a first-come-first-served basis. This does not provide
> >> the level of
> >>> control that expert review provides, but this is balanced
> >> to some degree
> >>> by the fact that the VCCV channel type is indicated in the
> >> data path,
> >>> and so a PE can choose to discard or rate limit VCCV packets on an
> >>> unrecognised associated channel.
> >>> 
> >>> Any change to the ACH allocation policy would be outlined
> >> in the GE-ACH
> >>> draft, which would update RFC 4385.
> >>> 
> >>> We would appreciate feedback on the list as to which 
> approach the WG
> >>> prefers.
> >>> 
> >>> Regards,
> >>> 
> >>> Stewart and Matthew
> >>> 
> >>> _______________________________________________
> >>> pwe3 mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/pwe3
> >>> _______________________________________________
> >>> pwe3 mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/pwe3
> >>> 
> >>> 
> >>> 
> >>> _______________________________________________
> >>> pwe3 mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/pwe3
> >>> 
> >> _______________________________________________
> >> mpls-tp mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/mpls-tp
> >> 
> 
>