Re: [Idr] draft-walton-bgp-add-paths-06.txt as IDR WG document

> This makes parsing extremely difficult. Reception of the capability
> from a peer is the only indication that the UPDATE parsing needs
> to retrieve the first four octets as path-id and the prefix
> follows after that. How would you differentiate an UPDATE message
> where prefixes are encoded with path-id vs. another where they
> aren't?	

Correct.

> If a speaker is able to send only one path and has advertised
> add-path capability, there are simpler ways to encode a (dummy)
> path-id, like always encode 0 or 1 or whatever...

It will be worth adding some text in the draft along the above line. 

Cheers,
Rajiv

> -----Original Message-----
> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of
> Pradosh Mohapatra (pmohapat)
> Sent: Tuesday, November 25, 2008 10:58 AM
> To: Danny McPherson; Yakov Rekhter
> Cc: idr@ietf.org
> Subject: Re: [Idr] draft-walton-bgp-add-paths-06.txt as IDR WG
document
> 
> | ---
> | While Path Identifier assignment is purely a local matter,
> | for operational reasons I believe that a receiving BGP
> | speaker SHOULD (MUST?) preserve any Path Identifier for an
> | associated path on receipt.  This will aid in operational debugging.
> 
> Right. It MUST preserve the path-id that it received in the path
> structure since the id would be used for replacing any new
> advertisement received for that path or removing the path upon
> withdrawl.
> 
> | ---
> | I wonder if it's necessary to state handling procedures in
> | S.6 of receipt of an update message that does not use
> | extended NLRI encoding from a peer that advertised they
> | support receive processing of the capability?  For example,
> | if an implementation wanted to optimize in some manner where
> | if only one path exists then don't use the the extended NLRI
> | encoding, because you could never pack updates, etc..
> |
> | Perhaps receipt of an update for a prefix that does not use
> | extended ecoding from a peer that advertised the capability
> | should be handled normally, and not considered or generate an
> | error condition?
> 
> This makes parsing extremely difficult. Reception of the capability
> from a peer is the only indication that the UPDATE parsing needs
> to retrieve the first four octets as path-id and the prefix
> follows after that. How would you differentiate an UPDATE message
> where prefixes are encoded with path-id vs. another where they
> aren't?	
> 
> If a speaker is able to send only one path and has advertised
> add-path capability, there are simpler ways to encode a (dummy)
> path-id, like always encode 0 or 1 or whatever...
> 
> - Pradosh
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr