[mpls] RE: draft-ali-mpls-rsvp-te-no-php-oob-mapping-01.txt

Adrian- 

Sorry for the delayed response. 

This is an excellent comment. While we can (try) to mandate label
recording for non-php behavior, there is no procedure other than use of
LSP Attributes subobject in the RRO (as suggested by you) to make
Ingress aware. In which case it's better to rely on LSP Attributes
subobject in the RRO for both attributes. 

In draft-ietf version 01 of this document, we will incorporate your
comment. 

Thanks again for your profound comment, as usual. 

Regards... Zafar  

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk] 
> Sent: Sunday, July 29, 2007 6:48 AM
> To: mpls@lists.ietf.org
> Cc: Zafar Ali (zali); George Swallow (swallow); Rahul Aggarwal
> Subject: draft-ali-mpls-rsvp-te-no-php-oob-mapping-01.txt
> 
> Hi,
> 
> I have added the two LSP_ATTRIBUTES bit reservations to the 
> temporary registry at www.olddog.co.uk/ccamp.htm
> 
> I think that your mechanism for signaling these requirements 
> is fine, but you have a problem with egress nodes that do not 
> recognise the bits or the whole object.
> 
> While you can check for the Null label in the PHP case if 
> label recording is in use, this is by no means fool-proof. 
> You have no mechanism to check for the OOB case.
> 
> Can I suggest that you use the LSP Attributes subobject in 
> the RRO to provide the information you require. The absence 
> of this object, or the presence with the bit clear, will 
> indicate that the egress has not complied with the request.
> 
> Thanks,
> Adrian 
> 

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls