Re: [Teas] A basic question on draft-ietf-teas-rsvp-egress-protection

Hi Lou,

    One way to re-use and extend SERO is briefed as follows:
    1) The format of the SERO defined in RFC 4873 is re-used. A SERO containing three subobjects for protecting a primary egress node of an LSP in the Path messages is sent from the ingress node of the LSP to the upstream node of the egress node. The first subobject contains the address of the upstream node of the egress node. The final (third) subobject contains the address of the backup egress node. The second subobject is a protection subobject defined in RFC 4873, but with some extensions, which include a few of flags for the egress local protection and some optional subobjects. These new flags can use a few of bits in the existing reserved field. The optional subobjects follow the flags field. Note that the protection subobject in the SERO in the Path message does not contain any optional subobjects.
    2) After the upstream node of the primary egress node receives the SERO, it creates a backup LSP from itself to the backup egress node for protecting the primary egress node. The path for the backup LSP is computed and created according to the information in the FRR object in the Path message. For example, if facility protection is desired, facility protection is provided for the primary egress node.
    3) The upstream node constructs a PROTECTION object based on the protection subobject in the SERO and puts the object into the Path message for the backup LSP. The PROTECTION object is extended in the same way as the protection subobject. The PROTECTION object in the Path message for the backup LSP contains a subobject called a primary egress node subobject, which indicates the address of the primary egress node. 
    4) The upstream node also constructs a PROTECTION object based on the protection subobject in the SERO and puts the object into the Path message for the primary LSP to be sent to the primary egress node. The PROTECTION object in the Path message for the primary LSP contains a subobject called a P2P LSP ID subobject, which contains the information for identifying the backup LSP, which includes the address of the backup egress node.

    I should appreciate your comments and suggestions on this approach.

Best Regards,
Huaimo
-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net] 
Sent: Monday, March 14, 2016 11:24 AM
To: Huaimo Chen; draft-ietf-teas-rsvp-egress-protection@ietf.org; TEAS WG
Subject: Re: [Teas] A basic question on draft-ietf-teas-rsvp-egress-protection

Huaimo,
> I will consider this in more details.

Thanks!

Lou

On 3/13/2016 10:51 PM, Huaimo Chen wrote:
> Hi Lou,
>
>     Thank you very much for your further comments.
>     My answers/explanations are inline.
>
> Best Regards,
> Huaimo
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net] 
> Sent: Sunday, February 21, 2016 7:35 AM
> To: Huaimo Chen; draft-ietf-teas-rsvp-egress-protection@ietf.org; TEAS WG
> Subject: Re: [Teas] A basic question on draft-ietf-teas-rsvp-egress-protection
>
> Huaimo,
> 	See below.
>
> On 02/20/2016 05:15 PM, Huaimo Chen wrote:
>> Hi Lou,
>>
>>  
>>
>> Thanks much for your comments.
>>
>> My answer/explanation is inline below.
>>
>>  
>>
>> Best Regards,
>>
>> Huaimo
>>
>> -----Original Message-----
>> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger
>> Sent: Wednesday, January 27, 2016 9:09 AM
>> To: draft-ietf-teas-rsvp-egress-protection@ietf.org; TEAS WG
>> Subject: [Teas] A basic question on 
>> draft-ietf-teas-rsvp-egress-protection
>>
>>  
>>
>> Hi,
>>
>>     I have a question on draft-ietf-teas-rsvp-egress-protection that 
>> is
>>
>> prompted by today's interim and can be covered there and/or on list:
>>
>>  
>>
>> Given that the draft says:
>>
>>>    The egress local protection may be generalized and used with the
>>>    segment protection defined in RFC 4873
>> <https://tools.ietf.org/html/rfc4873>.  How it is generalized and
>>
>>>    used is out of scope for this document.
>>  
>>
>> Why define a new set of formats and mechanisms when an existing set of
>>
>> formats and mechanisms can be used or adapted to (a) provide the same
>>
>> function and (b) do so in a more general way?
>>
>>  
>>
>> [Huaimo] RFC 4873 defines a segment protection, which provides a 
>> protection against a failure in a segment of an LSP. However, this 
>> segment protection can not be used or re-used to provide a protection 
>> against a failure in the egress of the LSP.
>
>> For a segment from a node B
>> to the egress E of the LSP, node B creates a backup LSP to egress E, 
>> and switches the traffic to the backup LSP when detecting a failure in 
>> the segment except for a failure in egress E. When egress E fails, the 
>> backup LSP will fail, thus no protection is provided by the segment 
>> protection against egress failure.
> I'm sorry I just don't follow your argument here. Are you saying a protected segment with a merge node which is also the egress doesn't protect against egress failure?  If so, then yes - sure.  If not, perhaps you can rephrase to state the point directly before jumping into an example?
>
> [Huaimo]: Yes. 
>
>> To provide egress local (or fast)
>> protection, the segment protection needs to be generalized/enhanced.
> Right. So my basic question is why not reuse/build on this existing mechanism?
>
> For example why not just define egress protection to use an SERO with a final subobject that is the secondary egress?
>
> [Huaimo]: The SERO can be re-used for the egress protection. The final subobject in the SERO can be used to indicate the secondary/backup egress as you suggested. The advantage of re-usng the SERO is that we do not need to define a new object. But the some semantics of the SERO will be changed when it is used for the egress protection. The protection subobject will be changed or extended to include the information for the egress protection.
>
> I will consider this in more details.
>
> Lou
>
>>  
>>
>> I look forward to hearing/discussing the rational for not not reusing
>>
>> what we already have defined.
>>
>>  
>>
>> Thanks,
>>
>> Lou
>>
>>  
>>
>>  
>>
>> _______________________________________________
>>
>> Teas mailing list
>>
>> Teas@ietf.org
>>
>> https://www.ietf.org/mailman/listinfo/teas
>>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>