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

[Lou Berger <[e-mail]>]

Huaimo,

On 3/15/2016 9:16 PM, Huaimo Chen wrote:
> 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.

This seems like a reasonable start to an SERO-based approach, which
leverages previously defined mechanisms -- a good thing.  I think the
next step is to document it to a sufficient level of detail that WG
input can be solicited.

of course others may wish to comment too.

Thanks,
Lou

> Best Regards,
> Huaimo
...