Hi,

I'd go further and suggest that we should recommend bidirectional LSPs as the 
preferred approach, regardless of composite links.

Tony


On Jan 30, 2011, at 6:07 PM, Bhatia, Manav (Manav) wrote:

> Hi Lizhong,
>  
> As a result of this discussion the RTGWG will add another requirement where 
> the solution should be able to indicate to a composite link that both the 
> directions of a bidirectional LSP must be bound to the same component link.
>  
> This is indeed what we want for 1588. We will also include a pointer to this 
> in the next revision.
>  
> Cheers, Manav
>  
> From: [email protected] [mailto:[email protected]] 
> Sent: Monday, January 31, 2011 6.10 AM
> To: Bhatia, Manav (Manav)
> Cc: [email protected]
> Subject: RE: [TICTOC] Transporting PTP messages (1588) over MPLS Networks
> 
> 
> Hi Manav, 
> I see the discussion at RTGWG, it is good. 
> Share within TICTOC: 
> http://www.ietf.org/mail-archive/web/rtgwg/current/msg03181.html 
> 
> Thanks 
> Lizhong 
>   
> 
> "Bhatia, Manav (Manav)" <[email protected]> wrote on 2011-01-28 
> 08:09:50:
> 
> > Lizhong,
> >  
> > > [Lizhong] I mean the LAG between two end-points, 
> > > not MC-LAG. E.g, one LAG interface with physical link 
> > > A & B between two end-points, it is possible that the forward 
> > > path will go through A, and backward path will go through B, 
> > > then the physical path is not symmetric. If I understand correctly, 
> > > you just assume the transport delay on link A & B are the 
> > 
> > On an ordinary lag, unless it's a MC-LAG this can be assumed to be 
> > more or less the same.
> > 
> > > same, but this is not always true, especially for the composite 
> > > link defined in RTGWG (draft-ietf-rtgwg-cl-requirement). 
> > 
> > I quickly glanced through this draft and these can imo be easily 
> > avoided by defining a new link type - Composite link, in the link 
> > type sub-TLV of Link TLV in OSPF [RFC3630]. Such links MUST be 
> > avoided for setting up the PTP LSPs. Similarly the extended IS 
> > reachability TLV could be extended for IS-IS to avoid composite links.
> > 
> > One could also use coloring to avoid these links, but this would 
> > entail manual configuration which may not be desirable.
> > 
> > Cheers, Manav
> > 
> 
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is 
> solely property of the sender's organization. This mail communication is 
> confidential. Recipients named above are obligated to maintain secrecy and 
> are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended 
> solely for the use of the individual or entity to whom they are addressed. If 
> you have received this email in error please notify the originator of the 
> message. Any views expressed in this message are those of the individual 
> sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
> 
> _______________________________________________
> TICTOC mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/tictoc

_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc

Reply via email to