Re: [mpls] RFC6378

Hi,
I believe that I addressed most of your questions in an earlier thread.

1. Basically 1:n is covered in a separate draft that is being advanced in
the group (see draft-ezy-mpls-1ton...)

2. Values for the timers should hopefully appear in either the MIB or a
future ITU document

3. Do not understand connection between PT field and different topologies

4. RFC5654 states that ET is frowned upon

5. The IETF does not comment on the status of ITU documents (I personally
got into hot-water on a previous occasion)

6. The mpls-tp mailing list is defunct, I no longer work at NSN therefore
direct mail to my gmail address

Hope this helps more than my previous attempt,
yaacov weingarten
On May 23, 2012 2:46 PM, "Lingaraj Mishra" <lmishra.ietf@yahoo.ca> wrote:

>
>  Hello MPLS-TP Protection Authors,
>
> My questions are far more simpler than already asked at archived thread.
>
> We are on verge of implementing MPLS-TP on our product.
> And there goes some questions about LINEAR protection scenario.
>
> 1 - The RFC6378 does not discuss anything about topology of LINEAR
> protection i.e 1:n. It should give different pictures of possible LINEAR
> topologies where protection can be applied. If we follow T-MPLS which is
> REJECTED now, it has more clear pictures of how LINEAR network
> topologies like 1+1, 1:1 and 1:n. As you can see, there is no other network
> topology being standardized yet and complete AGGREGATION or CORE network
> topology can not be contained in just LINEAR, we will fall back to native
> MPLS protection mechanisms (facility bypass, detour) in those
> scenarios.  But, I think we are still missing something here i.e. SNC
> protectection etc.
>
> 2 - What are the values of WTR and hold-off timer? This values are
> normally constant in TRANSPORT world. The hold-on and hold-off values are
> are defined by G.707 or GR-253 for same. Are there any standard values for
> MPLS based defects?
>
> 3 - Why value of PT(Protection Type) is already fixed ? Are we planning
> again new format for RING topology? The RING topology in TRANSPORT world is
> always 1+1 and Bi-directional.
>
> 4 - There is no such provision for ET(Extra Traffic) in case of 1:1
> scenario. I think we can include same here not to under-utilize protection
> PATH.
>
> 5 - Please confirm that current status of T-MPLS G.8131 stands as
> rejected. RFC6378 hold all rights for MPLS-TP v1.0.
>
> I will be waiting for an early reply on this.
> Thanks for your help.
>
> Regards,
> Lingaraj
>
>
>
>
>
>
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>